Thursday, January 23, 2014

Asking Kaizen Questions

If you've read my previous material you already know that I'm a big proponent of questioning everything - getting to the "Why?" of what we do. What I've realized lately is that simply asking "Why?", though a good start, is not as effective as asking the right "Why?".

We get better by asking questions and acting on the answers. The better the questions, the better the answers. I'm going to refer to the right kind of "Why?" question as Kaizen questions (full disclosure: I don't know if this is already a thing or not, but a basic Google search tells me it's at least not widely used).

Let me give you an example. One question I get a lot from those resistant to Agile is, "Why should I give up Waterfall?" or "Waterfall's always worked for me; why should I stop?" A slightly more open-minded derivative to this question is, "Why should I try Agile?" If we were to take the Kaizen approach and recognize that perfection is unattainable but improvement is always possible, we would ask, "Why should I continue using Waterfall?" or "What other approaches could I use to deliver quality and value to my customers?"

The Kaizen Question doesn't ask how well the current approach is working because there is an inherent understanding that it could be better. It focuses only on the alternatives to what is currently being done. This type of question is crucial for those adopting Agile to ask themselves as they transition. Otherwise, they risk simply moving from a poor status quo to a better status quo.

If you move to Scrum because you asked yourself, "Why should I try Scrum?" then you are more likely to stick with Scrum and never try something new than if you'd started your journey by asking, "Why should I stick with what I'm currently using?" Do you see the distinction?

I would hope that those who try Scrum eventually adopt a Kaizen mindset and continue to evolve regardless of what question originally got them there. Unfortunately, I have seen too many teams move to Scrum, settle in, and fight against later suggestions of Kanban, DevOps, and other emerging practices and processes. The way I see it, any status quo is a bad status quo and should, therefore, always be challenged. What do you think?

No comments: