Kanban Concepts & Guidance

Kanban for software development and ITSM is now a popular approach to delivering software and services. Explore this guide for techniques, tips, and best practice when getting the most from Kanban and Agile practices.


GENERAL GUIDANCE



  • 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 and improve team dynamics
  • Always visualise 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.
  • Write the card number from the electronic system in the top right hand side of the physical card.


  • INPUT COLUMN



  • 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.
  • 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.


  • 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 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 STAND UP 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



    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.


  • REAL TIME 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
  • End to end supply chain visibility


  • DEMAND MANAGEMENT: BAU VS STRATEGIC



  • Use classes of service 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!