Agile Portfolio Management

Functional silos… matrixed teams… unnecessary levels of specialization… these are the factors that make it really hard to run stable projects.

People are spread across too much stuff. Keeping up with where people are supposed to be (and when) is a nightmare. When projects change, it is very difficult to assess the impact because of the number of cascading interdependencies.

Unpredictable projects make for unpredictable portfolios. One significant change and the whole thing falls apart. The cost of change is way too high.

When faced with overwhelming system complexity, we move toward service oriented architectures. In the face of overwhelming requirements complexity, we move toward user stories and use cases. These strategies create independence between agents, hide their complexity, and have them interact with each other across defined boundaries.

It helps make each problem self contained and very well defined. When one component is changed, these strategies contain the cascading impact.

Think about Bill Wake's INVEST model for user stories. Stories should be independent, negotiable, valuable, estimateable, small, and testable. What if we applied the same logic at the project level? What if we created a project portfolio that followed this same general framework?

Let's see what that might look like?

Independent - Projects have minimal dependencies between them. They only share resources when absolutely necessary. You align releases to minimize date dependencies.

Negotiable - Project objectives are defined up front, not detailed requirements. Negotiable is manifest in the agile backlog.

Valuable - Expected return is defined up front. At the end of the project we can clearly assess if the project yielded the expected return.

Estimateable - Projects are well defined enough to get a handle on their size

Small - No project bigger than 3 - 6 months. Make investment decisions in smaller increments.

Testable - Projects must have well defined acceptance criteria

Could an organization run a backlog of projects like it runs a backlog of stories? Could a portfolio owner make decisions about what projects to bring into the next release based on their priority and relative business value? Could we take the sprint planning metaphor and elevate it to the portfolio? The same kinds of things we do to manage the flow of backlog items through the system would be done to manage the flow of projects, just one level up?

Stories are to projects as projects are to portfolios

Do these same metaphors apply? I know some folks are doing this. I don't know of anywhere where this is being written about. Anybody know of someone that has defined a model like this?

Photo Credit: http://www.onshoretechnology.com/EnterpriseServices/BusinessConsulting/tabid/132/Default.aspx

Comments

[Tara Lee Whitaker]

Hi Mike,

Great Article. We recently introduced an Agile Epic Board into the equation. This is similar to a task board but works at a higher level - as you describe above.

We stack projects/epics in the 'to do column' and instead of having the in progress / in qa / done columns, we have columns representing sprints. We also have multiple layers to the board - each horizontal layer representing another scrum team.

The Scrum of Scrums are now held around this board - we ask the basic SoS questions as described by Mike Cohn (http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting), however we've now added context to the discussion. We can move epics/projects around, share work out, identify potential blockers/bottlenecks etc.

I do believe that it's the same concept but just a level higher - the epic board deals in Epics/projects and stories. The task board deals with Stories and tasks.

I've posted a few pictures of our board on my blog - take a look and let me know what you think.

http://agile101.net/introducing-the-agile-epic-board/

Tara Whitaker