November in Sweden: Blä! The sky is impossibly low and grey, it’s pitch dark at 4 pm, freezing, and then everyone gets cold. Especially men: they get man-cold.
There are also situations when your Kanban gets a man-cold (though it doesn’t need to be November for that): it’s not really dying, but it feels like it and it becomes kind of useless. At the fika, the story sounds usually like this:
“Kanban worked well for a while, but then it started to feel cumbersome, it did not really fit anymore. So we started to skip some dailies…” (more details follow on how things start to go south).
Something is obviously wrong, but the good news is: it may not automatically mean that you’re doomed and that your organization is unfit to all Lean/Agile things (find a new job). On the contrary, it could be positive, a sign that you are improving, becoming more mature! Wait, what? How can this it be?
The cause can be a mismatch between your understanding of your way-of-working and the design of your Kanban system. In other words, that you somehow outgrew the design of your Kanban.
Policy Debt
You see, at its core, Kanban is about understanding Work, how you manage this Work and how the two match. Designing a kanban system, you put together a set of policies and rules governing what work you want to visualize, in which way, and how you want to manage it. Using the system daily, you then gain clarity and insight on how work should be managed and seen for you to best succeed (whatever success is for you). It could be insights on who to involve, when you have the daily meetings, what is in your DoD, how to manage Joe’s availability with a column, what WIP limits would work better, etc. And here comes the danger: the more you wait before reflecting this new understanding in your system, the more you build a “policy debt” (and as all of you agilists know very well, a paragraph containing “debt” will never end well). The more “policy debt” you have, the bigger gap between your mental model and your system, and the less your Kanban will be relevant, up to the point where it becomes misleading, unfit. There it is: it doesn’t “work” anymore, even if it all started well.
So, policy debt is bad, but seeing it in effect means that you have matured! You now better understand how to manage your work in your context. You have learned what needs to be done to come closer to your definition of awesome, your fitness to purpose, your definition of high performing. And that’s great news! You just need to implement this learning by performing changes. So, take the time to pay back your debts (re-fresh all policies?), and off you go with a newly-trimmed and Kanban to support you.
Do Not Panic!
As a corollary, it also means that you will see policy debt building up very quickly in new Kanban systems (everything still smelling plastic and yet untested). With an inexperienced team, you must expect – and plan – for moments when the team feels that “the board doesn’t work anymore”. No reason to panic, this is all very normal. Rejoice instead, this is good news: “Team, we are learning!”.
This makes me think that there is a way to measure a team’s maturity rate: keep track of the number of policy changes over time (redesign of the board, changes to DoD, new policies to interact with customers, changes to the agenda for daily meetings, etc.). You know that policy debt is building when no changes occur (especially at the beginning of your Kanban journey).
Some tips on how to avoid the Policy Debt trap
- Kanban works best when your policies (incl. visualization) are a true reflection of your current way of seeing and doing things. Unfortunately, teams tend to voluntarily inject a good dose of wishful thinking, wanting to create a “healthy” tension to force change (Document everything! Peer-review all changes! Longer Definition of Done! Tougher Definition of Ready! Etc.). Let me spoil it for you: it never works! Just stop. Now. Do you want positive changes? Don’t force it, be as honest as possible when creating your system and let Kanban show you what’s the next most meaningful improvement.
- Pre-cooked Kanban templates may be a quick and easy way to start, but beware! The more complex these are (beyond “To Do, Doing, Done”), the more alien they are to your context, and the quicker they will generate policy debt. Instead, try to tailor your kanban system to your context using a STATIK method (like the Kanban kick-start for example).
- Policies should be updated as soon as you identify a mismatch. The role of the facilitator of the daily meetings (flow manager, or whatever name you have for it) is crucial here in making the team reflect on which policies don’t work as intended and should be changed or removed. This especially relevant at the beginning of your Kanban journey.
- You will gain insight faster at the beginning of your Kanban journey, so be prepared to update your policies frequently to not fall into the trap. As a rule of thumb: every week the first month, once a month the first 6 months, slower than that later (assuming a stable team and stable service).
Fell into the trap? Update your policies before Kanban gets a real man-cold!
