Running Multiple Improvement Experiments in Parallel
Categories:
agile,
Scrum,
Improvement,
Choose your WoW,
#ChooseYourWoW,
#ContinuousImprovement,
Experiment,
#experiment,
GCI
Categories: agile, Scrum, Improvement, Choose your WoW, #ChooseYourWoW, #ContinuousImprovement, Experiment, #experiment, GCI
|
In Continuous Improvement Through Experimentation we described how a team could improve their way of working (WoW) via the strategy depicted in Figure 1. In Better Decisions Lead to Better Process Outcomes we showed how you can increase the rate of improvement by identifying potential improvements that are likely to work in your situation. In this blog we describe how to accelerate your team’s improvement by running multiple improvement experiments in parallel. Figure 1. Running an experiment to evolve your WoW (click to enlarge).
The strategy is exactly as it sounds. Instead of running a single process improvement experiment at a time you run several at once. You may decide to do this for one of several reasons:
Although this strategy will help your team to increase its rate of improvement, there are two fundamental challenges with it. First, it is harder to assess the effectiveness of an individual technique when multiple experiments are being run in parallel because they can interact with each other. For example, you decide to experiment with holding stakeholder demos and with active stakeholder participation at the same time (you weren’t doing either one until now). When you see improvements in the quality of stakeholder satisfaction with the product you’re developing, is that the result of one of the practices but not the other or both of them in combination? If can’t definitively answer that question, it will make it hard to assess the effectiveness of each technique. Second, you only have so much capacity for experimenting with new WoW. It can be hard enough, sometimes, to convince your organization’s leadership to allow you the time to experiment in the first place. Getting time to run multiple experiments is even harder. Our point is that running an experimentation-based approach to evolving your way of working (WoW) makes sense. In some cases running multiple experiments in parallel can be even more effective. MORE INFORMATION
For more information about choosing and evolving your WoW, we humbly suggest that you consider reading our book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. If you want to succeed at enterprise agile you need choices, not prescriptions. |
Continuous Improvement Through Experimentation
Categories:
agile,
Scrum,
Kanban,
lean,
Process,
#ChooseYourWoW,
#ContinuousImprovement,
#Experimentation,
#Kaizen,
#ProcessImprovement,
Experiment,
GCI
Categories: agile, Scrum, Kanban, lean, Process, #ChooseYourWoW, #ContinuousImprovement, #Experimentation, #Kaizen, #ProcessImprovement, Experiment, GCI
|
A fundamental philosophy of agile is that teams should own their own process, or as we like to say in Disciplined Agile (DA) teams should choose their way of working (WoW). Of course this is easier said than done in practice. The challenge is that every team is unique and faces a unique situation – in other words, context counts. Furthermore, there are no “best practices,” rather, every practice has tradeoffs and works well in some situations and poorly in others. Worse yet, you really don’t know how well a technique will work for you until you actually try it out in your environment. Given all of this, how can a team choose its WoW? Since the 1980s the lean community has shown that an effective way to evolve your process is to do so as a series of small incremental improvements, a strategy called kaizen. Numerous organizations have taken this approach over the years, and virtually every single DevOps success story is based on a multi-year kaizen-based continuous improvement strategy. Figure 1 depicts the workflow of implementing a single improvement, with Deming’s Plan-Do-Study-Act (PDSA) loop on the right-hand side to indicate the iterative nature of the overall process. Figure 1. Running an experiment to evolve your WoW (click to enlarge).
Let’s explore each step one at a time:
Figure 2 shows how your team’s effectiveness improves over time with a continuous improvement approach. When you experiment with a new technique and it works out well for your team then your team effectiveness improves. When an experiment “fails” your team effectiveness dips for a bit – the technique didn’t work well in your situation – but then you end the experiment and go back to your previous way of working (your team’s level of effectiveness goes back to where it was). Figure 2. Experiment to evolve your WoW (click to enlarge).
When you keep at it, when you adopt a kaizen mindset, your team effectiveness increases over time as we see in Figure 3. The figure also shows that when you first adopt a continuous improvement strategy that your team effectiveness drops at first because you’re learning how to follow the continuous improvement process of Figure 1. In many ways you begin this improvement journey by experimenting with this experimentation-based strategy. Figure 3. Continuous improvement over time (click to enlarge).
Some organizations struggle with the idea of experimentation, likely because they still believe in the idea of “best practices” and often because they’re looking for an easy answer. They’re afraid to experiment because they might “fail,” not realizing that a failed experiment teaches you what doesn’t work for your team given your current situation. Running small, “safe to fail” experiments is absolutely critical for improving your WoW. Where this blog overviewed the strategy of Continuous Improvement, in the next blog in this series we will see how better decisions lead to better outcomes via Guided Continuous Improvement. Stay tuned! More Information
For more information about choosing and evolving your WoW, we humbly suggest that you consider reading our book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. If you want to succeed at enterprise agile you need choices, not prescriptions. |





.png)


2.png)
1.png)
1.png)
