This is Kanban
Welcome to the dark side. We have cookies.
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
This article will provide a birds-eye view for anyone who wants to give Kanban a try. Before starting, a small disclaimer. I have always dealt with the idea of being an Agile Coach the same way a UFO deals with steady footage. I ran away every time I could. Nevertheless, I have helped IT Software Engineering teams using this methodology for some time and learned this method can be applied to multiple environments, even outside the scope of Software Engineering teams.
What is Kanban?
In a concise summary, Kanban is a set of methods for managing tasks via a crafted board unique to the team. The board reflects what the team is currently working on. Kanban differs from other Agile practices (for example, Scrum) due to its adaptable nature to complex organizations and products. It provides a breathing opportunity for your calendars by requiring fewer ceremonies. Kanban has some core principles which I will share below.
There are two main flows in Kanban:
Upstream: Product Owners are very familiar with this flow since is almost the same as the backlog refinement and discovery phase (but without the meeting overload).
Downstream: The board! The place where the team’s dreams come true. Is here where the tasks are accepted by the team and go through the team’s workflow.
For building a Downstream Kanban board there are some high-level notions to take into account:
Autonomy: The board and mindset in Kanban, is for everyone to be autonomous for picking up new work.
Ready to Start: This is a special column in the board where the Product Owner or Project Manager feeds the incoming work and sorts it by priority.
Replenishment: An informal session where a subset of the team (minimum 3 people) reviews a ticket, approves, and commits to its delivery, by adding the story to the board. No need to schedule a meeting. When someone wants to replenish a story, just call some colleagues and it’s done while your coffee is still hot.
Working and Waiting for Columns: Designing the board has its tricks. Some columns are designed to signal that an activity is being performed (For example Development, Testing, Deploying, etc). Other columns signal the work is waiting to move to the next stage (For example, To Development, To Testing, To Deploy).
Get out of the board! mentality. The Kanban mindset is to quickly get rid of already existing stories before adding new work to the board.
The board reflects the priority. No one should ask the Project or Product manager what the priorities are. Everything is displayed on the board. The highest priority tickets are at the top, from right to left.
WIP limits: A flag informing the team that a sort of bottleneck is happening on the board and should be addressed. It is triggered and many stories keep pilling up on a column and the size is bigger than the defined Work In Progress limit.
Swimlanes. They cross the board and allow multiple areas or products to be addressed by the same team. A famous one is the “Expedite”, when a blocking issue occurs and a story lands on the board, someone needs to stop what is doing to address it immediately. Other swimlanes are simply different products, which are also ordered by priority.
cottonbro studio: https://www.pexels.com/pt-br/foto/homem-escritorio-trabalhando-sem-rosto-6804091/
For the priorities, it works like this: If someone is available for a new task, the tickets closer to Complete or Done (typically the last column) have higher priority.
Let’s imagine we have a board with only 1 swimlane and we need to perform a test of a new feature and it’s in the “Testing” column, close to Done. This test has higher priority than starting a new specification document that is at the very beginning of the flow. The tickets at the very top of the board are the most pressing topics than the ones on the bottom. There is no need to ask the PM which ticket has the higher priority. The board says it already.
If everything goes right, the Project or Product Manager prepares the “Ready to Start” column and takes a block leave. The team is encouraged to autonomously take new work from Ready to Start, create more tasks if needed, and move on with the work. By the time the vacations are over, the feature is already delivered. (Real story! It happened to me)
Highly skilled teams in Kanban have little to no interference from leadership, apart from helping unblock deadlocks or other annoyances that prevent the team from delivering
FAQ for Kanban
How are estimations in Kanban?
Whatever works the best for your team. However, if I were to start a new team from scratch I would use Agile estimation practices, in particular the T-shirt sizing. If you are migrating a team into Kanban and you have already a mature estimation process that works, please continue using it. If you want to improve on it, be my guest! Kanban doesn’t dictate the method of estimation.
If your team has a Scrum background, be mindful that Kanban doesn’t require an entire team inside a room to estimate tickets. Give your developers a break! The tickets and their estimations can be reviewed in the same way as the code review goes.
Your team benefits a lot when metrics start to pop up. If needed, the Project or Product manager can extrapolate the different buckets, cards, points, and t-shirt sizing in actual effort in days or hours, without constantly asking the team for confirmation. Historical data is king.
My very strong recommendation for the team is to create stories that are below 3 days of effort in execution (for example development effort). More than this, is difficult to have an accurate estimation and blurs the board and its metrics. This might be particularly challenging for teams coming from a Scrum because the size of stories is not a particular concern.
If Kanban doesn’t have sprints, how is the planning?
This is why waterfall-based projects succeed so easily in Kanban. When a group of stories is created and estimated, the metrics provide visibility on how much effort is linked to each story. Then normal project management scheduling techniques (bottom-up or top-down) can provide visibility on the delivery date.
Be mindful, however, as with any Agile method it should be open to evolving requirements and continuous learning. One of the biggest criticisms of Waterfall is its inability to adapt to feedback loops. Learning and continuous improvement are integral parts of Kanban and Scrum.
In Kanban, if a product team wants to deliver some features on a given date, those tasks should have priority and scheduling can confirm if is feasible in a given timeframe. If asked about whether another set of features, with lower priority can also be delivered, it all depends on how things will progress and if changes are needed on the highest priorities tasks.
In what way is Kanban different from Scrum?
No sprints, fewer ceremonies, multiple flows.
Kanban is all about the flow of activity. The stories need to fly from the Replenishment to Done. A ceremony in Kanban can have 3 developers who agree on the ticket and estimation. Scrum drags entire teams across endless meetings and conflict arises when a feature takes more than 1 sprint to plan. Scrum tends to have its own phases, while in Kanban, the team designs the workflow first and adds a few informal ceremonies afterward.
Scrum doesn’t handle well multiple products with different objectives in the same squad. These are reflected on swimlanes in Kanban. Some organizations require the project team to handle part of the production support tasks and Scrum struggles to allocate capacity to surprises mid-sprint. Kanban has the notion of Expedites and BAU swimlanes which are typically at the top of the board (The priority is defined by the team and can shift).
What are the challenges of implementing Kanban?
Like any other big change, the resistance to adopting a different mindset and practices can be the bigger challenge.
Classical or waterfall teams adapt very well to Kanban. However, that cannot be said about Scrum teams. There are too many artefacts on Scrum which is hard for a person who worked years on Scrum to let go. Scrum stories might take weeks to complete while in Kanban we want to have smaller more refined tasks. Some notions are very close between Scrum and Kanban, and colleagues might even be misunderstood without everybody realizing it.
In contrast, applying the Definition of Ready, Definition of Done, and Acceptance Criteria are easily done on old scrum teams, whereas previously waterfall teams struggled to notice the difference between the three. The recommendation is to start by designing the team’s flow and implement incremental changes from that point onwards.
Is Kanban more Agile than Scrum?
It doesn’t matter what is more or less agile. It matters what works well for the team. Unfortunately, Scrum is used in environments which is not designed to. Kanban is just another possible solution for your team. Choose what works best.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur
One additional difference is that Scrum optimizes for predictability and planning, while Kanban optimizes for workflow duration.
Nice piece! I like how you are transparent about the possible advantages and challenges with Kanban.
I'm definitely more experienced in Scrum so I might have a bias for that, but I once made the mistake of letting go Kanban for too long (as I inherited a team) when the project needs (and the team maturity at the moment) were a better match for Scrum.
I guess it's a matter of understanding your team and the project you are working on. When that's clear, being flexible about what methodology can be a better fit becomes much easier.