When teams all over the world try to adopt agile methodologies, sooner or later they will be faced with a key question; Is KANBAN the right technique for us? Sometimes, they have known and experienced other agile techniques like SCRUM but most often they are new to agile to begin with. In this article I will try to explain what are some of the pros and cons of KANBAN and what common mistakes are unknowingly made so you can self-diagnose your particular use case, whether you're new to KANBAN or new to agile altogether.
Personally, I love KANBAN for two reasons related to the results it delivers.
- KANBAN is designed to adapt your workflow to changing priorities and interruptions. It makes bad news to be engulfed by the process. That's amazing. Instead of embarking yourself on "change management", you embrace it as a natural activity.
- Since KANBAN can tell you the average time a task takes to be completed, you can more or less predict when any random task will be finished. Averages aren't robust statistics but over time they can give superuseful time ranges.
Within the agile principles and frameworks KANBAN shines as one of the two most widely known techniques, together with Scrum. It is probably overused and overstretched but this is due to its obvious merits. What are those merits in the context of a team and a project?
Simple, everyone can understand it
KANBAN portrays itself as a board with as many states or columns are needed for an organic flow of tasks or cards. Your objective is to move those cards from the leftmost column to the rightmost column and crossing it off the list. It brings certain order and spatial awareness to the classical TODO list. You can't deny its simplicity and almost every cultural context provides the user with the tools to understand that this is a simple way to organize pending work.
A team is more than just a collection of individualities, there has to be a mutual purpose, a common vocabulary and a agreed upon priority. KANBAN is a nice shortcut to all that. The KANBAN status can be equated to the TEAM status or the PROJECT status. It's a nice example of visual management or an information radiator because everyone in the team is equally exposed to the same information.
Any organic flow is highly adaptative, true, but only if we are quick to remove any sudden bottlenecks. There is no use in a KANBAN board that lets certain cards die when they reach a particular column. You can picture those bottlenecks as death traps for tasks. You want to keep an eye and remove them as they appear. KANBAN is amazing as a heat map for bottlenecks, it even allows you to specify how many cards trigger the idea of a bottleneck per column.
There are some weaknesses inherent to the way people use KANBAN. I wouldn't go as far as to say they are KANBAN flaws, but rather common misuses that many teams eventually develop as they are enjoying the ride.
Everything has to go to the KANBAN
You know the saying about someone having a hammer and seeing everything as a nail, right? Any KANBAN board needs to remain significant for a team and a project, otherwise its apparent simplicity will suddenly make it look as a untidy room and trigger avoidance behaviours. This can happen if we force everything related to a project or a team to go to the KANBAN. Some information might be better handled through other means.
Too many workflow states
Overclassification can be tempting for teams that want to have powerful metrics and detailed accountability but there is a point when too much classification might impose cognitive and operational overhead. We are aware that NEW, IN PROGRESS and DONE columns might not work for every project on earth, but CRAZY IDEAS, REVIEWED IDEAS, DEFINED IDEAS, READY, DESIGN, TO BE DEVELOPED, DEVELOPED, TO BE TESTED, TESTED, TO BE DEPLOYED, DEPLOYED, DONE, ARCHIVED, REJECTED and POSTPONED could be a bit too much for many others. This typically happens when a team wished a tool could replace normal peer-to-peer communication.
Dubious quality of the initial column
Draft stages of a task or card should be carefully considered before entering the KANBAN. The initial column normally tracks recently added tasks. We use column names such as NEW, IDEAS, CRAZY STUFF, TO BE DISCUSSED and so on and so forth. That's great as long as it doesn't become a tasks graveyard. You can't afford to have one of those bottlenecks or death traps right at the beginning of the flow. If you start using that initial KANBAN column as your brain dump after every meeting, you are doing a disservice to one of the advantages we highlighted above.
People saying "What should I do next?" too often
Whether you have daily stand-ups borrowed from Scrum or regular checkpoints for sharing impediments or progress, one question you don't want to hear very often is "What should I do next?". Sometimes, it's the most appropriate question to ask, because there's a need for an arbiter to prioritise between seemingly important tasks. But if you keep hearing that question it might mean the KANBAN is not self-explanatory. To ask is to talk, and a team that has members talking to each other is great, don't get me wrong, but it's always better to have quality conversations where everyone is exercising their most proactive and responsible role. Ideally, if you use KANBAN, you generally know what to do next among the options in front of you.
Am I doing KANBAN wrong?
You are entitled to question your KANBAN approach but you have to be aware of some unnecessary constraints you might have self-imposed. Let's give some examples borrowed from experience where we take the first Agile Manifesto point "Individuals & Interactions over Processes and Tools" as our razor tool.
Who's assigned to what?
For a streamlined KANBAN process where you are counting on the "flow" to work like a charm, everyone in the team needs to know what they are responsible for. Multiple assignment is a dangerous practice as you risk diluting accountability but there can be a person assigned to a card that hold subtasks assigned to different people.
Also, anyone in the team should be able to know whether they should self-assign a card without asking too many questions.
To help with this, some platforms have the concept of roles or subteams and it might perfectly work to have a role assigned to the card as a first soft assignment and then allow anyone belonging to that role or subteam to take it for themselves alone.
If a card is in the middle of the KANBAN board but no one is working on it anymore, the kanban is not reflecting the state of the project, don't hesitate to remove the assignment and move it back to a suitable initial KANBAN state.
Are team members created equal?
KANBAN provides a shared vision but, unfortunately, that doesn't always equate to a shared empowerment. Very often, there are classes, where some people enjoy a certain status quo represented by a preference of vocabulary or a preference of workflow.
If KANBAN is your primary visual management technique and you feel somewhat alienated, then it's other people's KANBAN and you're just a visitor. That doesn't work as it undermines a lean approach where everyone enjoys a virtuous circle around accountability and autonomy.
Be aware of people not feeling comfortable with the KANBAN design and its contents. Very often, the developers will impose a particular workflow or card vocabulary because they are more used to states and workflows. It might be a great start but if the KANBAN board is going to reflect the whole process, it has to appeal to the whole team.
Is there a clear workflow?
On a small team and a small project, you need not to worry, personal interactions sort out 95% of impediments and decisions. For bigger teams (beyond 7-8 people) and bigger projects (beyond 3-4 months), how you treat demand management can be of enormous value.
First, should a small issue (like a bug in software development) enter the KANBAN alongside more fleshed-out tasks or not? Some teams try to make sure everything goes into the KANBAN. After all, isn't it a shared view? Yes. But a good shared view needs consistency. If cards that are very different in nature compete with each other, it's likely you are going to end up in a big mess. Consider having a separate view for a specific type of task. It could be a second KANBAN with a different workflow or perhaps a more simple TODO list.
Make sure the main KANBAN board represents the project's state quite faithfully and be open to add secondary boards or TODO lists for that remaining 10% of the project that doesn't fit into the main view.
Do you have a top level view?
The organic flow of a KANBAN board is much about the current state. It's an optimisation technique that leads to less waste and more predictability but what about the big picture?
When there are strategic objectives, it's easy to get lost in the now and forget about them. The KANBAN itself behaves a bit like a heat map. Work In Progress limit per column plus a bird's eye view of the whole KANBAN board might provide you with a qualitative assessment of the overall performance. It is sometimes very useful to have the ability to zoom out and get a sense of the general distribution of cards across all states.
Moreover, you might need a separate view where you keep track of your top level objectives. You can call them Epics, you can call them Objectives, Targets, Subprojects, it doesn't matter. What matters is that you can enjoy the progress of these big milestones or containers separately and quickly jump from Epic to Epic and view what KANBAN cards relate to them.
Key insights to take away
KANBAN is a deceptively simple agile technique. It requires relatively mature teams able to adapt to an organic flow of tasks. This is the quintessence of tuned teams so expect some bumps along the way.
It is vital that you see the KANBAN board and all its bells and whistles as a physical (or rather, digital) manifestation of a process, not a recipe to follow. And to do that, it is important to understand the value of KANBAN as well as some of the most common pitfalls. Without this, frustration will govern every team interaction and work and a sense of disorientation will permeate through all layers, from operation to strategy.
Is KANBAN suitable for everyone? Certainly not, but before questioning KANBAN itself, start analysing your specific KANBAN approach. After all, continuous improvement is part of the deal, right?