The 4-Step Action Plan for Agile Health: Step 4: Develop and Implement your customized plan for adopting healthy agile-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, 2 and 3 (highlighted in light green color) were completed.    In this Part 4 (highlighted in pink color), Step 4 – develop and implement your customized plan for adopting healthy agile-lean practices – is described.

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

R_Part4_Table1

Sprint History Map:  In Parts 1 to 3 of this blog series, I presented and extensively used Sprint History Map as a visual metric to understand what has happened on each day of a sprint timebox and to derive many useful data points to help us understand the health of an agile team:

  1. Cycle time for each accepted feature and the average cycle time
  2. WIP for each day of the sprint for accepted features in the sprint, and their average WIP
  3. Throughput (feature acceptance rate per day or per time unit) – calculated from 1 and 2 above using Little’s law; this number can be visually verified easily on the Sprint History Map
  4. WIP for each day of the sprint for all features (accepted as well as not accepted) worked on, and their average WIP
  5. Specific days when regression testing was done during the sprint (if any)
  6. Planned number of features and their total story points
  7. Velocity: Accepted number of features and their total story points
  8. Number of NT and IMP events, and their total.  These are the days when work stoppage occurred.

Many Agile Lifecycle Management (ALM) tools have a data warehouse facility for storing historical data, and analytics tools to generate reports from the historical data.   Ideally a single analytics report (or a small set of few reports) should present all the data listed above in a visually simple way to understand.   It might require some programming effort using the tool’s APIs.   You may check with your ALM tool vendor if this is possible, and seek vendor help to generate Sprint History Maps.  Otherwise, you may have to put some effort to gather different historical data items or reports to piece together your version of the Sprint History Map.

Sprint History Map is a very useful visual diagnostic tool that offers a number of critical insights indicating the health of an agile team, how effective its practices are, and how much dysfunction exists in its agile practices, etc.

Recommended approach for moving away from harmful behaviors and adopting healthy agile-lean practices:  Each team and organization is unique, and therefore has unique challenges and opportunities to move away from harmful behaviors to adopt healthy practices.   Your approach should be customized to your specific situation, constraints, needs and goals. 

It is helpful to organize 6 harmful behaviors and the corresponding 6 healthy agile-lean practices along 3 dimensions (X, Y, and Z) as shown in Figure 1.  X-dimension covers transition from manual testing to test automation, and from “frequent impediments and non-availability of qualified team members” to “effective impediment management and full availability of qualified team members”; Y-dimension covers transition from “non-lean” behaviors to agile-lean practices; and Z-dimension covers transition from “legacy mindset” behaviors to agile mindset practices.  For each transition (from a harmful behavior to a healthy practice) to succeed, I have also indicated the degree of senior management and functional management support likely to be needed along X, Y and Z dimensions.

R_Part4_Figure1

Figure 1: 6 Harmful Behaviors and 6 Healthy Agile-Lean Practices organized along three dimensions including the degree of senior management support needed

I recommend launching an immediate effort along the X-axis by embracing test automation practice, both unit test automation with test-driven development discipline, and acceptance test automation.  Both practices will need training.  Get help from qualified coaches, and relevant training courses and books.   No team can migrate from the manual testing norm to fully automated testing practice in few sprints.   Test automation will require serious commitment and effort over several release cycles to get more and more test cases automated, and thereby building a growing suite of automated regression tests.   As explained earlier, without regression test automation, fully tested, potentially shippable software for every sprint is not feasible.  It is imperative to get started on the test automation practice and gradually minimize the manual testing effort.  Clearly, some types of testing that require human judgment, such as usability testing, cannot be automated.

Effective impediment management can be learned with practice and improved with process maturity and experience; management support is still needed for removing organizational impediments.  As multiplexing and multitasking reduces, and the team starts following Stop-Starting-Start-Finishing lean mantra, the number of NT events should reduce over a period of time.  Moving away from non-lean behaviors (3B and 4B) to healthy agile-lean practices (3P and 4P), shown along the Y-dimension of Figure 1 is a challenge that can be addressed at the team-level.  It usually doesn’t depend on and need not wait for senior management support.  I suggest starting with training and workshops on lean methods from qualified coaches.  A number of good books and web resources are also available.

Moving away from legacy mindset behaviors (1B and 2B) to healthy agile mindset behaviors (1P and 2P), shown along the Z-dimension of Figure 1, is likely to require a high degree of support from senior management and functional management because it is probably the most dramatic change in a hierarchically structured, waterfall organization.    Only the senior managers are in a position to move an organization from multiplexing/multitasking behaviors to instituting and empowering cross-functional, self-organized agile teams consisting of full-time, dedicated team members.   If you believe getting support from senior management would be a significant challenge in your organization, I suggest starting with agile-lean training for executives, where they could understand how their role changes to support agile-lean adoption, and what they will need to do differently.

You should assess which specific current behavior(s) produce the most pain, which new practice may produce the most benefits quickly, and the degree of support needed from senior management.   Some of this assessment can be done qualitatively in discussions among the team members and stake holders.   This qualitative assessment should be supplemented with measured quantitative data for one or more agile teams in your organization.  I recommend taking a look at your team’s most recent Sprint History Maps (typically the last 4 sprints) to assess its current state.

Does your agile team’s Sprint History Map look more like a healthy agile team’s map (as shown Figure 2 of Part 3)? Or does it look closer to the map of a struggling agile team (as shown in Figure 1 of Part 3)?  A careful analysis of your team’s Sprint History Maps will provide quantitative data, such as the cycle time, WIP, throughput, velocity, number of IMP and NT events.  I suggest doing this analysis for the last 4 sprints, if you have that data available.    In addition, I suggest analyzing more traditional reports for your team, such as sprint burn-down and burn-up charts, and cumulative flow charts to identify problem areas, if any.   For example, if the sprint burn-down charts show flat horizontal lines, they might be caused by IMP and NT events (but not always).  If the sprint burn-up charts show most features getting accepted towards the very end of a sprint, it may indicate that the team is not following the Stop-Starting-Start-Finishing lean mantra and has no WIP limit for its work.

With this information (qualitative as well as quantitative) you can assess your current situation, and perform a gap analysis, i.e., determine the gap between the desired goal state at some time in future (say six months from now) and the current state.  Based on this gap, you should then decide and implement the course of action: where is the biggest return on investment would be, i.e., the most benefits for the least amount of effort or time.

Table 2 summarizes the transition from 6 harmful behaviors to 6 healthy agile-lean practices.  It also summarizes several recommended possible actions that you may choose from to implement your customized action plan.

Table 2: Transition from harmful behaviors to healthy agile-lean practices
Expected challenges and suggested actions

satishgraphic

How does your History Map look? Are any of the 6 harmful behaviors causing serious challenges and issues in your organization? Are any of the 6 healthy agile-lean practices giving your team tangible benefits? Are you interested in developing and implementing a customized approach for your transition from harmful behaviors to healthy agile-lean practices?

I would love to hear from you either here or by email: (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

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

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

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

This entry was posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Metrics, Agile Project Management, Agile Software, Agile Training, Iterative Development, Kanban, Lean, Lean Software Development, Scrum Development, Scrum Methodology. Bookmark the permalink.

2 Responses to The 4-Step Action Plan for Agile Health: Step 4: Develop and Implement your customized plan for adopting healthy agile-lean practices

  1. Agility works big time and that is fact cant be denied but yeah if things are planned in the good way and the way how its required we can get to have betterment which finally goes ahead and works in the finer and that is the way how it is.

  2. Satish Thatte says:

    Thank you for your comment. I agree; planning is critical to making agility work. I’m glad you found the post useful. — Satish Thatte

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>