Chapter 20. Human Resources, Facilities, and the PMO

To achieve long-term success with Scrum, the implications of becoming agile must be transferred into other parts of the organization. When this is not done, organizational gravity—those influences that formed the organization into whatever shape it existed in before the start of the transition—will kick in. I have seen Scrum transitions stalled or completely stopped because they ignored the impact of becoming agile on groups outside development. Doing so results in situations like these:

• Human resources. Scrum teams start out doing extremely well until annual review time comes around. Suddenly, everyone realizes they will again be assessed, and receive raises, based entirely on individual performance. The annual review might have one field for assessing whether an individual plays well with others, but at the end of the day individual contributions and heroics bring home the raises and promotions.

• The facilities group. It’s much easier to be agile when the whole team sits together. But when a facilities group makes that difficult, or when it prevents teams from using wall space for burndown charts and other important project data, teams become demoralized. It becomes harder to continue the push toward becoming better at Scrum when it feels like everyone is against you.

• The project management office (PMO). Without thinking about how its project relates to an existing PMO, a Scrum team kicks off with a “damn the paperwork and process” attitude. This creates an enemy out of the PMO, a group that was already uneasy about the organization’s initial, tentative experiments with Scrum. The PMO responds by convincing departmental management that Scrum is OK as long as it is supplemented by a crushing set of documents and practices.

When Scrum is mistakenly viewed solely as a change within the development group, the organizational gravity created by the departments outside of IT can pull the development group right back where it started. In this chapter we look at things you can do to help your organization’s transition effort achieve sufficient escape velocity to break free. In particular, we look at the impact of Scrum on the three groups mentioned—human resources, facilities, and the project management office.

Human Resources

Many of the issues involving the HR group are the result of a change to shared accountability. In The Wisdom of Teams, Katzenbach and Smith describe why this is difficult.

Most organizations intrinsically prefer individual over group (team) accountability. Job descriptions, compensation schemes, career paths, and performance evaluations focus on individuals.... Our culture emphasizes individual accomplishments and makes us uncomfortable trusting our career aspirations to outcomes dependent on the performance of others.... Even the thought of shifting emphasis from individual accountability to team accountability makes us uneasy. (1993, 3–4)

As an example, consider the case of Chuck. When I told Chuck and his team-mates that I wanted them to try pair programming for a few sprints, Chuck stood up, said, “I’m going to HR about this,” and left the sprint retrospective. What was he going to do? Have me fired? I wasn’t even an employee, so I was totally confused. The looks on the faces of the rest of the team showed they were equally perplexed, but we continued the meeting.

Later that morning, and before I had a chance to talk to Chuck so I could understand his perspective, I got a call from Ursula, the company’s human resources director, asking me to come by her office. Our discussion was the first of a handful of nearly identical discussions I’ve had since then at other companies. Chuck had gone to Ursula complaining that if the team instituted pair programming, he would be unfairly penalized. Chuck, who was one of the better and more quality-conscious programmers, explained to Ursula that his annual pay raises historically had been above average because he had consistently written the best code in the group. If pair programming were introduced, he said, his manager would be unable to adequately review him because it would be impossible to know which code was Chuck’s and which code was someone else’s. As a result, Chuck argued, his raises would be unfairly dragged down. Ursula bought the argument and told me that I would not be allowed to have developers write code in pairs because it would hide performance problems and result in unfair reviews.

Because of situations like this one and employees like Chuck, some of the thorniest issues you’ll encounter will be those related to human resources policies. Employees in that department can be either a significant help or a hindrance with these problems. In this section we look at human resources issues you might encounter involving reporting structures, periodic performance reviews, handling performance problems, and determining career paths.

Reporting Structures

There is no one reporting structure that must be used to be successful with Scrum. I have seen functional, project-oriented, and matrixed organizations each be successful. A matrixed organization will be prone to more challenges, but that should not be surprising to an organization that has chosen that structure for its other benefits. So, although I won’t argue strongly in favor of a specific type of organizational structure, I will say that the organization should be as flat as possible. The more layers there are between team members and the top of the company, the more opportunities there are for dysfunctionality to creep in.

Reporting to the ScrumMaster

When discussing management layers, questions often arise about whether team members can report to their ScrumMaster. Common advice is that this is a bad idea. I’m going to deviate from this common advice and say that I am not strongly opposed to having team members report to their ScrumMaster. My view might come from having been both a ScrumMaster and boss for years in small organizations in which we couldn’t afford to separate those roles. Or it might be a result of my hiring exceptional individuals who could fill both roles.

The usual objection is that a team member who reports to the ScrumMaster will not speak freely during daily scrums. A developer will not, for example, mention an impediment out of fear that the impediment will later be mentioned in a performance review. Of course this is a risk. But it is easily mitigated by having ScrumMasters who understand the implications of using voiced impediments as ammunition. Further, there are some benefits to a team whose ScrumMaster is also their boss, including that such a person is sometimes better able to remove some types of impediments.

Are there some ScrumMasters to whom I would not want team members to report? Absolutely. In fact, I prefer that team members report to functional managers rather than to their ScrumMaster. However, in the pantheon of agile sins, having team members report to their ScrumMaster is a minor one—if the right ScrumMaster is in place.

Reporting to the Product Owner

Considering my willingness to allow the team members to report to their Scrum-Master, you might be surprised to learn that I strongly advise against them reporting to their product owner. The difference is that in healthy teams there is a natural tension between the product owner and the team. It is part of a product owner’s job to push for more features and faster delivery. A good team would always love to deliver more faster. But it also needs to sometimes push back against a product owner’s demands if it feels that doing so would harm the internal quality of the product. I find that when the team reports to their product owner, the natural tension that should exist evaporates. It’s one thing for team members to sometimes resist a product owner’s pressure for more; it’s another for them to do so when the product owner is also their boss.

For the same reasons, it would be unwise to have the ScrumMaster report to the product owner. The ScrumMaster and product owner do not need to be peers on the company’s org chart, but they should treat each other as peers and partners on the project.

Periodic Performance Reviews

Many people have called for organizations to abolish the annual merit rating system. I’ve argued for this with various human resources groups but have only won the argument in very small organizations, where the human resources director was probably too busy to institute annual reviews anyway. So, rather than just advise you to rail against a practice you probably can’t eliminate, let’s look at the impact of periodic performance reviews on your Scrum teams and explore ways you can minimize the negative impact and accentuate the positive.

Try to eliminate most individual factors from assessments

It is no surprise that individuals will behave in accordance with what is valued during their performance reviews. I’m looking at an old review form right now. It asks me to rate the employee on “the degree to which the individual effectively manages tasks within budget and timeline.” How would you anticipate someone to behave in regard to this factor if it were something he was rated poorly on the last time? Would the person be responsive to coworker requests for assistance? Probably not. Individual assessment factors lead to individual-focused behavior. We want instead to encourage people to do what is most beneficial for the team and product. In many western cultures, eliminating all individual performance factors from reviews will also meet resistance from many team members. In such situations, try instead perhaps for a 50/50 split between individual and team factors.

Include teamwork factors

Most performance reviews have a section for the manager to indicate whether the employee plays well with others. A useful review needs to go beyond that to establish the teamwork focus we want. Consider the case in which employees are assessed on whether each “effectively manages tasks within budget and timeline.” An initial improvement might be to change that to “helps the team finish tasks within budget and timeline.” But even this does not go far enough because “helps the team finish” is still an individual measure. The factor here should be “the team effectively manages its work within budget and timeline,” and everyone on the team should get the same rating.

Review performance much more often than annually

Employees and their managers should meet as often as they can, of course, for informal discussions about performance, expectations, and objectives. But, if you’re going to do formal performance appraisals at all, you need to do them much more often than once a year. Although this is true even for non-agile organizations, it becomes critical when using Scrum because Scrum projects move more quickly, and employees are learning new skills and ways of working, especially in the first year or two.

Solicit input into the review from a broad set of people

When you sit down to write a periodic performance review, it is extremely unlikely that you know all there is to know about the person’s performance. So, solicit feedback from others, and do so broadly. A functional manager should ask for comments from the employee’s ScrumMaster, product owner, some team members, some peers in the functional group, and some users or customers the person has worked with. I usually select a handful of contributors for each review and e-mail them asking that they tell me what the employee could start doing, stop doing, or continue doing that would improve his performance. I then look for common threads through the responses and from them try to formulate actionable suggestions.

Educate and engage the human resources group

Many of the changes we’ve discussed require the participation or approval of your HR group. But, beyond that, actively seek to educate them about what changes are afoot in the development organization. If you’re doing a half-day training session on Scrum, ask someone from HR to attend. Gabrielle Benefield did this while director of agile product development at Yahoo!. The senior HR representative who attended her training was so intrigued that the HR department began using Scrum to manage its own project of updating the annual review process. Benefield describes the results.

Using Scrum, they completed the project on time, and it was successful. They loved the rhythm of the iterations and meeting frequently to keep up to date on progress as the team was distributed and interrupt-driven.

Removing Team Members

When I saw Derek walking toward me at the conference, I was thrilled. I had first met him a year earlier when I taught a class at his company. I had been back a handful of times, and I always enjoyed talking to him, but we hadn’t talked in three months. I thought this would be a good chance to catch up. As we said hello, I could tell something was really bothering him, so we sat down to talk. Derek told me that at his team’s sprint review the week before, the team members had decided to ask him to resign as their ScrumMaster and to leave the team. He had done so and was looking around within his company to find another Scrum team to join. But the shock of being asked to leave had not yet worn off.

Although rare, Derek’s situation is not unheard of. The question of whether the team has the authority to remove someone from the team is a common topic. Commonly referred to as “voting someone off the island,” removing a team member is not an action to be considered lightly. Before such measures are taken, efforts should be made to address problems that lead some or all team members to feel that they might be better off without one of their members.

A team alone should not have the right to remove someone from the team. If we think back to Chapter 12, “Leading a Self-Organizing Team,” you will recall that self-organization does not occur in a vacuum. The right preconditions must be in place for self-organization to occur. Individuals then self-organize within boundaries established by the organization. This was referred to as the CDE model, which says that for self-organization to occur there must be a container that bounds the individuals, some differences among them, and transforming exchanges. Chapter 12 also made the point that leaders within the organization exert influence on the self-organizing team by adjusting its containers, differences, and exchanges. For example, over time and through attrition a team might have become too homogeneous. An astute product owner, functional manager, or even ScrumMaster might counter that by adding two new team members with radically different backgrounds, skills, decision-making styles, or so on.

Doesn’t it seem possible—likely even, in this example—that a team might have a knee-jerk reaction and vote the new, nonconforming individuals off the team, negating the work of the leader who deliberately added them? Ultimate authority for team composition, therefore, must reside with the leadership of the organization. Those leaders should listen, of course, when team members say they think they’d be more productive without a member. But, team members should not be allowed on their own to remove someone from the team.

Career Paths

Although some employees might be worried about being voted off the team, others will be more worried about the next step in their careers. In most organizations, it has historically been easy to see one’s career path. You developed a reasonable level of technical proficiency, became a team leader over a small group of similarly skilled individuals, then a manager, a senior manager, and so on. At each level up that ladder, you lost a little technical proficiency but had more names under yours on the org chart. The number of people reporting to you could be directly correlated to your importance in the organization.

With the flattening of the organizational chart brought about by Scrum and the elimination of some roles or titles, many employees will wonder what their new career path will be. They will want to know what type of work they’ll be doing down the road and how they (and everyone else) will know that their work has become more valuable. After an organization adopts Scrum, a person’s success can no longer be measured by how many people report to him. It can, however, be measured by how much responsibility the person is given. A new ScrumMaster might, for example, be given responsibility for one small, perhaps mature, team. After successfully handling that situation, this ScrumMaster might work with a different team that has no Scrum experience and is on a more important project. This might continue until our ScrumMaster is working with multiple teams, leading a ScrumMaster community of practice, and so on.

This same career path (success on one project leads to increased responsibility on the next) applies to all roles on a Scrum team, including programmers, testers, designers, and so on. Early in her career, a programmer might be assigned to a team to do little more than code. Later, that programmer might be assigned to another team because we want others to learn from her experience with high-availability websites. Later again, she might be put on a particular team because her problem-solving and interpersonal skills will be needed. Success leads to increased responsibility.

This attitude is prevalent at SAS, a privately owned software development company with over 4,000 employees. SAS has been in the top 20 of Fortune magazine’s Best Companies to Work For list every year the list has been published. An article in the Harvard Business Review describes the motivational culture at SAS.

SAS operates on the belief that invigorating mental work leads to superior performance and, ultimately, better products. It does not try to bribe workers with stock options; it has never offered them. At SAS, the most fitting thanks for a job well done is an even more challenging project. (Florida and Goodnight 2005, 126)

With People Involved, There Will Always Be People Issues

Because software development is an inherently human-intensive activity, there will be people problems. It’s impossible to identify all of them in advance. Those covered here are the ones you are most likely to encounter. Other personnel problems that arise can hopefully be tackled by adhering to the same principles underlying the actions proposed for the obstacles in this section.

Facilities

Any team that has tried to do Scrum in an inappropriate workspace knows how difficult it can be. An ideal workspace will support team members as they learn to work in an agile manner. Unfortunately, there are many less-than-ideal workspaces that actually impede a team’s efforts. In fact, a team’s physical workspace can have so much influence on how it works that Gerald Weinberg has asked, “Who is the most important process person? The one who arranges the furniture” (Dinwiddie 2007, 208).

A team’s physical environment can have so much influence on how agile the team can become that in the second edition of Extreme Programming Explained, Kent Beck and Cynthia Andres elevated an “Informative Workspace” to the level of a primary practice (2004). Given the influence that a team’s physical environment can have on its ability to be agile, in this section we will consider two aspects of that environment: the physical space and the furniture in the space.

The Space

The traditional high-tech office with six-foot (nearly two meter) high cubicle walls is a definite impediment to collaboration. The most common replacement for it among teams that have had input into designing their workspaces is what commercial interior designers call “caves and commons.” This approach combines small, quiet places (caves) with common areas.

A typical pre-Scrum caves-and-commons approach might have included a dedicated cubicle for each employee and a central area containing perhaps a pair of couches, a white board, and a bookshelf. The idea was that employees would meet in the commons area for spontaneous discussions. When given the chance, Scrum teams take this idea but shift the ratio of caves to common space far in favor of common space. A Scrum caves-and-commons workspace will typically forgo the cubicles altogether and feature a large common work area surrounded by a couple of small offices or meeting rooms that can be used by anyone.

The Scrum teams at 3M had this to say about their switch to an open work environment: “We have found an open area wonderful in encouraging impromptu collaboration. Team members can quickly see if other team members are available.” The collaborative spirit and energy inherent in an open area, they say, has energized the team. They conclude: “Designing a team room focused on collaboration has been beneficial to implementing a Scrum work environment and has improved the focus and cohesiveness of the team” (Moore et al. 2007, 176).

A further benefit to this type of open work environment is the ease with which the layout of the area can be changed. As the people on the team are learning how best to work with one another, they often experiment with different arrangements in the space. Additionally, as teams change size, it is beneficial to have the flexibility to reconfigure an open workspace to better accommodate the needs of the team.

The War Room Becomes the Whole Space

Before adopting Scrum, many teams used to lust after a “war room,” which was a conference room the team was given permission to occupy and use for all of its meetings. A dedicated war room becomes less necessary for a Scrum team because its entire open workspace becomes the war room. Daily scrums and other meetings are often held in the openness of the team’s space rather than in a conference room.

One benefit of the traditional war room was that it provided a convenient place for unscheduled meetings to occur. Four team members who suddenly decide to have an extended discussion about an issue could simply walk into the war room without scheduling a meeting on a shared calendar. Because the room belonged to the team, it would almost certainly be available when needed. Scrum teams still require a place for spontaneous meetings. But while this is sometimes still a small conference room dedicated to a team (or shared among a small number of Scrum teams), it is just as often a small table situated in the middle of the team’s open workspace. Whether impromptu meeting space is behind a door or in the shared space depends largely on the team’s preference for hearing all discussions (and being able to opt into or out of them) versus moving lengthy discussions behind a door to keep the space a bit more quiet.

If you are going to take on the work of reconfiguring space to create a large, open area, make sure to include enough room for everyone on the team, including the ScrumMaster and ideally even the product owner. There is nothing worse than collocating all but a handful of team members. Having the designers, for example, sit apart from others will cause resentment. Worse, while team members sitting together bond because of their proximity, those sitting apart will begin to feel like outsiders on their own project.

This is not to say that an entire 100-person project, comprising perhaps a dozen teams, must sit in one extremely large open space. For large projects, the most common, successful approach is to create multiple open areas that can each comfortably house 20 or so people. Three or four teams who are working together can then share such an area. When doing this, be careful to have people sit with their Scrum development teams rather than with their functional teams. Avoid, for example, having all the programmers in the company sit together in a different part of the building than the testers.

Executive Sponsorship Is Helpful

It is, of course, the ScrumMaster’s job to remove any impediments to productivity. And a workspace that hinders communication and teamwork is a definite impediment. However, a ScrumMaster will often need help from the Enterprise Transition Community or an executive in making improvements to the workspace. Scrum trainer Gabrielle Benefield found this to be the case when she led Yahoo!’s transition to Scrum.

An executive sponsor is pretty critical in working with Facilities, as they tend to be very set in their own process and bureaucracy and have a lot of power. You get told no a lot; you just need to keep chipping away and seeing what you can get away with. Some teams were more proactive and simply removed furniture themselves (against company policy) and sometimes got away with it, sometimes not. This is where you need an upper manager to help remove these impediments, as it can be difficult for team members to do this and not jeopardize their jobs. When you get told no you need to find out the real reason behind the answer. Sometimes it’s financial, in which case, see if there’s a cheaper approach or if you can secure funding some other way. If it’s a fire policy, this is pretty much impossible to change. If it’s time or resources, see if you can do it yourselves.

The Furniture

Some teams get very creative with their furniture and are fortunate to be given the budget to go with big ideas. A common approach for teams in this situation is to combine movable desks with a large open workspace. This allows teams to form workspaces in whatever arrangements they see fit. Some teams will prefer to sit facing each other across two-deep desks. Other teams find it unsettling to look at someone else’s face all day and prefer to arrange desks with team members’ backs to one another. Beyond providing the ultimate in ad hoc reconfigurability, movable desks send a powerful message to the team: it literally reinforces the idea that they are to organize themselves—and their workspace—to best develop the product or system they have been asked to produce.

Probably more important than movable desks is the shape and width of the work surfaces. Most good Scrum teams will eventually incorporate some amount of pair programming (or, more generally, pairing of any two team members). Even if they choose to pair on only the most critical tasks, the process can be made much more feasible with an appropriate work surface. Small or curved work surfaces make it difficult for two people to work side-by-side at the same monitor. The problem is made worse when only one person can put his or her legs under the desk.

Sweating the Small Stuff

Attention must be paid even to items much smaller than desks. Phones are a common source of problems. Although it might be easy for a team member to roll a desk from one location to another or to pack and unpack a desk, changing where the phone rings always seems far harder than it should be. Some companies try to get around this with VoIP phones. But the teams that I’ve talked to that have tried this generally report having many of the same problems.

John Cornell, director of agile development at Kofax, experienced an entirely different problem with phones when introducing an open workspace.

The initial plans for the first open space called for office phones that would be shared amongst team members, replacing the individual phones that each person previously had in their cubes. Management did not think this would be an issue as everyone has mobile phone these days and the vast majority of technical staff do not receive business-related calls. The staff strongly felt otherwise. They saw the office phones as critical. Once again, the team members felt that management was inhibiting their ability to be productive.

I’m confident that some of those developers did not have landlines at home and relied entirely on their mobile phones from there. But, I also suspect that some of the team members would have felt like second-class citizens without their phones. Although this was certainly not the message that management intended to send the team, it is easy to see how it would be interpreted that way.

Where Everyone Sits

Where people sit within a shared, open workspace is usually less critical than it is when everyone works in a cubicle. With fewer cubicle walls, everyone can enjoy the view. Frequent pairing keeps people from sitting in the same place all day. And the ability to move from one part of the open space to another (even without movable desks) decreases the sense of permanence.

As the protector of the team, the ScrumMaster often sits closest to the main entry into the team area. Agile coach George Dinwiddie recalls one team where the team’s manager/ScrumMaster acted as a watchdog for the team. One of the developers referred to it as the manager’s “Doberman impression,” so called “because he’d abruptly interrupt his work to halt and interrogate anyone entering the room” (2007, 208). If the manager could provide the needed information, he did so, and the team was protected from an interruption. If not, and the need was genuine, the visitor was granted access to the team’s area.

Items That Should Be Visible in Your Workspace

Now that we’ve considered both the space and furniture of a good Scrum workspace, this section contains a checklist of things that should be visible within the ideal agile workspace.

• Big, Visible Charts. A good Scrum team will fill its workspace with a variety of big, visible charts. One of the most common is the sprint burn-down chart, showing the number of hours remaining as of each day of the current sprint. Charts like these provide a strong visual reminder of the current state of the project. What is shown on these charts will get the attention of team members, so consider varying the information to showcase what is most important for that sprint. Ron Jeffries suggests a variety of charts, including ones that show the number of passing customer acceptance tests, the pass/fail status of tests by day, sprint and release burn-down charts, number of new stories introduced to the product backlog per sprint, and more (2004a).

• Additional feedback devices. In addition to big, visible charts, it is common for a Scrum team to use additional visual feedback devices in their workspace. One of the most common is a lava lamp that is turned on whenever the automated build is broken. I’ve also worked with teams that use flashing red traffic lights to indicate exceptional conditions, such as an issue on a production server. LED signs can be programmed to display messages from Twitter. Also popular are ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires. Software architect Johannes Brodwall exhibits the agile preference for simple solutions and recommends using USB-connected devices, such as those from Delcom, which he has used to monitor testing, staging, and production servers (2008). Devices like these make a workspace more lively, unobtrusively bringing into it information the team might find helpful.

• Everyone on your team. Each person on the team should ideally be able to see every other person on the team. This absolutely includes the Scrum-Master and ideally includes the product owner. I do understand, however, that product owners often have responsibilities to other groups outside the development team and so might sit near them instead. Still, in an ideal world the product owner would be visible to everyone in the team workspace.

• The sprint backlog. One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible. The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board. A task board is usually oriented in rows and columns, with each row containing a particular user story and one index card or sticky note for each task involved in that story. An example can be seen in Figure 20.1. Task cards are organized in columns, minimally including To Do, In Process, and Done.¹ Task boards allow team members to see at a glance how work is progressing and all the work left to be done.

1 For photos of various task boards, see http://www.succeedingwithagile.com.

Figure 20.1 A task board makes the sprint backlog highly visible.

• The product backlog. One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities. A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible. This can be as simple as keeping the shoebox full of user-story index cards on a table in the middle of the team’s space. Even better, tack the index cards of upcoming user stories on a wall where all can see them. This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.

• At least one big whiteboard. Every team needs at least one big white-board. Locating this in the team’s common workspace encourages spontaneous meetings. One developer might start using the board to think through a problem; others might notice and offer to help.

• Someplace quiet and private. As important as open communication is, there are times when someone needs some peace and quiet. Sometimes this is for something as simple as a private phone call. Other times it can be to think through a particularly challenging problem without being interrupted.

• Food and drink. It’s always a good idea to have food and drink available. These don’t need to be fancy, and they don’t even need to be provided by the organization. I’ve worked with plenty of teams that buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it. Other teams buy a coffee machine. Some teams rotate bringing in snacks, both healthful and not.

• A window. Windows are often a scarce commodity and are doled out to an organization’s favored employees. One of the nice things about an open workspace is that windows are shared. Even if the view is of the parking lot and can only be seen across three messy desks, it’s nice to be able to see the window and some natural light.

The Project Management Office

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 practices 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.

One of the reasons why the natural response of most people in the PMO is to resist the change to Scrum is that much of it is personally and professionally frightening. Scrum scatters traditional project management responsibilities among the ScrumMaster, product owner, and the team, leaving project managers to wonder what their role is. The absence of the PMO in most Scrum and agile literature adds to the natural concerns of PMO members.

In this section, 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.

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 a tremendous aid 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 them 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 fill on its own. The PMO should identify and develop coaches by watching the 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 teams who are falling back into old habits or whose old habits are preventing them from becoming agile. Later, members of the PMO can remind teams that Scrum is about continuous improvement and can help prevent the onset of complacency.

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 weekly report or meeting 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. But 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 things an agile PMO can do is assist in managing the rate at which new projects flow into the development organization. As described in Chapter 10, “Team Structure,” 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.

Process

As keepers of the process, members of the PMO will find themselves working 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:

• Provide and maintain tools. In general, tool decisions should be left to individual teams whenever possible. When not, a community of practice might decide that there are sufficient benefits to choosing one tool for all projects. As a last resort, tool decisions might 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.

• 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. One of the most important things an agile PMO can do is to help encourage the formation of communities of practice 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.

• 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 its usefulness as a general-purpose project management framework. At that point, many 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 a great assistance to teams in working with other groups, especially human resources and facilities, as already described in this chapter.

Renaming the PMO

Many PMOs choose to rename themselves to better match their revised role. There is no one standard name, but I’ve heard these most frequently:

• Scrum Center of Excellence

• Scrum Competence Center

• Scrum Office

• Development Support

In Chapter 2, “ADAPTing to Scrum,” I cautioned against naming the effort to adopt Scrum. 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—PMO, Scrum Center of Excellence, or so on—to succeed with Scrum, the PMO that supported the organization’s sequential development process will need to change more than just its name. But as this section has pointed out, there is a great deal an agile PMO can bring to the organization.

The Bottom Line

You can ignore the implications of Scrum on these groups and be successful—for awhile. Eventually, though, you will need to engage with these groups to create a successful, long-term transition. It is almost farcical to think of adopting a process founded on a preference for “individuals and interactions over process and tools” without engaging the human resources department. In the typical organization, this group might have even more influence on how people perceive their jobs and act in them than do those individuals’ functional managers.

Similarly, the physical environment in which we work has a direct influence on us. Consider the conflicting messages sent when a company proclaims “people are our greatest asset” while the facilities group prohibits hanging burndown charts on the walls. The real message is loud and clear: “The walls are a greater asset.”

A PMO often has tremendous political clout and project experience. By getting this part of the organization on board with Scrum, not only do you avoid a possible source of resistance, you also benefit from their experience. Members of the PMO become guardians of self-organization, continuous improvement, ownership, communication, experimentation, collaboration, and other values.

It’s easy to view human resources, facilities, and the project management office as obstacles to be overcome. A more productive approach is to view each as an ally to be enlisted. Though an adversarial relationship might work for a while, long-term success requires the support of the entire organization. The road to becoming agile can be a long one; when you can, choose to make friends, rather than enemies.

Additional Reading

Cockburn, Alistair. 2006. Agile software development: The cooperative game. 2nd ed. Addison-Wesley Professional.

In this Jolt Award-winning book, Cockburn covers a wide variety of topics, but Chapter 3, “Communicating, Cooperating Teams,” is essential reading. This chapter includes wonderful information on the impact of the physical environment on the project team. This chapter from the first edition is available online at www.informit.com/articles/article.aspx?p=24486. Do yourself a favor, though, and pick up the entire book.

Jeffries, Ron. 2004. Big visible charts. XP, October 20. http://www.xprogramming.com/xpmag/BigVisibleCharts.htm.

An excellent description of some of the big, visible charts that should be found in an agile team’s workspace.

Nickols, Fred. 1997. Don’t redesign your company’s performance appraisal system, scrap it! Corporate University Review, May–June.

There are many great references about the evils of periodic performance reviews. This is a good starting point because of its brevity and the strength of the arguments.

Seffernick, Thomas R. 2007. Enabling agile in a large organization: Our journey down the yellow brick road. In Proceedings of the Agile 2007 Conference, ed. Jutta Eckstein, Frank Maurer, Rachel Davies, Grigori Melnik, and Gary Pollice, 200–206. IEEE Computer Society.

Seffernick describes the successful transition to an agile PMO at KeyCorp, a large financial institution with 1,500 people in its development organization. Included is how the pre-agile PMO was stripped to a core set of members, with others returning to the development teams, and how the PMO reinvented itself as the Software Development Support Center.

Tengshe, Ash, and Scott Noble. 2007. Establishing the agile PMO: Managing variability across projects and portfolios. In Proceedings of the Agile 2007 Conference, ed. Jutta Eckstein, Frank Maurer, Rachel Davies, Grigori Melnik, and Gary Pollice, 188–193. IEEE Computer Society.

Tengshe and Noble established the agile project management office at Capital One Auto Finance. This paper describes their experience doing so and provides good advice for transitioning a PMO from traditional to agile.