The 4/Step Action Plan for Agile Health: Step 3: Understand how to use additional enablers of Agile Health
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”:
- Agile development “sprints” assigned to software development lifecycle phases
- Agile development “sprints” assigned to technology tiers
- Mini/Waterfall inside sprints
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 and 2 (highlighted in light green color) were completed. In this Part 3 (highlighted in pink color), Step 3 / understand how to use additional enablers of agile health / is described. Parts 4 will be presented in the future.
Table 1: The 4/Step Action Plan for Agile Health
In Part 1 of this blog series, I used an example of a typical 4/week (20 workdays) sprint for the Struggling Agile Team. Figure 1 illustrates the Sprint History Map of this 4/week sprint for the Struggling Agile Team after the sprint is over. This Figure 1 is a revised version of Figure 1 of Part 1 as it shows the effects of two additional harmful behaviors, 5B and 6B, described below.
Figure 1: Sprint History Map of the Struggling Agile Team suffering from 6 harmful behaviors
5B. Frequent impediments and non/availability of qualified team members: With struggling agile teams, there is often no disciplined way to minimize and manage impediments. Team members (especially contractors supplied by an off/shore vendor) are reluctant to bring impediments to the attention of ScrumMaster in a proactive manner. ScrumMaster may have difficulty in removing organizational impediments. More importantly, the team may not have the required training and norms to prevent or minimize the impediments in the first place by taking timely proactive actions to resolve issues to prevent them from becoming impediments. As a result, the number of impediments experienced by the Struggling Agile Team is rather large (as shown by 9 impediments // marked as IMP – on the Sprint History Map of Figure 1). Furthermore, impediments may take substantial time to be removed, which holds up the work. As shown in the Sprint History Map in Figure 1, a rather larger number of 32 cells are marked as NT (No Team Member Available) events because of frequent non/availability of qualified team members. These members may be busy on other projects or teams due to multiplexing, or busy with other features due to multitasking, or are interrupted by customer support work or customer demos. Members that may be available are not qualified or ill/prepared to do work outside their area of expertise due to the silo mindset. Although it can be argued that NT events is an example of impediments (as no work can proceed due to non/availability of qualified team members), it is important to differentiate between NT events from general impediments to understand the gravity of problems caused by non/availability of qualified team members and then take appropriate actions to correct or mitigate that problem. As shown in its Sprint History Map (Figure 1), the Struggling Agile Team planned 8 features, but could complete only 4 features (Features 1 through 4). Four features (Feature 5 through 8) could not be completed. 6B. Manual testing is the norm: For struggling agile teams, the level of automation for unit testing, acceptance testing and regression testing is non/existent or at best low. This creates an untenable situation as evermore regression test cases need to be run within each successive sprint to ensure that the functionality implemented in all previous sprints is still working, i.e., hasn’t regressed. This growing effort for regression testing for each successive sprint with the same number of QA testers in the team performing manual regression testing is simply not feasible. As a result, many teams do little or no regression testing in each sprint as shown in Figure 1; that effort is postponed until the so/called hardening sprint. Neither the team nor its customers or users are clear about the quality of each sprint release as there was little or no regression testing done. In Part 2 of this blog series, I used an example of a typical 4/week (20 workdays) sprint for the Healthy Agile Team. Figure 2 illustrates the Sprint History Map of this 4/week sprint for the Healthy Agile Team after the sprint is over. This Figure 2 is a revised version of Figure 1 of Part 2 as it shows the positive effects of two additional healthy practices, 5P and 6P, described below.
Figure 2: Sprint History Map of the Healthy Agile Team following 6 healthy agile/lean Practices
5P. Effective impediment management and full availability of qualified team members: ScrumMasters should develop and practice these skills:
- Encourage team members to bring to attention issues in a proactive way
- Resolve issues before they have a chance to become impediments
- Recognize real impediments that team members simply cannot resolve on their own
- Develop technical and organizational skills to resolve impediments quickly if they still occur
- When an impediment stops work on a feature (should be rare event), the feature team members may be assigned to help other feature teams, instead of pulling a new feature to work on (which increases WIP)
- Apply the 5/Why’s technique (see: http://en.wikipedia.org/wiki/5_Whys) to find and address the root causes for recurring impediments
As a result of this practice, the number of impediments is minimized and impediments are removed quickly when they occur. Compared to the Struggling Agile Team’s 9 impediments (see its Sprint History Map in Figure 1), the Healthy Agile Team encountered only 2 impediments (see its Sprint History Map in Figure 2). NT (Non/availability of qualified team members) events can be completely eliminated for the Healthy team as shown in its Sprint History Map (Figure 2) because full/time, dedicated, cross/functional team members swarm on features; they do not squander their time on multiplexing or multitasking. As shown in its Sprint History Map (Figure 2), the Healthy Agile Team planned 8 features, and completed 7 features (Features 1 through 7). Only one feature (Feature 8) could not be completed. 6P. Test Automation: Evermore regression testing is required in each successive sprint to ensure that the functionality built during past sprints is still intact and has not been broken, i.e., hasn’t regressed. Unit tests are automated by following the practice of Test/driven development, and acceptance tests are also automated. These two classes of automated tests are added to build the growing automated regression test suite. It now becomes practical to run ever larger number of automated regression test cases on Day 18 and 19 of a 4/week sprint by using computers (typically virtual machines) as shown in Figure 2. Although it is not possible to automate every test case, such as usability testing that involves subjective judgment, a vast majority of test cases are automated by the Healthy Agile Team. I recommend to gradually growing test automation expertise within each cross/functional team. If you have to depend on the availability of test automation experts controlled by some group or department, you will be back to harmful behavior 2B of Team members working with a silo mindset. These test automation experts will always be in high demand by multiple teams, and often will become a bottleneck. By no means, the list of 6 harmful behaviors and the corresponding 6 healthy agile/lean practices presented in this blog series is exhaustive. More Practices for you to consider: Build automation, Continuous integration, DevOps, Refactoring, Technical debt reduction, Spikes, Waste reduction to improve lean flow, etc. Now let us take a holistic view of all 6 harmful behaviors to move away from, and 6 healthy agile/lean practices to adopt. Six harmful behaviors feed on each other to create more harm: When multiplexing and multitasking is common, team members get distracted and lose productivity, which reduces throughput and increases NT events (work cannot proceed due to non/availability of qualified team members) as team members get pulled off to work on other multitasked work. When team members work with a silo mindset and don’t have skills or inclination for cross/functional work, there are many NT events. When team members have no focus on completing the work already started, WIP goes up, cycle time goes up, and throughput goes down. Lack of test automation (manual testing is the norm) also reduces productivity and makes regression testing almost impossible in each sprint, which reduces quality. As a result of all these 6 harmful behaviors, the Struggling Agile Team could get only 4 features (Features 1 through 4) accepted in the sprint representing a velocity of 8 story points. The remaining 4 features (Features 5 through 8) could not be completed within the sprint. A struggling agile team may continue to struggle into a downward spiral, until and unless it starts moving away from harmful behaviors and start following healthy practices. Six healthy agile/lean practices feed on each other to create increasing benefits: When multiplexing is avoided and multitasking is minimized, team members increase their productivity due to single/team loyalty and by not wasting time on context switching, which increases throughput and reduce NT events. As teams develop and use cross/functional skills, NT events reduce dramatically as at least one team member is almost always available to do any work (each member is a Master of One and Jack of Two). As team members follow lean mantra of Stop/Starting/Start/Finishing, and work in a highly focused way, WIP goes down, cycle time goes down, and throughput and quality go up. As manual testing reduces, and Test automation increases, it increases productivity and makes regression testing possible in each sprint, which improves quality. Instead of struggles caused by harmful behaviors, an agile team starts experiencing an upward spiral of improved health and consequent higher productivity, throughput, and quality. As a result of all these 6 healthy/lean agile practices along with the practice of sprint pipeline, the Healthy Agile Team was able to get 7 features (Features 1 through 7) accepted in the sprint representing a velocity of 15 story points. Only one feature of 1 story point (Feature 8) could not be completed within the sprint. 6 healthy agile/lean practices synergize to create more positive benefits. Success feeds on success 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 or of interest to you for your adoption? 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 2: Understand healthy Agile Mindset and Lean Practices to adopt Part 4: Develop and implement your customized plan for adopting healthy agile/lean practices