Stumbling blocks in the introduction of Kanban

“Scrum is very exhausting, let’s do Kanban, it’s easier. And is without meetings.”

As a Kanban trainer at Kanban University, I’ve been hearing this for more than 5 years. I have accompanied numerous teams in their transition, so I can safely say: Kanban is also exhausting, just in a different way.

Here are the main stumbling blocks that all my teams and organisations have fallen over in recent years – so that you don’t stumble over them too, I’ll show you the warning signs to look out for.

Stumbling block 1: Participants are confused because important terms are not established from the beginning

In most organisations, Kanban terms like flow or WIP limits are Bohemian villages – no wonder, given the unwritten law that every single person in the system should be working at maximum capacity (for cost reasons). The goal of Kanban, however, is to improve the overall systemic performance. We always look at the system as a whole and focus on the interactions.

I like to start my workshops with some form of simulation (more or less complex depending on the time required) to illustrate the relationships between work in progress, delivery and waiting times and yes, stress. At the end, there is always the insight that the amount of projects started at the same time has maximum influence on delivery times and predictability in our system.

In addition, I establish “flow” as a desirable state and define appropriate metrics.

Stumbling block 2: Boards give no clues for improvement because the value-creating activities are not visualised

To Do / In Progress / Done may be fine for the beginning on a Kanban board, but this representation quickly reaches its limits. How much information can you derive from this picture, for example?

All you know is that a lot of different things are being done right now, but what does that mean exactly? It therefore makes sense to map the individual phases that your work item has to go through before it can be considered finished as separate columns.

You can already recognise where in the process the work is jammed, which work is blocked and what (as of today) will come next. You can research the causes of problems and develop initial hypotheses to solve them and then test them.

The only important thing is to model the Kanban board as the work is actually done – not according to defined target processes in some manual (yes, there is a difference!). A first draft is good enough for the start – no board is set in stone, you can (and should!) adapt it.

Stumbling block 3: Participants are overburdened because there is no regulation of the work that follows

In the search for better results, making work visible via cards on the Kanban board is a good and important first step, but it is still not enough. To permanently unburden your system and allow work to flow again, you need to limit yourself.

Many participants ask themselves the question “What limit is right for my team?”

At the beginning, it is not the number itself that matters, but THAT you agree to no longer let work enter the system without limit. As a rule of thumb for the start in the team, I have found it useful to always have one card less than the number of people in the team. This way, instead of creating queues, there is always one person available to deal with problems or code reviews without delay.

Stumbling block 4: Participants are confused because facts are interpreted differently

Surely you have also heard sentences like “I don’t understand what the problem is with it. I thought things were clear!”.

We humans have a big problem. We cannot copy information from one brain to another. Each person brings their own context and experiences, so the sender-receiver problem always resonates in communication: What may be clear to you is far from being equally clear to your interlocutor. Only in joint dialogue (and documentation) will you find out whether and how clear things really are. Therefore: Make things explicit!

• “For us, a job is finished when xyz is done.”
• “Two other peers are always needed for a code review.”
• “Before we are really done, person Z has to look over it and sign off.”
• …

Your policies are as individual as you are – so I recommend writing them down. This minimises misunderstandings and misinterpretations.

By the way: Your stakeholders will also thank you if they can learn and understand what you have to do and how. And who knows, maybe this will even lead to a discussion about whether you really have to do everything exactly the same way.

Stumbling block 5: Teams poking around in the fog because no metrics are used

You need to be able to regularly evaluate where you currently stand. To do this, you need objective and consistent criteria. No one is well served if you only act on the basis of opinions or feelings – the danger is too great that the hierarchically higher opinion then counts.

I always agree with teams that we will use two metrics to describe the system:

• Lead time and
• throughput.

Lead time gives you an answer as to when any given work item will be completed by us. And throughput tells you how much you can complete in a defined period of time.

By the way, “When metrics become a goal, they cease to be good metrics.” – Charles Goodhart

Stumbling block 6: No view on flow

With Kanban, you try to improve the flow of work. A good time to market or fast feedback cycles can only be achieved if work can flow through your system swiftly and without friction. This is the antithesis of maximum individual workload.

You therefore no longer focus on what each individual has done throughout the day, but on how well the current work has progressed along its path. When blockers appear, the whole team is required to work IMMEDIATELY to remove them. Perhaps this is the biggest hurdle of all: avoiding busyness for the sake of busyness.

Conclusion

Kanban – like Scrum – is not easy and can be very exhausting. If you avoid the described stumbling blocks, you will significantly lower the hurdles for a successful introduction. In ongoing operations, you then have to take care of regular communication and presentation of the most up-to-date measured values. Then there are no limits to your success.

Notes:

If you have any questions or would like to learn more about Kanban, please feel free to make an appointment with Daniel Westermayr. You can find more articles by Daniel Westermayr on the Colenet Blog.

If you like the post or want to discuss it, feel free to share it with your network.

t2informatik develops and modernises software as a service provider. Click here to learn more.