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

Doing Less

I wish I could find the exact quote. Back in the early 90s, when I was using Prince 2 on several projects, there used to be a slim “Introduction to Prince 2” volume that explained you don’t have to do everything on every occasion. It said something like “the Project Manager needs to distinguish the essential from the merely important.”

At the time, I was really looking forward to the occasion when my Project Owner would ask me to do something, and I would be able to reply: “No, I’m not going to bother with that; it’s merely important.”

Alas, my Project Owner was far to sensible to request anything other than essential, but the phrase has stayed with me to this day.

The real sentiment behind the statement is that the PM should not be following the methodology blindly and by-the-book, but should be thinking about why the various activities are needed — what value they add — and adjusting them accordingly. Take reporting, for example. In many organisations, project reports are issued weekly. In some, they are issued fortnightly. In the former case, does the report add twice as much value compared to the second? If not, why spend double the amount of overhead on producing it?

It isn’t just the frequency of reporting that is an overhead; it is also the volume. I have known a few senior stakeholders who are genuinely able to absorb and respond to a multi-page report each and every week. Many more, however, only have enough time and attention to pick up on a few bullet-pointed highlights. So if that is your typical stakeholder, why write any more?

As Project Managers, we are an overhead. We may work hard in terms of hours and effort, but it is the team that does the real work. So the less time that is spent on project management, the better. Agile Scrum recognises this in the use of self-organising teams. There is no project manager, and no project management overhead. Project Managers are an endangered species in the Agile world.

Actually I don’t think the wider profession of project management is threatened by Agile, as there will always be essential (that word again!) activities that sit outside the Scrum team: portfolio and programme management, long-term planning, corporate governance, executive reporting. These are the domain of PPPM (Portfolio, Programme & Project Management) and the PMO (Project — or Programme, or Portfolio — Management Office). Our employment prospects are safe, even if we don’t retrain as ScrumMasters or Product Owners.

It is a sign of maturity and experience as a Project Manager that we prioritise our own time more effectively. Comprehensive methodologies such as those documented in Prince 2, PMI’s PMBOK, APM’s BOK, and others, are more likely to be followed as a “paint by numbers” exercise by those early in their project management careers. And a good thing too, as they contain a great deal of insight and best practice that provides a solid framework. Over time, we learn which things to leave out, and which to focus on – and that varies from project to project. The ability to distinguish the essential from the merely important comes with experience.

 

By | 2015-08-19T10:54:44+00:00 January 2nd, 2015|Agile, Project Management|1 Comment

Spot the Agile PM

Last week I was able to attend the excellent Thomson-Reuters/PMI Project Management “Unconference”, held at Exeter University. I also volunteered to host a couple of the bar-camp sessions, one on Coaching for PMs and the other Stakeholder Management.

The event offered plenty of opportunity for discussion during the breaks, and it struck me in particular how much Agile came up as a topic of debate. This was even more remarkable because it wasn’t particularly a subject on the agenda. Even in my bar-camp sessions if I spoke about coaching, I got asked about best practice as an Agile Coach. If I spoke about stakeholder management, I was asked about stakeholders in Agile projects. It is clearly a hot topic!

One thing that seems to be happening is that project managers are concerned about their role in the Agile world. Quite a few are going on Scrum Master training courses, and are confused because there is no explicit PM role in Scrum (which is, of course, just one flavour of Agile – but seems to be the one that most are going for).

Here are the three roles defined in Scrum (source: The Scrum Alliance):

Product Owner

  • The product owner decides what will be built and in which order
  • Defines the features of the product or desired outcomes of the project
  • Chooses release date and content
  • Ensures profitability (ROI)
  • Prioritizes features/outcomes according to market value
  • Adjusts features/outcomes and priority as needed
  • Accepts or rejects work results
  • Facilitates scrum planning ceremony

ScrumMaster

The ScrumMaster is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues.

  • Ensures that the team is fully functional and productive
  • Enables close cooperation across all roles and functions
  • Removes barriers
  • Shields the team from external interferences
  • Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
  • Facilitates the daily scrums

The Team

  • Is cross-functional
  • Is right-sized (the ideal size is seven — plus/minus two — members)
  • Selects the sprint goal and specifies work results
  • Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal
  • Organizes itself and its work
  • Demos work results to the product owner and any other interested parties.

So where has the PM gone? The answer, of course, is that the responsibilities have  been redistributed.

If we start from The Seven Essentials being the basis of project management, how do these map onto the Scrum roles?

  • Benefits – clearly the responsibility of the Product Owner
  • Scope and Quality – also Product Owner, since they define the features, and accept or reject
  • Stakeholders and Communications – not really mentioned, but external communications (to senior stakeholders) will also be handled by the Product Owner
  • Plan – This one is split. Scrum Planning (i.e. high-level planning) is facilitated by the Product Owner. The Team organises its own work (detailed planning).
  • Team – Scrum Master looks after the team.
  • Suppliers – Not explicitly mentioned, but both the Product Owner and the Scrum Master have a role here. The Scrum Master in particular has a responsibility to remove barriers, which could indeed be due to suppliers.
  • Risks – Again, not mentioned, but there is a touch of risk management in everyone’s role. The Product Owner will be concerned with external and commercial risks, the Scrum Master with risks to the team’s efficiency, and the Team itself organises its work accordingly.

So, to summarise in table form:

Scrum roles

 

Now can you spot the PM?

I’m not saying that Project Managers shouldn’t retrain as Scrum Master. I’ve done it myself, and the training will teach you a lot about Agile. And the Scrum Master role itself can be interesting, demanding, exciting… I’m sure it would suit many former project managers. But if you’re a “seven essentials” sort of PM and you want to continue to develop those skills, then you should think about moving towards becoming a Product Owner.


 

Update March 2015

I’ve been reading Essential Scrum by Kenneth Rubin. Interestingly the book contains a very similar table, but using the PMI’s 9 knowledge areas from PMBOK Version 4 (since superseded by a slightly different set in Version 5). Here is Ken’s analysis:

Mapping of Project Management Responsibilities in a Scrum Organization

Project Management ActivityProduct OwnerScrumMasterDevelopment TeamOther Manager
Integration??
ScopeMacro levelSprint level
TimeMacro levelHelps Scrum team use time effectivelySprint level
Cost?Story/task estimating
Quality????
Team (human resource)?Formation
Communications????
Risk????
Procurement??
Source: Essential Scrum, by Kenneth S. Rubin (Addison-Wesley, 2013)
By | 2015-08-19T10:54:45+00:00 April 30th, 2013|Agile, Project Management|4 Comments