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.
Hi, I think the general idea is to start by visualising part of the lived process. We focus on the actual value stream. But it might not matter too much if the team visualises the described process instead. Differences will be made apparent and the team can discuss what to do.
I do agree with you that the Kanban community overstates the “don’t change anything”. They do mean “don’t change the existing value stream at first”. Of course introducing Kanban causes some significant changes, perhaps to the process, but ideally not to the value stream. If a developer switches from checking Jira to decide what to do next to checking a card board, that is a process change but not necessarily a value stream change. (And once WIP limits and pull come in, that is a significant culture and process change, but not necessarily a value stream change.)
As far as your biggest struggle goes, go back and have a look if they were really talking about process, or just a part of it, the value stream. They talk about both I guess, but I think it makes a difference.
Hi Kurt,
don’t get me wrong. I feel confident that I can introduce Kanban without this knowledge. But the wording in the community confuses me.
The piece on the value stream focus of process is an interesting thought. Will consider that next time.
Thanks.
I agree with Kurt but would like to add another point, maybe just as a side-note:
To distinguish between “lived process” and “written process” it might be helpful to recognize them as two very different things by using a more concise language.
A Process is what really happens. No matter if it’s written down or not, no matter if it’s in line with what’s writen down. There will always be some process, you can’t not have a process.
A Procedure is what has been (more or less) formalized. Either in written form or in the heads of people. Procedures are often referred to as processes but in fact they often don’t align to the actual processes.
I’m not sure, if this contributes to your thoughts, Markus, but it helps me with recognizing the usual misalignment between the two by making the difference explict.
I agree with the two commenters so far. My blog was the one was that was quoted :) The focus is on visualizing what really happens and not what people think happens. The two are often at odds and seeing what IS often teaches people a lot about their system that they are too close to see.
Basically, visualize what is and see what you can learn from it. Then, decide what optimizations you can make and try them out. The emphasis on not having to change anything right away is meant to avoid barging in with a solution when you haven’t even properly identified the problem. As I noted above, what IS and what is perceived are often different. Once you reconcile the two (with visualization playing a key role) then you can begin to really make the right improvements.
Interesting post, its good to see how words can be perceived in many ways and thus a message can be lost or misconstrued. It teaches us not to get lazy with our examples!
Oh, also to bolster the comment about the value stream, everything serves to facilitate smooth flow through the value stream. The process is not important in and of itself, but for how it should facilitate even flow through said value stream.