Disciplined Agile

Continuous Improvement

Continuous Improvement

The purpose of the Continuous Improvement process blade is to enable people within your organization to easily share their improvement learnings with one another in a systematic way. This article addresses several topics:


Why Continuous Improvement?

There are several reasons why you want to have a continuous improvement program within your organization:

  1. Shorten the time from idea to implementation. Improvement ideas can come from anyone, at any time, from anywhere in your organization. As a result you want to have organizational mechanisms to identify and explore those ideas so that they get to the person(s) most suitable to implement them quickly.
  2. Increase skills and knowledge sharing. The high-collaboration environments that are typical of agile teams are wonderful for sharing skills and knowledge within each team, but fellow team members aren’t the only people within your organization that you can learn from. An important goal of a continuous improvement program is to motivate and enable people to share their skills and knowledge outside of their immediate team. You can do this through strategies such as communities of practice, online discussion forums, practitioner presentations and many others.
  3. Maximize your “failure ROI.” A fundamental of lean thinking is to learn from your failures, to treat each “failure” as an opportunity to improve. Having said that, every team doesn’t need to experience all of the same failures. One team, or a handful of teams in some cases, can fail in similar ways and then share those learnings with others. This way other teams can avoid that type of failure and thereby increase the value of the learnings to your organization. But we can only do that when it’s safe to fail and better yet recognize that failures should be celebrated and the learnings shared with others.
  4. Increase the opportunity for radical improvements. The challenge with the Japanese concept of kaizen, which is to continuously make small incremental improvements, is that you can get on an improvement path that will never lead to a quantum leap in your process. Yes, things are getting better, but you may be missing opportunities to make things a lot better. For example, a team following the Agile lifecycle may never identify the strategy of continuous deployment (CD) on their own because having a two-week iteration may preclude the idea of releasing several times a day into production. Yet, if people on your team were to hear about other teams in your organization working that way, they might soon choose to start experimenting with CD techniques. This in turn could lead to the “radical” process improvement of abandoning the idea of time-boxed iterations and moving to something much closer to DA’s Continuous Delivery: Lean lifecycle. 

In short, your organization needs a strategy for communicating potential improvements across teams. Ideally the flow of work should be streamlined to make it as easy as possible for teams to learn from one another.


The Process

The following process goal diagram overviews the potential activities associated with disciplined agile continuous improvement. These activities may be performed by, or at least supported by, a process improvement team (sometimes referred to as a Software Engineering Process Group, or SEPG). Some of these practices will be performed by Centers of Excellence (CoEs) and supported by your Communities of Practice (CoPs) (if any).

Figure 1. The process goal diagram for Continuous Improvement (click on image to expand).

Continuous Improvement Goal Diagram

Figure 1. The process goal diagram for Continuous Improvement (click on image to expand).

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, 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 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.