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.
Let’s explore each step one at a time:
- Plan: Identify an issue. A potential issue, perhaps an inefficiency in your current WoW or an unanticipated side effect of your WoW, becomes apparent to you. This may have occurred as an insight during a reflective session such as a retrospective, as the result of a customer complaint, as an observation, or simply as an insight that someone has. Regardless of the source, you have identified an issue that you hope to address.
- Plan: Identify a potential improvement. The team identifies a technique, either a practice or strategy, that they believe will work for them. This may be something someone on the team has done before, something they’ve read about, or even an idea that they’ve identified on their own. An important consideration is to try a technique where it is “safe to fail” at it – you shouldn’t be putting your team at risk by experimenting with a new WoW. If an experiment is deemed to risky to try, attempt to break it down into a series of smaller experiments that are less risky. It is also critical to identify the criteria against which you’re going to assess the effectiveness of the technique. Ideally most of the criteria is quantifiable in nature, although don’t ignore qualitative measures too.
- Do: Try out the new WoW (experiment). The team needs to see how well the technique works for them in their environment. Do they have the skills to perform the technique? How well does it work given their technology platform? How well does it work given their organization and team culture? The team needs to give the experiment sufficient time to determine how well it works in practice. This could several anywhere from several days to several months, although in most cases several weeks is sufficient.
- Study: Assess effectiveness. After you’ve run the experiment you should assess how well it worked for you. This assessment should be against the criteria that you agreed to at the beginning.
- Act: Adopt or abandon the new WoW. Sometimes you’ll find that a new technique works incredibly well for you, and other times you’ll experience the other extreme and discover that a technique is an abysmal failure for you. But in most cases there will be some aspects of the technique that work well for you and other aspects that do not (an indication that maybe you need to consider running a new experiment to identify a solution). Our advice is to adopt what works well for you and to abandon or better yet improve upon what doesn’t.
- Act: Share learnings with others. DA™ teams are enterprise aware, recognizing that they are only one of many teams within your organization. So, when a team learns something about a technique the implication is that they should share it with others. Strategies for doing so are addressed by the Evolve WoW process goal.
- Act: Share learnings. When you learn something about a technique you should share it with others.
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).
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.
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.