The Arrow – An advanced Kanban board
After his success with the Priority Pyramid, Tomas Rybing is back with another great way to organise your workflow via the Kanban methodology.
Ever since we started to use Kanban I have been thinking about how the “perfect” Kanban board would look like. I have searched for answers in the Kanban literature, but usually the boards shown there are simple examples to get you started, rather than ”evolved” or “advanced” variants.
Shortly after I had the idea of the priority pyramid, I discussed it with others in the Agile community. One of them gave the following advice, “Why don’t you rotate the pyramid 90 degrees and connect it to a Kanban board?” This is what I came up with.
This is the type of advanced or “ultimate” Kanban board to aim for. At least for now, our Kaizen efforts will for sure evolve it in the future. The picture holds quite a lot of information, so let me walk you through the arrow from left to right. Let’s get started!
The priority pyramid has been rotated 90 degrees and the former “top” of it is now replaced with a number of “swim lanes” (going horizontally). The function of the priority pyramid is to visualise and help out with the prioritisation of the backlog.
This example version of the arrow holds three swim lanes. The swim lanes are used to limit WIP (work in process). How may swim lanes shall you have? It depends on the size of the team and how much flow efficiency you want to have.
One swim lane will give the highest flow efficiency, then the team will be working on one story at the time. This may not be practical in reality – various team members will be idle at different times. One word of advice is to have fewer swim lanes than you have team members to encourage collaboration. We have started with two people per story and the team holds six team members, i.e., three swim lanes (the same number that this example version of the arrow shows).
To limit the number of swim lanes hopefully also gives a mindset of using the capacity of the process with caution. Don’t let stories “fill” a swim lane if they’re not ready for it. If, for example, the needed information is not present to perform the analysis, the story will not “move forward” in the flow and a swim lane will be “blocked”. We are “wasting” capacity.
Columns (the process steps)
The steps (columns going vertically) presented in the picture are Analysis, Design, Development, Test and Deployment. These columns shall reflect the steps you have in your process (i.e., they may not be the same as in the picture). How do you find out what columns to use? You have to take a few stories and discuss the way they flow through your process (a requirement comes in, a team member is assigned to perform a short analysis, etc).
Each column/step in the process has a written DoD (Definition of Done) with the criterions that need to be fulfilled before a task can move into the column. See it as a check list: this and that needs to be done before moving the task. Using this approach will prevent tasks from moving further down in the process without being ready for it. An example:
- “Have you tested this?”
- “Yes, yes.”
- “Do you have written test cases?”
- “Hmm, well no…”
- “Please write the test case before we can move this task further.”
The point of the arrow
Normally, the stickies are removed from the “Done” column when it gets crowded (the same thing goes for Scrum, where the board is “cleaned” before each sprint starts). But why don’t we make the point of the arrow into a larger area that can hold more stickies, so that we can see our achievements over a longer time period! Then you can count the number of stickies in the “Done” column and connect them to certain events.
For example “when we have reached 50 stickies in Done we celebrate with a cake” (cake limit). For every twenty stickies in the Done column (20, 40, 60, etc.) perform a retrospective, and so on.
In front of the arrow a print out of the overall goals for the team are present. The goals shall be written in a way so that they can be a guide in our daily work. “Shall we solve this problem in this way or that way? This way will not lead us closer towards our overall goals, we have to do it that way”.
Classes of service
By categorising the work into classes of service, the Kanban board will radiate with even more information. In this example three classes of service are used:
- Green – System improvements (technical or maintenance driven)
- Yellow – Features (customer or roadmap driven)
- Pink – Bugs (errors in existing functionality, found internally or by customers)
Now policies can be created – for example, that X% of the work has to be system improvements. Other things can also be spotted, if the pink stickies (bugs) are dominating we may have a problem with quality, and so on.
Expedite (Fast line)
Sometimes the shit hits the fan and you have to work with something that wasn’t planned. To minimise discussions like “I’m working with other things not on the board”, urgent work needs to also be visualised – it could, for example, be preparations for a sales demo.
A dedicated swim lane above the others (to indicate its importance) is used for this fast lane. You should be aware that putting work here will delay all the other work that is ongoing, so this fast lane should be used with caution. You should have rules that puts limit on the usage of the fast lane, such as only one task present at a time in the fast lane, max one piece of work per week, etc.
Here are some learnings after using the arrow for some time:
- We didn’t put any rules on the fast line, and no surprise, much of the work ended up here when we started. Uncertainty was shown whether work was ”important enough” to take up an ordinary swim lane, therefore it ended up in the fast lane since it had no other place to go. By setting rules on the fast lane, and having criterions how to use the ordinary swim lanes, this can be avoided
- Since the swim lanes now make it more restricted when new work can be started (i.e., only when a swim lane becomes available), team members became more blocked. We have started to experiment with a “slow lane” for lower prioritised work that can easily be picked up (and left) when a team member is temporarily blocked on their main task
- As a separate section at the point of the arrow, we have a section “ready to demo” where tasks end up that we show in a weekly demo session. If no tasks are present here, the demo is cancelled for that week
Since we’ve been using priority pyramids for quite some time it was a natural step to evolve into the arrow: a visualisation of the backlog, combined with the Kanban board that visualised the work process. One problem can be physical space – we are using two whiteboards to hold the arrow for one team.
I’ve prepared a presentation to show in more detail how I think the arrow can be used.
Here are some comments from the Agile community about the arrow:
Let me know what you think in the comments below.
This blog post originally appeared on The Agileist, Tomas Rybing’s blog about Lean, Agile and Management.