Table of contents
In the technological era we live in it is more complex than ever to create an efficient, performative process for getting work done. Many project managers in software development turn towards the Agile frameworks for project management (which Agile itself an answer to the Waterfall method that dominated how work was getting done in the late 20th century) to give teams a quicker and more flexible approach to meeting requirements for the customers.
When most think of Agile methodology they go to the Scrum framework, a popular extension of Agile that utilizes sprints (set blocks of time to accomplish specific goals). However, a perhaps lesser-known extension of Agile is the Kanban method, an arguably more flexible model that is based around a Kanban board. In this article I will delve into a brief history and overview of Kanban while establishing Kanban as an effective tool that is optimized for quickening cycle times by providing extreme flexibility.
A note before beginning: Kanban is often compared to Scrum to determine which process is better. While there are significant differences, they are both at their core Agile methodologies that attempt to accomplish the goals of Agile through different means.
It is the classic apples to oranges; they are similar objects, both with healthy goals, but key differences in structures. I will occasionally use Scrum as a comparison to highlight these differences, but I would not recommend reading this with an end goal of deciding which process is better; that decision is dependent on specific context.
Kanban: Where Did It Come From?
The concept of Kanban comes from a Toyota factory in the mid-1900’s. Toyota was struggling to turn a profit and were looking for a change in process to turn the tides. Taiichi Ohno, a manager for Toyota at the time, was given the chance to evaluate why Toyota was under performing so heavily.
There is more to the story, but for brevity it was this situation that gave rise to the idea of Kanban. Ohno came up with a system of using literal signcards (the approximate translation of “Kanban” itself being “signboard” or “signcard”) to signal how requirements and demands for production progress towards the end goal. Fast forward to today when Agile Kanban makes use of the same system: relying on cards that progress across a board towards an accomplished state.
The Process Itself: What are the Defining Characteristics?
By far the most recognizable piece of Kanban is the board. Kanban relies on a literal structured board divided into several states that cards enter onto and progress across towards the end state. For example a board could be divided into: Backlog, Development, Testing, Deployment, Completed.
Having clearly defined states in a format like this allows for quick comprehension of the work and an easy way to visualize tasks. It is simple to tell where work items are in the process and identify chokeholds preventing work from progressing to the next state.
Note that Scrum also uses a Scrum board for organization of work, but a key difference is the maintaining of state on the board. A Scrum board is recycled at the end of the sprint, putting the main focus again back on the sprint itself. In Kanban, the work items on the board are not beheld to a specific sprint or amount of time (although the board itself can, and arguably should, change often).
Another essential part of the Kanban board is work in progress limits (or WIP Limits). WIP Limits are assigned to each column on the board, and once one column reaches its WIP Limit no other work items can progress to that state. At first this may sound intimidating (our work can get blocked?!) but this system actually serves several crucial purposes.
Focus: Stop Starting, Start Finishing
When I was part of an organization that was setting up Kanban there was concern regarding the WIP Limits. These are valid concerns which at first seem to conflict with Kanban’s trademark flexibility but in practice WIP Limits serve as natural limiters to distractions and give clear focus of what work needs to be completed for other work to continue forward.
This leads into a main tenant of Kanban: Stop Starting, Start Finishing. If a WIP Limit for a column has been reached on the board the only way to move work forward is to clear room, and the main way to accomplish this is to advance work items in that column forward. The advantage becomes clear: work no longer lands in dead zones of completion, being left behind as new work becomes the higher priority simply because it is new.
Workflow: Why Pulling is Better than Pushing
Now that WIP Limits have been established it is important to understand another key concept in Kanban: the idea of work being pulled instead of pushed. I first heard the phrase “Command-and-Control” from Lyssa Adkins’ book Coaching Agile Teams. When using it Adkins was referring to the style of management where managers give direct commands to team members on what work to complete; in other words pushing the work onto the team.
This creates ground for miscommunication in the team. Unless a manager and team are exactly in tune with each other the workflow of the team can become disrupted causing work to become lost in the shuffle (or worse: incorrectly completed and turning into technical debt).
Instead, Kanban relies on the concept of team members pulling work. Team members select the work they want to pull onto the board from a queue, usually referred to as a backlog, allowing team members to pick what work they are ready for and pull it onto the board.
Now the head of the team, referred to as the “Coach” in Kanban, can quickly scan the board and see what the team members are working on. Combining this with WIP limits naturally focuses the work of the team and allows for effective, functional communication instead of wasted communication as priorities conflict.
Note: This section is not to say that without Kanban a team cannot communicate effectively or that with Kanban team communication will be perfect. These things are situation-dependent and it is possible for a team to be synced and communicating well without using Kanban. (For example: Scrum uses sprint planning to hone focus and ensure team members are all on the same page.) However, Kanban gives a natural environment to set up this communication level. Anyone can go directly to the board and see the current focus of the team.
Coaching: Who’s In Charge, Anyway?
In the previous section I mentioned the Coaches in Kanban, so lets dig into that role. Outside of the Kanban board, the role of coaches is the second most distinct attribute of Kanban vs other project management strategies due to the reversed role of team leaders.
In a typical Command-and-Control structure the manager is giving direct instructions to team members. In Kanban the Coach is instead effectively a mouthpiece for the team. Since team members are pulling the work they can complete the Coach no longer has to manage this attribute of the team and can instead focus on providing the support for the team to keep work flowing across the board. If a member has a question or needs additional information to complete a work item it lands on the Coach’s shoulders to resolve and unblock the work.
This way the Coach serves as a natural blocker against distractions for the team, becoming the single point of communication for the entire team and serving as a filter for questions coming in. A Coach can deflect unnecessary probing directed towards team members, relieving them of distractions.
This is not to say that the Coach is voiceless on the team. Coaching requires drawing out the best from the team. This often takes the form of being their support and distraction-reflector, but it is also the Coach’s responsibility to keep the team accountable.
Since the Coach is not distracted with trying to determine which members can take on what work, they are given opportunity to stay in constant communication with the team, determine potential blockers, raise concerns with the team, and keep work flowing across the Kanban board.
Prioritization: Supporting the Team Before the Work Starts
We’ve established some of the functional advantages of Kanban once work reaches the board, but before team members can even start working there is an essential practice to ensure Kanban can achieve its maximum potential: prioritizing work to determine the order work is pulled onto the board.
The is a simple reason this is so important: one of the core Kanban principles is Stop Starting, Start Finishing. If there are several pieces of work to be completed and the least important piece is pulled onto the board it’s only a matter of time before the more pressing work is going to force its way onto the board and the entire process starts to break. WIP Limits start to get overloaded, focus declines, and soon work is disorganized and lost.
It is imperative that proper time is given to prioritizing work before it is pulled onto a board. One of the best ways to support this is careful auditing of what makes its way into the prioritization queue. Making use of Portfolio Managers (also known as PMs), people designated to consider what work makes it to prioritization, ensures there is not too much work ending up being prioritized. If just anyone can create a work item to be prioritized it will cause issues both immediately and further in the process.
In the same way a Coach is the mouthpiece and filter for the development team, a PM is the same for customers requesting work to be done. The Portfolio Manager’s responsibility is to become the voice of the customers they represent and ensure the most crucial work being requested for a particular sector is being sent to prioritization.
When the emphasis is on finishing, priority work can be completed quickly and efficiently. If at any point anyone has questions about the state work is in they can consult the board to check how it has progressed.
Refinement: Keep the Focus on Finishing
It is clear the prioritization process is important to the health of the Kanban system. After Prioritization, there need to be steps taken to break down what the customer is requesting into pullable work items, and that phase is called Refinement.
Refinement can feel like an ambiguous process but in my opinion it is always necessary. It can be hard to get the correct group together to perform refinement of complex tasks, but it all boils down to the same thing: take the request, define a Minimum Viable Product (MVP), and create work items to complete this MVP.
An MVP refers to the bare requirements necessary for completing a feature request. The importance here goes back to the same core tenant of Kanban: Stop Starting, Start Finishing. A solidly defined MVP with clear work items and a plan of attack creates avenues for work items to be pulled onto the board and focus-fired across the board to completion.
If, while along the way, there are other features requested these can be documented discussed, and if deemed appropriate can be prioritized to re-enter the workflow for refinement. It is normal to not capture all requirements right from the start. However, the important part here is to set aside these feature requests and finish the MVP. Kanban is set up to support this plan, utilizing proper refinement and WIP Limits to ensure focus stays on the MVP.
This is where the true flexibility of Kanban comes at. At first, it may seem rigid to limit the amount of work that can be focused on at a time. But the entire point of Kanban is that you don’t have to worry about 10 things being worked on at once. Instead, work is constantly being defined, prioritized, refined, and pulled, with MVPs being cycled through quickly, allowing for a true iterative approach. Customers get their workable requests completed much quicker and any additional requests can be redefined in an MVP-2, MVP-3… MVP-n until no more and a feature is truly completed.
This gives massive flexibility in what is getting done. As work is being completed and delivered much faster, any changes in deliverables along the way can quickly be reconsidered from a fresh state instead of having to tag more and more discussions onto an ever-growing set of requirements.
The full picture then starts to form: work is requested and vetted by a Portfolio Manager (PM), prioritized, and broken down into a lean MVP. The MVP is pulled onto a board and work begins, while any additional requests along the way are cycled back into the prioritization queue, refined, pulled, completed, rinse, repeat.
Note: during the entire process if anyone has questions on the state of a specific feature or work request they simply go the board and see where it is currently. If there are questions the Coaches are in place to limit distractions on the team, keeping the MVP always moving forward and allowing iteration to be achieved quickly and at regular intervals.
Retrospection: How Did We Do Here?
The Kanban production process has been established, now what happens after the work is completed? Similar to Scrum, Kanban takes advantage of retrospectives to analyze how well things went for the project. Retrospection allows for continuous improvement of how Kanban is operating for the team. Retrospectives can sometimes be tricky, especially as a team is just starting out or just completing a project, however it is absolutely vital to keep these in place.
I personally believe you can never retrospect too much, and Kanban embraces this mindset by encouraging retrospectives at any time to assess how a team is performing and break down any blockers that might be rising. Post-project retrospection is mandatory, but even more useful is a regular cadence of team retrospective to encourage team members to share their thoughts.
I recommend always taking one or two action items from a retrospective session to concretely complete; the longer the delay between work completion and retrospection the harder this becomes to accomplish as there will be more things to discuss among the team.
In this way retrospection in Kanban becomes a way to ensure the team is operating at efficient, high velocity and can quickly react to and counter and blockers that may arise in the process. Some things I have personally heard discussed at these retrospection meetings are board structure (WIP Limits, column states themselves, etc), refinement process, how to know when a work item is ready to pull, how to push back against a work item not ready to pull, and many more.
Conclusion: Is Kanban the Perfect System?
In a word: no. There is no perfect method to getting work done. Especially when switching to a new project management method (or starting one for the first time) there are going to be many bumps in the road. Kanban in particular took several months to really start seeing the benefits of the work process.
Another difficulty regarding setting up Kanban is that everyone needs to buy into the system. If some team members are cheating and working outside the board, all the issues we discussed earlier present themselves.
However, I believe Kanban has a high payoff once the wheels are rolling and provides many boons of teamwork. The deliverable speed makes these initial bumps worth it. I’ve shared the biggest functional advantages of Kanban in this blog, but there are many more improvements that can be seen when Kanban is set up successfully: clean, understandable, and important metrics, general team member fulfillment, improving meeting efficiency, and many more.
No system is perfect, and it is always important to consider all options when reviewing how you are planning to get your work done, but hopefully this blog has shown the possible advantages of Kanban in embracing an Agile process.
