Back to blog home

The Kanban can-can

The Can-Can is a high-energy and physically demanding music hall dance, traditionally performed by a chorus line of female dancers. The spectacle is at its best when the troupe appear to perform as one harmonious unit, much like an established Kanban team.

Tenuous links aside, I’ve had the pleasure of seeing several teams and their associated customers benefit from a Kanban approach to maintenance work (aka business as usual, or 'BAU' for short), so I’d like to share with you some of the processes we’ve come up with to help keep the work flowing smoothly – and how we’ve implemented these ideas in Jira.

But first, a quick reminder of the five core properties for successful Kanban delivery as espoused by David Anderson:

  • Visualise workflow
  • Limit work-in-progress
  • Measure and manage flow
  • Make process policies explicit
  • Use models to recognise improvement opportunities

The processes in this post are aimed primarily at the first and fourth of these.

Swimlanes

Swimlanes help draw our attention to tickets that are outside the normal flow. So far we’ve found that three additional swimlanes are enough to cover this requirement. They should all be considered impediments to the normal flow. As such they need to be addressed ahead of the rest. In increasing order of priority they are:

 
Blocked

If you can’t make progress on a ticket for whatever reason, consider it blocked and move it out of the normal flow (Jira solution: label = blocked). Make sure the rest of the team and the product owner are aware that there is a new blocked ticket.

Unless the original assignee is planning to help unblock the ticket, e.g. they need a partner to pair programme with, the ticket should be unassigned.

Moving the ticket into 'blocked' may also mean that the original assignee is blocked as well. This is a good thing, as once stakeholders are made aware, they have more motivation to resolve the blockage.

Note: if the reason the ticket is blocked is likely to be resolved in less that half an hour, don’t let the process slow things down. Leave it where it is and get the unblocking done. For example, you have a ticket in QA that just needs a minor fix to pass and the developer knows how to fix it and is available to do so. If there’s any doubt about how long it’ll take then don’t waste time worrying about it, just move it.

Expedite (blocking issues)

If a ticket is holding up the progress of another ticket moving across the board, unassign it and move it out of the normal flow (Jira solution: priority = blocker). Make sure the rest of the team and the product owner are aware that there is a new blocking ticket. In this way one or more team members can stop what they’re doing, jump onto this ticket and get things flowing again.

Silver Bullet

In the very exceptional circumstance that a ticket really can’t wait for the rhythm of the usual process, unassign it and move it out of the normal flow (Jira solution: label = silver-bullet). Marking a ticket as a 'silver bullet' in this way highlights that it is the top priority ticket on the board and that the team as a whole must make every effort to get it across the board as quickly and efficiently as possible.

By its nature, this requires ignoring any work in progress (WIP) limits set on the columns. The decision as to what constitutes a silver bullet lies with the product owner. They are normally bugs affecting the production system affecting the majority of customers and/or resulting in significant losses in revenue.

Swarming is one technique often appropriate for silver bullets. This is where multiple team members work together on the ticket rather than the usual one or two. Although it can lead to team members working in areas outside their comfort zone, the benefits achieved almost always overcome this. So much so that it can become necessary to recognise when the swarming has had its effect and the ticket can progress more effectively with less people on it.

Kanban Planning

In project work the use of scrum specification workshops (aka example workshops) and sprint planning meetings provide an excellent way for the team to work with the product owner to estimate and prioritise the backlog. There are typically lots of user stories that can be story-pointed and then broken down into subtasks and have time estimates assigned. There may also be the odd spike (aka investigation) to be time-boxed. There aren’t normally any bugs as these are usually dealt with mid-sprint.

In maintenance work the mix of types is usually the other way round, lots of defects to fix, some spikes to work on and the odd minor enhancement now and again. As mentioned above spikes are normally time-boxed, an approach which also works well for defects.

In a recent planning session with the product owner the team trialled a different approach to planning. We agreed on the following before we started:

Only estimate to the nearest day, week or month for each ticket. Jira solution: Insert 1d:, 2d:, 3d:, 4d:, 1w:, 2w:, as a prefix to the ticket title, allowing everyone to see the estimates in backlog view and differentiate them from story points and more accurate time estimates arrived at by standard processes. Add TBox to the prefix for time-boxed estimates, eg. 2d TBox: for a two-day time box.

Make it clear whether or not the estimate is a time-box. For defects (where the solution is unknown) and spikes use a time-box. For defects (where the solution is thought to be known) and enhancements use a simple time estimate.

If a ticket doesn’t have sufficient information to make an estimate then don’t make one. Mark the ticket as blocked and add a comment to explain why. Ask the product owner to help address this in time for the next planning session.

Once a ticket is prioritised by the product owner and moves from the backlog into 'To do' it should be confirmed as ready for development (full description and acceptance criteria). The estimate should be reviewed and escalated if it has increased at all.

Once any ticket is underway, and we are halfway through the estimate, we should confirm that it can still be achieved within the estimate. If it can, then proceed. If there’s any doubt, stop work immediately, calculate a revised estimate should work be allowed to proceed and escalate to the product owner for direction. Should the product owner decide that the ticket should be cancelled then all the work on it up to that point will count as waste.

Feedback after the session was all very positive, including the product owner describing the output as 'priceless'.

It’s important to note that the above estimates are for development and internal QA only. Cycle time analysis is the subject for a future post.

Only one #1

The normal flow of Kanban focuses on getting the top priority ticket across the board as efficiently as possible. With only one ticket moving across the board that’s straightforward, but as soon as there’s more than one it’s all too easy for that focus to wander.

The teams I work with chose to address this by making the product owner’s top priority ticket stand out from the rest. Jira solution: flag the ticket (and any subtasks).

Once that ticket was closed we asked the product owner for their new number one.

Identifying the highest priority issue in the workflow is a potential first step in defining the classes of services and policies for the project and offers another possible candidate for analysis of cycle times.

Food for thought 

Ways these processes have proved more effective include:

  • Process improvement comes from within the team, giving them ownership and thereby improving cohesion.
  • Progress is clearer for everyone to see (team and product owner alike).
  • It is easier for the team to see what they should be focussed on.
  • It is easier for the product owner to see how they can help the team.
  • It is easier for the product owner to prioritise the backlog.
  • The product owner feels more in control of priorities.

Kanban is all about continuous improvement, so these processes are just a snapshot ripe for new ideas to make them even better.

I’d love to hear any thoughts you have …

About the author

Adam Scott is a seasoned project manager and ecommerce professional with more than 20 years' experience in the digital industry. He has diverse sector experience within the utilities, life assurance, automotive, leisure and retail industries. Adam is a certified scrum master. You can find Adam blogging at Pi in the Sky.

Author's note: Many thanks to Stephen McNairn and Shane Auckland for their invaluable contributions to this post.