Updated April 20, 2023
Today’s software teams are, at least in their processes, more Agile! They are eager to learn and adopt new techniques of project management and project processes. They are willing to think outside set parameters to follow what works for them.
A project management method called Kanban has been making the rounds in the software industry for quite a few years and has gained currency in the last five years. Adopting the Kanban method with Agile methodologies has given companies much to celebrate.
But there is also the criticism that Kanban is a glorified to-do list. So what’s that all about? Let’s find out.
What is Kanban?
If your company is ready to move beyond the traditional software project management approach, there is plenty of project management techniques today. The Agile Project Management system focuses on non-linear, iterative software development methods. Agile methodologies use in Scrum, which focuses on a more flexible approach to project management.
Agile also has links to other project management frameworks such as Kanban and Extreme Programming. Of these, Kanban has achieved a lot of popularity. After all, who doesn’t want a process evolved by the Japanese? Kanban is a concept that evolved at the Toyota Manufacturing Plant to achieve just-in-time (JIT) production, which cuts costs and enables less utilization of resources. At its heart, it follows the “pull” principle of work, meaning that tasks or products need to be “pulled” by requirements and demand and not “pushed” from the top down. Toyota plants develop the market to ensure better stocking of automobile components. It meant that as the demand rose, requests would be filled in.
David Anderson adapted the concept to the software industry with a few changes in his 2010 book, Kanban. Since then, it has been used for various projects with great success. It can be of immense help in complex projects which have the potential to suffer from overloading on one side of the development cycle. The Kanban system treats the software project process as a pipeline. Let’s say a software process has three types of tasks: analysis, development, testing, and finally, deployment. You need to complete twenty tasks.
In the case of a traditional project management system if, for instance,
- There are 25 stories in total
- Analysts can handle five stories a week
- Developers can handle five stories a week
- There is a limit of three stories a week for testers
In this situation, work simply piles up at the testers’ end. At the end of Week 1, the situation will be as follows:
- Only three stories have moved on to deployment.
- Developers and analysts work on three stories, as testers cannot take the developers’ output and test the same.
- In this situation, work piles up at the testers’ end. Work gets piled up, leaving developers, analysts, and the project manager in a fix.
The analysts and developers may now simply be twiddling their thumbs! Or their manager might realize they are idle and reallocate them to another project, where a similar situation may arise. So two projects are now stuck in the testing phase!
The problems in such a situation are relatively easy to see. What point does it serve to develop ten stories (or bits of software) when they aren’t tested soon?
Now, on to the Kanban method.
The Kanban method is an extremely simple concept. It follows a simple logic of using a “pull method” to remove the bottlenecks first and limiting the Works in Progress (WIPs) for better work processes.
In its simplest form, Kanban, literally “visual board,” helps by “pulling” items off a to-do list rather than working with timelines. The Kanban method helps identify the bottlenecks to manage the process flow better.
A basic Kanban board lists tasks to be done, jobs in progress, and completed tasks.
Most Agile projects have a similar board as well. However, the tasks can be more complex in software management. In a Kanban board, you mark the stages of the deployment, along with a number for each column. This number represents the maximum number of tasks, or stories, a certain step can handle.
Our example on a Kanban board looks like this at the beginning of the second week. It means developers and analysts will not work on the optimal number of stories that week. Work is getting piled up at the tester’s end. And organizations can ensure that teams work together to get the testing done. Alternatively, they can look at other process flow models to avoid this.
When handling projects through the Kanban system, the scope for work to get piled up reduces. Teams take up stories according to the maximum bandwidth available.
In a typical Kanban setup, teams pull in work according to the available bandwidth, ensuring that they always operate at maximum capacity. The system also allows for a fast track for urgent tasks so that they move through the board with minimum effort.
Take a look at this Kanban board.
All steps are operating at maximum efficiency. The task on the “Fast Track” is also taken into account.
Kanban is by no means the only method used to increase efficiency by limiting WIP. Other systems achieve the same result—for instance, CONWIP (Constant Works in Progress) and DBR (Drum-Buffer-Rope) systems, primarily meant for manufacturing industries.
However, the software industry has modified the Kanban system to suit it the best.
How is Kanban Different from Agile Methodologies?
At its heart, Kanban is a methodology that uses some elements of Agile Project Management. Many projects in the Agile framework have roots in Lean approaches. The difference between Kanban Methodology and Agile Project Management is not as black and white as the proponents of the two methods would have us believe. They have more in common than differences.
The Agile framework is not absolute. The question is not whether teams are Agile or not. Teams often have the agility to varying degrees. One of the methods to have more skill in your software development process is to use Kanban.
A few differences exist between Kanban and Agile methodologies. Some of the features of Kanban development that are a bit different from Agile are:
- Timelines are not a significant factor. This concept is tough to wrap our heads around, as it seems very non-intuitive. “How do you work without deadlines?” people often ask. If every team member engages at their maximum efficiency, time ceases to be a factor.
- Stories (tasks) are larger than in typical Agile systems. Typically, the length and complexity of stories are longer than with a specific Scrum project. Since the focus is not on estimating time but moving the process along, Kanban can afford to work on larger stories.
- All existing processes remain the same. The principles of Kanban for software development, as articulated by its founder, David Anderson, in his blog, include the following basic principles:
- Start with what you do now.
- Agree to pursue incremental, evolutionary change.
- Respect the current process, roles, responsibilities & titles.
- Each story is measured in cycle time. The project is evaluated by cycle time instead of the traditional Agile computation of velocity (the number of stories completed during a given time). It means that Kanban emphasizes how long it takes to complete a task. This estimation feeds into the next cycle. You can often see a ticker on many Kanban boards that mention how many days the team takes to finish a story.
Kanban: A Board, But What Else?
So, Kanban is a board that shows us how the stories are arranged—is that even such a big deal, many ask. There is, in fact, a great deal of discussion about what Kanban is and can do.
Is Kanban just a method to manage the workflow? Or is it something that one can use together with Agile methodologies for maximum efficiency? Or, can it be a whole new way of workflow management?
Each team uses Kanban, as they deem fit, for their particular situation. Regardless, Kanban has the potential to work as a way of life for software development if used to its optimum level.
Whether it uses to manage workflow or as a new paradigm in software development, there is no denying that it helps manage WIPs.
It’s crucial to view Kanban as a framework for project management rather than merely a tool for managing work in progress if you want it to be effective.
- Optimize teams so that no team starts something they cannot finish, which helps the process.
- Do not resist changes from the original Kanban system. If your project will do well with deadlines and timelines, incorporate the same as you would. It makes for a healthier and more robust development environment.
- Do not shun teamwork. Kanban may seem like, but it is not, a model based on individuals working in isolation. Teamwork must be an integral part of Kanban software development.
- Think outside the box. Think about changes in the workflow. Many teams are now opting for Test-Driven Development, with Acceptance Test-Driven Development. The use cases drive the required features and the nature of development in a way that the acceptance tests are carried out first.
Hybrids
As more and more companies use the project management tools best suited for their particular situation, it is not surprising that two of the best project management methodologies: Scrum and Kanban have been integrated to much success.
The hybrid, called Scrumban, is making inroads into many projects.
Suppose an organization is already using Scrum but finding it difficult to hold the project together, either with the sprints not working well or testing not being airtight. In that case, it might be time to consider Scrumban.
To explain it, Scrumban involved taking a magnifying glass to the sprints. It’s not just about the sprints as part of the project but also about what happens within them. Scrumban helps look into how a story gets processed within a sprint, and that might make all the difference.
Scrumban, or any of its variants, is a minimal change from existing practices. The beauty of using Kanban is that it can operate with virtually any project management model: waterfall, Agile, or anything in between.
Getting Started with Kanban
It’s easy to get started with the Kanban system. Implementing Kanban minimally as a trial for a particular part of a project is also possible.
- Map out the software development process. Make a clear map of the entire process. How does the project—from the initial design to development to testing to feature changes- work in reality?
- List down the steps that Kanban will use. It typically comprises the analysis, development, review, and testing phases. Use the steps that are entirely under your control.
- Work on important points such as:
-
- Limits to the Works in Progress for each step.
- Processes for expedited/blocked work
- Back-of-the-envelope estimates about the cycle time
- Frequency of the Kanban board/process/estimate review
- Buy a whiteboard and a stack of Post-It notes.
- Get started
- Review as required.
- Repeat
So, go ahead and get started on Kanban!
The whole idea behind Agile methodologies is to accommodate changes in people and processes! Stay calm if it turns out how you initially intended. Let us know about your experiences with the Kanban method.
