Susanne Bartel

With Scrum and other agile project management frameworks spreading more and more across the industry, there is also a certain maturing process happening: If you have a few scrum projects ‘to test the waters’ in your company, not a big deal. Once you fully commit to agilizing ;) your project portfolio, you’ll come across issues like:

‘Is there still a need for a Project Management Office (PMO)? And if so, how on earth can this fit with the self-organization and minimum-interference approach of Scrum?’

I thought a lot about this in the past weeks, gathered all my thoughts in a little mindmap, and am sharing the key thoughts with you today.

For a little fun at the start, have a look at The Biggest Little List of Oxymorons Online! Agile PMO is not in there yet, and maybe there’s no need to submit it. I believe that there is still value in having a PMO, even in times of Scrum&Co.

I’ll touch briefly on both sides of the Portfolio Management as suggested in the Portfolio Management Guidance by Craig Kilford:

• Project Portfolio Definition – investing in the RIGHT projects
• Project Portfolio Delivery – making sure projects are done the RIGHT WAY

Regardless of the project management approach applied, you as the owning organization still want to ensure you’re investing your resources into the RIGHT projects, i.e. the need to apply Project Portfolio Definition techniques (strategic alignment, categorization, prioritization, based on business value, financially and non-financially). I’d see no big difference here compared to the ‘classic’ approach, the same rigor should be applied when it comes to project appraisal and authorization, based on a compelling business case. Keep in mind, there is nothing in Scrum that prevents you from developing software that is not needed (if only the Product Owner thinks so).

Once your authorized projects are up and running, you’re entering the Portfolio Delivery cycle, and you’ll want to be up-to-date about the status of upcoming major milestones / releases, key impediments and risks that cannot be resolved/mitigated within the individual teams, etc.

For impediments and risks – all that lies within the team boundaries and can be resolved there should stay there. Impediments and risks that span across teams could and should be escalated to from the Scrum teams, so that the PMO can get organization-wide issues out of the way. In addition on the risk side, risks should also proactively be identified and managed across projects, as a function of the PMO.

When it comes to reporting, you’ll need to start looking at the iron triangle between time, cost, and functionality. Typically, time and cost will be fixed, with functionality somewhat flexed, as the GOAL is fixed but not the exact detailed features to get there. This will provide you a first clue where to start. A few ideas for information to gather at the end of sprints below:

• Overall RAG status for upcoming releases
• End-of-sprint report
• Release Burndown Bar
• Impediment chart, particularly any impediments that could not be resolved within the team
• Identified risks that impact other projects, too

And this is where I’d probably stop. Minimize the overhead as much as you can, keep it simple and reuse artifacts created by the team anyway as much as possible. And remember, WITHIN Sprints, this is all a black box to everyone outside the team! No interference except the team specifically asks you for it. If you’re too curious, you can ask the team to observe (silently!!) their Daily Scrums, but that’s it.

I’d be careful when it comes to comparing velocity across teams. You’ll have to be cautious not to compare apple with pears, and furthermore you could introduce a sense of competition that might be counter-productive. This leads us to standards:

As one of the underlying philosophies of Scrum is a team that organizes itself the way it works best for this respective team, one should generally be very careful when it comes to standardizing.
However, once you have a certain number of projects running, a certain level of standardization will help you to ease the overarching functions. A few examples:

• Use a standard environment for team collab spaces / wiki sites, e.g. provide a standard server, but allow the team to structure and fill their space as it fits best.
• You COULD standardize story points, i.e. define a typical “5″ story points user story, that everyone can relate to. Use with caution as this smooths the way to compare velocity across teams (see my comment above).
• If you’re thinking about standardizing things like reporting or minimum requirements for tasks boards, starting with a ‘best of the breed’ approach would be wise. As a rule of thumb when it comes to standards: Always bottom-up, never top-down.

The last area where a PMO can add a lot of value is in a facilitator role to encourage the sharing of knowledge and experiences across teams. The PMO could for instance suggest rotations across teams, informal meetings between ScrumMasters, and so on.

To get an indication how the change process (i.e. Scrum adoption level) is going, the PMO could sit together with ScrumMasters from time to time (I’d say no more often than once or twice a year) and go through one of these Scrum Checklists that are available online. This will give you clues which areas are working really well already, and where further improvements could be made.

That’s it for now. I’d love to hear your thoughts and experiences. And a little health warning: This is just a collection of thoughts and not a scientific paper ;)