Your explanation of Kanban is by far the clearest I’ve seen thus far. It is clear to me that it is working for you. My concern though, is that it may not be working for the reasons you think. A lot of emphasis is made on where your process overlaps with lean thinking, but there are still gapping gaps that go undescribed. For example, how are MMF levelled so that they are similarly sized? How much effort is spent levelling MMF and what is the return on that investment? Could what is going on in these “gaps”, be as equally if not more important as the aspect you choose to describe?

A jump up thought is that it may be better explaining what you actually do day-to-day, the people involved, their interactons etc, sort of in a narrative – “a day in the life of a Kanban team” – Similar to what Ron Jefferies is doing with the fictional “Kate O’Neal”.

This would be a true primary source, and would leave the interpretation to the rest of us. The post analysis you present in Lean language could be just one interpretation of what is actually happening.

What Kanban seems to be missing is a silent witness, like a Alistair Cockburn, observing and taking notes. Instead the main reporters are also the main protagonists, which has the potential for “post rationalisation”. If you know what I mean.

My last point. A small group of self-organised people collaborating effectively can solve a multitude of problems in a multitude of ways. We have a tendency to extrapolate systemic behaviour where infact there is just chaos. The assumption being that chaos is a bad thing. Chaotic behaviour is actually just part of being human, and part of the creative process. Allowing for chaos, whilst retaining discipline seems to me to be the essence of Agility. In your explanation of Kaban, this essence is noticeable by its absence.

Paul.

In the situation Tim describes I’m not sure any process – Scrum, Kanban, CMM can fix the root cause. That’s because the cause is the people.

Tim’s scenario makes a number of assumption: Harry is incompetent, Bill is lazy, etc.

That is, Tim (or the manager in the scenario) is operating with this mental model. Once they assume Harry is lazy it becomes self-fulfilling. Why would a Scrum planning meeting, a retrospective or a release fix this problem? It won’t.

The manager needs to reset their model, talk to Harry, find out what might be inhibiting Harry’s performance, etc. etc.

I think claiming that any system will fix these kind of problems is a little naive. The best a process can do is show they exist.