The Scrum PMO

The challenge is this: How do you make Agile Scrum work in a traditional corporate environment? The problem is simple to state, but the solutions are frustratingly complex.

I am a strong believer in Agile Scrum. I like the theory, and I have plenty of experience of it succeeding in practice (having served as a team member, ScrumMaster, Product Owner and as an agile coach).

The challenge

Scrum is usually represented something like this:

Scrum

 

Part of its power is the simplicity of the model. The Product Owner sets the priorities, the ScrumMaster coaches and facilitates the team, and the self-organising Team gets on with the work. It works very well.

Unfortunately large organisations now throw two huge spanners into the works:

  1. Governance. Meaning stage gates. Typically there will be a formal and complex corporate hoop to jump through in order to move between project phases (such as from “Feasibility” to “Detailed Design”, or “Alpha” to “Beta”, or “Planning” to “Delivery”). Such gates are likely to involve the very un-agile practices of baselining the project scope, plan and milestones.
  2. Management reporting. Senior folk like to know how the project is progressing against plan.

Both of these requirements are understandable in a command-and-control management structure, but they conflict with the agile philosophy. For organisations that are in transition from traditional to agile methods throwing them away is a step too far, so they remain as a necessary evil, and a potential source of friction for agile delivery.

A possible approach

A solution that I am seeing being tactically deployed by my current client is to put an insulating layer between the Scrum Team and the corporate governance layer. For want of a better term, this is referred to as a Scrum PMO (Project Management Office). The PMO can be a single person, or a small team.

Scrum PMO

 

The primary purpose of the Scrum PMO is to keep the corporate hassle away from the Scrum Team, so that they can get on with the business of being a high-performing team! There are two main interfaces shown:

  1. For Governance processes, the PMO represents the project. The overhead of preparing governance materials and attending governance boards falls entirely to the PMO. This can be substantial – including preparation of high-level project plans, scope documents, risk assessments, and whatever else is needed to feed the corporate machine. The PMO does this based on an information exchange with the Product Owner – but in a way that seeks to minimise the impact on the Product Owner.
  2. For Reporting processes, again the PMO represents the project and prepares all necessary management reports, including status reporting against the high-level milestones. Reporting is based on information received from the ScrumMaster, who should be preparing NOTHING more than one would normally expect in Scrum (such as burn-down charts).

The Scrum PMO can, of course, serve more than one Scrum Team:

Multi PMO

Hasn’t anyone solved this before?

The approach shown is very similar to that adopted by DSDM (Dynamic Systems Development Method) – the flavour of agile favoured by (for example) the APM Group’s AgilePM qualification. An excellent paper “The DSDM Project Framework for Scrum” can be downloaded from DSDM.org, and it contains this diagram:

DSDM scrum

Source and copyright: DSDM Consortium

 

 

Notice the “Project Manager” sitting outside the Scrum Team, whose role is much like the one I have described for the Scrum PMO.

Is this the right solution?

So far, in my experience, it seems to work – but the Scrum PMO needs to be seen as a transitional sticking-plaster solution. At the same time as ridding the Scrum Team of corporate tasks, overall it is adding significant overhead and bureaucracy.

Also, the insulating layer is removing senior management from direct involvement in the work of the teams – and in doing so, giving a false sense of security.

But it is probably no worse than the traditional approaches that went before, and if that is what it takes to enable Scrum Teams to succeed, then it is the right answer. For now.

By | 2015-08-19T11:24:44+00:00 February 13th, 2015|Agile, Project Management|6 Comments

About the Author:

6 Comments

  1. Daniel Tobler February 15, 2015 at 10:02

    You describe the two spanners very well. And I see PMO also as a pain killer, as a temporary thing that – if management is properly involved in the agile transition – should not be necessary. I was recently involved in such a transition where no PMO was necessary, because management was the driver for the transition.
    1.) Governance: DSDM is for sure a good project setup method. But the real problem is deeper: Traditional management is used to very large projects which run once through each gate. Agility allows to cut the tail, not implementing unnecessary functions. This is not foreseen by traditional gate models. The gate model needs to change for agility: A project/product must be able to run several times through the same gate. And it only gets budget for 3..6 months and needs to be refunded after that. When a company asks me to help them getting more agile, budgeting is always a big issue.
    2.) Reporting: Management is used to the reports lying at them: green-yellow-red, top-achievements, Budget burndowns, … The only real report that I would want as top-manager overseeing 100x Projects is a release burndown/cumulative flow diagram from where I can tell in a second whether the project is on track or not. Very transparent, very honest! Btw: I’ve lost a job due to such a burndown, having been too transparent in a command and control company. Unnecessary to say that top-management is also invited to Sprint Reviews. In larger companies, Sprint Reviews are often combined to show the work of several teams at once. See e.g. LeSS, SAFe, … Mangers do not need to attend 100x such reviews.

    • Russell Whitworth February 16, 2015 at 15:00

      Thanks for your comment, Daniel. It clearly highlights the importance of (re)educating and transforming senior management behaviour.

  2. James Strangeway February 18, 2015 at 15:40

    I enjoyed your article and Daniel’s reply.

    It has been my limited experience that when an organization is transitioning to an agile methodology it is essential for senior management to be fully engaged and completely on board with the decision. At a minimum, they must fully empower those in the middle management positions that are implementing agile. Otherwise, the need for the PMO will never go away as senior management will always have need of the PMO and the old metrics, plans etc..

    • Russell Whitworth February 18, 2015 at 15:46

      Thanks, James. You are absolutely right… but old habits die hard and senior managers will find it hard to take away the safety net (as they perceive it).

  3. Mahmoud Hegab December 28, 2016 at 17:35

    Hi,

    I’m going to assume by the dates on your articles, yours is the original

    https://www.linkedin.com/pulse/scrum-pmo-shivpal-singh-prince2-practitioner-itil-csm-

    • R Whitworth December 28, 2016 at 17:42

      Wow – yes, that is wholesale piracy and copyright violation. Thanks for letting me know; I will try to have it taken down.

Comments are closed.