Lean Product Development: the Volcano of Priorities

In the last months of experimentation in 20tab a new tool was born, useful for viewing and communicating the priorities of the various products on which the different teams work, often with very different speeds and needs. Because of its shape it has been called 'the volcano'.

In this short article, I’ll explain how it works.

Background

20tab began as a classic software consulting and development company, but over the years it has evolved to what we call 'Product Team As A Service'.

The goal of this working method is to provide customers with an entire product team that is agile and performing, and with a goal-oriented mindset, which can be used with the time and rate that is closest to the needs of each customer.

The problem

From this derive several complications, such as having to work on different products or different features simultaneously, maintaining a constant Sprint rhythm according to the Scrum framework, and avoiding the problem of the context switch. Someone says it can't be done.

On the other hand, collaboration on different products always has a different duration and speed: for some it is necessary to commit a full-time team, but often the pace is slower.

This is because the discovery work is so much, it is done together with the customer's team, and its availability does not allow for too high a pace: you would end up producing features without having the right feedback and without evaluating step by step the results actually obtained (outcomes over outputs).

The solution

As Product Owner (or if you prefer Product Manager, I like to think they are exactly the same role), I have to refine over time the ways to communicate priorities and goals to teams to achieve, having to keep the focus on the fewest number of things in a single sprint and at the same time having to balance at least a dozen products / projects.

So, I'm trying to apply some rules, which are summarized graphically in our 'volcano'. The drawing below created on Miro should be much more explanatory than words.

Given 100%, for simplicity , the available capacity (we measure it in story points), each team in each sprint should:

• have at most one product to focus more on and that takes up more than half of the time available (about 60-65%): the one to tackle, so you have time to focus on a problem, sleep on it, and be able to continue on it the next day (you see them in the green band);
• have another couple of products that take up about 2/3 of the remaining effort (about 25-30%) that have simpler things to do, or discovery activities to be able to then resume the focus in the next sprint, also useful in case the main product has blocks for any reason (I put them in the blue band);
• have a final range of products or activities, which typically may require small maintenance interventions, simple bugfixes or organizational activities, and which occupies the remaining 10-15% in the lower gray range.

This creates, for each team, a kind of pyramid where at the top is the one product with the focus, below a couple of secondary low effort products, and at the bottom a series of small activities to create a layer of 'dust'.

Then there are some common parts, which can be in the upper red band if in emergency, or in the various layers up to the dust at the bottom, and which require a choral work where some (or all) of the team members collaborate, and for this reason they are placed in the center.

Since there are currently 3 teams in 20tab, it is easy to connect each of them with a 'side' of the volcano, but if they were to grow the principle does not change, it would only be necessary to divide the volcano into several vertical bands.

Each product includes a post it with the name, and one or two with the sprint goals (at this moment it is convenient for us to indicate one of discovery and one of delivery), as well as an indication of the total effort (story point) which is foreseen during the planning, which is flanked during the review by an indicator of objective achieved or not (for me a thumbs up or down is enough), with the total of story points actually achieved.

Finally, next to the volcano, there is an area where the paused products that do not fall within the current sprint are located.

I hope you have found this reading useful. As team needs evolve, forms of communication and interactions will also shift and adapt to changes. The volcano could turn into an island or a spaceship, for me the important thing is always that it remains effective in communicating in a clear and visual way what is necessary.

Never abandoning the idea of Inspect & Adapt, and that interactions are far more important than the tools used.