The 4-Step Action Plan for Agile Health: Step 1. Understand “Legacy Mindset” and “Non-Lean” behaviors to move away from

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: analysis, design, code development, testing and defect fixing, delivery and deployment activities are carried out in sequential “sprints.”
2. Agile development “sprints” assigned to technology tiers: user interface tier, business logic tier and data management tier work are carried out in sequential “sprints.”
3. Mini-Waterfall inside sprints: for example, in a 4-week sprint, week 1 is used for analysis and design, week 2 for code development, week 3 for testing, and week 4 for defect fixing, i.e., these activities (design, code development, testing, defect fixing) are sequential, creating a mini water fall; they are not concurrent as required by true agile development.
4. Water-Scrum-Fall: Although design, code development, testing and defect fixing go on concurrently in each “sprint,” there is a fairly long Requirements Analysis phase carried out upfront prior to the first sprint by a group of business analysts producing a comprehensive Requirements Specification document; and at the end of the last sprint, IT Operations staff spends a fair amount of time in deploying the system in a production environment, often finding problems that are expensive to fix.

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: In this Part 1 (highlighted in pink color), Step 1 – understand “Legacy Mindset” behaviors (1B and 2B) and 2 “non-lean” behaviors (3B and 4B) – is described. Parts 2 to 4 will be presented in the future.

In this blog series, I typify an agile team A consisting of a business analyst, 2 full-time developers and 2 half-time developers, 1 full time QA tester and 2 half-time QA testers, a Product Owner and a ScrumMaster.  Business analyst works with product owner to write and clarify feature specifications as part of Analysis tasks.  As you will see shortly, Team A exhibits all 6 harmful behaviors (1B to 6B) listed in Table 1; it is our prototypical “Struggling Agile Team.”

In this blog series, I use an example of a typical 4-week (20 workdays) sprint.  Figure 1 illustrates a Sprint History Map of this 4-week sprint for the Struggling Agile Team after the sprint is over; it is not a sprint plan projecting what will happen in future on each of those 20 days; this kind of plan would be a total anti-pattern for agile development.  In Part 4 I explain how to get information to construct a Sprint History Map as a visual metric for gaining critical insights that you can act on.  The 20 workdays of the sprint are shown as columns numbered 1 through 20 Figure 1.

The Struggling Agile Team completed sprint planning on Day 1 where the Product Owner rank ordered the sprint backlog of features.  In our example, the sprint backlog has 8 rank-ordered features (also called “stories”) shown under the backlog column in Figure 1.  During sprint planning, the Struggling Agile Team also estimated the relative effort of features in story points.  For example, Feature 1 is of 1 story point (indicated by “1, 1”), Feature 2 is of 3 story points (indicated by “2, 3”), and Feature 8 is of 1 story point (indicated by “8, 1”).  In this example the Struggling Agile Team planned 8 rank-ordered features representing a total effort of 16 story points.  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 Struggling Agile Team suffering from
“Legacy Mindset” and “Non-Lean” behaviors

Two harmful “Legacy mindset” behaviors to avoid:   I have called these 2 behaviors as “legacy mindset” behaviors because they arise primarily from legacy habits and practices of old waterfall days, silo mindset, and resistance to cultural change needed for agile adoption to succeed.  These behaviors give rise to many difficulties in successful agile adoption and prevent the teams from getting full benefits of agile development.

1B. Multiplexing and Multitasking is common:  Members are tasked by management to work on multiple concurrent teams of the same project or even different projects.  The behavior is rooted in the traditional project management mindset of treating people as resources and attempting to maximize their utilization by assigning them to multiple concurrent projects or teams.  This behavior is further driven by the fact that most people are narrow specialists; they are assigned to do work in their specialization on multiple teams or projects, as there is usually a shortage of other people to do that kind of work.

It has been reported that a team member working on two concurrent teams or projects loses 20% productivity due to frequent context-switching.  A member working on 3 or 4 concurrent teams or projects may lose 40% or 60% of productivity respectively, due to frequent context switching (Reference: Quality Software Management: Systems Thinking, Gerald Weinberg, 1991).

Multitasking behavior is also common.  Team members work on several tasks of different features of a sprint that match their skills often concurrently (frequently switching from one task to other), or team members may be pulled away for production support work or customer demos.   Their work gets frequently interrupted by meetings, phone calls, people stopping by for discussions, as well as self-imposed urge to check and respond to emails and instant messages incessantly, and in general, due to lack of self-discipline to focus on one task at a time.   Like multiplexing, multitasking also diminishes productivity.  Unlike CPUs, humans are not well suited for multiplexed or multitasked work.  Unfortunately, the trend is to do extreme multitasking: doing work, web surfing, tweeting, “Liking” on Facebook, talking over phone, replying to email and instant messages, and eating…all concurrently.   Single-minded focus means “while eating, only eat with single-minded focus on enjoying food.”

Thus in reality, the Struggling team has at best 2.8 (not 3) equivalent developers with its 2 full-time and 2 part-time developers, and 1.8 (not 2) equivalent testers with its 1 full-time and 2 part-time testers.  The team members’ effectiveness and productivity is further reduced proportional to the degree of multitasking they may indulge in.

2B. Team members with silo mindset develop features in a “micro waterfall” manner:  Each member works on only specialized tasks suited to his/her expertise or interests.   Departmental silo mindset is common.  A developer is reluctant to test code written by other developers, a tester is not skilled to write automated acceptance tests, an architect is reluctant to get down into trenches and write code, a technical writer rarely does usability testing, etc.

A team is also likely to develop each feature in a sequential “micro waterfall” by performing the implementation tasks (analysis, design, code development and unit testing, acceptance test case development, acceptance test case execution, defect fixing, etc.) within the sprint timebox in a linear order.  Although the Sprint History Map in Figure 1 shows only three micro waterfalls (for Features 1 through 3) for brevity, all 8 features are developed in a micro waterfall manner.    In a micro waterfall there are very few concurrent activities.  As a result, in the first half of a sprint, most developers of the Struggling Agile Team are too busy and testers believe they don’t have much work to do until developers have completed all their work.  This picture reverses in the second half of a sprint; testers get too busy and developer don’t have much to do.

Two harmful non-lean behaviors to avoid: I have called these 2 behaviors as “non-lean” behaviors because they arise from not understanding the relevance and importance of key lean principles and practices.  Just like “Legacy mindset” behaviors explained above, these non-lean behaviors give rise to many difficulties in successful agile adoption and prevent the teams from getting benefits of agile development.

3B. Team members start new work without any focus on completing the work already started: Most team members eagerly start working on new features and tasks of their personal interest with almost total disregard to features and tasks that were already started and are still in progress (Work in Process).  There is no focus on completing the features and tasks they have already started.   After all, starting new features is more exciting work compared to fixing defects in features that were already started.  The less exciting work of completing the features already started and getting them accepted by the product owner gets short shrift.     Similarly, due to multitasking habits, starting a new exciting task within a feature is much more tempting, leaving many “boring” tasks unfinished until the very end of the sprint timebox.

As shown in the Sprint History Map of the Struggling Agile Team (see Figure 1), the Work in Process (WIPs) on Day 2 through 19 (total 18 days) for 4 completed features (Feature 1 through 4) in the sprint are 4, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 3, 2, with the average WIP = (68/18) = 3.77.  However, the WIPs on Day 2 through 19 (total 18 days) for all 8 features are 3, 4, 4, 6, 7, 7, 7, 8, 8, 8, 8, 8, 8, 8, 8, 8, 7, 6, with the average WIP shooting up to (123/18) = 6.83, i.e., almost 7 features (out of 8 in the backlog) being worked on by the team in parallel!   The Struggling Agile Team does not have the required focus on completing the work in process before starting new work.  As a result, at the end of the sprint, only 4 out of 8 features were completed by the team and accepted by the product owner.   Sadly this Struggling Agile Team claimed that the remaining 4 features (Features 5 through 8) are “almost done” while in reality they took considerably more time in the next sprint to complete.  With proper coaching and experience the team learns that a feature is either 100% Done or Not Done, and there is no such thing as “Almost Done” or “98% Done.”  It is very binary.

4B. Work within a sprint proceeds oblivious to feature cycle time:  Feature cycle time (cycle time in short) is the total end-to-end time starting from when team members pull the feature from the sprint backlog to work on until the feature is accepted by the product owner after it passes the acceptance tests.   In Figure 1, cycle time for Feature 3 is 18 days, i.e., day 2 through 19 of the 4-week sprint.  Cycle times for the 4 completed features (Features 1 through 4) are 16, 17, 18, 17 days, with an average cycle time of (68/4) = 17 days.  This Struggling Agile Team is unaware of the importance of reducing the average cycle time, and could not complete 4 features within the sprint timebox due to their long cycle times.

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 Struggling Agile Team.

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

Average Throughput = Average WIP / Average Cycle time

In this example, Average WIP = 68/18 (see Behavior3B above), and Average Cycle Time = 68/4 (as explained just above).

Therefore, Average Throughput = [(68/18) / (68/4)] = 4/18 features per day.

You can use the Sprint History Map (Figure 1 ) to visually verify that the team has delivered 4 accepted features (Features 1 through 4) in 18 actual work days of the sprint, confirming the average throughput of 4/18 features per day.

This low throughput is caused by the fact that the team is new to agile (low productivity due to learning curve), and also due to its own harmful behaviors:  it lost productivity due to frequently non-available members (NT events) and due to impediments (IMP events) marked in Figure 1.  This is explained in Part 3 of the blog series.  Also due to multiplexing and multitasking, silo mindset, no emphasis on finishing the work that was already started, long cycle times (average cycle time of 17 days in an 18 workday sprint), and manual testing (as explained in Part 3 of this blog series).  The Struggling Agile Team could not do any regression testing within the sprint due to its practice of mostly manual testing.  This is explained in detail in Part 3 of the blog series.

When Features 5 through 8 are completed in the next sprint (if that were to happen), it would be possible to consider the WIP on every day of two consecutive sprints for these 8 features and any new features started and completed in the next sprint, and also consider the cycle times for these 8 and new features over two sprints to calculate the average throughput per day over two sprints by following the procedure above.

The Struggling Agile Team failed to recognize the need for limiting the WIP and lowering the cycle time.  Large average WIP means large average cycle time, which increases the risk of many features not being completed and accepted within the sprint timebox.    The Struggling Agile Team is simply oblivious to the implications of Little’s Law.

The Struggling Agile Team attempted to do all work for each feature (shown in Figure 1 as A: analysis, D: Design, C: Coding, TD and TE: Acceptance Test Develop and Execution of QA tester, DF: Defect fixing, AT: Acceptance testing by product owner) in the same single sprint timebox as this workflow is simple to understand and to follow.   However, this behavior created many adverse effects as the answers to some analysis questions raised by team members could not be available immediately; a product owner had to talk to customers or senior management to seek clarifications, and those answers took too much time to complete all development within a tight sprint timebox.  As user interface design work could be tested only through working code, the feedback cycle was too long to correct the UI issues in the same single sprint timebox.  Analysis and UI design work, and associated clarifications and corrections for certain features took too much time to complete the feature within a single sprint.  What the Struggling Agile Team failed to recognize was that Analysis and UI design work had become bottleneck hampering the overall flow and increasing the cycle time; but the team didn’t know what action to take to remove the bottlenecks.

Is your team experiencing the harmful legacy mindset and non-lean behaviors, and looking for solutions?   I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

Part 2: Understand healthy Agile Mindset and Lean Practices to adopt

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