Beyond Agile Basics: The Kaizen Culture

Posted by Keith McMillan

December 30, 2015 | Leave a Comment

In my current engagement, I’m working once again with teams that are adopting agile development practices. Since I started coaching agile teams in 2009, knowledge of how a team “does agile” has become more common, but true agility, such as the adoption of a kaizen culture, is still rare.Kaizen, a Japanese word that translates as “improvement” is a by-word with many agile practitioners. It represents one of the twelve principles behind the Agile Manifesto

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

That’s just the retrospective in Scrum, right? Yes, and no. The retrospective is indeed the Scrum ceremony intended to formalize kaizen, but many teams seem to struggle with the true spirit of “what can we do differently to be more efficient or better,” so much so that I usually coach teams to get the “forms” of agility in place first (things like: all sprints are such-and-so length, sprint scope does not change once the sprint starts, Scrums consist of only the three questions), then to try and tackle the change in mindset to continually improve.  It’s easy to observe the form of having the retrospective on the last day of the sprint, but teams typically struggle with having an effective retrospective, which I define as one that successfully changes team behavior for the better. Why is this so hard?

The most obvious reason, but by no means the only one, is pride. A team that just successfully completed a sprint, earning all their story points, and maybe even increasing their velocity over the last sprint feels “We’re doing pretty good! I don’t think we need to change anything.” (I’ve even had a scrum master at a previous client say that to my face when as a team member I tried to push for improvements.) The truth is that you don’t need an exceptional team to deliver on your commitments and increase your velocity, you just need a competent one. Delivering what you bought during sprint planning only requires that you do a reasonable job of estimating your velocity. Increases in velocity happen routinely as well, caused by team members growing more familiar with each other, and with the software they are building, and by the increasing corpus of functionality onto which they are adding.  Teams in this situation tend to focus on what others outside of the team should be asked to do differently, rather than how the team can change it’s own behavior.

Another reason is fear. Let’s face it, most information technology workers are still used to being dictated to in terms of scope, resources and time (the classic iron triangle). Many organizations continue quite hostile to IT workers, and we’ve grown used to not really speaking our mind, because it gets us into trouble. Why should we admit to being less than perfect if it will be used against us when we are evaluated for annual raises, or worse yet, when it’s time for the hire/fire ax to fall? This creates a culture where we’re afraid to do a great many things, not the least of which is to admit there may be a better way for us to work, or to push for an organizational change that would make us less efficient. If this sounds like your organization, then you have a serious problem, and one that the team can’t solve: the organization has to sincerely change the way these teams are treated, and it’ll take time to convince teams that they are safe when they want to be critical of themselves and the environment in which they operate.

Teams may also be ignorant that there are levels of performance they could achieve that are far beyond what they are currently doing. This is somewhat related to pride, but not quite the same thing, I think. If you’re unaware that there are orders of magnitude improvement that could be made, it’s perhaps understandable that you wouldn’t think of going for the big changes that would get you an order of magnitude, or even two, of improvement. I think this is where a coach comes in, one who has seen world-class teams perform, and knows what good teams are capable of. A coach here can challenge a team, letting them know that others have been far more successful, and the good team will rise to the challenge once they are aware of what can be accomplished.

Most of my direct experience has focused on Scrum, but I’ve started working with some teams adopting Kanban for their project management. Proponents claim that Kanban more quickly and naturally allows teams to arrive at a kaizen culture. Visualizing the process work goes through, and setting limits on work in progress organically focus the team on improvements in the way work flows.

Kanban shows promise to address both the pride and ignorance causes of failed kaizen. If teams don’t feel safe in being critical of their own behavior, or that of the broader organization, that’s still a big problem.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.