Disciplined Agile

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:

• A kaizen loop is an approach where a team experiments with a small change in their WoW, adopting the change if it works in their given context and abandoning it if it doesn’t.
• 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.

In the article we go into the details of the technique, exploring:

• Why every team is unique
• Why agile methods/frameworks will only get you so far
• How to apply a kaizen-based improvement strategy
• How to improve kaizen loops with the DA toolkit
• How to break out of “method prison”

We hope you find the article to be a game changer for your agile adoption efforts.

Choosing your way of working (WoW) isn’t just a one-time event, instead it is an ongoing effort.  Figure 1 shows the workflow for choosing and then evolving your WoW.  In our previous blog, Choosing Your Initial Way of Working (WoW), we worked through the left-hand side of Figure 1.  In this blog we explore how a team evolves their WoW via a series of experiments, hopefully ones that are guided by the Disciplined Agile (DA) toolkit.

Figure 1. The workflow for choosing and evolving your WoW.

As you can see in Figure 1, evolving your WoW is a two-step process at a high-level.  First, you identify that you have a potential issue with your current WoW and second you experiment with one or more potential improvements that you believe will address the issue that you’ve identified.  And of course you repeat this strategy whenever needed.

Identify Potential Process Issue

There are various ways that a team can identify a potential process issue:

1. Retrospectives. Retrospectives are a strategy for a team to reflect upon what is working well for them and what isn’t working so well. Some teams, particularly agile ones, will choose to hold a retrospective at the end of each iteration/sprint whereas lean teams tend to hold them on an as needed basis.  Regardless, one of the outputs of such a working session is a list of one or more potential issues the team wants to address.
2. Someone recognizes there’s an issue. Sometimes it’s as simple as someone saying “Hey, I think that X is a problem. Is there anything we can do about it?”
3. Someone from outside the team points it out. It can also be as simple as someone from outside of the team – one of your stakeholders, a colleague on another team, a leader within your organization, or others – identifying a potential issue.

The point is that there are multiple ways that potential issues are identified.  So what are you going to do about them?

Experiment with Potential Improvement(s)

For any process issues that you believe you can address, the next step is to experiment with one or more potential solutions. Experiment?  What?!?!?!?!  That’s right, experiment. Any given practice works well in some situations but not in others.  Just because a technique worked well for another team, maybe even one that you’ve worked on in the past, that doesn’t mean that it will work well for your team in the context of the situation that you currently face. There is no such thing as a best practice, regardless of the endless marketing you may have heard telling you otherwise.

What you need to do as a team is to identify ways that you can potentially address an issue, narrow down your options, and see how well a given technique works for you by trying it out in practice.  In other words, you need to run an experiment.  Figure 2 depicts a continuous improvement loop, also known as a “kaizen loop,” where you choose a technique to experiment with, you try it for a sufficient amount of time to determine whether it works for you, and then you decide what aspects of the technique (if any) you should keep and which you should abandon.  And if you’re enterprise aware your team will share your learnings with others.  Guided continuous improvement takes this one step further by employing the DA toolkit to help identify potential new WoW for you to experiment with that is more likely to work for you, thereby increasing your team’s rate of improvement.  Better decisions lead to better outcomes.

Figure 2. Guided continuous improvement.

An Example

Let’s consider an example.  We’ve been working together as a team for several months, have released the initial version of our solution into production, and have been working on our next release for about a month.  Our Team Lead has informed us that we’ve coming to the end of the funding for the team.  When we formed the team we received funding for a 6-month project, following our company’s fixed cost approach to funding solution delivery teams.  Our team expanded in size so that we could become a complete, whole team, and a side effect of that is that after a bit more than 4 months we’ve run out of money.  This is a problem that the team needs to address.

Terry, our Team Lead, gathers the team to work through the issue.  The first thing we do is discuss whether this is an issue that we can even influence.  The Team Lead believes that we can because our organization’s leadership is very happy with our work and can see the value in the product that we’re working on.  Because they have been receiving advice from an Executive Agile Coach they are beginning to realize that the way that they fund teams needs to evolve. Terry believes that our team is in a position to suggest, and then experiment with, a new approach to funding.

As a team we discuss what we need to do, realizing that there are really two issues commingled here: First, we’re funding a project, not the actual team.  Second, we’re taking a fixed-price approach. Carlos, our Agile Coach, suggests that we review the options captured by the Secure Funding process goal, the goal diagram for which is shown in Figure 3. It indicates that both project-based funding and fixed-price funding are the least effective options for agile teams, and more importantly it also indicates that there are better options available to us.  We look up the trade-offs associated with the options in our copies of Choose Your WoW! and after a bit of heated discussion agree that we should suggest to our management team that we adopt a stage-gate funding strategy for a product (long-lived) team.  Several of us wanted to push for a time-and-materials (T&M) approach, but we felt that would be a future improvement that we could experiment with once we’re successful with stage-gate funding.

Figure 3. The Secure Funding process goal diagram.

Terry, with the support of Polly (our Product Owner), manages to convince our senior managers to experiment with a new approach to financing.  Terry and Polly were able to describe the trade-offs associated with both the existing approach to funding and their suggested new approach. Interestingly, their suggestion was whole-heartedly supported by Florinda our finance officer.  She’s been concerned for several years about the way that IT projects have been funded, and is eager to move from a cost-based funding model towards one focused on investing our company’s money wisely. Our team was given the go-ahead to try the new funding strategy.

Sure enough, we run the experiment with stage-gate funding of a product team and it works well.  Our “stages” were three months in length, and after two rounds of such funding we successfully experimented with a T&M approach as we’d originally hoped.

In our previous blog, Continuous Improvement Through Experimentation, we worked through how teams can evolve their way of working (WoW) through experimentation and kaizen.  Figure 1 depicts the logic of a single pass through a Plan-Do-Study-Act cycle for doing so. The team identifies a potential way to improve their WoW, they experiment with it for a bit, they assess how well it worked for them, then they keep what works well and drop what doesn’t.

Figure 1. Continuous improvement through experimentation (click to enlarge).

Figure 2 shows how the effectiveness of a team’s WoW rises over time via this experimentation-based strategy.  When an experiment with a new technique works (the experiment is successful) the team’s effectiveness increases.  When an experiment “fails” their effectiveness dips for a bit but then rises back to where it was once they go back to their previous WoW.

Figure 2. Team effectiveness improves over time by experimenting with new WoW (click to enlarge).

So what can we do to improve on this? The linchpin is the very first step in the process of Figure 1, the identification of a technique to experiment with.  As you see in Figure 3, 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.

Figure 3. Guided continuous improvement increases the chance of successful experiments (click to enlarge).

It’s a simple idea – with better process decisions we achieve better process outcomes, as you can see in Figure 4. There are three ways that you can do this:

1. 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.
2. 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, as you can see by following the previous links, and the book Choose Your WoW! summarizes the trade-offs for Disciplined Agile Delivery (DAD).
3. 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 ways of working (WoW) to experiment with.

Figure 4. Team effectiveness improves at a quicker rate with guided continuous improvement (click to enlarge). 

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 takes it one step further and streamlines your experimentation efforts.

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.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 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.