Managing portfolio with roadmaps and teams

If you are working with teams, assign products or project to them and want to structure your planning process on a higher level, you might consider using a roadmap for your portfolio level (I use the term product equal to project).

To give product portfolio a sound basis you might use a roadmap to visualise the load factor of your teams. Just give every team its own lane and assign the planned products to the teams.

If you are doing this for the first time, you might wonder on how much products in parallel your teams are working. It is reasonable to think about the reduction of product multitasking to increase productivity.

For those products you are not sure if they are worth working on them yet, you have three choices:

  1. Keep them unassigned (unstaffed), but put them on the "should be considered soon for implementation list". Those products should be discussed in a portfolio meeting.
  2. Put them on a parking lot, if you do not want decide soon about the implementation but do not want to forget about them.
  3. Kill them, if you don't want to think about them in the future anymore or if they will never get the priority to get capacity.
This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

Here comes a little more description about the used lanes in the roadmap:

The team lanes

Within the team lanes you assign products to the teams. As long as a team works and is planned on a given product no other product should interfere. I recommend you to set a work in process limit (wip limit) for each team. This should speed you up and reduce waste.

Unassigned

Each product which could not be staffed by a team stays unassigned. Unassigned indicates: you want to work on this product, but do not know how to stuff it yet. In future discussion these products might get development time.

Parking Lot

You've got a product which is interesting enough not to kill it but doesn't have the priority to be developed you put it on the parking lot. These products might be good opportunities but hard to realise in practice.

Killed

If you refuse to work on a product, kill it. This means throw it away. Do not bother yourself in the future with concerns or thoughts about this product.

If you decide about your product portfolio, share it. Communicate it and make it visible as much as you can. If you want alignment, people must know about your decisions and for sure you have to defend it against the drift of the daily business. You might provide guidance for people and create policies for them. If you want to read about an example, I recommend to read about "how an issue finds its way into development".

If you are working in a hierarchical organisation, management should support or communicate the decisions. If communication is not aligned chances are hight that your portfolio gets sacked. Or just to stick with Gojko Adzic:

If communication fails, everthing else is just painting the corps.

SVNWNK

Sources:

Surfing on the learning wave

Surfing in projects

If you inspect something you will learn about it. Your learning will lead to new insights that will lead to action. Action needs to be inspected and new insights will rise new learnings and further paths to inspect. Sounds like infinite play of waves against the shores and sure it is.

If we take for granted, that we'll learn on the way while we inspect something - when we analyse something - then we cannot deny and have to admit, that the learning is something that changes reality. So staring at reality and learning about it rises the need to deal with change.

Analysing too much, before taking action on it, creates waste. It is not only the waste of missing feedback, to a greater degree I think it is the waste of not catching the insight and the learning. Not preserving the change seems like wasting the investigation at all.

Back down the big analysis change wave

Let's have look at the most project management techniques: Usually we plan, when we have the least knowledge of a project ever. There is huge front-up planning at the start of each project, so we analyse a lot. Makes sense? Yes maybe, but do we really preserve the learning we've created? Do we fully accept that we changed our view about the thing we investigated? Not sure, in most times I would say yes - if the chunk of change is small enough.

As I said: While we analyse we change our view at a lot of things. So with each analysis we need to manage more change. Again: the more we analyse, the more we have to manage change. So far the creation of a big plan, without handling the wave of change created by the analysis, leaves the learning and preservation of insights behind. Instead of making big plans which drown us, we should focus on small batches to analyse where we can cope with the change we've created. So we need to find a batch size so small, that we can cope with the change we created.

Making the drop

You are shouting "Coming down" when you are the first to drop into the change wave? Only few surfers are brave and skilled enough to survive the big waves. So why not surf on the waves big enough you are able to deal with. Even when there are always a lot of change waves following, as soon as the ocean bed flattens out:

A guy who is making the drop in a nice wave. Every investigation reveals insights, and those insights lead to a wave of change. Don't let the wave grow too big to withstand it.

At the moment we hand over our experience, means sending out our deliveries to customers and users, we create more change. Now change might increase more than linear, according to the batch size of done work and people involved. If we take feedback outside of the team into account, then there might be a good reason to move to an even small batch size of analysis to cope with this wave of insights and demands again. 

Making the drop - again

Now, how can we really make the drop - again and again? To me one answer is to work in small timeboxes, where each timebox represents a small batch size of delivery and a deadline. Furthermore I would arrange a framework around it, which is able to inspect and adapt. This framework should be able to deal with experiments and feedback: something like a plan-do-check-act cycle. Fortunately here is already something out there and they call it Scrum. Wanna try it?

SVNWNK 

PS: Socrates said: “understanding a question is half an answer”.  .. and I want to append: "the second half of answer will change the question".