Skip to content

Feed aggregator

Why Agile Is Failing in Large Enterprises, And What You Can Do About It

Leading Agile - Mike Cottmeyer - Mon, 07/28/2014 - 17:13

Here is the deck from my Agile2014 talk on why many folks are struggling to adopt agile in larger, more complex enterprises. The presentation explores many themes persistent on this blog. Why agile works, why agile fails, what gets in the way, and how to systematically and pragmatically begin to refactor your legacy organization into an effective agile enterprise? If you came to the talk, I appreciate it. If you have any questions, please let us know. Thanks!

Why Agile Is Failing in Large Enterprises, And What You Can Do About It from Mike Cottmeyer

The post Why Agile Is Failing in Large Enterprises, And What You Can Do About It appeared first on LeadingAgile.

Categories: Blogs

Montreal Agile Game Development Courses, September 17th - 19th

Agile Game Development - Mon, 07/28/2014 - 16:03
I'm teaching two public courses on agile game development in Montreal this September:

Certified ScrumMaster for Video Game Development

Kanban for Video Game Development


Categories: Blogs

Performance appraisals without a number!

Growing Agile - Mon, 07/28/2014 - 15:00

Below are my slides for my Agile 2014 talk: Agile Performance Appraisals without a number. If you missed the session is was recorded, so the video should be available on the Agile Alliance site in a few weeks.

Categories: Companies

At Agile2014 in Orlando. Good to be back!

TestDriven.com - Mon, 07/28/2014 - 14:37
The last time I attended the Agile Conference was in 2008 when I presented a workshop on Build/Test Grids and Selective Testing. I am happy that in the last few years there has been a lot of development in this space. For example, Solano Labs has a compelling offering that works both as SaaS and […]
Categories: Communities

The 4-Step Action Plan for Agile Health: Step 2. Understand how to adopt healthy Agile Mindset Practices and Lean Practices

Agile Management Blog - VersionOne - Sun, 07/27/2014 - 17:01

Agile development requires a cross-functional, self-organized team to deliver potentially shippable software at the end of each sprint, with analysis, design, code developing and testing activities going on concurrently (not sequentially) within each sprint.      Combining Agile/Scrum development with some of the lean methods is also becoming popular (so-called “Scrumban” methods). These methods emphasize reducing Work In Process (WIP), reducing feature cycle time and increasing throughput (feature completion rate).

In my blog on From Agile Pathologies to Agile Health I explained that some “agile” teams suffer from the following common pathologies, i.e., major dysfunctions in practicing agile methods, while claiming that they are “doing agile”:

  1. Agile development “sprints” assigned to software development lifecycle phases
  2. Agile development “sprints” assigned to technology tiers
  3. Mini-Waterfall inside sprints
  4. Water-Scrum-Fall

While an agile team may not be exhibiting gross dysfunctions (pathologies) listed above, it may still behave in harmful or unhealthy ways that would prevent it from realizing the benefits of agile development, such as higher productivity, throughput and quality.    Absence of major pathologies or sickness doesn’t imply health; agile teams may still not be healthy due to one or more harmful behaviors.

In this 4-part blog series, I focus on 6 harmful behaviors exhibited by agile teams and how to move away from them, and transition to 6 healthy agile-lean practices in order to get more benefits (improved productivity, throughput and quality).  I also present 4 specific steps to transition to healthy agile-lean practices.   Table 1 summarizes these 4 steps, and labels 6 harmful behaviors (as 1B through 6B) and 6 healthy agile-lean practices (as 1P through 6P) for ease of cross-referencing. Table 1 also indicates what is covered in each of the 4 parts of the blog series: Part 1 (highlighted in light green color) was completed.    In this Part 2 (highlighted in pink color in Table 1), Step 1 – understand healthy “Agile Mindset” practices (1P and 2P) and 2 lean practices (3P and 4P) – is described.  Parts 3 and 4 will be presented in the future.

Table 1: The 4-Step Action Plan for Agile Health

R_Part2_Table1

“Agile Mindset” practices to improve agile health:  I now explain and recommend 2 specific practices to embrace an “agile mindset.”   I typify an agile team B that consists of a business analyst, 3 full-time developers, 2 full-time QA testers, a Product Owner and a ScrumMaster.   All members of Team B are full-time, dedicated members unlike the Struggling Agile Team of Part 1 of this blog series which had part-time, multiplexed members.   As Team B follows all 6 healthy agile-lean practices (1P to 6P) listed in Table 1, it is our prototypical “Healthy Agile Team”.

I use a similar example of a typical 4-week (20 workdays) sprint for the Healthy Agile Team.   Figure 1 illustrates the Sprint History Map of this 4-week sprint after the sprint is over.   It uses the same format and legend as used in in the Sprint History Map of the Struggling Agile Team (see Figure 1 of Part 1). Each feature was broken down into its implementation tasks either during sprint planning or actual sprint execution.  These tasks are indicated in the legend at the bottom of Figure 1.

R_Part2_Figure1

Figure 1: Sprint History Map of the Healthy Agile Team following the
Agile Mindset Practices

The 2 “Agile Mindset” practices (numbered 1P and 2P below) require replacing the legacy mindset with agile mindset, moving away from silo thinking, welcoming the change necessary for successful agile adoption and implementing the required change to get the benefits of higher productivity, throughput and quality.

1P. Full-time, dedicated agile team members without multiplexing and with minimal multitasking: Move away from the old mindset that treats people as resources whose utilization needs to be maximized via multiplexing and multitasking.   It is much more important that you maximize agile team throughput than worry about utilization of each team member as a resource.

Assign agile team members to work full time (100%) on a single agile team through all sprints of at least one release cycle.  You need at least a full release cycles (4 to 6 sprints) for team members to understand each other’s strengths and weaknesses, develop a (hopefully smooth) working relationship, and jell together as a team.  These well-jelled team members show higher productivity as they learn how to capitalize on each member’s strengths and compensate for weaknesses.  They learn to work with each other as human beings, and not replaceable resources.  This often requires a significant buy-in from management, if it is steeply rooted in traditional project management practices.

Cultivate the habit of doing focused work – one task at a time – starting with 30 minutes of uninterrupted work on a single task, and gradually extending it up to two hours.  Then you will need a well-deserved 5-minute break due to intellectual fatigue.  See The Energy Project: http://theenergyproject.com/  to understand how to conserve your energy to work in a highly focused way on single task at a time. Each team member learns to focus on a single task at a time (up to 2 hours in a stretch) until the task is over, before switching to other tasks.

Avoid multiplexing and minimize multitasking.  It increases productivity by avoiding wasteful context switching, and making each team member committed to and accountable for the success of a single team.  There are no divided loyalties of a person among different teams and projects.  That simply doesn’t work well.

2P. Cross-Functional Team Members: An agile team is composed of cross-functional team members: Train, cultivate and invest in each member to become a “Master of One and Jack of Two”.   Each member has primary expertise or mastery in at least one area, and working level skills in two other areas.  From time to time, each person is needed to work in areas outside his/her own mastery.  For example, a developer tests features developed by other developers, or a tester develops scripts for automated tests, etc.   See: http://bit.ly/1lkaXHc.

Investing in team members to become “Master of One and Jack of Two” may require a significant buy-in from functional or departmental managers.   Team members don’t just do their own tasks that match with their primary expertise or interest.  They swarm as a team to deliver working features within each sprint. Each feature is worked on by a logical feature team swarming to complete the feature in the shortest cycle time.  See: http://bit.ly/1rhtV6g.  Although the Sprint History Map for the Healthy Agile Team (Figure 1) shows swarming feature teams only for Feature 1 and 2 for brevity, they exist for all 8 features in the backlog.  These feature teams are “logical” teams in the sense that they may share one or more individual team members.

How to adopt two lean practices:  These 2 lean practices (labeled 3P and 4P in the list of 6 healthy agile-lean practices of Table 1) are described below.

3P. Stop-Starting-Start-Finishing and work under WIP limit: Form swarming features teams within an agile team to focus attention on getting each feature accepted by the Product Owner as soon as possible.  Without completing a feature or a task already in progress, resist the temptation to start working on a new feature or a new task.  Stop starting new things (features or tasks) before completing the things you have already started.  This is a good mantra for life too.   This practice will effectively allow a lower WIP limit in an informal way.

As explained by David Anderson in his book “Kanban: Successful Evolutionary Change to your Technology Business,” 2010, page 114, the WIP limit needs to be set up as 2 to 3 people per feature plus 2 to 3 to smoothen the impact of a blockage.   For an Agile team of 7 full-time, dedicated team members, the WIP limit can be set up as 3 + 2 = 5.   You will need to experiment with this number and adjust it empirically up or down based on the experimental results.  Progressively lowering WIP limits will bring out bottlenecks that need to be resolved.  Agile Lifecycle Management tools, such as VersionOne, help you visualize the Kanban workflow under WIP limits, and provide warnings if WIP limits are exceeded.  Learn how to work with smaller WIP limits.

As shown in the Sprint History Map (Figure 1), the WIPs on Day 2 through 17 (total 16 days) for 7 completed features (Feature 1 through 7) in the sprint are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 2, 2, 1, 1, with the average WIP = (46/16) = 2.875.    The WIPs on Day 2 through 17 (total 16 days) for all 8 features are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 3, 3, 2, 2, with the average WIP = (50/16) = 3.13, which is only slightly more than the WIP of 46/16 = 3.13 for 7 completed features.  The Healthy Agile Team has its focus on completing the work in progress before starting the new work by following the Stop-Starting-Start-Finishing mantra which reduces WIP.   The Healthy Agile Team has a smaller WIP compared to that of the Struggling Agile Team illustrated in its Sprint History Map (see Figure 1 in Part 1, and the WIP data for the harmful behavior 3B in Part 1).

4P. Focus on minimization of cycle time: Improve team’s throughput (features completion rate) with cross-functional team members, eliminate NT events by avoiding multiplexing and multitasking, and use of proper test automation tools (see Part 3 of this blog series).

Reducing WIP reduces the cycle time.    As shown in the Sprint History Map (Figure 1), the cycle times for the 7 completed features (Features 1 through 7) are 6, 8, 5, 7, 7, 8, 5 days, with an average cycle time of (46/7) = 6.57 days.   I will now use the well-known Little’s Law to calculate the average throughput (rate of feature completion and acceptance by product owner) of the Healthy Agile team.

Average Cycle Time = Average WIP / Average Throughput, or alternatively

Average Throughput = Average WIP / Average Cycle time

In the example of Healthy Agile Team, Average WIP = 46/16 (see Practice 4P above), and Average Cycle Time = 46/7 (as explained just above).

Therefore, Average Throughput = [(46/16) / (46/7)] = 7/16 features per day.

You may use the Sprint History Map (Figure 1) to visually verify that the Healthy Agile team has  delivered 7 accepted features (Features 1 through 7) in 16 actual work days of the sprint, confirming the average throughput of 7/16 features per day.  Sprint History Maps provide visual data for WIPs and Cycle Times, and visual verification of Little’s law.

The higher throughput of 7/16 features per day for the Healthy Agile Team (compared to the Struggling Agile Team’s throughput of 4/18 features per day) can be attributed to the facts that the team has moved away from harmful behaviors:  it has no NT events and substantially reduced number of  impediments (IMP events); it avoided multiplexing and minimized multitasking, gotten away from the silo mindset,  is practicing Stop-Starting-Start-Finishing lean mantra, has reduced long cycle times (average cycle time of only 6.57 days in a 16-workday sprint), and is practicing automated testing (as explained in Part 3 of this blog series).

Little’s Law is a powerful and versatile tool.  A change in any one of its parameters (WIP, Cycle Time and Throughput) is most likely to effect a change in one or both of the other two parameters.  You can reduce cycle time by reducing WIP while holding throughput constant.  Or you may increase throughput by decreasing cycle time as we have just seen.  There is a third option: a team may increase the average WIP (more work in parallel) and thereby increase the throughput, provided that the team can hold the average cycle time by increasing its intrinsic productivity by upgrading its skills via training and apprenticeship, getting more experienced members on the team, using various automation tools, increasing its design and code reuse, etc.   If any one of these 3 parameters needs to be corrected or improved, Little’s Law tells us exactly what to do to achieve the desired results.  Most of the time the goal is to increase throughput (without sacrificing quality) by reducing cycle time or by increasing team’s intrinsic productivity or both.   Bennet Vallet of Siemens Health Care presents a great case study of Kanban success providing the details of how to harness Little’s law to reduce the average cycle time, increase the average throughput and improve the release predictability.

Lean methods provide us additional options to reduce the cycle time, and thereby, increase the throughput.  Splitting large features into smaller features (they still must deliver value to customers) reduces the average cycle time.   How small should these features be?   Larman and Vodde suggest that for an N-week long sprint, each feature should take no more than N/4 staff-week of total effort (Reference: “Scaling Lean and Agile Development” by Larman & Vodde, 2009, page 120).  For the 4-week example sprint used in this blog series, it would be ideal if each feature takes no more than 4/4 = 1 staff-week or 40 staff-hours (or less) of total effort.  For a 2-week sprint, each feature should take no more than ½ staff-week or 20 staff-hours of total effort.

Furthermore, leveling the workload, i.e., having all features of roughly the same size also reduces the average cycle time.  Uneven sized sprint workload (small features intermixed with medium and large features in a sprint backlog) increases the average cycle time.

As shown in the Sprint History Map (Figure 1), the Healthy Agile Team has swarming feature teams; each feature team is working on multiple tasks of a feature concurrently.  For example, in the Sprint History Map (Figure 1), Software Design task (D) and Acceptance Test Development task (TD) were going on concurrently on Day 2, Code development task (C) and Acceptance Test Case execution task (TE) were going on concurrently on Day 4.  This swarming action also reduces the cycle time due to intense collaboration among the feature team members, their focus on completing the feature and getting it accepted as fast as possible.

Sprint pipeline: Learn and apply the Sprint pipeline practice where feature analysis and UI design work is done one timebox ahead of software design, coding, testing, defect fixing, acceptance testing.   This effectively allows two successive timeboxes for each sprint, but without adversely impacting throughput (it still produces working software at the end of each sprint).   With sprint pipeline, feature specification and UI design is in much better shape when a sprint starts, compared to trying to squeeze all work for a feature in a single time box where analysis or UI design may become bottlenecks.   In the Sprint History Map (Figure 1), there are no “A: Analysis” tasks at all, because the Healthy Agile Team is following the sprint pipeline well. 

Is your team facing the challenge of moving away from harmful “legacy mindset” and “non-lean” behaviors, and is interested in transitioning to the healthy “agile mindset” and lean practices?  I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

Part 1: Understand harmful legacy Mindset and Non-Lean behaviors to move away from

Part 3: Understand how to use additional enablers of Agile Health

Stay tuned for the 4th and the last part of the blog series.

Part 4: Develop and implement your customized plan for adopting healthy agile-lean practices

Categories: Companies

The Right Way to Do Scrum, but ...

NetObjectives - Sun, 07/27/2014 - 13:02
We Do Scrum-But I often hear people say “oh, we do Scrum but we don’t do …”.  This includes “we do Scrum, but we don’t have fully cross-functional teams.”  Or, “we do Scrum but management interrupts us all of the time with needed new functionality.” With the creation (and misunderstanding) of Kanban, we often hear “we do Scrum but we don’t have hard iterations, we follow more of a flow model.”...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Need Admin Tools And Reports For Your SaaS? Build A Separate Site

Derick Bailey - new ThoughtStream - Sun, 07/27/2014 - 02:46

In the last year, I’ve used command line tools to run various reports for SignalLeaf. It’s worked out well, but I’ve outgrown the usefulness of these reports.

It’s not that the reports themselves are no longer useful – but the format in which they are displayed, and the limited interactivity of them. I need to do more than just get some read only data. I need to also drill in deeper and get more information from accounts, users, podcasts, etc.

Separate admin site

I Don’t Want A /admin Route

I’ve been hesitant to add in a “/admin” route on SignalLeaf for a lot of reasons. Then a few weeks ago, it suddenly dawned on me – I don’t need to add a “/admin” route set to the main app itself. I can build a separate admin app, and have it focused 100% on the administrative tools, reports and dashboards that I need.

So that’s what I did over the last week or two. I set up a new website, with it’s own authorization configuration, dedicated entirely to my needs for administrative tools. It’s working out really well for me, too. I don’t have to worry about polluting the core SignalLeaf app w/ administrative tools. I don’t have to worry about re-deploying the core system when I change the admin tools. I don’t even have to worry about the admin tools crashing, because I’m the only one that will ever use them. If the admin tools crash, who cares. They are on a separate site, and will not affect the core of SignalLeaf at all.

Build A Separate Admin App

If you’re looking at building an administrative section of your SaaS or web application, you might want to think about creating a completely separate application. It’s been a real breath of fresh air for me and SignalLeaf.

Of course, I needed a good authorization system to handle the admin site. I want something simple to require authorization for all routes on the site, and I wasn’t quite happy with the ones that I was finding. Far too many authentication systems in NodeJS land claim authorization as well, then don’t deliver. So I built my own authorization system – mustBe – but that’s another blog post to come soon.

     Related Stories 
Categories: Blogs

Jean Tabaka at Agile 2013 — Buckle Up and Press Play.

BigVisible Solutions :: An Agile Company - Sun, 07/27/2014 - 01:24

Jean sits down with Dave Prior at the end of day two at Agile 2013, the intent is to to talk about the maturation of agile, and enterprise agility from her (well respected) perspective, and what begins as a conversation around her conference sessions evolves into something so much more powerful, and impossible to summarize.

The post Jean Tabaka at Agile 2013 — Buckle Up and Press Play. appeared first on BigVisible Solutions.

Categories: Companies

Interview with Tim Lister, Keynote at Agile 2013 – Forty Years of Trying To Play Well With Others

BigVisible Solutions :: An Agile Company - Sun, 07/27/2014 - 01:23

Tim Lister, co-author of “Walzing with Bears”,”Adrenaline Junkies and Template Zombies”and “Peopleware” was one of the keynote presenters during Agile 2013. Tim’s talk “Forty Years of Trying to Play Well With Others” was a big hit. In this interview Tim shares some of the highlights of his talk, including his opportunity to work on one of the very first WANG computers

The post Interview with Tim Lister, Keynote at Agile 2013 – Forty Years of Trying To Play Well With Others appeared first on BigVisible Solutions.

Categories: Companies

An Awesome Conversation on Agile Coaching With Lyssa Adkins and Michael Spayd

BigVisible Solutions :: An Agile Company - Sun, 07/27/2014 - 01:22

At Agile 2013, Lyssa Adkins and Michael Spayd co-presented a session focused on helping coaches develop conflict facilitation skills. In this interview they discuss what makes agile coaches different than other types of coaches and some key ideas from their presentation.

The post An Awesome Conversation on Agile Coaching With Lyssa Adkins and Michael Spayd appeared first on BigVisible Solutions.

Categories: Companies

Transformation Case Study Highlights

Agilitrix - Michael Sahota - Sun, 07/27/2014 - 00:44

I was fortunate to act as  a catalyst for a transformation of a 100 person departments. Here is an early release of a presentation summarizing my learnings.

Transformation Case Study Highlights from Michael Sahota

 

What I did (that made the difference)
  1. Uncover what’s really going on
  2. Share observations in a loving and caring way
  3. Help people choose their own reality and destiny

Related posts:

  1. The Business Case for an Authentic Workplace People are messy: they have personalities and emotions. In this...

Related posts brought to you by Yet Another Related Posts Plugin.

Categories: Blogs

The Good, The Bad and the Ugly of Scrum: Or Telling The Emperor He Has No Clothes

NetObjectives - Sat, 07/26/2014 - 22:28
I am about to head off to the Agile Conference in Orlando.  At these times I always think about the state of Agile and am usually disappointed when I think about what is possible and what actually is present.  Oh, I don’t mean “if only the industry would do what works” kind of thoughts, I’m more thinking “if only consultants would recognize what works and what doesn’t.”  I just started working...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

LAST (Lean Agile Systems Thinking) 2014 Conference

Agile World - Venkatesh Krishnamurthy - Sat, 07/26/2014 - 19:26

image Last week I had the pleasure of speaking  at the LAST 2014 (Lean Agile Systems Thinking) conference. This is my second consecutive year of having opportunity to speak at this popular Melbournian event.I  have seen this event growing year after year. First year, we had 150 attendees, the second year 350 and third year is even more successful with 450 people. The event is highly affordable and run by the Melbourne community.  Some call this conference as  “Meet up on Steroids”. 

The two passionate people who are successfully managing this event are Craig Brown  and Ed Wong.  Organizing such a large scale event managing speakers, schedule, events and sponsors is not a simple thing. The event was such a smooth one, didn’t realize that the day had already passed.

This is a classic example of power of passion and network in the community.  You don’t need many people to make a positive difference to the society, you just need one or two passionate givers.

The session was organized by  TABAR 

I spoke about  10 Irrefutable laws of Agile Coaching.  The presentation slides are available on Slideshare as well. Feel free to download/share.  

My intent for sharing these ideas was to encourage Agile coaches to think beyond  Scrum, Lean, XP, etc.   Agile coaching involves a broader systems knowledge to succeed.

More details about my session:  Agile coaching is one of sought after skills in the IT industry and many experienced coaches are doing extremely well. However some change agents are struggling to make an impact, not because, they don't know Agile but because, they don't know some ground rules dealing with the coaching teams and leaders.

Whether you are a novice or an experienced coach, there are irrefutable laws governing Agile coaches. Based on my own personal experiences coaching teams/leaders since the last several years, I have come to realize the 10 secrets. Irrespective of where you are in the journey as an Agile coach, practicing these 10 laws will help you to become a successful Agile coach. These handy rules can help you anywhere in Agile coaching journey.

Categories: Blogs

Fearless Speaking

J.D. Meier's Blog - Sat, 07/26/2014 - 18:58

“Do one thing every day that scares you.” ― Eleanor Roosevelt

I did a deep dive book review.

This time, I reviewed Fearless Speaking.

The book is more than meets the eye.

It’s actually a wealth of personal development skills at your fingertips and it’s a powerful way to grow your personal leadership skills.

In fact, there are almost fifty exercises throughout the book.

Here’s an example of one of the techniques …

Spotlight Technique #1

When you’re overly nervous and anxious as a public speaker, you place yourself in a ‘third degree’ spotlight.  That’s the name for the harsh bright light police detectives use in days gone by to ‘sweat’ a suspect and elicit a confession.  An interrogation room was always otherwise dimly lit, so the source of light trained on the person (who was usually forced to sit in a hard straight backed chair) was unrelenting.

This spotlight is always harsh, hot, and uncomfortable – and the truth is, you voluntarily train it on yourself by believing your audience is unforgiving.  The larger the audience, the more likely you believe that to be true.

So here’s a technique to get out from under this hot spotlight that you’re imagining so vividly turn it around! Visualize swiveling the spotlight so it’s aimed at your audience instead of you.  After all, aren’t you supposed to illuminate your listeners? You don’t want to leave them in the dark, do you?

There’s no doubt that it’s cooler and much more comfortable when you’re out under that harsh light.  The added benefit is that now the light is shining on your listeners – without question the most important people in the room or auditorium!

I like that there are so many exercises and techniques to choose from.   Many of them don’t fit my style, but there were several that exposed me to new ways of thinking and new ideas to try.

And what’s especially great is knowing that these exercise come from professional actors and speakers – it’s like an insider’s guide at your fingertips.

My book review on Fearless Speaking includes a list of all the exercises, the chapters at a glance, key features from the book, and a few of my favorite highlights from the book (sort of like a movie trailer for the book.)

You Might Also Like

7 Habits of Highly Effective People at a Glance

347 Personal Effectiveness Articles to Help You Change Your Game

Effectiveness Blog Post Roundup

Categories: Blogs

An Open Letter to Executives Leading Agile Transformations

Agile Management Blog - VersionOne - Sat, 07/26/2014 - 17:00

Dear Executive,

Let me congratulate you on your decision to introduce agile methods within your organization. It is a wise decision that holds incredible potential for your employees, your company, and especially your customers. If you are just beginning your improvement, or are yet to begin, the journey upon which you are about to embark is one that will be well worth the effort. And it will take effort—long, arduous, and at times frustrating effort.

Although Machiavellians do exist, my experience is that they are exceedingly rare.  In general, people are good, honest, and hard-working and really want to do the right thing. We hold a desire to do our jobs well, be recognized for it, and make a difference in the world by being part of something larger than ourselves; to have a purpose at work, if you will. To this end, we will do what is necessary to get our work done in the manner that our environment best supports. Put more simply, we will take the path of least resistance and complexity. Your move toward agility may be more challenging than necessary if you don’t keep this in mind while traversing your path toward improvement.

Rather than simply introducing and mandating agile methods such as ScrumeXtreme Programming (XP), and/or Kanban, create an organizational environment where agility is the path of least resistance for your employees and colleagues to get their work done. Here is a ten-step plan of action to help you create that environment within your organization.

  1. Stop referring to the change as organizational and/or agile transformation. We’ve all heard and understand the cliché that “change is the only constant.” Using phrases like agile transformation can shoot fear of the unknown into the psyche of everyone as it screams massive change. A less scary word is improvement. We all like to improve. Start talking about improving delivery, increasing customer engagement, and enhancing responsiveness to new challenges.
  2. Restructure your organization to reduce emphasis on functional specialization.One of the factors strongly contributing to the slow responsiveness of waterfall is the typical hand-off of work as it passes from the hands of one functional group to another—Business Analysts for requirements to Architects for design, to Developers for build, etc. Create teams that are cross-functional and require little to no hand-off of work. If so desired, create Centers of Excellence (CoE) organized around professional career ladders but remove reporting ties to any functional manager in the CoE.
  3. Start demonstrating the behavior you desire in your organization. One of the most powerful ways to build momentum is to first change yourself and your behavior. You really can’t force change within others, but you can inspire it. It’s amazing the change you’ll see in others when you first seek to change yourself. Actively seek ways you can serve the teams within your organization. With genuine curiuosity, caring, and empathy ask them what gives them headaches in their jobs. Be the aspirin for these headaches and remove the obstacles that are getting in their way. You might also consider working cross-functionally as a leadership team. Break down functional silos by creating teams that consist of representatives from many departments such as sales, marketing, IT, support, etc. The gears in any machine only work if cogs make contact and work collectively.
  4. For technology projects, refuse to move forward on any project without business representation and team involvement. Be uncompromising about beginning any project that does not have business representation. I was recently asked what I thought was the one thing that, if it did not exist, you could not consider yourself to be agile. This is that one thing—business involvement. If it’s not important enough to warrant business involvement, it’s not important enough to work on. Thank you, Samar Elatta, for this reminder because it’s so obvious it can easily be overlooked.
  5. Completely drop discussions of “resource allocation” and speak only of “team availability”. Agile is a team sport. The focus needs to shift from individuals to teams. Instead of identifying individuals within a functional specialty and percentage of availability to do work seek out only complete teams with availability. Also, don’t begin work with incomplete teams. Have all of the requisite skill sets available so you can avoid slowing them down with the burden that’s created to bring a new team member up to speed on the project.
  6. Increase your delivery cadence. The ideal situation is to be able to deliver at any time (or all the time, as in continuous). Take incremental steps toward this goal by reducing the delivery window by at least half. If you’re on a semi-annual (6-month) delivery cycle reduce it to quarterly. If it’s annual, reduce it to semi-annual; quarterly, release every six weeks. This will automatically require teams to focus on smaller increments of work instead of looking at very long horizon delivery windows that only serve to increase estimating complexity and uncertainty about scope of delivery.
  7. Give high praise for “complete” features only. The only features that provide customer value are those that are complete. Almost done features may have future value potential but they have zero value right now. Consider work either done or not done. There is no credit for work that is not 100% complete. Define expectations very clearly for what is meant by “complete”.
  8. Recognize entire teams. The best way to support teamwork is to value and recognize teamwork, especially in a public setting. Praise entire teams and avoid the temptation to call out individuals on the team that did an excellent job. While it’s true that some of them may well have went above and beyond, it’s dangerous to the cohesiveness of the team if you praise an individual. If you must mention names, mention the names of all individual members of the team. Only the team (those on the frontline of value delivery) has the credibility to recognize individual team members for their efforts.
  9. Don’t mandate a methodology at the team level. Rather than requiring teams to do Scrum, or any other methodology framework, put the ingredients in place for agility such as those described in points 1-8 above, provide and demonstrate your personal support and commitment to the removal of organizational obstacles and dysfunction, and stand out of the way. These people are professionals, they are smart, and are very capable. If not, why are they working in your organization? They will do what’s required to get the results expected of them, sometimes regardless of whether those results are even realistic. This is autonomy and is one of the incubators of the only form of motivation that is effective, intrinsic.
  10. Invest in your workforce and your teams and they will invest in you. I do not tolerate tales of woe about organizations experiencing a lack of worker loyalty when those same organizations refuse to invest in their workforce. When times get tough and the C-suite is getting pressure to show near-term stock price growth, drastic measures are taken to reduce costs. Unfortunately, these short-term measures such as workforce reductions, slashing benefits, and cutting investment in training usually have a negative long-term effect. Make decisions that will positively impact the long-term value of both your stock price and your organization (boths its viability and people). If you’ve created an unsustainable cost structure that requires drastic measures, then you obviously need to take some drastic measures. If you and your management team created it, admit it because your people probably already know it. They have great “BS” meters and will see right through any attempt you or your leadership team make at masking it. Demonstrating humanity through vulnerability and admitting personal fault may feel terrible but it will increase your credibility in the eyes of your constituents by orders of magnitude. If you create an environment that inspires workers to give their all, run a company that gives to the community, and demonstrates that it values its workforce by investing in them, you and your organization will have a much greater chance of competing in the marketplace for a long time to come.

I opened this letter by expressing my belief that people are generally good, honest, and want to do the right thing. I close this letter by restating that this belief I hold has only been reinforced through my personal interaction with a diverse group of colleagues throughout many organizations spanning a long career. I would like to affirm that this belief also extends to you, the organizational leader. I believe that you genuinely want to do the right thing, to contribute to something larger than yourself, and to support those around you to improve the quality of life for each of us.

With high confidence in your ability, personal desire, and integrity I urge you to create an environment within your organization that inspires those around you and that enables agility. The future of your organization is depending on it.

Categories: Companies

R: ggplot – Plotting back to back charts using facet_wrap

Mark Needham - Fri, 07/25/2014 - 23:57

Earlier in the week I showed a way to plot back to back charts using R’s ggplot library but looking back on the code it felt like it was a bit hacky to ‘glue’ two charts together using a grid.

I wanted to find a better way.

To recap, I came up with the following charts showing the RSVPs to Neo4j London meetup events using this code:

2014 07 20 17 42 40

The first thing we need to do to simplify chart generation is to return ‘yes’ and ‘no’ responses in the same cypher query, like so:

timestampToDate <- function(x) as.POSIXct(x / 1000, origin="1970-01-01", tz = "GMT")
 
query = "MATCH (e:Event)<-[:TO]-(response {response: 'yes'})
         WITH e, COLLECT(response) AS yeses
         MATCH (e)<-[:TO]-(response {response: 'no'})<-[:NEXT]-()
         WITH e, COLLECT(response) + yeses AS responses
         UNWIND responses AS response
         RETURN response.time AS time, e.time + e.utc_offset AS eventTime, response.response AS response"
allRSVPs = cypher(graph, query)
allRSVPs$time = timestampToDate(allRSVPs$time)
allRSVPs$eventTime = timestampToDate(allRSVPs$eventTime)
allRSVPs$difference = as.numeric(allRSVPs$eventTime - allRSVPs$time, units="days")

The query is a bit because we want to capture the ‘no’ responses when they initially said yes which is why we check for a ‘NEXT’ relationship when looking for the negative responses.

Let’s inspect allRSVPs:

> allRSVPs[1:10,]
                  time           eventTime response difference
1  2014-06-13 21:49:20 2014-07-22 18:30:00       no   38.86157
2  2014-07-02 22:24:06 2014-07-22 18:30:00      yes   19.83743
3  2014-05-23 23:46:02 2014-07-22 18:30:00      yes   59.78053
4  2014-06-23 21:07:11 2014-07-22 18:30:00      yes   28.89084
5  2014-06-06 15:09:29 2014-07-22 18:30:00      yes   46.13925
6  2014-05-31 13:03:09 2014-07-22 18:30:00      yes   52.22698
7  2014-05-23 23:46:02 2014-07-22 18:30:00      yes   59.78053
8  2014-07-02 12:28:22 2014-07-22 18:30:00      yes   20.25113
9  2014-06-30 23:44:39 2014-07-22 18:30:00      yes   21.78149
10 2014-06-06 15:35:53 2014-07-22 18:30:00      yes   46.12091

We’ve returned the actual response with each row so that we can distinguish between responses. It will also come in useful for pivoting our single chart later on.

The next step is to get ggplot to generate our side by side charts. I started off by plotting both types of response on the same chart:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  geom_bar(binwidth=1)

2014 07 25 22 14 28

This one stacks the ‘yes’ and ‘no’ responses on top of each other which isn’t what we want as it’s difficult to compare the two.

What we need is the facet_wrap function which allows us to generate multiple charts grouped by key. We’ll group by ‘response’:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  geom_bar(binwidth=1) + 
  facet_wrap(~ response, nrow=2, ncol=1)

2014 07 25 22 34 46

The only thing we’re missing now is the red and green colours which is where the scale_fill_manual function comes in handy:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  scale_fill_manual(values=c("#FF0000", "#00FF00")) + 
  geom_bar(binwidth=1) +
  facet_wrap(~ response, nrow=2, ncol=1)

2014 07 25 22 39 56

If we want to show the ‘yes’ chart on top we can pass in an extra parameter to facet_wrap to change where it places the highest value:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  scale_fill_manual(values=c("#FF0000", "#00FF00")) + 
  geom_bar(binwidth=1) +
  facet_wrap(~ response, nrow=2, ncol=1, as.table = FALSE)

2014 07 25 22 43 29

We could go one step further and group by response and day. First let’s add a ‘day’ column to our data frame:

allRSVPs$dayOfWeek = format(allRSVPs$eventTime, "%A")

And now let’s plot the charts using both columns:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  scale_fill_manual(values=c("#FF0000", "#00FF00")) + 
  geom_bar(binwidth=1) +
  facet_wrap(~ response + dayOfWeek, as.table = FALSE)

2014 07 25 22 49 57

The distribution of dropouts looks fairly similar for all the days – Thursday is just at an order of magnitude below the other days because we haven’t run many events on Thursdays so far.

At a glance it doesn’t appear that so many people sign up for Thursday events on the day or one day before.

One potential hypothesis is that people have things planned for Thursday whereas they decide more last minute what to do on the other days.

We’ll have to run some more events on Thursdays to see whether that trend holds out.

The code is on github if you want to play with it

Categories: Blogs

Welcome to SAFe 3.0!

Agile Product Owner - Fri, 07/25/2014 - 22:53

Hello,

Well, it seems like it’s been a long time coming, but we are happy to announce the release of SAFe 3.0, right on time! This latest version features extensive refinements to many elements of the methodology infrastructure, as well as new content and guidance that helps enterprises better organize around value delivery, and improve coordination of large value streams.

With a primary focus on a substantially improved representation of the Portfolio level and organizational structure optimized for better flow of value, highlights of changes in this new version include:

In addition, almost all articles have been updated for additional clarity, and better fit in the 3.0 context. (I hope not to have to do that again for some time … ). And for those would like an informal introduction, our colleague and SPC Inbar Oren produced this five minute overview.

It is our sincere hope that this new version helps you and your enterprise achieve the benefits you all deserve for working so hard in building the world’s biggest, and best, software intensive systems. And as always, SAFe remains free and publicly available, for all to use as they can.

————————-

Of course, with every new release, you are never done. The end of one thing is the beginning of another, and I’d guess some of you look forward to future versions. At this moment, I’m not so sure I do, but I’m sure I will feel differently next week. (Or maybe the week after.)

This has certainly been a group effort amongst the authors (see below), but we also owe a special thanks to all the great folks at Scaled Agile, Inc. who helped us push out this release, including Regina Cleveland, Matt Clinton, and Vanessa Villarreal.

 

Regards,

-Dean Leffingwell, Chief Methodologist, Alex Yakyma, Associate Methodologist, and Richard Knaster, Scaled Agile Thought Leader and SAFe Principle Contributor

Categories: Blogs

Assembla now allows automatic payments with PayPal

Assembla Blog - Fri, 07/25/2014 - 20:17

Paying for your Assembla subscription with PayPal has never been easier. We recently added the ability to set up recurring payments with PayPal that will automatically pay for your Assembla subscription every billing period, whether that be monthly or annually. Previously, it was a manual process that required logging in and paying every time an invoice was created.

To set up automatic payments with PayPal, visit your billing page > select the PayPal option > and follow the steps.

assembla paypal option1

If you have any questions or issues, please contact Assembla support at support@assembla.com.

Categories: Companies

Marketing scrum vs IT scrum - a report published and presented at agile 2014

Xebia Blog - Fri, 07/25/2014 - 18:49

As we know, Scrum is the perfect framework for IT / software development projects to learn, adapt to change and deliver great software of value, faster.

But is Scrum also usable outside of software development? Can we apply similar or maybe even the same principals in other departments in the enterprise?

Yes, we can! And yes there are differences but there are also a lot of similarities.

We (Remco en Me)  successfully implemented Scrum in the marketing departments of two large companies: The ANWB and ING Bank. Both companies are now using Scrum for the development of new campaigns, their full commercial expressions and even at the product development level. They wanted a faster time to market, more ownership, and greater innovation. How did we approach and realized a transition with those goals in the marketing environment? And what are the results?

So when we are not delivering software but other things, how does Scrum change? Well, a great deal actually. The people working in these other departments are, in general, quite different to those in Software Development (and yes more than you would expect). This means coaches or change agents need to take another approach.

Since the people are different, it is possible to go faster or ‘deeper’ in certain areas. Entrepreneurial skills or ambitions are more present in marketing. This gives a sense of ‘act first apologize later’, taking ownership, a higher drive to succeed, and upfront and willing behavior. Scrumming here means thinking more about business goals and KPIs (how to go from department to scrumteam goals for example). After that the fun begins…

I will be speaking about this topic at agile 2014. A great honor offcourse to be standing there. I will also attende the conference and therefor try to post some updates here.

To read more about this topic you can read my publication about marketing scrum. It has the extensive research paper I publisched about this story. Please feel free to give me comments and questions either about agile 2014 or the paper.

 

Enjoy reading the paper:

Marketing scrum vs IT scrum – two marketing case studies who now ‘act first and apologize later'

 

Categories: Companies

The Drag of Old Mental Models on Innovation and Change

J.D. Meier's Blog - Fri, 07/25/2014 - 18:06

“Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats.” — Howard Aiken

It's not a lack of risk taking that holds innovation and change back. 

Even big companies take big risks all the time.

The real barrier to innovation and change is the drag of old mental models.

People end up emotionally invested in their ideas, or they are limited by their beliefs or their world views.  They can't see what's possible with the lens they look through, or fear and doubt hold them back.  In some cases, it's even learned helplessness.

In the book The Future of Management, Gary Hamel shares some great insight into what holds people and companies back from innovation and change.

Yesterday’s Heresies are Tomorrow’s Dogmas

Yesterday's ideas that were profoundly at odds with what is generally accepted, eventually become the norm, and then eventually become a belief system that is tough to change.

Via The Future of Management:

“Innovators are, by nature, contrarians.  Trouble is, yesterday's heresies often become tomorrow's dogmas, and when they do, innovation stalls and the growth curve flattens out.”

Deeply Held Beliefs are the Real Barrier to Strategic Innovation

Success turns beliefs into barriers by cementing ideas that become inflexible to change.

Via The Future of Management:

“... the real barrier to strategic innovation is more than denial -- it's a matrix of deeply held beliefs about the inherent superiority of a business model, beliefs that have been validated by millions of customers; beliefs that have been enshrined in physical infrastructure and operating handbooks; beliefs that have hardened into religious convictions; beliefs that are held so strongly, that nonconforming ideas seldom get considered, and when they do, rarely get more than grudging support.”

It's Not a Lack of Risk Taking that Holds Innovation Back

Big companies take big risks every day.  But the risks are scoped and constrained by old beliefs and the way things have always been done.

Via The Future of Management:

“Contrary to popular mythology, the thing that most impedes innovation in large companies is not a lack of risk taking.  Big companies take big, and often imprudent, risks every day.  The real brake on innovation is the drag of old mental models.  Long-serving executives often have a big chunk of their emotional capital invested in the existing strategy.  This is particularly true for company founders.  While many start out as contrarians, success often turns them into cardinals who feel compelled to defend the one true faith.  It's hard for founders to credit ideas that threaten the foundations of the business models they invented.  Understanding this, employees lower down self-edit their ideas, knowing that anything too far adrift from conventional thinking won't win support from the top.  As a result, the scope of innovation narrows, the risk of getting blindsided goes up, and the company's young contrarians start looking for opportunities elsewhere.”

Legacy Beliefs are a Much Bigger Liability When It Comes to Innovation

When you want to change the world, sometimes it takes a new view, and existing world views get in the way.

Via The Future of Management:

“When it comes to innovation, a company's legacy beliefs are a much bigger liability than its legacy costs.  Yet in my experience, few companies have a systematic process for challenging deeply held strategic assumptions.  Few have taken bold steps to open up their strategy process to contrarian points of view.  Few explicitly encourage disruptive innovation.  Worse, it's usually senior executives, with their doctrinaire views, who get to decide which ideas go forward and which get spiked.  This must change.”

What you see, or can’t see, changes everything.

You Might Also Like

The New Competitive Landscape

The New Realities that Call for New Organizational and Management Capabilities

Who’s Managing Your Company

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.