Agile Portfolio Management — 2

OK, so we got started earlier. This continues an earlier post.

What next?

Ummm. One of the goals of Agile Portfolio Management is making sure the most important things are done first. And that all of us are only working on the highest priority things. And Agile Portfolio Management should try to achieve that goal at a high level.

One of the goals of Agile Portfolio Management is to enable us to harness change for our competitive advantage.

(Note: Agile Portfolio Management is distinct from Scrum, but I will talk about APM in a Scrum context. In a different context, one would need to explain it differently.)

OK. So how do we do that?

Well, if we have a bunch of teams, let’s say five Scrum teams of about seven people each, we name a Chief Product Owner for that whole group. The CPO prioritizes a high level Product Backlog, and assures that all five teams are only working on the most important stuff. The CPO must organize the “Product Owner team” so that great “stories” are given to each team so lots of Business Value is realized in every Sprint and every release, much more than before.

The CPO is not trying to make individual teams efficient per se, but trying to identify and get the Business Value released (and get the cha-ching, the dollars rolling).

The CPO (and the PO team) is always surveying the winds of change, to enable our company to adapt faster (or to minimize any negative impacts).

Every month, the PO team is looking at all efforts and teams, and asking: How can we adapt faster so that more BV is realized? They recognize all the different learning that are going on and see where it leads them. The monthly cycle is largely because this is the typical frequency with which senior stakeholders can engage and participate. So, the PO team is looking across all the teams and saying: OK, where is the best place to invest now?

Many consequences could arise from these conversations:

• any month a significant effort could be decommissioned
• any month a new effort could be started
• the direction of any team could be changed, perhaps in a minor way, perhaps in a more major way
• the master Product Backlog is refactored with input from all stakeholders
• stories are eliminated, modified, added and the impact of this is understood and socialized

Thus, at a fairly high level, the overall direction of this group is adjusted. Then, at a lower level, the CPO gives specific stories (maybe larger ones) to each team. The PO for each team typically will need to organize the refactoring of the (large) stories into smaller ones that can go into an individual Sprint for his team.

The PO team does not attempt to micro-manage at a level below the story. And, in general, the PO team does not have time to deal much with small stories, unless there is conflict or important learning needed about such things as: “How does this story fit with our overall direction?” or, “How does the story in team X fit with another story in team Y?”

More later.

« « Agile Portfolio Management – 1 || The Nokia Test (6): Estimates created by the team » »