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 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 the Liberating Structure 15% Solutions. It is a good way to grow confidence, celebrate small successes, and build the muscle to get through the hard stuff.
Required skill
Automation is hard, but identifying and executing the first steps isn’t.
Impact on survival
Since you can’t really ship faster when you don’t automate, your chances of survival will get a good boost.
Steps
To try this experiment, do the following:
- Schedule a room where you have space to work for 2 hours and invite your team(s). Allow people to opt into the meeting, rather than being required to join. Prepare a ‘value/effort’-canvas on the wall or on the floor as per the example with this experiment.
- 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 when more would be automated. What would be easier? What would become possible that isn’t now? Repeat this two more times in different pairings. After three minutes, ask people to form new pairs. Repeat until people have been in three pairs. With the whole group, take a few minutes to share the most surprising, impactful, or important changes.
- Now that you’ve helped the group create a vision of a hopeful future, return to the present. Ask people to again 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 5–8 most promising ideas on stickies for the next round.
- Introduce the ‘value/effort’-canvas. In order to give the group a reference, ask for one example of a solution that is very easy to implement (e.g. “Automatically check if the site is up every hour”) and one that is very hard (e.g. “Automatically rollback when a new version fails during deployment”). Put them 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–15 minutes to decide for each of their solutions where they think they are on the canvas compared to the rest.
- When all the solutions are mapped, take 15–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 & 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 them 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.
- Repeat this experiment as needed to continue making progress on automation. Use the “Quick Wins” to build confidence that it 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.
Looking for more experiments?
Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.