This is how I’ve come to see Kanban too. Infact I’ve come full circle:
http://pab-data.blogspot.com/2009/02/post-agile-beyond-best-practice-and.html

You offer a very powerful metaphor for organisational ability, one that is sorely needed. Not every team is ready for the black slopes. I would say most aren’t. Matthais makes a good point about false safeguards. We could label them “safety blankets”?

Like with children perhaps it’s not a good idea to take away their safety blanket straight away. Maybe its best to be patience and do a little cajoling until the child is finally ready to let go…

I did some coaching for a team which was managed by a friend of mine. He was adamant that the team and the organisation wasn’t ready for Agile. He as much as banned the use of the term Agile less it came to mean cowboy coding.

Initially I was just going to show them how to do TDD, but we ended up focusing on finding ways for them to better manage their work load and interact successfully with the business. We still didn’t call it Agile though. I think we said that they were learning how to do iterative development or something…

Anyway, Agile was mentioned, but in context, and we had an open and honest debate about the real obstacles that stood in the way of them becoming Agile, assuming that they wanted to get there at all.

Thanks for this. It has cemented where to fit Kanban into my bag of tricks. If I was in that same situation again, I would be advocating Kanban. Not sure that I’d use the label though…

No thanks for this. And thanks for putting up with me in the past. I see the light. This is powerful stuff.

Paul.

Some safeguards look like safeguards but they actually provoke the behavior that they were trying to avoid.

Example: The waterfall process with several signoffs between phases tries to make sure that the software will be implemented exactly as the customer needs it. However, because of the large batch size, the lead time becomes so long that the customer will finally get software that he does not need any more. Just like Job (Hiob) in the Bible: “For what I fear comes upon me, And what I dread befalls me.”

I think it is important to talk about false safeguards, too, and make clients aware of them. In a way, it’s like this: If they would have taken more risk, they would have protected themselves better! Absolutely ironic, isn’t it?

that’s what fascinates me about Kanban: it gives us a new, generalized language to talk about various development processes, just like Einstein gave a generalized theory to what Newton described in simpler and more specialized terms.

Kanban allows me to talk to waterfall experts in a completely different way than before. I do not need to argue for Agile immediately, but instead I can just ask them things such as:
* How large is the batch with which you go through the waterfall?
* “How often do you go through it?
* “Which queue size do you use between requirements analysis and design?

Your post now gives me even more possibilities to ask, such as:
* The large batch size in analysis looks like a safeguard. Against what are you trying to protect yourself?
* How much reward would you expect when you let go of this one safeguard?
* and so on…

Thanks for bringing this up!
Matthias