While working with organizations to help them to learn how to improve their way of working (WoW), we’ve developed a technique that we call guided continuous improvement (GCI). Adopting an agile method such as Scrum, or a framework such as SAFe, may give you an initial start at improving your WoW you will quickly find yourself in “method prison.” The organizations that break out of method prison do so with a kaizen-based continuous improvement approach, or better yet GCI.
First, some definitions:
In the article we go into the details of the technique, exploring:
We hope you find the article to be a game changer for your agile adoption efforts.
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.
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.
This posting, the latest in our series focused on a disciplined agile approach to continuous improvement, overviews the activities associated with it. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy. The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog posting we present the goal diagram for the Continuous Improvement process blade and overview its process factors.
The following process goal diagram overviews the potential activities associated with disciplined agile continuous improvement. These activities are performed by, or at least supported by, a process improvement team (sometimes referred to as a Software Engineering Process Group, or SEPG).
The process factors that you need to consider for continuous improvement are:
Future blog postings in this series will explore the workflow between continuous improvement and other process blades as well as the internal workflow of a process improvement team.