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?
While working with organizations to help them to learn how to improve their WoW, we’ve developed a technique that we call guided continuous improvement (GCI). Let’s start with some definitions:
- A kaizen loop is an approach where a team experiments with a small change in their way of working (WoW), adopting the change if it works in their given context and abandoning it if it doesn’t. The goal of kaizen is often to reduce or better yet eliminate waste (muda) or to eliminate overly hard work (muri).
- Continuous improvement is the act of applying a series of kaizen loops to improve your WoW over time.
- Guided continuous improvement (GCI) extends the kaizen loop strategy to use proven guidance to help teams identify techniques that are likely to work in their context. This increases the percentage of successful experiments and thereby increases the overall rate of process improvement.
This article is organized into the following topics:
- Every team is unique
- Agile methods/frameworks only get you so far
- Kaizen: Improvement through small changes
- Guided Continuous Improvement (GCI)
- Escaping method prison
- Concluding Thoughts
Every Team Chooses It’s Own WoW
Agile teams are commonly told to own their process, to choose their WoW. This is very good advice for several reasons:
- Context counts. People and teams will work differently depending on the context of their situation. Every person is unique, every team is unique, and every team finds itself in a unique situation. A team of five people will work differently than a team of twenty, than a team of fifty. A team in a life-critical regulatory situation will work differently than a team in a non-regulatory situation. Our team will work differently than your team because we’re different people with our own unique skillsets, preferences, and backgrounds.
- Choice is good. To be effective a team must be able to choose the practices and strategies to address the situation that they face. The implication is that they need to know what these choices are, what the trade-offs are of each, and when (not) to apply each one. In other words, they either need to have a deep background in software process, something that few people have, or have a good guide to help them make these process-related choices. Luckily this book is a very good guide.
- We should optimize flow. We want to be effective in the way that we work, and ideally to delight our customers/stakeholders in doing so. To do this we need to optimize the workflow within our team and in how we collaborate with other teams across the organization.
- We want to be awesome. Who wouldn’t want to be awesome at what they do? Who wouldn’t want to work on an awesome team or for an awesome organization? A significant part of being awesome is to enable teams to choose their WoW and to allow them to constantly experiment to identify even better ways they can work.
In short, we believe that it’s time to take back agile. Martin Fowler has coined the term agile industrial complex (AIC) to refer to the observation that many teams are following a “faux agile” strategy, sometimes called “agile in name only” (AINO). This is often the result of organizations adopting a prescriptive framework, such as SAFe, and then forcing teams to adopt it regardless of whether it actually makes sense to do so (and it rarely does). Or forcing teams to follow an organizational standard application of Scrum. Yet canonical agile is very clear, it’s individuals and interactions over processes and tools – teams should be allowed, and better yet supported, to choose and then evolve their WoW.
Agile Methods/Frameworks Only Get You So Far
Many teams start their agile journey by adopting agile methods such as Scrum, Extreme Programming (XP), or Dynamic Systems Development Method (DSDM)-Atern. Large agile teams dealing with “scale” may choose to adopt SAFe, LeSS, or Nexus to name a few. These methods/frameworks each address a specific class of problem(s) that agile teams face, and from our point of view they’re rather prescriptive in that they don’t provide you with many choices. Another problem is that they only address some aspects of tactical agility at scale, and certainly not strategic agility at scale, regardless of their marketing around being agile scaling frameworks. Sometimes, particularly when frameworks are applied to contexts where they aren’t an ideal fit, teams often find that they need to invest significant time “descaling” them to remove techniques that don’t apply to their situation, then add back in other techniques that do. Having said that, when frameworks are applied in the appropriate context they can work quite well in practice. When you successfully adopt one of these prescriptive methods/frameworks your team productivity tends to follow the curve shown in Figure 1. At first there is a drop in productivity because the team is learning a new way of working, it’s investing time in training, and people are often learning new techniques. In time productivity rises, going above what it originally was, but eventually plateaus as the team falls into its new WoW. Things have gotten better, but without concerted effort to improve you discover that team productivity plateaus.
Figure 1. Team effectiveness when adopting a prescriptive method or framework (click to enlarge).
Some of the feedback that we get about Figure 1 is that this can’t be, given that the claim is that with Scrum you can do twice the work in half the time. Sadly this claim of 4X productivity improvement doesn’t seem to hold water in practice. A recent study covering 155 organizations, 1,500 waterfall and 1,500 agile teams found actual productivity increases of agile teams, mostly following Scrum, to be closer to 7 to 12 percent. At scale, where the majority of organizations have adopted SAFe, the improvement goes down to 3 to 5 percent.
We are constantly running into teams that have adopted a prescriptive agile method, very often Scrum or SAFe, that have plateaued because they’ve run into one or more issues not directly addressed by their chosen framework/method. Because the method doesn’t address the problem(s) they face, and because they don’t have expertise in that area, they tend to flounder – Ivar Jacobson has coined the term “they’re stuck in method prison.”
Kaizen: Improvement Through Small Changes
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 2 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 2. Running an experiment to evolve your WoW (click to enlarge).
Let’s explore each step one at a time:
- 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.
Figure 3 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 3. 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 4. 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 2. In many ways you begin this improvement journey by experimenting with this experimentation-based strategy.
Figure 4. 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.
Guided Continuous Improvement (GCI)
So what can we do to improve on this? The linchpin is the very first step in the process of Figure 2, the identification of a technique to experiment with. As you see in Figure 5, when we improve the likelihood that a technique will work in our situation then our effectiveness rises faster due to more successful experiments. We call this guided continuous improvement (CGI).
Figure 5. Guided continuous improvement increases the chance of successful experiments (click to enlarge).
It’s a simple idea – with better process decisions our average rate of process improvement is faster, as you can see in Figure 6.
Figure 6. Team effectiveness improves at a quicker rate with guided continuous improvement (click to enlarge).
There are three ways that you adopt a GCI-based approach:
- Hire an experienced coach (and listen to them). Although it can be
hard to find an experienced agile coach they do exist and if you’re lucky enough to have one then follow their guidance.
- Apply the Disciplined Agile (DA) toolkit. There are several ways you can apply the DA toolkit to help you to make better process decisions. Instead of prescribing the “best practices” you must adopt, DA instead advises you on process-related issues you need to think about and the options available to you. Such issues include what you should consider when choosing a lifecycle, what you should consider when forming your team, and what you should consider when addressing changing stakeholder needs (to name a few important things). The DA toolkit then presents you with potential options and the trade-offs associated with those options. This gives you an idea as to what techniques you might want to experiment with and what is likely to happen if you do, enabling you to make better process decisions. This site overviews these decisions and the book Choose Your WoW! summarizes the trade-offs for Disciplined Agile Delivery (DAD). GCI is one of several strategies for applying the DA toolkit, see the process goal Evolve Your Way of Working (WoW) for further ideas.
- Both of the above. Good coaches have the humility to recognize that they don’t know everything, and will leverage the DA toolkit to help your team to make better decisions about new WoW to experiment with.
Escaping Method Prison
The good news is that these two strategies, adopting a prescriptive method/framework, then improving your WoW through GCI, can be combined as you see in Figure 7. By applying a continuous improvement strategy, or better yet GCI, their process improvement efforts soon get back on track. Furthermore, because the underlying business situation that you face is constantly shifting it tells you that you cannot sit on your “process laurels” but instead must adjust your WoW to reflect the evolving situation.
Figure 7. Evolving away from a prescriptive agile method (click to enlarge).
To be clear, GCI at the team level tends to be a simplified version of what you would do at the organizational level. At the team, level teams may choose to maintain an improvement backlog of things they hope to improve. At the organizational area or enterprise levels we may have a group of people guiding a large transformation or improvement effort that is focused on enabling teams to choose their WoWs and to address larger, organizational issues that teams cannot easily address on their own.
Continuous improvement, evolving your WoW through experiments, is a proven way to achieve lasting process improvement. Lean practitioners have been doing this for decades and virtually every DevOps case study advises you to evolve your WoW this way. Guided continuous improvement (GCI) takes it one step further and streamlines your experimentation efforts. Agile methods/frameworks will only get you part of the way towards working effectively, the rest of your journey requires you to adopt a constant learning, continuous improvement strategy. Disciplined Agile (DA), and more importantly DA practitioners, can help you do that.