Today’s software teams are, at least in their processes, more Agile! They are willing to think outside set parameters to follow what works for them. They are eager to learn and adopt new techniques of project management and project processes.
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. Together with Agile methodologies, adopting the Kanban method has given companies a lot to celebrate.
But there is also the criticism that Kanban is nothing but 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, today, there is no dearth of project management techniques.
For one, there is the Agile Project Management system, which focuses on non-linear, iterative methods of software development. The use of Agile methods is evident 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. It was developed to ensure better stocking for automobile components in Toyota plants, based on demand. This meant that as the demand rose, requests would be filled in.
The concept was adapted to the software industry with a few changes by David Anderson, in his 2010 book, Kanban. Since then, it has been used for various projects with a great deal of 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.
Basically, 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. Let’s say there are twenty tasks that need to be completed.
In the case of a traditional project management system if, for instance,
- There are 25 stories in total
- Analysts are able to handle five stories a week
- Developers are able to handle five stories a week
- Testers are limited to three stories a week
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 are unable to take the developers’ output and test the same.
- Work gets piled up, leaving developers and 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 there are two projects that are now stuck at the testing phase!
The problems in such a situation are not hard to see. What is the point in developing ten stories (or bits of software) when they aren’t going to be tested any time 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 removing 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 in identifying the bottlenecks so that the process flow is better managed.
A basic Kanban board has a list of tasks to be done, tasks in progress, and tasks completed.
In software management, however, the tasks can be a bit more complex. Most Agile projects have a similar board as well. In a Kanban board, the stages of the deployment are clearly marked, along with a number for each column. This number represents the maximum number of tasks, or stories, a particular step can handle.
Our example on a Kanban board would look something like this, at the beginning of the second week. This means that developers and analysts will not work on the optimal number of stories that week. It would be obvious that 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 models of process flow so that this doesn’t happen.
When projects are handled through the Kanban system, there is less scope for work getting piled up. Stories are taken up according to the maximum bandwidth available.
In a typical Kanban set up, work will be taken up according to the available bandwidth, and work will be pulled in by teams, so that they are always at maximum capacity. The system also allows for a fast track, for tasks which are urgent, so that they move through the board with minimum effort.
Take a look at this Kanban board.
It is clear that all steps are operating at maximum efficiency. And the task that is on the “Fast Track” is also accounted for.
Kanban is by no means the only method used to increase efficiency by limiting WIP. There are other systems that achieve the same result—for instance, CONWIP (Constant Works in Progress) and DBR (Drum-Buffer-Rope) systems, which are primarily meant for manufacturing industries.
However, Kanban is the system that has been best modified to suit the software industry.
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 an absolute. The question is not whether teams are Agile or not. Teams often have agility in varying degrees. One of the methods to have more agility 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:
- Time lines are not a significant factor. This is a tough concept to wrap our heads around, as it seems very non-intuitive. “How do you work without deadlines?” people often ask. But if every member of the team is engaged at his/her maximum efficiency, then 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 typical Scrum project. Since the focus is not on estimation of time, but simply on getting the process moving along, Kanban can afford to work on larger stories.
- There is no significant change in existing processes. The principles of Kanban for software development, as articulated by its founder, David Anderson, in his blog, includes 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 not by the traditional Agile computation of velocity (the number of stories completed during a given time), but by cycle time. This means that Kanban places emphasis on how long it took to complete a task. You can often see a ticker on many Kanban boards that mention how many days the team takes to finish a story. This estimation feeds into the next cycle.
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 is used to manage workflow or as a new paradigm in software development there is no denying that it helps manage WIPs.
To make Kanban work best, it is important to think of it not just as managing WIPs, but as a project management framework. Certain basic guidelines will help the process along.
- Optimize teams so that no team starts something they cannot finish. This helps the process along.
- 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. This makes for a healthier and more robust development environment.
- Do not shun team work. Kanban may seem like, but is not, a model based on individuals working in isolation. Team work 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, where the acceptance tests are carried out first with use cases, which then drives the required features and the nature of development.
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.
If an organization is already using Scrum, but is finding it difficult to hold the project together, either with the sprints not working well, to testing not being airtight, it might be time to consider Scrumban.
To explain it simply, Scrumban involved taking a magnifying glass to the sprints. It’s not just about the sprints as part of the project, it is about what happens within the sprints. 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 be used with virtually any kind of project management model: waterfall, Agile, or anything in between.
Getting Started with Kanban
It’s easy to get started with the Kanban system. It is also possible to implement Kanban in a minimal manner as a trial for a particular part of a project.
- 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 changes in features, work in reality?
- List down the steps where Kanban will be used. Use the steps that are entirely under your control. This typically comprises the analysis, development, review, and testing phases.
- 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 with regard to 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!
Do not be scared if it doesn’t turn out the way you had initially intended. The whole idea behind Agile methodologies is to accommodate changes in people and processes! Let us know about your experiences with the Kanban method.
Recommended Articles
100+ Online Courses | 400+ Hours | Verifiable Certificates | Lifetime Access
4.6
View Course
Related Courses
