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. There are several reasons why you want to have a continuous improvement program within your organization:
- 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.
- 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.
- 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.
- 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 Scrum-based Agile/Basic 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 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. There are many options for doing so available to you, the topic of a future blog posting.