The Kanban Method for software development is now a popular approach for software and service delivery. It is firmly rooted in concepts from the manufacturing processes of the Toyota Product System. These core concepts are explained further below and how they’re applied to development teams. Explore this guide for techniques, tips, and best practice to get the most from Kanban and related Agile practices.
THE KANBAN METHOD – KEY CONCEPTS
- Visualise the end to end value creation process.
- Limit the amount of work in progress (WIP) to increase flow and improve team dynamics.
- Pull work, don’t push.
- Pull work, but only when you have capacity to service it.
- Optimise your approach for good end to end flow.
- Use queues to exploit bottlenecks and to smooth the flow of work.
- Nothing has value until it is live, up until this point it only has cost.
- Visualise Blockers using magenta post it notes.
- Each team member has one Avatar and sticks it to the card they are working on.
- Cards shouldn’t really go backwards on the card wall (one-way system). If you find yourself having to move a card backwards treat this as a signal of an underlying problem that should be addressed.
- Use an electronic system to capture cycle time and lead time metrics.
- Kanban is an evolutionary change tool that starts with what you do now.
- The electronic system should support your physical Kanban board.
- Write the card number from the electronic system in the top right-hand side of the physical card to help with tracking.
- A Kanban board is a visual representation of your Kanban system.
The next column has a strict limit, normally of about 3 cards. It is used to drive out prioritisation from the backlog. The delivery team pull from this column; BUT only when they have capacity to deal with it. The Next column is also known as Input or Select. Stakeholders should regularly review the Next column and decide which cards from the backlog should be selected.
Use limits to increase the flow of work. Limits show the teams true capacity (constraints). A blown limit is a visual signal from the system that something is wrong in your process.
Use a physical limiter on the card wall as well as a number in the column header to show the limit. WIP Limits are not to be changed as and when you feel like it. It should be the team members decision, based on the notion that flow will be improved. If you change a limit, make sure you measure the effect of the change through your metrics.
One instance of an avatar per person – you can only be in one place at a time. Choose avatars that are a reasonable size. If they’re too big they’ll cover the details of the card they’re stuck to and make it hard to read. Laminate them!
Queues are used to stop the throwing of work over the wall and creating a bottleneck. They are extremely useful for improving the flow of work as they provide you with a mechanism to pull work items in; but only when you have the capacity to deal with it. Be careful not to have unnecessary queues as they can increase inventory across the whole Kanban system. The queues in the photo above are the Done sub-columns.
Visualise blockers using a magenta post-it note and stick it to the card that’s blocked. Write the reason for the blocker on the blocker sticker. Some teams find it useful to capture the date when the card became blocked on the blocker sticker. Focus on unblocking the blocked card. We’ve all been conditioned in our careers that when we get blocked on something, keep yourself busy and pick up the next piece of work.
In Kanban, we don’t start more work but instead focus on unblocking blocked work. Blocking a card in the backlog is commonplace and useful for identifying blockages before they even get on the delivery part of the card wall. It’s an effective method of reducing waste.
Nothing has value until it goes live. Any complete or incomplete software that hasn’t gone live has no value and therefore only has cost. We call unshipped software Inventory. The more work you have in progress the more inventory you are carrying as a team.
The more work you have in progress the more likely you are to task and context switch. Less work in progress means less context switching. Having less work in progress also enables tighter feedback loops. Kanban’s golden mantra is Stop starting, start finishing.
DEFECT TRACKING & MANAGEMENT
If defects are found during testing, think carefully about the administrative overhead of logging each defect in a defect tracking system. Ideally, when defects are discovered, the developer who worked on the code immediately stops what they’re doing and works with the tester to resolve the issues. No defects are logged. No red cards are created. Automated tests are updated.
All focus is on getting the story into an acceptable state. Ship the story to live/production as soon as it’s ready. If defects are found in live, write them on a card and put them in the backlog so they can be prioritised alongside all other demand. If defects are found in a later phase/environment than the test column, then log the defect with root cause analysis. Use these defects in order to drive quality improvements upstream and continuous improvement.
BACKLOG VISUALISATION & MANAGEMENT
Layout each source of demand horizontally in the backlog. Make all work types visible, particularly tech debt, live defects, BAU, and incidents. Constantly review and refine the backlog to ensure it always represents the top priorities for each demand type. Visualising blockers in the backlog is very useful and common place.
To minimise the potential wasted effort of writing out cards that may never make it onto the supply board, why not just show the top 5 or 10 from each source of demand. If you do this, make sure you add a ‘+18’ to indicate the overall number of cards in the demand.
A number of strategies are available for reducing the impact of dependencies on flow. Some of these are listed below.
- Planning & Scheduling
- Visualise & Manage Blockers
- Develop self-serve capability
- Systemic Swarming
- Pull Requests in GitHub
- Fake Objects, Stubs, Mocks
- Queue and Wait
- Identify blockers upfront with backlog visualisation
- Manage both ends of the dependency
- Use explicit policies to expedit
- Avoid self-competing
- Remove environment contention (cloud provisioning)
- Merge Hell – use feature toggles
DEMAND MANAGEMENT: BAU VS STRATEGIC
Use classes of service to govern the selection policies for the Input column. In the photo above, two yellow cards can be in progress at any point in time. In progress = between A+D WIP and QA Done. If stakeholders want to select another yellow to be worked on they must first get one of the existing yellows complete. Make the classes of service policy explicit by providing a key along the top of the card wall. In the above example, 1 green card, 2 yellow cards, 1 pink card, and 1 blue card.