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

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

“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.

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

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