The Volcano – An enterprise Kanban board
After some experimentation, Tomas Rybing is back with another visualisation for teams using the Kanban method. He’s cut the top off of his Priority Pyramid and created The Volcano, which covers bigger teams and more products.
We have been using Kanban for over a year now, and things are really progressing well. I have written two previous blog posts about our visualisation work, and they have both become very popular:
- Priority Pyramid – Is a great way to prioritise your personal work, or to be used for a small team.
- The Arrow – Is the ideal way to go if you have one product backlog and one team.
Gradually as we have grown our Kanban initiative, the need emerged for a solution that could serve both multiple products and multiple teams. I thought for a long time on how to solve this, but I couldn’t really come up with a good visualisation. A colleague of mine kept saying that priority must be ”from top to bottom” if it should work (i.e. done vertically). That kept ringing in my head. One day it just hit me, why don’t you have ”swim lanes” also inside the pyramid? We cut off the top of the pyramid, and The Volcano was born!
An introduction to The Volcano
The purpose of The Volcano is the following:
- Prioritise work for multiple teams.
- Prioritise work for multiple products. In the picture above three ”swim lanes” are present for Product A, Product B and Product C.
- Indicate capacity allocation between different products.
- Indicate priority between work in different products. Individual positioning of the stickies can for example show that two stickies for Product A are more important than the most important for Product B.
- Can visualise a futurelog.
- Is an enterprise Kanban board that can cover the whole value chain.
Zooming in on the actual Volcano in the middle
The Volcano is horizontally divided into three separate priority levels:
- ”P1 – Next” – In this level work is placed that is ready for teams to take on as the ”next” thing to do. The work must be prepared and in such a state that a team can start to work on it, for example by including a clear and understandable DoD (Definition Of Done). A set of criterions should be fulfilled (like specifying a DoD) before moving work into ”next”.
- ”P2 – Soon” – In this level work is placed that shall take place ”soon”. It could be plain text with ideas on the stickies. However, for work to move on to the ”next” state, it has to be prepared as stated above.
- ”P3 – Later/Maybe” – In this level we place work that may or may not be done ”later”. As we do in the ”soon level” there is no need to specify this work in detail, it is kept here as a wish list or to not forget about it.
The Volcano is vertically divided into ”swim lanes”, one for each product it should support. The width of the ”swim lane” is used to steer capacity allocation between the products. A narrow ”swim lane” indicates low capacity allocation, while a wide one indicates high capacity allocation. In the picture above all ”swim lanes” have the same width, indicating that the three products have the same capacity allocation.
The work flows out of the Volcano (shown by the four arrows in the picture) and into the team’s respective Kanban boards. When a team has completed work and a ”swim lane” is free (capacity available), a work item is fetched from the volcano into a free ”swim lane” as an ongoing activity. It works best if the work items are of approximately the same size, we use stories (represented by ”larger” stickies). When the team starts to work with a story, they usually call for a planning meeting to break it down into tasks (represented by ”smaller” stickies) that then flows through their Kanban board.
How do you initialise the Volcano? One way can be to have a visual planning meeting.
Team’s Kanban boards
The picture above shows one of the four team Kanban boards (in this case for Team 3, but they are all similar). Lets start to look at the board to see what’s included.
Expedite (Fast Lane)
Sometimes the shit hits the fan and the team has to work with something that was not planned. To minimise discussions of the type, ”We are working with other things that are not on the board”, this urgent work also needs to be visualised. It could be, for example, preparations for a sales demo. A dedicated ”swim lane” above the others is used for this fast lane (to indicate the importance). You should be aware that putting work here will delay all other work that is ongoing, so this fast lane should be used with caution. You should have rules that limits usage of the fast lane, for example only one task at a time in the fast lane, max one per week etc.
Columns (the process steps)
The steps (columns going vertically) presented in the picture are Analysis, Design, Development, Test & Deployment. These columns shall reflect the steps you have in your process (i.e., they may not be the same as in this example picture). How do you find out what columns to use? You have to take a few stories and discuss the way they take you through your process.
This example shows three ”swim lanes” per team (lanes going horizontally). The ”swim lanes” are used to limit WIP (work in process). How many ”swim lanes” should you have for a team? It depends on the size of the team and how much flow efficiency you want to have.
One ”swim lane” will give you the highest flow efficiency, then the whole team will be working on one story at the time. You can also call this mob programming when the whole team is only doing one thing at the one time. This may or may not be practical in reality, as team members will be idle. On the other hand, if you have the same amount of ”swim lanes” as you have members of your team, you will end up with a group of individuals working with their own thing, with little or no interest in functioning as a team!
One word of advice is to have fewer ”swim lanes” than you have team members to encourage collaboration. We have started with two persons per story and the team holds six team members, i.e., three ”swim lanes” (the same number that this example 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 a story take up a ”swim lane” if it isn’t ready for it. If 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.
DoD (column criterions)
Each column/step in the process has a written Definition of Done (DoD) 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.”
- ”Have you written automated test cases?”
- ”Hmm, well no…”
- ”Please write the test case before we can move this task further.”
Classes of service (shown beside the Volcano in the first example picture)
By categorising the work into classes of service, the Kanban board will radiate 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)
Policies can be created: For example, X% of the work has to be in 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.
How to operate The Volcano
These are the steps needed for working with The Volcano:
- A regular meeting (we do it weekly) with all relevant stakeholders present to discuss the content of the volcano and decide what activities to move into the ”P1 – Next” section.
- When a team complete a story (capacity is available) they ”check out” a new from P1 and move it to the empty ”swim lane” as an ”ongoing” activity. It will be an empty spot in P1, but that does’t matter, as long as the meeting in 1) is held regular enough, not to let the whole P1 section become empty.
- The ”swim lane” of the product in the volcano is completely owned by the product owner. The product owner can at any time add or change the priority of the activities. But only in his or her ”swim lane”. Coordination, priority between activities for different products, takes place on the regular meeting in 1).
The volcano clearly states the difference between the ”what” and the ”how”. The stakeholders (management) decides on what shall be done, the teams decide how it should happen.
In-depth details of The Volcano
It’s said that a picture says more than thousand words. So instead of more written text, I have prepared a presentation on how work flows using The Volcano. You can find it below:
This version of The Volcano is put up on three whiteboards (1.4 x 1.6 meters). The volcano part in the middle serves four team Kanban boards, one to the left, two on the right, and one on the other side of the room (see the arrows coming out of the top of the Volcano). The team on the left is actually using a mirrored Kanban board to fully visualise the flow of the work out from the Volcano and in and through their Kanban board!
Here are some learnings after using The Volcano for some time:
- We are using The Volcano in combination with a visual plan. The visual plan covers one of our products (we have three different products). The visual plan is discussed regularly and then we ”feed in” work to the Volcano. For another product we have a more formal process with a product owner that fills up that ”swim lane” with work items.
- The Volcano works best if the work items are approximately the same size (we have a rule of ≈10 working days, corresponding to a story). This makes prioritisation easier. You could in theory have features alongside bugs in the Volcano, but then the short term work will probably always be favoured.
- We update The Volcano at least once a week during a weekly planning and priority meeting. It’s very important to find a person that can host this meeting and lead a fruitful priority discussion. It should be someone with mandate and insight on all products. We don’t quite have this in place yet, so we are still struggling with this.
I hope you now have an better understanding of what The Volcano is and how it’s operated. If you have any feedback or comments, please feel free to contact me. One last thing, maybe you wonder why it’s called The Volcano? It’s because it’s a Priority Pyramid with the top cut off that ”shoots out” work to the teams, just like a volcano :)
Blog post update:
Here are some comments from the agile community about The Volcano:
This blog post originally appeared on The Agileist, Tomas Rybing’s blog about Lean, Agile and Management.