Visualize the workflow.
The magic of Kanban is the focus on the board. The Kanban agile methodology was inspired by the Toyota Production System. There, a kanban (Japanese for “sign board”) was a ticket that traveled with each component as it made its way through the assembly line. These boards ensured limits to how many items could be on the assembly line and ensured each item completed all of the required steps.
To use Kanban, you need to have a model for your workflow. Kanban works best if you have an environment where there is a never-ending stream of new feature requests, enhancements, and bug reports. Also, it works well for applications that can be updated in production on demand. This profile fits many agile teams well, especially web-based applications.
On the other hand, if you are delivering packaged software, where the quality of the delivered, final media is more important than the time frames, then other, more formal methods may be more appropriate.
To visualize your workflow, you need a large board that is visible to everyone in the development team. Divide the board into columns, with each column representing a state in the workflow. Order the columns left to right in the order of the steps of the development process. For example, you might have steps like “backlog”, “analysis”, “development”, “testing”, and “in production”. If you have a distributed team, this can be problematic, as this works best with a board that everyone can see throughout the day. The most popular substitute is to use an electronic board, so that teams in each city can view the same board.
Every feature, enhancement, bug report, story, or task should be represented on the board with a ticket. This may be a 3×5 card with magnets, or it may be a post-it note, or cards posted on a corkboard with push pins. Each ticket should have a ticket number to tie to your online ticketing system, which brings together various other data elements like pull requests, comments, and approvals. The ticket on the board should have a short name on it so that anyone glancing at the board knows what that ticket represents.
From here, people vary their tickets a lot. Some use different colors to represent the issue type, or the component, or the development team, or the priority. It doesn’t matter; you should use whatever works best for your particular team.
As the ticket proceeds through the workflow, it should be physically moved across the board to the column representing its current state.
More complex boards add swimlanes, which are horizontal rows across the board. Typically a swimlane represents a logical grouping of tickets. You might opt to have separate swimlanes for UI, backend, and API stories. Or maybe the swimlanes represent the Javascript, PHP, and Java teams. Sometimes there is an expedite lane, and this is typically placed at the top of the board. Again, adjust your swimlanes to represent a grouping that works well for your team.
If an issue has a blocker, it is best to note this on the board with an indicator of some sort. Maybe it’s a red card or post-it that is placed over the blocked card. On magnetic whiteboards, you might circle the blocked card. The idea here is to see at a glance which tickets are blocked.
Another handy feature of the board is that when there are clogs in the process, it becomes immediately apparent. For example, if there are two tickets in each state but 15 tickets in the testing status, then this makes it obvious to everyone that you should stop adding new tickets in development and put more people to the task of testing, to clear the clog, and restore the flow.
Kanban is all about optimizing the flow of tickets to production, and the board is the go-to tool to help with this.
Today's Card 