A project management office (PMO) that is engaged in and supportive of transitioning to Scrum can be a tremendous boon. Members of the PMO often view themselves as protectors and supporters of a practice, so a PMO can help implement and spread agile project management across the organization. However, when the PMO is not properly involved, it can be a source of resistance as it tries to defend the current process, rather than improve it.
The natural response of most people in the PMO is to resist the transition to Scrum, because much of the change is both personally and professionally frightening. Scrum scatters traditional project management responsibilities among the ScrumMaster, product owner, and the team, leaving project managers questioning their role. The absence of the PMO in most Scrum and agile literature adds to the natural concerns of PMO members.
In this article, we will ease those fears by looking at the type of work performed by PMOs in organizations that have successfully transitioned to Scrum. We will look at the contributions and work of the PMO in three areas: people, projects, and process.
The Project Management Office And People
Although it’s called the project management office, the PMO has tremendous influence on the people involved in a Scrum transition. An agile PMO should do the following:
Develop a training program. There is much to adopting Scrum that will be new and unfamiliar to many team members. The PMO can be of tremendous assistance in putting together a training program, selecting outside trainers to deliver the training, or delivering the training themselves.
Provide coaching. Beyond training people, individual and small-group coaching is incredibly helpful. In a training class, the instructor says, “Here’s how to do a sprint planning meeting,” for example, and perhaps runs the class through an exercise to practice it. With coaching, someone with deep experience sits with the team and helps team members through their own real sprint planning meeting (or whatever skill is being coached). Early on, members of the PMO might not have these skills themselves, but they should focus on acquiring them from outside coaches and then do the hands-on coaching themselves.
Select and train coaches. A successful Scrum initiative will eventually lead to more coaching needs than the PMO can manage on its own. Members of the PMO should identify and develop coaches by watching the scrum teams they help and then providing training or assistance to help selected individuals become skilled coaches. These coaches usually retain their current jobs but are given additional responsibilities, such as spending up to five hours per week helping a specific team.
Challenge existing behaviors. When the organization begins to adopt Scrum, the members of the PMO look for scrum teams who are falling back into old habits or whose old habits are preventing them from becoming agile. Later, members of the Project Management Office can remind teams that Scrum is about continuous improvement and can help prevent the onset of complacency.
The Project Management Office And Projects
Although some project-oriented responsibilities go away with the change to an agile PMO, some responsibilities remain, including the following:
Assist with reporting. In most organizations large enough to have a PMO, there is usually something like a meeting or weekly report on the status of each project with the department head. If this is a meeting, it should be attended by appropriate project personnel, such as the product owner or ScrumMaster. If it is a weekly, standardized status report, the PMO can assist in preparing the report.
Assist with compliance needs. Many projects need to comply with standards (ISO 9001, Sarbanes-Oxley, and so on) or with organization-specific rules, such as those for data security. An agile PMO can assist teams by making them aware of such needs, advising them on how to comply, and serving as a central clearinghouse for tips and shared knowledge on compliance and similar matters.
Manage the inflow of new projects. One of the most important responsibilities of an agile PMO is to assist in managing the rate at which new projects flow into the development organization. As described in chapter 10 of Succeeding with Agile , it is important to limit work to capacity. Otherwise, work piles up, leading to a litany of problems. For each project completed, a new project of the same size can be started. The agile PMO can serve as gatekeeper and help the organization resist the temptation to start projects too quickly.
The Project Management Office And Process
As keepers of the process, members of the PMO will work closely with the organization’s ScrumMasters to make sure Scrum is implemented as well as it can be. These process-related activities include the following:
Assist in establishing and collecting metrics. As it did before becoming agile, the PMO can identify and collect metrics. Scrum teams are even more leery of metrics programs than traditional teams, so this is an area where the PMO should proceed cautiously. One thing an agile PMO should collect is information on how well teams are doing at delivering value.
Reduce waste. The PMO should aggressively help the team eliminate all wasteful activities and artifacts from its process. An agile PMO should avoid introducing documents, meetings, approvals, and so on unless absolutely necessary. It should also help teams look for things that they are doing that might not be adding value.
Help establish and support communities of practice. A community of practice is a group of liked-minded or like-skilled individuals. One of the most important things an agile PMO can do is to help encourage the formation of these communities and then support them after they begin. Not only do communities of practice help Scrum spread through the organization, they also help spread any good idea from one team to another.
Create an appropriate amount of consistency across teams. Most teams, especially Scrum ones, bristle at the thought of consistency enforced through dictate. The best type of consistency across teams comes from most or all teams agreeing that a particular practice is a good idea. The agile PMO facilitates this by making sure good ideas spread rapidly among teams. Two practices they can use for this are communities of practice and shared coaches.
Provide and maintain tools. In general, tool decisions should be left to individual teams whenever possible. On occasion, a community of practice might decide that there are sufficient benefits to choosing one tool for all projects. As a last resort, tool decisions can sometimes be made by the PMO, although this should be extremely rare. But, the agile PMO can assist teams by acquiring the appropriate tools and performing any configuration or customization necessary.
Coordinate teams. Because they work with individuals from many different teams, PMO members are vital in coordinating the work of separate teams. Someone from the PMO will often be the first to notice when the work of two teams starts to diverge or overlap. PMO members can provide value to teams by alerting teams to these situations when they occur.
Model the use of Scrum. Through their intensive exposure to Scrum, most agile PMOs quickly realize Scrum’s usefulness as a general-purpose project management framework. At that point, many PMOs choose to use Scrum itself to run the PMO. They plan monthly sprints, conduct daily scrums, and so on just like any other team.
Work with other groups. The PMO can be of great assistance to teams in working with other groups, especially human resources and facilities. A PMO can help explain to the facilities group the negative impact of spreading a team across two floors or of having programmers and testers from the same team sitting separately. A good PMO will work with human resources to remove from the annual review process questions that discourage teamwork.
Renaming the Project Management Office
Many PMOs choose to rename themselves to better match their revised role. Though there is no one standard name, I have heard these most frequently: Scrum center of excellence, Scrum competence center, Scrum office, and development support.
Many people have become cynical and suspicious of name changes and of well-crafted names. That cynicism will be directed at the PMO if it is renamed but remains otherwise unchanged. So, whatever it's called, the PMO that supported the organization's sequential development process will need to change more than just its name to succeed with Scrum.
A PMO often has tremendous political clout and project experience. Though an adversarial relationship might work for a while, teams that have a PMO on board with Scrum not only avoid a possible source of resistance but also benefit from having a powerful ally. When possible, in transitioning to agile, choose t make friends rather than enemies.