8. Experiments
A zombie film is not fun without a bunch of stupid people running
around and observing how they fail to handle the situation.
—George A. Romero, Creator of Night of the Living Dead
In This Chapter
• Explore ten experiments to start shipping faster.
• Learn what impact the experiments have on surviving Zombie Scrum.
• Discover how to perform each experiment and what to look for.
In this chapter, we share practical experiments to start shipping faster. Some are designed to create transparency around what happens because you can’t ship fast, while others are designed to start taking the first small steps. While the experiments vary in their difficulty, each one will make taking further action easier.
Experiments to Create Transparency and Urgency
The whole point of shipping fast is often difficult to understand for organizations where Zombie Scrum is prevalent. They believe either that shipping fast is impossible for them or that it is less efficient than releasing everything in one go. To bridge this gap, the following experiments are about creating urgency by showing what happens when teams can’t ship fast(er).
Make a Business Case for Continuous Delivery
Continuous Delivery is the practice of automating your release pipeline—from code commit to release. Without it, shipping fast is difficult and time-consuming, if not impossible. Unfortunately, Continuous Delivery is one of those dreams that teams often keep postponing by doing everything “manually one more time.” Or management doesn’t want to invest in Continuous Delivery because it would take time away from delivering more features; they forget that each manual release already costs the team valuable time.
When the promise of Continuous Delivery doesn’t convince others to invest in it, one thing that can help is to turn that promise into something quantifiable. How much money and time can actually be saved by automating your deployment pipeline? This experiment is a great example of how Scrum Masters can use transparency to drive inspection and adaptation.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. For a typical release, map out your current deployment process on a timeline—both inside and outside your team. Make sure to consider the entire process up to the point when users can interact with it. Which manual tasks does it involve? For example: “Writing release notes,” “Going through the prerelease test procedure,” “Creating a deployment package,” “Performing a backup before deployment,” or “Installing packages on the server.” You can prepare this timeline either on your own or with the Development Team.
2. If you have the opportunity, time the actual hours that each manual task requires for a few releases. This gives you the most reliable data. Otherwise, ask people to estimate how much time they typically spend on each task.
3. Based on the data you collected, calculate the hours that each step takes on average. If more than one person is involved, sum their hours. Also, sum the total amount of time spent on all the manual tasks of a single release. You now have a metric that tells you how much time is potentially wasted on manual work per release.
4. When you have data from an actual release, you can also include the time it took to fix bugs, perform rollbacks, and address rework that resulted from the release.
5. Determine the hourly rate of developers in your organization. If you don’t have access to this information, use an online calculator to translate an average salary to an hourly rate. For most Western countries, an example would be $30 per hour. Multiply the hourly rate with the total time of each task in the entire release to calculate how much that release costs.
6. You now have the cost of all the manual work involved in a single release, as well as the time it takes everyone involved. For example, it might take 200 hours to release a new version to production; that’s $6,000 if you use a $30 hourly rate. If your organization releases twelve times a year, this cost becomes a whopping $72,000.
7. With the Product Owner, consider the total time spent on manual tasks. Very roughly, how much value could have been delivered if people were able to spend that amount of time on implementing more work from the Product Backlog?
8. Convene the people involved and ask them where automation can both reduce manual effort and create time to get more valuable work done. The purpose here is not to automate everything, but to start where the team thinks it is possible and where the gain is the most substantial. Obviously, automating tasks requires investment. And you can now offset that cost with how much the organization stands to benefit from making that investment.
Our Findings
• One knee-jerk response to the high costs of releasing may be to do it less frequently. You can counter reaction this by emphasizing that bundling releases only makes them more risky and expensive as the number of changes—the complexity—increases. By automating parts of your process, you’re effectively enabling your organization to decrease the risk and cost of each subsequent release. That makes automation an investment in your future.
• A side effect of tedious manual work is that people tend to forego it even though it’s necessary, or they use shortcuts that lead to additional unintended work. Automated processes don’t get bored and don’t suffer from this limitation. To add this dimension to your calculation, you can estimate how much time is spent after each release on fixing issues that would’ve been prevented if the manual steps were performed as they should.
Measure Lead and Cycle Times
Zombie Scrum flourishes in environments where people are unaware of how much time items from the Product Backlog are “in progress” somewhere in the organizational pipeline. Product Backlog Items are valuable only when they are released to stakeholders. Not releasing them early is essentially a form of waste, as those items have to be tracked, managed, and coordinated throughout their lifetime in the pipeline.
This experiment is all about creating transparency around this type of waste with two related metrics: lead time, or the time that transpires between when a stakeholder request enters the Product Backlog and when it is fulfilled to that stakeholder through a release, and cycle time, or the time that transpires between when work begins on an item and when the item ships. The cycle time is always a part of the lead time. Lead and cycle times are great measures for agility; the shorter they are, the faster you ship and the more responsive you are. In environments with Zombie Scrum, these timings are much longer than in environments where Scrum works well. Figure 8.1 illustrates this point.
Figure 8.1 An example of lead time and cycle times compared between Zombie Scrum and Scrum as it is intended. The numbers are from two actual teams.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. For this experiment to work, you need to track three dates for every item on your Product Backlog that you want to analyze. You can track the dates for all the items or for a sample. For each item, add the date of arrival. This is the moment when an item is added to the Product Backlog.1 Whenever an item is put on the Sprint Backlog, put the current date on the item, to track when the team started work on it. Finally, record the date when the item is made available to stakeholders. This is the moment of the actual release, not the moment when the team considers the item “potentially releasable.”
1 If a lot of time usually transpires between the identification of the item and when it ends up on the Product Backlog, track the moment the item was identified instead for a more accurate picture.
2. Whenever an item is released to stakeholders, calculate both the lead and the cycle time in days and keep those times with the item. Remember that the cycle time is the time in days between the moment that the team started its work on the item and the release date. The lead time is the time in days between the date of arrival and the release date. Do this for a while so you have at least thirty items, where more is statistically better.
3. Calculate the average lead time and cycle time in days and write them on a flip. The lead time is “the time stakeholders have to wait for us to help them” and cycle time is “the time for us to get something done.” If you keep tracking these metrics, you can demonstrate improvements (or declines) over time. Most of the experiments in this chapter help you drive both metrics down.
4. Use the cycle and lead times as inputs to Sprint Retrospectives and organization-wide workshops focused on reducing these times. What actions can be taken to shorten both? Who needs to be involved to do so? Where are impediments making it hard to shorten the lead time?
5. Recalculate the cycle and lead times every Sprint (or even more often) to monitor progress and identify further improvements.
Our Findings
• Incoming requests from stakeholders may be big enough to warrant refinement. In that case, maintain the same arrival date to the smaller items coming out of this refinement.
• Some Scrum Teams require other departments, teams, or people to do additional work before something can be released to stakeholders. For example, another team may need to perform Quality Assurance, run a security scan, or perform the actual installation. In all cases, the release date of an item remains the date when that item is actually made available to stakeholders. Using the date when your team hands off work to others is a great way to fool yourself (and the organization) that things are going well.
• Calculating an average cycle time is a rough indicator that we included for the sake of simplicity. A more precise approach is to use scatter plots and confidence intervals.2
2 Vacanti, D. S. 2015. Actionable Agile Metrics for Predictability: An Introduction. Actionable Agile Metrics Press. ISBN: 098643633X.
• Don’t worry if the items you picked are not the same size. Since we’re working with averages, differences even out. Just make sure that the work is small enough for (roughly) a Sprint.
Measure Stakeholder Satisfaction
Asking how satisfied a stakeholder is essentially amounts to asking them how valuable your work is to them. Do they think you are responsive enough to their needs? Do they believe that their investment of time or money results in sufficient value? This experiment is a simple way to use Empirical Process Control in your work with stakeholders. Rather than make assumptions about how satisfied stakeholders are, you can now make decisions based on objective data.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Determine your most important stakeholders. Don’t fool yourself by including people who don’t actually have a stake in your product. Refer back to Chapter 5 to tell the difference.
2. Start by frequently measuring stakeholder satisfaction. Use the questions below these steps as inspiration. You don’t have to ask everyone; a sample is fine. The larger the sample, the more reliable your results will be as the distribution of scores becomes more normal and less prone to extremes. We like to keep the score—as well as the historical trend—visible in the team room. It’s also something to inspect during the Sprint Review or Sprint Retrospective.
3. A natural opportunity to measure stakeholder satisfaction is at the end of a Sprint Review, when your stakeholders are physically present.
4. Set up a short survey to measure stakeholder satisfaction. A survey can be as simple as a paper form or a digital one. Keeping surveys anonymous and short removes barriers for people to participate. Make sure to explain how getting this data will help you be more effective as a team.
You can use the following questions as a starting place or substitute your own. The satisfaction for each stakeholder is represented by their average score on the four questions (on a scale from 1 to 7). You can calculate the satisfaction of groups by averaging the individual scores.
1. On a scale from 1 to 7, how satisfied are you with how responsive we are to your questions, needs, or issues?
2. On a scale from 1 to 7, how satisfied are you with the results we deliver for the money or time, or both, that you invest?
3. On a scale from 1 to 7, how satisfied are you with how fast we deliver features, updates, or fixes?
4. On a scale from 1 to 7, how satisfied do you expect to be six months from now if we continue to work as we do now?
Our Findings
• When you calculate averages for groups of stakeholders, keep in mind that averages are sensitive to extreme scores. One extremely satisfied or dissatisfied stakeholder will distort the results. As a very rough guide, for groups with fewer than 30 participants, the median is more reliable than the average. For groups with fewer than 10 participants, the mode is more reliable than the median.3
3 The median is the middle value when you order all values from low to high. Or the average of the two middle values if you have an even number. The mode is the value that appears most often.
• Don’t use the numbers as a way to compare teams. Every team is different. Instead, involve everyone—including stakeholders—in making sense of the numbers and how you can work together to improve them if they are low.
Experiments for Starting Shipping More Often
Once Scrum Teams learn how shipping fast enables them to reduce the risks of complex work, their next challenge is to remove what is getting in the way of that. The experiments that follow help you make improvements in these areas to enable you to ship faster.
Take the First Steps to Automating Integration and Deployment
Automation is the primary enabler of shipping fast. Without it, the repetitive manual work that a team must perform for every release becomes a huge barrier. This drudgery may lead them to cut corners, especially on the time they spend on manual testing, and compromise the integrity of the product.
But automation can overwhelm teams too, especially when they are working on a legacy application that was never designed with automation in mind. Where should they begin? What if they don’t have control over important parts of the process? How can they start untangling the huge web of dependencies and technologies?
Rather than avoiding the journey altogether, they are better off starting with something simple that is within their control. This experiment is based on “15% Solutions,”4 a Liberating Structure intended to trigger big change by starting small. A 15% Solution is any first step that you can do without approval or resources from others and that is entirely within your discretion to act. It is a good way to build confidence, celebrate small successes, and build the muscle to get through the hard stuff.
4 Lipmanowicz, H., and K. McCandless. 2014. The Surprising Power of Liberating Structures: Simple Rules to Unleash a Culture of Innovation. Liberating Structures Press. ASN: 978-0615975306.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Schedule a room where you have space to work for two hours and invite your team(s). Allow people to opt in to the meeting, rather than being required to join. Prepare a “value/effort” canvas on the wall or on the floor, based on the example with this experiment (see Figure 8.2).
Figure 8.2 The value/effort canvas is a great way quickly to pick the most viable options.
2. Start by traveling to a hopeful future instead of remaining stuck in the dreary present. Ask people to stand up, form pairs, and talk about what their work would look like if more of it were automated. What would be easier? What would become possible that isn’t now? Repeat this process two more times in different pairings. After three minutes, ask people to form new pairs. Repeat until people have been in three pairings. With the whole group, take a few minutes to share the most surprising, impactful, or important changes.
3. Now that you’ve helped the group create a vision of a hopeful future, return to the present. Ask people again to take a few minutes of silence to write down their 15% Solutions for moving towards that future. A 15% Solution is something that teams can do right now, without requiring approval or resources they don’t currently have access to. For example, “Replace external libraries with packages,” “Create one passing unit test for X,” or “Ask Dave to give us access to the cloud-based deployment server.” After a few minutes, invite people to share their ideas in pairs and to come up with more. After four minutes, ask pairs to form quartets and continue sharing and building on their ideas for a few more minutes. Ask the quartets to capture their five to eight most promising ideas on stickies for the next round.
4. Introduce the value/effort canvas. To give the group a reference, ask for one example of a solution that is very easy to implement (e.g., “Automatically check if site is up every hour.”) and one that is very hard (e.g., “Automatically roll back when a new version fails during deployment.”). Put the examples on the canvas. Do the same for a solution that has a small impact and one that has a huge impact. Then ask the small groups to take 10 to 15 minutes to decide for each of their solutions where they think the solution falls on the canvas compared to the rest.
5. When all the solutions are mapped, take 15 to 20 minutes with your team to select the solutions you want to work on in the next Sprint. Start with “quick wins” (low effort, high impact) and stay away from “time and money drains” (high effort, low impact). If there are many options, let people vote by placing a limited number of dots on the items they feel provide the highest benefit. Put the options on the Sprint Backlog if you are doing this experiment as part of a Sprint Retrospective. Or on the Product Backlog if you’re using this experiment outside of a Sprint Retrospective.
6. Repeat this experiment as needed to continue making progress on automation. Use the “quick wins” to build confidence that making change is possible, and build out from there by venturing into the “low-hanging fruit” and the “big wins.”
Our Findings
• Items that end up in the “high effort” half of the canvas are probably not 15% Solutions. You can refine them by doing another round to identify what first steps make sense to start work on these solutions.
• Work hard to include the Product Owners, as you probably need their help and mandate to make the solutions possible. It’s also a good way for Product Owners to understand the complexities involved in shipping fast while offering their own perspective on what is the most valuable.
Evolve Your Definition of Done
Your Definition of Done is the set of rules that governs the implementation of every Product Backlog item. To be considered “Done,” every item must conform to the Definition of Done. This definition reduces rework and problems with quality by setting clear goalposts around what quality and professionalism mean to your work. There are three steps to using a Definition of Done successfully:
1. Having a Definition of Done
2. Actually using a Definition of Done
3. Gradually evolving your Definition of Done to make it more professional
If you don’t have a Definition of Done or don’t use it, you will have to take care of that first. Then you can gradually expand the definition to ship faster.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Gather your Scrum Team and familiarize yourselves with your current Definition of Done. Make sure it accurately represents what you are currently doing. A good opportunity is to do this periodically during a Sprint Retrospective.
2. Ask the question “If we wanted to release immediately after a Sprint, what rules should be added to our Definition of Done to ensure a high-quality result?” What checks would be necessary in addition to the current Definition of Done so that each Product Backlog item, and the Increment as a whole, is “Done” to the extent that the Increment can be released immediately after the Sprint? Include even the rules that seem completely infeasible at this time but are vital to guarantee high-quality releases. Collect the additional rules on a second list.
3. You now have two lists: your current Definition of Done, and a list of rules you are not yet following or cannot yet follow. The second list represents the gap between what you are doing now and what is necessary to reduce the risk of complex work (see Chapter 4). Each item on that gap list would take away or reduce a risk that is present today. The bigger the gap, the more risks you accept and the more work will be needed. Most Zombie Scrum Teams start with a big gap. When you find yourself in a heavily zombified environment, the best strategy is to start broadening your Definition of Done by making small improvements instead of going for huge shifts.
4. Ask your team “What would be our first step towards being able to release immediately after the Sprint?” What is something that your team can do right now, without needing approval or resources they don’t have access to? Who needs to be included? Where can you find help and support? The experiments “Take the First Steps to Automating Integration and Deployment” and “Ship Every Sprint” in this chapter help when your team is struggling. Make sure to come up with specific, actionable steps such as automating certain tasks or involving people to broaden your Definition of Done.
5. Add one or two action steps to the Sprint Backlog of upcoming Sprints. Keep both your Definition of Done and the gap list clearly visible in your team room. Collaborate with stakeholders about your Definition of Done and your gap list. They are your natural allies. An expanding Definition of Done increases quality and allows stakeholders to receive value sooner. Continuously ask: “What creative solutions can we find to include items from our gap list into our Definition of Done and prevent the associated risks?”
Our Findings
• Break up bigger improvements into items that you can actually accomplish within a Sprint. It is more helpful to take several smaller steps than one big leap.
• If you are already able to release immediately after a Sprint, you can make your experiment more ambitious by asking your team to consider adding rules or steps that improve your ability to release individual Product Backlog items during the Sprint.
• Make sure your improvement activities are aligned with your business needs. Dedicate large portions of a Sprint to improvement only when everyone on your Scrum Team and your stakeholders are on board.
Ship Every Sprint
When you’re developing a new product, you may be tempted to postpone shipping until everything in the planned release is done. Development Teams may fear that the quality of their work isn’t good enough, and so they delay releasing the product. Product Owners may want to delay shipping to add more features to deliver more value. These decisions may sometimes be the right call, but Scrum Teams that perpetually postpone releases are setting themselves up for failure. Releasing infrequently removes the pressure that helps the Scrum Team improve their product and their own way of working, and lets bad habits take hold. It allows Product Owners to pile more and more features of unknown value into a larger and larger release, delaying feedback, increasing waste, and delaying the realization of value that users will receive from the features that turn out to be actually useful.
This experiment is about bringing the pressure of releasing front and center. Instead of considering shipping fast a luxury, this experiment makes it a principle to enable learning based on feedback that Scrum Teams can only acquire by shipping fast (see Figure 8.3).
Figure 8.3 Development Teams continue adding more details to the product while the customer urgently needs a much simpler version.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. With your Scrum Team, explore what happens when they release infrequently. What mistakes do they make? Where do risks increase? As an experiment, set a goal to release, at a minimum, at the end of every Sprint for five or more Sprints.
2. Together, explore the different release strategies discussed at the end of Chapter 7. From the principle that you are going to release every Sprint, which strategies are the most feasible?
3. Together, agree how you will celebrate a release to production. Will the Product Owner bring snacks? Will you go for drinks afterwards? Will you watch a zombie movie together? Involve your stakeholders in the celebration.
4. Keep track of the number of Sprints since your last release, and draw attention to that number during your Sprint Review and your Daily Scrum. Use your Sprint Retrospectives to investigate what you achieved by releasing more frequently.
5. If you are unable to release, capture your reasons for not doing so; these are impediments you want to focus on. For example, the team may lack the skill to perform releases or may depend on others to do it. The technology and infrastructure may not support it. Or the Product Owner doesn’t have a mandate to release.
6. Make the number of Sprints since the previous release, as well as impediments that got in the way, transparent in the team room.
Our Findings
• This experiment is a leap that requires the respect and trust of the Scrum Team. When you—the one initiating this experiment—don’t have it, focus on other experiments first.
• Your team may have no control over releases. If you can’t change the frequency of releases or exercise more control over them, you may have to settle for an imperfect alternative: releasing to a staging or acceptance testing environment. Although you will not realize the same benefits as releasing to actual stakeholders, you can still learn more than not releasing at all. Use this environment during your Sprint Review to inspect your Increment with stakeholders.
• Your stakeholders are your natural allies. Involve them to help you remove the impediments that are getting in the way of delivering value to them faster.
Ask Powerful Questions to Get Things Done
Shipping fast is difficult when Scrum Teams struggle to create a “Done” Increment every Sprint. This often occurs because team members are working on too many items at the same time and have difficulty completing any of them. As the end of the Sprint approaches, stress rises as team members rush to complete all their work in progress. This experiment helps you ask powerful questions to help Development Teams remain focused on the Sprint Goal.
You can gently challenge the way that members of the Development Team collaborate during a Sprint. Like a psychologist, you can ask the powerful questions that everybody knows should be answered but are avoided because the answers may be inconvenient. The Daily Scrum is a natural opportunity to ask these questions, as this is where collaboration is (at the very least) coordinated.
Effort/Impact Ratio
Steps
Before engaging in this experiment, have an open conversation with the Development Team about whether it’s okay for you to help them think by occasionally asking powerful questions. Here are some examples of questions you (or others) can ask while people talk about the items they’re working on, or planning to work on:
• How does working on this Product Backlog item help us achieve the Sprint Goal?
• If you were a stakeholder, what would be the most valuable thing for us to work on today in order to achieve the Sprint Goal?
• Instead of picking up something new, where can you help others get work done that is already in progress?
• Where can others help you get this item done?
• What is keeping us from completing this item? Where do we need help?
• If we stopped our work on this item, how would it impact our Sprint Goal?
• What is the biggest bottleneck in our current work together? What can we do today towards removing it?
• If we pick up new work instead of working on things that are already in progress, how does this increase our likelihood of achieving the Sprint Goal?
Try it for several Sprints and see what happens. You’ll probably notice that others start asking similar questions of each other. Learning to ask the right questions, and how to ask them, is a skill the Development Team also has to learn.
Our Findings
• Asking powerful questions isn’t hard. The challenging part of asking powerful questions is doing so in a friendly and inviting way that doesn’t sound condescending and pedantic. Practice and ask for feedback.
• If you feel uncomfortable interrupting with questions, or if you notice resistance to your presence, you can make an agreement with the Development Team on a signal they can use to let you know that they’re open to a powerful question.
Experiments for Optimizing Flow
It’s hard to ship fast when teams struggle to get items from their Sprint Backlog completely done within a single Sprint. There are many reasons for this friction. A team may be missing skills, or they may be working on items that are too large, or they may be working on too many things at the same time. The experiments that follow help you optimize flow by removing bottlenecks and working on fewer things at the same time.
Increase Cross-Functionality with a Skill Matrix
Is your team experiencing bottlenecks because only one person is capable of testing work? Is a developer on your team struggling to implement something that is blocking everyone else until she is done? Do team members start work on unrelated and low-value tasks simply because they have nothing else to do? These symptoms arise when teams are not cross-functional enough, causing work to pile up for some people and creating delays for others.
The Scrum Framework is built on cross-functional teams because they are better able to overcome the unpredictable challenges that arise when working on complex problems. Your team is cross-functional enough when items flow smoothly through your workflow. Cross-functionality does not mean that everyone can perform any kind of task or that you must have at least two experts for every kind of skill on your team. Often, just having another person who has a particular skill, even when they are slower and less experienced at it, already improves flow enough to prevent most problems.
This experiment offers your team practical strategies to help them improve their cross-functionality (see Figure 8.4).
Figure 8.4 Increase cross-functionality with a skill matrix.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. With your team, map the skills you need during a typical Sprint. Together, create a matrix on a flip chart where you plot the members of your team against the skills you identified. Invite people to decide for themselves what skills they possess and to self-rate their proficiency with it using plus signs (+, ++, and +++).
2. When you’re done with the matrix, ask “What do you notice about how the skills on our team are distributed? What is immediately obvious?” Invite people to reflect on this question individually for two minutes, then for a few minutes in pairs. With the whole group, capture important patterns on a flip chart.
3. Ask “What does this mean for our work as a team? Where should we focus our improvements?” Let people reflect on this question individually, then in pairs for a few minutes, and then capture the biggest insights on the flip.
4. Ask “Where should we start improving? What first step is possible for us without needing approval from others or resources we don’t have?” Let people reflect on this individually, then in pairs for a few minutes, and then capture the biggest insights on the flip chart. Use the strategies as described in the next section as inspiration when people struggle to see possibilities.
5. Keep the skill matrix in your team room and update it frequently. You can tie it to flow-based metrics such as throughput and cycle time, which should improve over time as cross-functionality increases. See the experiment “Limit Your Work in Progress” to learn how to do this.
There are many strategies for improving cross-functionality on your team.
• You can add people to your team who already have skills that you need. Although a seemingly obvious solution, adding skilled people isn’t always possible. It’s also doubtful how structural this solution really is, as it can cause “Skill Whac-A-Mole,” where other skills then become bottlenecks and you have to add even more specialized people. Instead of maintaining high degrees of skill specialization, it’s often more effective to distribute skills.
• You can automate tasks that require scarce skills. For example, creating a backup of a database or deploying a release are critical tasks that are often performed by database specialists and release engineers. When you automate these tasks, you improve not only the speed of the activity, but also how frequently these tasks can be performed, while also removing the constraint.
• You can purposefully limit your team’s work in progress, putting constraints on how much new work can be started, to encourage cross-functionality. Instead of starting a new Product Backlog item, because there isn’t anything else to do, ask “How can I help others complete their current work?” or “How can others help me complete this work?” The Daily Scrum is a natural opportunity to offer and request help.
• You can encourage people to pair on tasks that only a few people can perform. When you pair experienced and inexperienced people, the less experienced people develop new skills, and both people find better ways to support each other. For example, pairing developers who typically work on the front end with developers who work on the back end makes it easier for them to support each other when bottlenecks occur.
• You can use approaches such as “Specification by Example”5 to allow customers, developers, and testers to work together to develop automated test cases. In a similar vein, front-end frameworks (e.g., Bootstrap, Material, or Meteor) can make it easier for designers and developers to work together with a common design language for elements.
5 Adzic, G. 2011. Specification by Example: How Successful Teams Deliver the Right Software. Manning Publications. ISBN: 1617290084.
• You can organize skill workshops where people who are skilled at a particular task demonstrate how they perform it and help others perform it.
Our Findings
• When Scrum Teams have been affected by Zombie Scrum for a long time, they may have come to believe that nothing ever changes. You may even face understandable cynicism. If this is the case, start with the smallest possible improvements to show people that change is possible and worth the time spent making it happen.
• When the skills of team members are narrowly specialized, they may struggle to see how broadening their skills will benefit the team. They may also fear losing their uniquely visible contribution to the team. Make an effort to celebrate the successes of the team to emphasize the collective outcomes over individual contributions.
Limit Your Work in Progress
Intuitively, multitasking feels like a way to get more work done. But when people, especially when they work on teams, try to work on many things at the same time, they usually struggle to get any of it actually finished. They are certainly busy, but they lose a lot of time reestablishing context when they pick up a task again. When you consider how teams work, and analyze how much work they really complete, you find that teams get more done when they work on less at the same time. Optimizing flow by limiting work in progress (WIP) is built on this counterintuitive truth. It fits well with the Scrum Framework because it gives teams direction on how to optimize their work during a Sprint.
This experiment is a good starting point for limiting your work in progress and seeing what happens because of that. For more information and potential pitfalls, we highly recommend The Kanban Guide for Scrum Teams by Scrum.org.6
6 Vacanti, D. S., and Y. Yeret. 2019. The Kanban Guide for Scrum Teams. Scrum.org. Retrieved on May 26, 2020, from https://www.scrum.org/resources/kanban-guide-scrum-teams.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. With your Scrum Team, set up a Scrum Board that represents how Product Backlog items move through the team’s current workflow (see Figure 8.5). For example, when an item is pulled from the Sprint Backlog, it begins in “Coding,” then moves to “Code Review,” “Testing,” and “Releasing,” and ends in “Done.” Don’t start with a dozen columns; start with the minimum.
Figure 8.5 An example of a Scrum Board with work-in-progress limits and flow-based metrics
2. With your Scrum Team, decide on a limit to the number of items that are allowed to be in any one column at a given time. For example, you may decide to limit to three items in Coding and Testing and two items in each of the other columns. Although you want to limit your work in progress as much as possible, a limit of one may be unfeasible. Finding the optimal limits is an empirical process, so experiment with different limits and measure how they affect the amount of work done during a Sprint. A good starting point is to look at how much work is usually “in progress” for a particular column in a regular Sprint and lower the work in progress to see what happens.
3. Agree with your Scrum Team to respect the WIP limits for the upcoming Sprints. In practice, this means that work can only be pulled into a column when the number of items in that column is lower than its limit. When every column is at maximum capacity, members who are available pair up or support work that is already in progress rather than picking up more. You will notice that the limits induce pressure on the system by constraining what is possible. Instead of simply adding more work, the team learns that collaboration is now essential. The limits also surface impediments as certain bottlenecks become apparent. For example, work may quickly pile up in a Testing column when there is only a part-time member who can take care of testing.
4. Tracking two related flow-based metrics will help you determine where and how to optimize your limits. The first is the throughput, or the number of items completed each Sprint. The second is the cycle time, or the number of days that items spend on the board between the column for the Sprint Backlog and the one for Done. A simple approach to track cycle time is to dot the items for every day they are in progress and calculate the number of dots at the end. As cycle time decreases, your team becomes more responsive and more predictable at the same time.7 Throughput should also increase as more items get completed and more value is delivered.
7 Vacanti, Actionable Agile Metrics for Predictability.
5. Use these metrics as input for your Sprint Review and Sprint Retrospectives and to drive decisions you make about changing your limits to work in progress.
Things to Watch Out For
• Resist the temptation to change limits during the Sprint, but use your Sprint Retrospectives to make such changes. Track the impact of those changes on your flow measures. More often than not, increasing your work-in-progress limit essentially obscures underlying impediments. For example, increasing the work-in-progress limit for your Testing column to reduce the pressure on the one tester on your team would hide the fact that you don’t have enough people who can test. Instead, find ways to add more of that skill to your team (e.g., with training, new members, or other ways of testing).
• Recruit your Product Owner and your stakeholders to help you remove the impediments that emerge by enforcing work-in-progress limits. Help them see how removing impediments will improve throughput and lower cycle time, and why this is beneficial to them.
Slice Your Product Backlog Items
One of the most persistent reasons why teams struggle to release is that their items are too big to finish in one Sprint. The larger items are, the more risk and uncertainty they hide. When teams work on two, three, or four huge items during a Sprint, every setback or delay can result in the inability to deliver an Increment at all. So one of the most important skills for Development Teams is to learn how to break down larger items into smaller ones. Smaller items increase the flow of work through a team, improve predictability, and give more flexibility to decide where to add or drop items in order to achieve the Sprint Goal. This is exactly what the ongoing activity of refinement in the Scrum Framework is all about.
This experiment is about starting to develop these skills. As a Scrum Master, Developer, or Product Owner, you encourage the development of this skill by asking powerful questions. This experiment is based on the Liberating Structure “Wise Crowds.”8
8 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Work with the Development Team to organize a refinement workshop. Allow people to opt in, instead of requiring everyone to show up. Select the largest items. If possible, identify one member of the team, potentially the Product Owner, who is most likely to have a good understanding of what the item entails. Print the questions outlined in this experiment on cards, adding more if you want.
2. For the first item, invite the member (the client) who knows most about the item to present it briefly for a few minutes. The team (the consultants) can ask clarifying questions for another few minutes. Then invite the client to turn their back to the team so they don’t influence what’s coming next. Invite the team to take 15 minutes to talk about how the item can be sliced, using the questions that follow as inspiration. The client is free to take notes, but they don’t engage in the discussion.
3. The client turns back to the team and takes a few minutes to share what they discovered while listening. Which strategies seemed the most feasible? Give the whole group 10 minutes to capture their ideas.
4. Repeat as often as people feel they are still getting value from the exercise. You can also do multiple rounds on a single item, building on ideas from earlier rounds.
Here are some powerful questions you can ask:
• If we had to implement this item in only one day, what would we focus on? What could be done later?
• What is the smallest and simplest possible way to implement this item?
• Which steps do users go through when using functionality described in this item? Which steps can we implement now? Which can be implemented later?
• Of the business rules that are important for this item, which are the least vital or impactful? Which can we let go of for now or work around creatively?
• What do the “unhappy paths” for this item look like: What are some unintended ways that users could interact with this functionality? Which are the least common ways?
• Which of the acceptance criteria for this item can we get away with by implementing later?
• Which groups of users will be using this item? Which group is the most important? What can we let go of if we focus on that group?
• Which devices or modes of presentation do we need to support for this item? Which ones are least common or important?
• Which CRUD (create, read, update, delete) interactions do users have with this item? Which could be implemented later without much impact now?
Our Findings
• Most developers love their craft and care deeply about the work they do. They don’t want to deliver something that feels incomplete—and that’s a good thing. If developers start to express concerns that slicing a Product Backlog item will result in something that is incomplete, or of low quality, emphasize that the goal of slicing isn’t to deliver incomplete work, but to find the smallest possible implementation of a larger item that is, in itself, complete and of high quality.
• Perform the actual administrative work of updating the Product Backlog, especially when you work with tools such as Jira or TFS, outside of this workshop. Waiting for people to write something down is a huge energy drain for groups.
• The goal is not to end up with a Product Backlog where all the items have the same size. Instead, focus on breaking down each item as much as possible.
Now What?
In this chapter, we explored experiments that help your team and organization to ship fast(er). Although the experiments differ in difficulty, each should create a noticeable improvement. Signs that you are recovering include increased stakeholder satisfaction, higher quality, and lower stress levels. And if you’re still stuck, there are more experiments in the following chapters that help you sort out other issues first. Don’t give up hope. The road to recovery can be long, but it is a road worth walking.
Looking for more experiments, recruit? There is an extensive arsenal available at zombiescrum.org. You can also help expand our collection by suggesting what worked well for you.”
