How & Why to Use the Kanban Methodology for Software Development
You’ve probably heard of the Kanban project management methodology, but you may not know a lot about it. What are the differences between Kanban and other agile methodologies like Scrum, and instruments like the Gantt chart? What is the Kanban methodology used for?
Let’s take a look at the origins of Kanban, answer these questions, and see how it’s used in practice.
The Main Principles of the Kanban Methodology
The term Kanban comes from Japan thanks to the Toyota production system, which is well-known in narrow circles. It would be great if everyone knew about the Kanban methodology and its basic principles: lean manufacturing, continuous development, customer orientation, etc. All the principles are described in Taiichi Ohno’s book, Toyota Production System: Beyond Large-Scale Production.
The term Kanban has a verbatim translation. “Kan” means visible or visual and “ban” means a card or board. Cards of the Kanban methodology are used throughout the Toyota plants to keep inventory management lean — no cluttered warehouses, and workshops with sufficient access to parts.
Imagine that your workshop installs Toyota Corolla doors and there is a pack of 10 doors near your workspace to be installed, one after another, onto new cars. When there are only five doors in the pack, you know that it is time to order new doors. Therefore you take a Kanban card, write an order for another 10 doors on it, and bring the card to the workshop that manufactures doors. You are sure that new doors will be manufactured by the time you have used the remaining five doors.
That’s the way it works in Toyota workshops: when you are installing the last door, another pack of 10 doors arrives. You constantly order new doors only when you need them.
Now imagine that this Kanban system works all over the plant. There are no warehouses with spares laying around for weeks or months. All the employees work upon requests and manufacture the only the necessary amount of spares. If there are more or fewer orders, the system will match the changes.
The main idea of Kanban methodology cards is to scale down the amount of work in progress. For example, due to the Kanban methodology, only 10 cards for doors may be given for a whole manufacturing line. It means that only 10 ready-made doors will be on the line at any time during the production loop. Deciding when those doors are ordered is a task for those who install them. Always limited to 10 doors, only the installers know the upcoming needs of the workshop and can place orders with the door manufacturer.
This methodology of lean manufacturing was first introduced at Toyota, but many companies all over the world have adopted it. But these examples refer to manufacturing, not to software engineering.
How Does the Kanban Methodology Work for Software Development?
Let’s start by looking at the differences in project planning between Kanban and other agile methodologies.
The difference between the Kanban methodology and SCRUM is that:
- There are no time boxes in Kanban for anything (either for tasks, or sprints)
- The tasks in the Kanban methodology are larger, and there are less of them
- The period assessments in Kanban are optional, or there are none of them at all
- There is no “speed of team” in Kanban — only average time for a full implementation is counted
Now look at this list and think: what will remain of the agile methodology, if we remove sprints, increase dimensions and stop counting the speed of the team’s work? Nothing?
How is it even possible to talk about any supervision over development if all the major tools of control are removed? This is, probably, the most important question for me in the Kanban methodology.
Managers always think about control and try to attain it, though they don’t really have it. A manager’s supervision over the development process is a fiction. If a team doesn’t want to work, it will fail a project despite any level of control.
If a team has fun while working and works with total efficiency, then there is no need for control, because it just disturbs the process and increases costs.
For example, a common problem with the SCRUM methodology are higher costs due to discussions, meetings and big losses of time at the joints of the sprints, when at least one day is wasted to complete a sprint and one more day to start another. If a sprint is two weeks, then two days out of two weeks is 20%, which is a heck of a lot. So while using SCRUM methodology, just about 30-40% of the time is wasted on supporting the process itself including daily rallies, sprint retrospectives and so on.
The Kanban development methodology differs from SCRUM with its focus on tasks. The main objective of a team in SCRUM is the successful completion of a sprint. In the Kanban methodology, tasks take first place. There aren’t any sprints and a team works on a task from beginning to end. The deployment is made when it is ready based on the presentation of work done. A team that follows the Kanban methodology should not estimate time to fulfill a task, since there is no sense in it and these estimates are almost always incorrect.
Why should a manager need a time estimate, if he or she believes in the team? The objective of a manager who uses the Kanban methodology is to create a prioritized task pool, and the team’s objective is to fulfill as many items from this pool as possible. That’s it. There is no need for any control measures. All the manager needs to do is add items to the pool or to change their priority. This is the way a Kanban manager runs a project.
The team works from a Kanban board. It may look like this:
Columns from left to right on the Kanban board:
- Goals: This is an optional, but useful, column on the Kanban board. High-level goals of a project may be placed here so everyone on the team knows about and can be regularly reminded of them. Example goals could be “To increase work speed by 20%” or “To add support for Windows 7”.
- Story Queue: This column deals with the tasks ready to be started. The highest card (which has the most priority) is taken first and its card is moved to the next column.
- Elaboration & Acceptance: This column and all the others before the “Done” column may vary, based on the workflow of individual teams. Tasks that are under discussion — an uncertain design or code approach that needs to be finalized, for example — may be placed here. When the discussion is finished, it is moved to the next column.
- Development: The task lives here until the development of the feature is completed. When the task is complete, it is moved to the next column. If the architecture is incorrect or uncertain, it may be moved back to the previous column.
- Test: The task is in this Kanban column while it is being tested. If there are any issues, it is returned to “Development.” If there are none, then it is moved to the next column.
- Deployment: Each project has its own deployment. This could mean putting a new version on the server or just committing code to the repository.
- Done: The card appears in this section of the Kanban board when the item is completely finished and doesn’t need to be worried about anymore.
Top-priority tasks may appear in any column. Planned or not, they are to be performed immediately. A special column may even be created on the Kanban board for these items. In our example picture, it is marked as “Expedite”. One top-priority task may be placed in “Expedite” for the team to start and finish as soon as possible — but only one such task can exist on the Kanban board! If another is created, it should be added to the “Story Queue” until the existing top-priority task is dealt with.
Let’s talk about one of the most important elements of the board. Do you see the numbers under each column on the example board? This is the number of tasks that can be placed simultaneously in each column. The figures are chosen experimentally, but they are usually based on the number of developers in the team — the team’s capacity for work.
If there are eight programmers on the team, you might give the “Development” column a 4. The programmers can only work on four in-development tasks at a time and will have many reasons to communicate and share experiences. If you put a 2 there, they may begin to feel bored and waste too much time with discussions. If you give it an 8, then each programmer will work on his task, but some items will stay on the board too long, while the main aim of the Kanban methodology is to shorten the time from the beginning of a task until its end.
No one can give you an accurate answer on task limits — each team is different. A good place to start is dividing the number of developers in two, and adapting the figures from experience.
By “developers” I not only mean programmers, but other specialists too. QA specialists, for example, are developers for the column “QA,” since testing is their responsibility.
How Teams Benefit from Kanban
What benefits will a team derive from a Kanban methodology with these limitations?
First, decreasing the number of the tasks performed simultaneously will reduce the time it takes to complete each one. There is no need to switch contexts between tasks and keep track of different entities since only necessary actions are taken. There is no need to do sprint planning and 5% workshops because the planning has already been done in the “Story Queue” column. In-depth development of a task starts only when the task is started.
Second, showstoppers are seen immediately. When the QA specialists, for example, can’t handle testing, then they will fill their column and the programmers who are ready with new tasks won’t be able to move them to the “Test” column. What shall be done then? In such a situation it is high time to recall that you are a team and solve the problem. The programmers may help to accomplish one of the testing tasks, and only afterward move a new item to the next column. It will help to carry out both items faster.
Third, the time to complete an average task may be calculated. We can log the dates when a card was added to “Story Queue,” when it was started, and when it was completed. We can calculate average waiting time and average time to completion through these three points. A manager or a product owner may calculate anything he or she wants using this figures.
The Kanban methodology may be described with only three basic rules:
- Visualize production:
- Divide your work into tasks. Write each of them on a card and put the cards on a wall or board.
- Use the columns mentioned to show the position of the task under fulfillment.
- Limit WIP (work in progress or work done simultaneously) at every stage of production.
- Measure cycle time (average accomplishment time) and improve the process constantly to shorten this time.
There are only three basic rules in the Kanban methodology!
There are nine basic rules in the SCRUM methodology, 13 in the XP methodology, and more than 120 in the classic RUP methodology. Feel the difference.