Kanban and Understanding

Thanks to Mike Burrows and his work on the values of Kanban (see this excellent Blog Post) I am more and more aware how important understanding is and how deep it is rooted in Kanban.

Let me give you some examples:

Understanding our work

Why is it so important that we visualize our work? And why do we do demand analysis in Kanban? Because we want to understand our work! How much demand do we have? What are the sources of our demand? Do we have seasonal variance in demand? What are the risk profiles that are attached to different types of work (that’s why we might want to introduce different classes of service)? What skills are required for different types of demand? etc. If we don’t understand our work, how can we possibly balance demand against capability to improve flow? We can’t. And we will sooner or later end up with cargo cult solutions. Of course it’s a long way to understand our work completely, and maybe we will never manage to. But the more we understand it, the better we can manage our system. And even a small bit of understanding is probably better than no understanding at all.

Understanding problems

My observation is that in most contexts we don’t understand our problems – and we don’t really try to do so. My main takeaway from many different contexts in many different organizations: The problem is almost never what we thought it is at first glance! And for me, that’s one major reason why models are so important in Kanban (and not only in Kanban). If we use them wisely, they can guide us in understanding our problems and finding good countermeasures. Reading John Shook’s great book on A3 Thinking really was enlightening for me in this respect. When we discover a problem and start dealing with it, there is most often a mix up between symptoms of the problem („What can we observe that we don’t like?“), deeper roots of this problem („What are the reasons for this symptoms?“) and possible countermeasures („What do we think is a good idea to do in order to make the symptoms go away, as well as the roots of the problem?“) So it is a good idea to think these things through, have structured discussions, talk to people who are involved and might know more than we about the problem, do observations and experiments etc.

And then there is another issue with the way we usually encounter problems: Jumping to conclusions. I thik that agile retrospctives are very powerful for avoiding this behaviour. Let’s look into the „classical“ schema for retrospectives as suggested by Diana Larsson and Ester Derby (look into the book Agile Retrospctives):

1. Set the Stage
2. Gather data
3. Generate insights
4. Determine actions
5. Close the Retrospective 

There s a reason why the third step exists: When we have gathered our data and identified a problem, we should not directly determine actions, but generate insights first. And this generation of insights means to understand our problem better (no matter what practices we use to do this). This step ist often the hardest one in a retrospective, and teams as well as facilitators tend to skip it. But it is very valuable! (example Henning)

Understanding people

Of course we will never understand a person completely. What I mean here is the following: If we observe a behaviour that seems to be stupid to us, what do we do? Do we ignore this? Do we tell the person "Stop it!" ? Or do we assume that there is a good reason behind his behaviour and try to understand this reason? Everyone who ever played GetKanban knows the devastating effects that are caused by Carlos the test manager and his policies. Any team playing GetKanban hates Carlos, yells at him and desperately waits for Alison to fire him. But if we step back for a while and ask ourselved why he set up the policies, we can find very good reasons for this. If we did this, it could be easier to deal with him. Here is another example, this time from real life: I trained a team, including a project manager in Kanban. Of course we talked about the advantages of WIP limits and having a pull system in place. They all agreed that they wanted to introduce this. But after a couple of weeks it became clear that the project manager kept pushing work into the system without regard to the WIP limits. My first reaction was „What a moron!“ Luckily, I did not day that loudly. After having talked to him, the picture looked differently. It turned out that he was totally aware of the problems his behaviour was causing. But he had a reason for this: „Look, I am responsible for the on-time delivery and quality of our small projects. I totally get this pull-stuff. But I know that our team members have very different skills and experience. So I don’t have faith in a system where an inexperienced person pulls an item he cannot master. This puts the commitments towards our clients at risk. So I bypass the pull-system by assigning tickets to specific persons and putting them on their desks.“ Now we had a better perspective on the problem. It was not the „stupid project manager“ but maybe a problem of too little training for new people. Or maybe it was only a problem of showing the project manager that the skill level was much higher than he thought. In both cases the way we had to approach the problem was different from getting rid of the project manager.

So the bottom line here is: Let’s not jump to conclusions when it comes to strange behaviour either! When we observe bad behaviour, let’s ask questions like: „Assuming this person is a good guy, what might the reasons for his behaviour be?“, „What does this person see that I cannot see?“, „What are his fears?“ etc. This helps us improving by showing respect for people.