A long-term approach to work that systematically seeks to achieve small,
incremental changes in processes in order to improve efficiency and quality.
–Margaret Rouse, WhatIs.com
At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
— Agile Manifesto
The Scaled Agile Framework (SAFe) and other agile strategies all emphasize continuous improvement, and at Streamline Health we take scrum team retrospectives very seriously. But it’s useful to take a look at the root guiding principles of the agile strategy: Kaizen.
Western manufacturing concerns began adopting the principles of Kaizen back in the early 2000s when Jeffrey K. Liker published The Toyota Way. To software developers who had signed on to the principles of the agile manifesto, Kaizen’s principles of lean continuous improvement were a perfect fit.
Kaizen culture can be summarized in a few bullets:
- All levels of the organization are involved in continuous improvement.
- Participation by all levels is essential.
- Draws upon varied talents and skills – the more diverse the better.
- Peer-to-peer accountability.
- Self-evaluation at the team level.
- Self-evaluation at the event level.
It sounds simple, but for many organizations it represents a difficult release of managerial control. As recently as last month a director in our company, observing a team planning their sprint work, asked if I step in to resolve conflicts about how they will do the work. The observer was a little surprised when I said absolutely not, they have to work it out. Our teams are generally quite successful, so the observer couldn’t argue that this approach won’t work.
Software development sprints are a series of “Kaizen events.” Improvement goals are set at the beginning. At the end, the team reviews its success at improving from the previous sprint and develops plans for improvement in the next sprint. During the next sprint the team implements the improvements they agreed upon.
In addition to being the root of agile’s process improvement principle, the Kaizen approach of continually making small improvements applies to agile iterative development. Each sprint contributes a few small, valuable, demonstrable changes to the application. If they’re good, they’re kept, if they aren’t, they’re modified in a future sprint.
Kaizen’s principle of peer-to-peer management governs our continuous integration strategy. Everyone is responsible for a clean build, for storing source code correctly, and for organizing test plans and automating testing. Everyone is responsible for maintaining automated build and deploy processes. Code reviews, design reviews, and test plan reviews all draw upon the diverse skills and experience of all team members to improve the quality of their code.
The notion that your team members, teams, processes, and products are unlikely to ever be perfect might be difficult for some people to accept. Traditional managers like to expect perfection, even though they rarely see it. But accepting imperfection and making it an opportunity for collaboration and growth is the very essence of Kaizen. Organizations that focus on collaborative improvement tend to see that same collaboration across other work. Teams that accept responsibility for maintaining and improving their process tend to be more successful at regularly delivering working code.
How Are You Doing?
How are you doing at continuous improvement? Do your teams identify and work on process problems as part of their regular work cycle?