In this article I am going to describe some conditions under which a team adopting Kanban can be set up for success or failure.
Historically used in the manufacturing industry, Kanban has been incorporated in the successful Toyota Production System (TPS). Kanban is one of the most known Agile frameworks and often over-simplified with the adoption of a Kanban board.In its minimal version, the board has 3 columns (to do, in progress and done) and each task is written in a post that would travel left to right across the board. As soon as someone is ready to take on a task, the post is moved under the “in progress” column. There is a limit on the number of items that can be “in progress” at any given time.
Given the above oversimplified refresh on Kanban definitions, here are a few things you need to consider before adopting it in Software Development.
Kanban works for tasks without unknowns.
The team member who will pick the kanban card (or token) knows what to do from the beginning to the end. Whilst the token owner can of course ask questions, look for clarity, involve others, use the common knowledge of the team/organization, it is recommended that they pick cards for tasks already known by them. By “already known” I mean something that they have experience in completing it fully. Something they master.
The Pizza Restaurant
The pizza chef doesn’t need to ask around how to make a pizza. They master all aspects from pre-production to delivery, from buying the ingredients to using the most suitable container for transportation, including of course all intermediate stages of working the dough, choosing and matching the add-ons, cooking time, controlling the temperature, packaging… You can have a team of pizza chefs in a large kitchen even sharing the same wood-fireplace, same tools and space, orders pipeline, clientele.
Each and every pizza-chef takes care of their Kanban-pizza autonomously.
You may have seen places where someone prepares the dough, someone else the sauce or other ingredients, someone takes care of the oven and someone else of packaging and delivery. If they share the responsibility of different preparation steps, still the sequence is performed without hesitations and the agreement is explicit and clear throughout the process. There is also the implicit agreement that if something goes wrong in the pipeline, everyone has the full knowledge to provide support and manage to complete the order without under-cooking or over-cooking and most importantly without burning the place or having a burn-out.
In many kitchens (not only pizza places) the orders are written down on cards that are aligned in a way similar to a Kanban board and they are quickly processed.
The chef and all the kitchen knows what to do. Unclarity in the order would increase completion time, disrupt flow, reduce rhythm and performance. Anything that has gone wrong would be discussed in the kitchen briefing the morning after. Whilst the team is capable of doing more, they do not commit to preparing something that is not in the menu, or to something they do not master.
Yes, they do it on request whenever the circumstances are favourable but they do not commit to complete any capricious or extravagant request from the customer.
Software production and delivery
A strong, ruthless, high-performing DevOps team with highly competent and trained team members could use Kanban for known repeatable sequences, pipeline steps, configurations. Unfortunately a good percentage of DevSecOps issues do not have a clear, immediate solution because they may require troubleshooting, and deeper investigations. Nevertheless, the capacity to react and keep the system running should be planned, configured, tested many many times and activated on demand with no hesitations.
Can a person with partial knowledge take or start a Kanban card?
If the Kanban board has different statuses that reflect a breakdown for the activities in progress, it is possible that a team member takes a card even without being able to complete the full definition of done.
There are 2 main things to consider though:
1. If a team member takes a card that they cannot complete or progress to the next stage autonomously they will need to ask for support from someone else.And when this happens they are disrupting someone else’s work and interrupting the journey of the card. Tasks can have dependency on each other. That task may be an enabler for subsequent activity. The complexity of the process would increase according to the number of cards, statues, team members, interruptions. Kanban is meant to be a simple and tidy production system, theoretically one of the most straight-forward agile frameworks.
2. In a Kanban board where the “In Progress” status is broken down into a sequence of steps with different responsible people, it is crucial to make sure that there is always someone you can pass the torch to.
Assuring so depends on many factors such as, for instance, the number of cards, skillset of the team members, speed of execution, capacity to remove bottlenecks and many more.If you do not control and limit the flow, all the “in progress” work (i.e. Waste in LEAN) piles up and it all turns into a dump.That’s why in a decent Kanban implementation you stick to both the overall limit and per-column limits. These limits are meant to be respected because each team/organization has limited resources and limited tokens. Not setting or respecting these limits means you are not doing Kanban and you are creating all the conditions for failure.
The Garden
If you go to the East Gardens of the Imperial Palace in Tokyo, they issue you with a token (Kanban) on entry. You keep it in your hand till the end of your visit. You don’t pass your token to others after half a visit. You don’t keep the token in your pocket just because you may come back the day after.
You give it back at the exit when you are done. Also, once the tokens run out they stop letting people in.
Limiting the number of visits in progress makes the experience more enjoyable, it ensures that security measures can be taken easily, everyone has plenty of space, the flow is constant and sustainable, all under control and the garden is never overloaded.
Again, to work smoothly everyone needs to know what to do with the torch, where to go, who is the next one ready to receive it and run at the same speed. The agreement among all interacting team members needs to be in place, clear and explicit. That’s what Kanban is for. Very disciplined, knowledgeable, relying teams with known tasks to be completed.
If your people work better when collaborating as a team, there are other Agile frameworks that support best pair programming, cross collaboration, and team work. XP and Scrum are among these.
If you need to discuss the card, understand more about the UX, what the PO wants, how the architect thinks to get rid of legacy solutions, go around looking for the right set of people that can decide… then use a framework where cards (or backlog items) can be continuously discussed, clarified, estimated, solved together as team. XP and Scrum are among these frameworks.
Switching among different frameworks without the correct preparation can be fatal.
The team will need to be trained and coached not only for a smooth shift but for a solid start that will help them progress in their own framework implementation. The organization will need to know the different ways of working with the team, how to interact, how output will differ, the frequency of productions & delivery cycles and so on. If tools and policies need to be amended or reconfigured, that needs to happen and be clear to everyone. The team will commit to new agreements and start new practices.
The Dump
I have seen organizations mixing up frameworks according to managers’ agenda or delivery dates promised to customers without even discussing them with the team. This type of announcement may sound something like “Great demo! Starting from today, for the next 2 weeks we will work in Kanban mode.”
As a developer, tester, business analyst, product owner, software contributor or agile coach (scrum master) it is important to recognise and stop the danger of similar shocking disruptions.
“Kanban mode” or similar improvised ideas are simply garbage, good for a dump and you can smell there is something else going on. Probably office politic, someone’s agenda or self-sabotaging intentions.
Reject it as a team and toss it as soon as you can.
Imagine in a pizzeria the manager orders all pizza chefs, “from today and next two weeks we will work in cocktail bar mode” and expects this to be clear for everyone.
Conclusions
Kanban is a good, simple framework that requires highly skilled autonomous independent team members. If you fear isolation or the team breaking apart, get more chances to take a pizza together and a good agile coach that grows the team, builds up their strength, sets them for success.
Breaking down the In-Progress activities into different statuses with different responsible people is tricky, but it can be done under the conditions explained above:agreement, seamless flow, no capacity or knowledge bottleneck, everyone knows from whom they receive the torch, what to do when they hold the torch, who should receive it next, and the full torch journey just in case.
If to implement Kanban you need to complicate things or introduce a workaround, you may need to review your decision and consider opting for another Agile framework.
Choosing the right framework is important and it is an expensive decision. Don’t do it often. Prepare the organization for it with training and coaching sessions.
To fail using Kanban is very easy. An improvised or non disciplined approach to Kanban can easily transform a queue of ordered tasks into a nasty, confusing, overloaded dump.
To succeed using Kanban, you need to keep the same discipline, simple and elegant solution used in the East Gardens of the Imperial Palace in Tokyo: one token per visitor; visitor keeps the token from beginning till the end of the visit; limited tokens available.
* * *
I write about organizational patterns, transformational leadership, healthy businesses, high-performing teams, future of workplace, culture, mindset, biases and more. My focus is in leading, training, and coaching teams and organizations in improving their agile adoption. Articles are the result of my ideas, studies, reading, research, courses, and learning. The postings on this site and any social profile are my own and do not represent or relate to the postings, strategies, opinions, events, situations of any current or former employer.
This article has been published for the first time on danieledavi.com by the author Daniele Davi’.
© Daniele Davi’, 2022. No part of this article or the materials available through this website may be copied, photocopied, reproduced, translated, distributed, transmitted, displayed, published, broadcast or reduced to any electronic medium, human or machine-readable form, in whole or in part, without prior written consent of the author, Daniele Davi’.