Most large enterprises claim to engage in continuous improvement but they are really improving incrementally. Their efforts often include annual reorganizations whereby vice presidents are shuffled around and new procedures are put in place. In my experience, little if any value derives from such organizational tinkering.
Another form of incremental improvement results from conducting “project reviews” at the end of major projects. These reviews might take the form of interactive retrospectives but often the reviews are nothing more than questionnaires. Team members answer questions. A manager, PMO representative, or process enforcer reviews the answers and looks for ways to improve the development process.
“Process improvements” often require documentation changes that may take weeks or months. By the time the changes are implemented and new project results can be evaluated, it’s time for another reorg. Is it any wonder that big companies can’t get out of their own way?
Continuous Evolution
Continuous improvement is quite different. It’s not an annual or quarterly event. In fact, it’s not an event at all. It’s more like an evolutionary lifestyle. When a development team discovers a better way of doing something, they change — immediately. Other development teams may or may not adopt the change — it’s up to each team to decide.
Changes that result in measurable improvement may be institutionalized — propagated to other teams. This can be handled by Project Management Offices or, preferably, Centers of Excellence. (A PMO enforces rules while a CoE identifies high-performance techniques.)
The only practical way to leverage continuous improvement is by implementing short delivery cycles. Consider product manufacturing teams . They often deliver hundreds or thousands of products per day across multiple teams. This gives them many opportunities to discover problems or inefficiencies and apply corrective actions.
Compare them to software development teams that may deliver software monthly, quarterly, or (cringe!) annually. They have far fewer opportunities to improve. Add administrative reviews and approvals to the cycle and continuous improvement becomes a sequence of fits and starts.
Any business that’s serious about continuous improvement has to do three things:
- Keep delivery cycles short. Many agile software teams use 4-week cycles but I’m encouraging you to try 2-week cycles. You’ll evolve faster.
- Empower teams to make changes to their process flow including their definitions of done. Don’t force every team to follow the “corporate standard”.
- Encourage teams to openly share information and collaborate across projects. Every project should be an open book that everyone can learn from.
Companies that are serious about changing and equally serious about being agile leverage continuous improvement techniques. Those that only talk about change and agility rely on reorgs. How does your company approach change?