Kanban is a scheduling system for lean and just-in-time manufacturing [1], developed to improve manufacturing engineering.
It can be used to define the flow of value through a system and is being widely adopted by the software industry. Its simplicity and easy application to software work are contributing factors of its widespread use.
The flow is represented using Kanban boards. The simplest boards model the flow by using only columns, more complex ones combine columns and lanes.
Walk into the working space of many agile software teams and you’ll see a myriad of Kanban boards, physical and digital. You’ll see boards with 3 columns, with 6, 10 and so on. You’ll see boards containing a multitude of coloured post-its, with different shapes and sizes.
Visualising the work in progress should help teams managing their work, and many teams claim just that.
But do all teams get all the benefits of Kanban? Have a look at your Kanban. Are there work items (post-its if you use physical Kanaban, JIRA tickets it you use JIRA, etc) that seem to stay on the board forever, to a point that no-one really knows what they are? In your stand-up, are you talking about work items that are not on the board? When you talk about items on the board, does the board reflect the correct status they are in? If you say that something has been developed, does the board say that? Do you ever have a feeling that looking at board there so many items on it that it hurts your eyes? Are post-its stashed on top of each- other, so that you need to lift them to see the items underneath? Do you ever look at an item and think ‘what does this means’?
If you experience any of the above issues, read on. I’ve captured some practical tips that helped me solve these problems in the past, allowing me to get more out of my Kanban.
1. Combine digital with physical boards
Physical board or digital one? I prefer to use both. Physical boards are easier to huddle around, you can move items easily. They provide a focal point for the team, a town-hall for the team if you wish. It feels real. The items on the board are backed by a digital version and the two are kept in synch. If a physical board cannot be used for whatever reason, then I prefer to use a TV screen (as big as I can get my hands on, on a tall stand if possible).
Why two types of boards? Because there are multiple modes of work in a team, and each board is better suited for these modes.
There is the ‘face-to-face discussions mode’, in ceremonies such as stand-ups, or planning sessions. These discussions are usually held in a meeting room, an open space, around a wall or a whiteboard. In these sessions I want to use the physical cards as a pointer for discussions. I want to capture some notes, move things around quickly, throw away what’s not needed. I don’t want to deal with technology, I want to interact effectively and it’s much easier with physical artefacts.
For instance, during a planning session it is much easier to write some notes on a card whilst keeping the discussion fluent. Even more, some techniques such as Story Mapping are almost impossible to achieve without physical cards. Cards are then easily moved on the Kanban board when this gets replenished.
During any discussion using the physical card, if we discover anything new about it then we’ll capture the details in the digital repository.
Then, there is the ‘I work on a card’ mode, a mode where I work at my desk, where as a business analyst, developer or tester I need to execute my tasks to complete the work. In this mode, it’s me and the card. I want to have a repository to help me remember as many details possible, to capture a question that I want clarified later on.
The digital board tracks the history of the item and gathers the invaluable data for workflow measurement. The physical allows me to collaborate and visualise easier.
What about keeping the two boards in synch? I never found this to be a real problem. Teams that define and limit their work in progress will work at any given time on a small number of items. Keeping them in synch is very easy in this situation.
2. Care about your board. OCD is good (in this context)
Take care of your board. Your board is a representation of your work. Treat it like that. If you are using a physical board make sure that the lines are straight. Same for the cards; make sure that they are sitting straight on the board.
Use conventions that everyone can understand and don’t deviate from them. If a story is an orange post-it, make sure that all stories are orange. People tend to forget conventions — give them little hints by writing the type of the ticket on a post-it of the chosen colour. Place the hint cards so that they are visible to everyone.
Write clearly so that everyone can read your writing with ease. There is nothing worse that trying to decipher someone’s writing. If your handwriting is not neat, ask a team-member whose writing is to write the cards.
Don’t put the entire story on the card. Add a good summary that gives you enough to understand what the story is. Your card will likely stay on the board for days, you want something on it that allows you to remember it easily. Instead of ‘As a premium user I want to play any song in the album’s original order so that I can follow the musical journey the artist designed’ write ‘Play songs in album order’. Leave the detail to the digital repository.
When you glance at the board you want to spend two seconds reading and understanding what the story is.
Don’t overlap cards. If you end up overlapping cards, then you either have a work in progress problem (too much work), your board is too small, or your team is too big. Identify the root cause and fix it.
Avoid overlapping cards
If you can not clearly see and read the card then it’s not worth putting it on the board. Remember, it meant to help your work easier, not harder.
3. Define WIP
Define ‘Work in Progress’ (WIP). While this is a simple concept on surface, I have seen many teams ignoring it, maybe because not enough importance is given to it.
Let’s look at it. What does it mean to define ’Work in Progress’? It means separating items currently on your work horizon that you are planning to work on in the near future, from the ones that you might work on one day. Delimiting ‘Work in Progress’ is defining the boundaries of your work.
Also, I think that the word ‘work’ used in this context is confusing. This might imply that some-one has to actively work on all the items which are in WIP, but that is far from it. It just means that those items are under your radar. There is a distinction between selected items to be worked on, from those non-working items that sit idle outside your WIP. The selected items are your immediate target, whereas the ones outside might never get done.
Teams should not work on any item that is not part of WIP. If you are working on something that is not in WIP it means that you haven’t defined well your boundaries of work.
Treat items outside WIP as a collection of ideas that one day you might be working on, but not just yet.
This concept applies as well if you are ‘chaining’ multiple Kanban systems together. Each Kanban system has its own WIP, with the output of one acting as an input for the next one.
4. Establish ceremonies (replenish, take-off)
How do items get on the board, how do you remove them? How do you control your WIP?
WIP increases when items are added to Kanban and decreases when items are completed and taken off. Execute these actions of adding and removing items at regular cadences by building ceremonies into your process.
A replenishment ceremony can have two main purposes: to select items from the ‘backlog’ to bring them into the system, and to eject the completed ones.
Look at the ‘backlog’ as a pool of ideas that you would like to work on. At the point of replenishment these items can, and I’d argue should be very ‘green’, not very elaborated. The elaboration phase should happen while the items are on your Kanban. Remember from the previous section, you should not be working on items which are not on your WIP. Elaboration is a type of work. For instance, elaborating stories and capturing ‘acceptance criteria’ should happen after after the replenishment and not before.
Since you are choosing items to bring into your WIP at replenishment time, it means that you are deferring the commitment decision on what to work on to the latest responsible moment, just before you are starting the work. You are using a form of just in time commitment.
How often should you have replenishment? Try to establish a routine by having it regularly and quite frequently. What I’ve seen working well is having a weekly replenishment. You can play with the time intervals between the sessions, but I’d caution to leave too much time between replenishments because this could drive you to take a larger amount of items in one go. This means that the session itself will be longer, your WIP is inevitably bigger, with all the negative side-effects it brings.
A frequent replenishment, coupled with just in time commitment can be very powerful concepts in your arsenal. They are your process enablers to reduce the waste on working on items that are not needed anymore, to take advantage of quick feedback loops from your users. They help you change direction quicker.
The start of the replenishment session could be used to take off the board those items that got completed since the last session. Use this time to reflect on what has been achieved. When you take the items off, count them as well (more about this in the next section). Don’t rush this part of the session. Allow the team to reflect on what has been accomplished from a quality and quantity point of view. Pick a few relevant items and talk about them, see what went well and why, or what didn’t go too well. What were the contributing factors? What was a complete waste of time? What item sparked the team’s interest and led to interesting ideas?
How many items should you bring into the system? Dan Vacanti in his ‘Actionable Agile Metrics for Predictability’ book [2] talks about preservation of flow, which can be achieved by matching the number of items that we bring in (arrival rate) with the number of items we take off (departure rate).
5. Measure
As the Kanban system contains one or multiple items, these items enter the system and depart once they are done. The elapsed time it takes an item to traverse the system can be measured and it is called ‘Cycle Time’. The number of items that leave the system can be counted as well and represent the ‘Throughput’ of the system.
What gets measured? All the items that are ‘Work in Progress’. One of the reasons to delimit WIP is to make it very explicit what gets measured.
Why measure? The metrics that you can collect can be used as indicators of the health of the system, enablers for predictability and team motivator factors.
On the motivator factor, an analogy I often use is of an athlete that prepares for months in advance of a big competition. The athlete can track their work (duration of training, pace, heart rate, etc.) and use those metrics to their advantage. Can the athlete compete their training and the competition without collecting metrics? By all means, yes. However, there is an interesting point on the benefits of tracking metrics as outlined in a NYMag article [3] — progress, on a neurochemical level, primes us to persist*. If tracking and observing progress in training is a motivator factor for athletes, then why not apply this in knowledge work as well?
Cycle Time
Cycle Time is measured as the elapsed time between the time item arrived in the system and it departed. I re-iterate here the point that in order to know exactly when it enters and when it departs, we need to delimit our ‘Work in Progress’.
Throughput
Throughput is the number of items that depart the system in a given time period. The selected time period can be anything, from weekly, fortnightly, monthly. Same as for ‘Cycle Time’, knowing what represents ‘Work in Progress’ is essential, otherwise you don’t know when an item departs.
6. Process metrics
With metrics collected, what’s next? Visualise, analyse, act, so that you have info on the health of the system and use data to build a more predictable system.
Visualise
Having collected ‘Cycle Time’ and ‘Throughput’, then visualise it. Show the team how they are doing. Turn the data-points into graphs — build scatterplots by using the ‘x axis’ for time and the ‘y axis’ to plot either throughput or cycle- time. There are multiple ways to achieve this — ask the team to draw a graph manually or use software tools for this. A simple excel sheet usually does the trick. If you don’t want to start from scratch, you can use ‘Focus Objective open- sourced spreadsheets’ [4]. Some Agile tools offer reports that generate these graphs as well.
Metrics — using Focus Objective spreadsheet [4]
Regardless of how the results have been visualised, what is important is to display them in team’s work area, and to use them. Remember, the point of visualisation is to let the team know how they are doing and use it as a motivator factor. If they don’t see it you loose significant benefits.
How often should you refresh the graphs? Tie the refresh process to your team ceremonies (replenishments or retrospective for instance), which hopefully are happening at a regular cadence, maybe every 1–2 weeks.
One note on the graphs — trends are much more important than absolute values. Don’t beat up the team, if, on some weeks the throughput has dropped. Instead focus much more on the trend.
Throughput trends — using Focus Objective spreadsheet
Analyse
Spend some time analysing the data. What does it tell you? Are trends leading in wrong directions (increase in Cycle Time, lower Throughout)? Think what could be the root cause for it.
Try to use the data to understand the correlation between actions and impact of those actions. Remember though, that impact is not instant. You might have introduced a change in the process or team (for instance you’ve increased the testing capacity of the team) but the results will show up on your data only after few days or weeks.
Act
Turn the analysis into actionable activities. Is the data showing that the WIP is ever increasing? Try bringing fewer items into the system by lowering the number of items that get replenished. Is the data showing an ever increasing Cycle Time? If you can increase the Throughput of the team do it, otherwise try lowering the WIP.
7. Rigour
A final closing point. None of the above will work if you don’t apply rigour. Simply put, say what you do, and make sure that you’re doing what you say and stick to it. If something is not working, the change it, but first talk about what and why you are going to change. Don’t introduce change silently.
Some days is harder to keep on top of things, but if you persist you’ll soon reap great benefits.
Good luck!
*This is something that I have personally experienced. In 2015 I have embarked on a daunting physical challenge, to go from relatively inactive person to ride across Britain in 9 days (960 miles). In the 9 preceding months of training I have used software to track my training and progress. Reflecting on those times I can call out the fact that signs of progress (achieving personal bests on segments, riding longer with increased power, seeing improved power curves) were one of the biggest motivator factors and made me persist. Ah, and I have completed the ride :)
References
[1] Wikipedia
[2] Dan Vacanti, ‘Actionable Agile Metrics for Predictability: An Introduction’
[3] NYMag, ‘Big Goals Can Backfire. Olympians Show Us What to Focus on Instead.’