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.

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:

• You want to compare several strategies that potentially address the same process issue you hope to resolve.
• You have several process issues that you hope to resolve at the same time.
• Your team is currently running an experiment and feels it has capacity to take on another improvement experiment.
• Techniques are dependent on one another, such as automated regression testing and continuous integration (CI).

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.

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:

1. Identify improvements.  There are several ways that your process improvement group can support the identify of potential improvements within your organization.  One of the more effective strategies is to help teams adopt the practice of holding regular retrospectives.  Although it is common for disciplined agile delivery teams to hold retrospectives this is often a new concept for enterprise architecture teams, IT governance teams, data management teams, and so on.  We also get very good traction with value stream mapping and brainstorming sessions, which invariably proves to be far more effective than the traditional approach of creating current and proposed (business) process models that rarely seem to result in lasting acceptance of the proposed new way of working.
2. Share improvements.  As you can see there are multiple ways that you can share improvement ideas between teams, many of them being free or at least very inexpensive to implement.  We’ve had very good experiences with internal discussion forums such as Jive or ActiveBoard, practitioner presentations (often called lunch and learns) where someone presents  their learnings to others, lean coffee sessions where people voluntarily meet at a regular time to share ideas, and communities of practice (sometimes called guilds) who purposely collaborate to educate themselves in a given topic.
3. Capture improvements.  There are various ways that identified improvements may be captured to retain them over time.  Possible strategies include describing each learning in a document and then managing that document in a documentation repository such as Sharepoint or more simply in a shared folder; capturing the learnings in a shared wiki such as Confluence; describing your evolving process using a process repository such as Stages or Rational Method Composer; or via an expert system such as Enterprise Transformation Advisor.
4. Support teams. Your process improvement team can help others to adopt process improvement techniques through training, education, and coaching.  They can also facilitate team assessments and retrospectives (a great idea is to co-facilitate a few retrospectives with someone on the team to transfer those skills to them).  A very effective strategy is to help a team run a process improvement experiment or two, particularly in situations where the team isn’t being supported by a coach.  This helps them see that they can safely try new ideas within their environment for a few iterations to determine whether it works for them or not.  Many teams, particularly those new to agile, often do not feel empowered to run such experiments and thus need help to do so.
5. Organize Communities of Practice (CoPs).  A Community of Practice (CoP) is a collection of people who share a craft or profession who have banded together to ‘learn’ from each other to develop themselves and often even the  organization.  We’ve seen CoPs for testing, architecture, agile/lean, business analysis, technical debt, and many others.  CoPs will often perform the activities called out by the Identify Improvements, Share Improvements, Capture Improvements, and Support Teams process factors.  A CoP will often start up when one or more practitioners within your organization recognize the need for it, although sometimes it may also start to support the efforts of a corresponding Center of Excellence (CoE).  Participation in a CoP is typically voluntary.
6. Organize Centers of Excellence (CoEs).  A Center of Excellence (CoE) is a group of people with specialized skills and expertise whose job is to provide leadership and purposely disseminate that knowledge within your organization.  CoEs are often created by an organization to support the adoption of a new technology or technique, and in fact  the creation of an Agile CoE is often a key component of your organization’s overall Agile transformation efforts.  Over the years we’ve seen CoEs for object technology (particularly in the 90s when it was new to most companies), solution architecture, testing automation, and of course agile/lean.  Participation as a member of a CoE will be part of, or the entire job for someone.
7. Govern improvement.  It is very common for senior management to want to know whether or not the organization is benefiting from your investment in adopting agile and lean techniques (or other potential improvements for that matter), how much things are improving, and how widespread the adoption is.  The implication is that there needs to be some way to monitor and report on, preferably in a lightweight and streamlined manner, the improvement activities.

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.