Something bothers me for a while about Kanban. These thought re-awakened during James Bach’s keynote at the Let’s Test conference in May. James was talking about the 1990′s movement into process. Processes needed to be everywhere. That’s why he became engaged with what turned out to end as the context-driven school of testing. Here is a quote that I heard in one form or another from the Kanban community:
The process needs to be defined, published and socialized — explicitly and succinctly.
(I got this from here.)
The Kanbanistas keep on confusing me with this. Here is why.
Believe the process
According to Gause and Weinberg in Exploring Requirements – Quality before Design, the Swedish Army has a dictum:
When the map and the territory don’t agree, always believe the territory.
(I wrote an article in the Better Software magazine in 2010 about this.)
When those Kanbanistas point out that the process needs to be defined, and published, it seems to me they are referring to the process map – or description – rather than the process that is lived – maybe that is also the reason why they are demanding the process is socialized.
In my experience, the process description always lags behind the process that is actually lived. It’s a case where the map (the process description) and the territory (the process that is socialized) don’t agree with each other. So, how can we get started with Kanban then?
You need to have a process
Another quote I just remember, but lost reference to, is that you need to have a process before starting to visualize your work when getting started with Kanban. I didn’t figure thus far how it would be possible to not have a process. We already covered the part in regards to the process description, that is lagging behind all the time. So let’s take a closer look on the process that is actually followed.
In my experience even though there is no defined process, there usually is a process implemented that makes people know what they are supposed to do, the rules of the infinite cooperative game in software development. For example, if you work in a matrix environment, your project manager probably is the main person who knows what the customer expects you to do next, and what could help bring the project one step forward. So, when in doubt about what to do, you go to the project manager, he helps you get new work, get over impediments, and so on. I would call that a process.
Now imagine another team that is working in a start-up. The business is not set, the founder knows which features should be built next, and has the biggest knowledge about the system. In case you don’t know what to do, you go to the team lead. He’s going to help you with the next step. I would call that a process.
Of course, it’s a bit tough to model these situations on a Kanban board. The problem with that lies in the nature that many processes are not linear in nature while a Kanban board tries to bring the current process down in a linear fashion. You have a linear flow through the board from left to right. You try to bring cards as fast to the right as possible, maybe you have a second dimension with swim lanes, or a third with colors, dots, or whatever low-level tools you might put in practice there. Still, the dimensions are at times too limited to visualize the process that is actually lived, since it might have become multi-dimensional, and not soooo linear as the Kanbanistas would like to have it.
Evolutionary change
I think the biggest rubbish spread about Kanban is that it is an evolutionary change management… thing. Why?
First, you need to have a sort of linear process described, and socialized before you can implement evolutionary change. This sounds a bit backward to me. Rather than starting from the process that is actually lived, making it transparent to the people around you, and help them to deliver better products in shorter times, Kanbanistas rely on a process model in place to start “evolution”. That sounds a bit like we need to have evolutionary theory before we can start to get out of the primordial soup.
I blogged before about the fact that introducing a Kanban board already introduces changes. How could you call such an approach evolutionary then? It’s much like the observer effect. You cannot tell whether the introduction of the board itself already lead to a variation in the process to start with. To say the least, it probably makes the people aware of the formal routine that is going to be followed in the months to come. Applying Systems Thinking tells me, that I should get a coach in touch with the team to observe what happens to their informal routines at the same time. This is going to be where the fun begins.
Conclusion
Maybe I was a bit harsh with Kanban in this post. In the past few years it has become a tool in my toolbox. Nevertheless my tester mindset keeps on challenging statements I read from the Kanban community. The biggest struggle I had with the necessity for a process – leaving open whether this means a lived process, a process description, or a process model. I am still puzzled about this. Combining these thoughts with something I learned from Dan North about Accelerated Agile Delivery, I think it’s time for the Kanban community to think about getting more in touch with Agile coaches. These guys and gals know how to bring the formal and informal routines more in line with the Agile mind-set: to ship better products in less time.
Recent Comments