What is Kanban?
Kanban is a work management method which focuses on work visualisation to identify bottlenecks, limiting work in progress to go reduce multitasking, and focuses on end-to-end delivery. Kanban is particularly powerful when combined with practices and tools from other methodologies such as Scrum and Extreme Programming. Often, this combination is referred to as Scrumban.
Key features of Kanban include, limiting the amount of work you have in progress, visualising the work, visualising blockers, focusing on removing blockers over starting more work, using queues to smooth flow by creating a pull system, using avatars to demonstrate where the team are focused, encouraging a swarming behaviour to enable teams to quickly tackle bottlenecks and problems. Reducing batch size is a key focus in Kanban to enable teams to release smaller amounts of value but more regularly.
To start with Kanban is very simple. You visualise what you currently do in terms of process. Once an initial visualisation has been created you can then focus on continuously improving your system. We refer to the card wall as a visualisation of your delivery system. All systems need a purpose. Another principle of Kanban is that nothing has value until it is deployed to a live environment, but more importantly, that it’s being used by end users. Until it’s in the hands of the users the work only has costs associated with it. Any work that is started and not finished is classed as inventory. Kanban aims to reduce waiting time by minimising hand-offs between teams.
Core Principles of Kanban
- Start With What You Do Now
- Agree to pursue incremental, evolutionary change
- Respect the Current Process, Roles & Responsibilities
- Encourage Acts of Leadership at All Levels
Kanban General Practices
- Visualise the workflow
- Limit Work in Progress (WIP)
- Manage Flow
- Make process policies explicit
- Feedback loops
- Improve Collaboratively (using models & the scientific method)
Kanban Service Delivery Principles
- Understand and focus on your customers’ needs and expectations.
- Manage the work; let people self-organise around it.
- Regularly review the network and its policies to improve customer and business outcomes.
Operating a Kanban System
- General Guidelines
- Work Visualisation
- Commitment Point
- WIP Limits
- Avatars
- Queues
- Blockers
- Inventory
- Handling Defects in Kanban
- Backlog Visualisations & Management
- Daily Standup Guidance
- Showcases – aka Show & Tell
- Data Driven Retrospectives
- Cross Team Retrospectives
- Realtime Retrospectives
- Estimation & Sizing
- Planning & Tracking
- Dependency Management
- Demand Management: BAU vs Strategic
- Distributed Development
General Guidelines
- Pull work, don’t push
- Pull work, but only when you have capacity to service it
- Use queues to exploit bottlenecks
- Limit work in progress to increase flow
- Always visualise the end to end value creation process
- 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) but if you find yourself having to move a card backwards treat this as a signal that you probably have an underlying problem that should be addressed.
- Use an electronic system to capture metrics and details.
- The electronic system should support your card wall, not rule it.
- Write the card number from the electronic system in the top right hand side of the physical card.
Work Visualisation
Commitment Point
The input column has a strict limit of 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 Input column is also known as Next, or Select. It represents the first commitment point in a Kanban system. Stakeholders should regularly review the Input column and decide which cards from the backlog should be selected.
WIP Limits
Use limits to increase flow. Limits show the teams true capacity (constraints). A blown limit is a signal from the system that something is probably 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. Limits are not to be changed as and when you feel like it. It should be a team 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.
Avatars
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
Queues are used to stop the throwing of work over the wall and creating a bottleneck. Queues are extremely useful for improving flow as they provide you with a mechanism to pull work 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 card wall.
Blockers
Visualise blockers using a magenta post it note and stick it to the card that’s block. 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 common place and useful for identifying blockages before they even get on the delivery part of the card wall.
Inventory
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. Stop starting, start finishing!
Handling defects in Kanban
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 story to live/production. 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 there may be a valid case for logging the defect in order to drive quality improvements upstream.
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.
Daily Standup Guidance
Get each team member to take a turn facilitating the daily stand up. This stops any one person dominating the stand up. Rotate daily. Walk the wall from right to left. Focus on the work, not each other. That is, starting at your right most column on the wall and working left. For each card on the wall ask the question “how can we get this card moved to the right?” Too many teams treat the daily stand up as a status update. Instead, the daily stand up should be about problem solving.
Gather in close around the card wall. Don’t be shy. If you can’t see the detail on the cards then you’re too far away. Get in close and jostle for position if needed. Come prepared. Make sure you’ve updated the card wall before the daily stand up, not during. Look right or down before looking left. That is, when you’ve completed a card on the wall, first look right or in your current column to see if you can help anyone else finish their work. If you’ve exhausted all avenues to help finish work, only then should you look left to start more work. Focus on unblocking blocked work. Summon the necessary people required to unblock a card to the daily stand up so they can see the impact they’re having on the team. Blockers with unblock ETA. If a blocker has an ETA date for unblocking (days or weeks) in the future, do you really need to have a repeat discussion about the blocker everyday? Use green arrows to show movement. When someone in the team moves a card on the wall, stick a green arrow icon on it. As the day goes on, more and more arrows should appear on the card wall. Then, at the daily stand up you will see a nice clear summary of movement over the previous day. At the end of the daily stand up “reset” the card wall by removing all the green arrows. External stakeholders to the team particularly like this feature. Card wall admin. At the end of the daily stand up, the person who facilitated it is responsible for tidying up the wall, i.e. straighten the cards, redraw any faded lines, remove the green arrows, and sync the physical card wall with the electronic card wall. Review Goals. Whatever goals you have in place, it’s really important to keep these at the forefront of everyone’s mind.
Showcases - aka Show & Tell
Real time:
When a developer is code complete they showcase the software on their PC to Product Owner, Tester, BA. Any issues are resolved immediately. When a tester has tested a story they showcase the story to the Product Owner and BA.
Ceremonious Showcase:
Every two weeks, an event is held to showcase the entire software with special emphasis on new features developed. The audience for this showcase tends to be wider than the development team and is usually an open invitation to all.
Data Driven Retrospectives
Run retrospectives (at least) every two weeks. Present cycle time data to the team. Drill down into the data looking for patterns or outliers. Ask why, ask who, ask how, and take action! Look for ways to reduce cycle time. Look for ways to reduce variation in cycle time. Use dwell time charts to identify unnecessary waiting time. Use unblocked blockers to look for common sources of delay
Cross Team Retrospectives
Meet frequently and ‘walk the walls’. Visit each team’s card wall to look for ideas for improvement on your own wall, or spot things on other card walls that the owners might be too close to to spot themselves. Bring metrics from all teams together from time to time to discuss org wide patterns.
Realtime Retrospectives
Avoid waiting for the next retro to look for improvements. Most of this data is available real time. Scrum Masters (or equiv job titles!) should be watching queues for long waiting times and attacking them. Tech leads should be looking at code quality metrics daily. Management should be spotting patterns of recurring blockers.
Capture improvement ideas or actions on your card wall. Some teams have a dedicated space on their card wall for capturing these ideas.
Estimation & Sizing
Use sizing instead of estimation. Aim for 4 categories of T Shirt sizing – S, M, L, XL. For L and XL, always try to break down smaller. Don’t get too hung up on accuracy. The real aim of sizing is to measure how well your work is broken down into pieces of similar size. Normal distribution of work unit size
Planning & Tracking
Use a burn up chart to track progress. Track changes in scope. Use forecasting instead of planning or estimating. Update your burn up chart daily (ideally) or each Friday. Don’t forget the effects of the s curve on forecasting. For constantly changing scope, use forecasting on the scope line as well if needed. The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience. Use multiple scope lines (goals) to represent multiple milestones.
Dependency Management
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
- Consumer Driven Contracts
- Fake Objects, Stubs, Mocks
- Queue and Wait
- Identify blockers upfront with backlog visualisation
- Manage both ends of the dependency
- Use explicit policies to expedite
- Avoid self competing
- Re architect your platform
- Remove environment contention (cloud provisioning)
- Merge Hell – use feature toggles
Demand Management: BAU vs Strategic
Use demand shaping to govern the selection policies for the Input column. In the example 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.
Distributed Development
Use an electronic tool that mimics a physical card wall as closely as possible. Still use physical card walls where possible, particularly at the point where decisions are made. Many teams just visualise the backlog and the Input column on a physical card wall to facilitate conversations with stakeholders. At the end or beginning of every stand up, quickly sync the physical card wall with the electronic tool. It should only take a minute or two as you should have reduced your work in progress anyway! When conducting distributed stand ups, make sure all callers are looking at a shared desktop view of the electronic tool. Do not attempt to run stand ups using a webcam pointing at a physical card wall…it does not work. Walk the electronic wall from right to left just like a face to face stand up. Level the playing field – make sure all participants are equally handicapped by making everyone dial in. Make sure your electronic tool can visualise blockers. Always limit your WIP, even if your electronic tool doesn’t specifically support limiting WIP, you should do it anyway!
Misspellings of Kanban
There are occasions when Kanban is spelt incorrectly. Examples include can ban, Kan Ban, canban, kamban, kambam and all other combinations. The correct spelling is Kanban.
Where to start?
FREE KANBAN CHEAT SHEET
