The Scrum PMO

The Scrum PMO
By Russell Whitworth

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:

Figure 1: How Scrum is typically represented

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-organizing Team gets on with the work. It works very well.

Unfortunately large organizations 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 organizations 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.

Figure 2: Scrum PMO serving one team

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:

• 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 minimize the impact on the Product Owner.

• 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:

Figure 3: Scrum PMO serving multiple teams

Hasn’t anyone solved this before?

The approach shown is very similar to that adopted by DSDM (Dynamic Systems Development Method) – the flavor 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:

Figure 4: Scrum PMO according to DSDM (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.

Q2 Associates Managing Director, Russell Whitworth, is an experienced project/program manager and consultant who has worked in the telecommunications industry throughout his career. His employers have included a user organization, a vendor, a management consultancy, a telecommunications consultancy, and a major telecommunications operator.