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):
- Set the Stage
- Gather data
- Generate insights
- Determine actions
- 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.
