Someone will probably lambast me for this article but that’s okay. Kanban isn’t necessarily an SDLC but it can be used as such. Kanban started out as a production method on Toyota plant floors. The term Kanban is Japanese in origin. Kan means visual and ban means card or board so combined Kanban means visual board. Kanban is considered an Agile methodology and can be combined with other methods.
Kanban in lean manufacturing
Kanban started out as a method to make automobile production smoother. Toyota used it to refine their just in time inventory system. The cards they used with their Kanban system helped them see where in the process they had bottlenecks.
Kanban boards have columns and each column relates to a certain step in a process. In car manufacturing I can’t imagine what the columns are but there may be an engine column, a front door column, a back door column, a trunk lid column and etc…
As a certain amount of product is used up a card is put on the board in a column to indicate that item is needed. The first available person from that area pulls the card off the board and builds that item. Each column can only have so many items in it. This prevents too many or too few items being built. You can see bottlenecks on the board as there will be a buildup of cards in a certain column.
Kanban in software development
To use Kanban in software development, you need to create a visual board. The board should have columns on it for each step in your process. Some common columns might be User Stories, Elaboration & Acceptance, Development, Test, Deployment and Complete.
User Stories start on the left side of the board and work their way to the right. Each column has a limit on how many items can be in the column. The limit is generally written at the bottom of the column. The size limit of the column depends on how many members are on the development team.
Priority for each column is from top to bottom. The story with the highest priority is at the top of the column. When a person from the next column has availability they will pull their next story from there. The exception for this is if you decide to use a complete but waiting next step spot. This is typically at the bottom of the column. Imagine this as a holding area while waiting for the next step.
Determining column limits
The common formula for determining total story spots on the board is the size of the development team divided by two. For Agile software development the team generally consists not only of developers but also business analysts, testers, deployment people and possibly UI designers. If there are 24 people total on your team, the Kanban board should have around 12 stories on it at any given time.
The User Stories column should have its limit set to half of your total limit. In our example above this column would be set to 6.
The limit for the Elaboration column should be set in conjunction with how many business analysts and/or UI designers you have. They will take a user story from its rough state to ready for development while it’s in this column. This column is one that may well have a complete but waiting for next step spot. A good number for this column in our above example is 2 or 3.
The development column should never have more spots than you have developers. It’s very common to limit this column to half the number of developers you have and force your developers to team up on user stories. This column will probably have a complete waiting for next step spot.
The test column should total the number of testers you have plus one. This is another column where you will probably have a complete waiting for next step spot. A good number for this column in our above example is 2 or 3.
The deployment column can be handled however you like. It will depend on your deployment process.
The complete column can have as many stories in it as you want. These are stories that are fully finished and deployed.
The goal here is to get the numbers in the columns correct so there isn’t anyone sitting idle but also so there are no bottlenecks. Since everyone on the team is devoted to getting the software complete, if there are bottlenecks its fine if someone else on the team pitches in and helps. Identifying bottlenecks will help refine the process.
It’s common in this process to have an expedite track either at the top or bottom of the board for things that can’t wait to go through the normal process. This expedite track will have all the same things as the other tracks but should always be limited to one item at a time.
Performance in Kanban is measured in Cycle Time
A cycle is the amount of time it takes for a story to get through all steps in the process. When a story enters the process the start date is noted. When it’s deployed the deploy date is noted. By doing this consistently you can determine an average cycle time. The average cycle time is typically put on the board in the first column. This lets people know how long it usually takes for an item to get from this position to the end of the cycle.
Other pieces of the process
It’s typical to have a daily stand up meeting in Kanban just like in other Agile processes. This daily stand up is typically held in front of the Kanban board.
It’s also typical to reflect on the process every few weeks. You can and should refine the process as time goes by. The goal is to optimize the process.
It’s typical to demonstrate progress on a periodic basis. Having a demonstration of the software every couple weeks will help keep everyone on track and keep the teams spirits up. Providing good quality software that is just what the customer wanted is very satisfying for the entire team.
Kanban can add structure around disorganized development teams. Having the columns with limits will help identify bottlenecks and help refine the process. Since the goal is to produce good quality software, this process can be combined with any other development process that makes sense. Kanban can be combined with Scrum. This combined process is typically called Scrumban and Corey Ladas has written an entire article on this topic.