An agile PMO transformation

For many organizations, using the words “PMO” and “agile” in the same sentence could be considered an oxymoron. Bringing “agility” into your project management office may be a challenge—depending on how much your organization has already invested in your current processes and how open you are to consider making “transformative” changes to support the organization's move to agile. If you're from the PMO, keep an open mind as you read some of the points in this paper as the ideas challenge traditional methods of thinking and execution. We'll discuss the top eight impediments faced during an enterprise-level agile transformation, as well as what we think the new role of the agile PMO should be to support a successful agile transformation.

THE AGILE PMO: TOP 8 DON'Ts

Let's cut right to the chase. While working in many organizations that seek a true enterprise-level agile transformation, we have encountered some key barriers in each that we believe only the PMO along with the executive team can truly influence.

1. Don't Equate Activity to Progress

Many organizations think that activity equals progress, so they start as many projects as possible with the hope that something gets done. They truly believe they will achieve more by multitasking (i.e., assigning resources to many initiatives at the same time). We call this the “false illusion of making progress.” Activity does not equal progress, and, in fact, more projects started simultaneously results in the completion of fewer projects.

There is a very popular game we play during our agile workshops called the “multitasking name game” (see Figure 1).

Figure 1 – The multitasking name game.

This simple game demonstrates very clearly the cost of multitasking. The goal of the game is to have one project manager (let's call her Amy) complete projects for four customers. The “project” in this case is to write down a four-letter name from each of the customers, with each customer providing one letter at a time. As an example, the first customer who wants Amy to write down the name “John” would provide it as “J - O - H - N.” We then record the time it takes Amy, our multitasking project manager, to write all four names out as the customers provide them. The game goes through three iterations as described below:

• Iteration 1. No customer shall wait. Every customer in this iteration is a high priority and thus, Amy, our unfortunate multitasking person, needs to listen to several requirements (letters) from different customers at the same time. Usually, the customer “who screams the loudest” (WSTL) wins (Customer 3 in this case). As you can see from Figure 1, this iteration results in several defects as well as frustrated customers who don't feel that Amy paid enough attention to them. Amy and her team are also frustrated and overwhelmed since they couldn't make anyone happy.
• Iteration 2. Each customer has a turn. In the second iteration, we decide to be fair and allow each customer to provide one requirement at a time (a single letter in this case); then Amy moves on to satisfying one requirement from the next customer. Amy feels more sanity in this iteration, and the customers feel the process is more predictable. However, she can't complete any project until the very end. As shown in Figure 1, this iteration has long time-to-market wait times.
• Iteration 3. One customer at a time, ranked by value. In the third iteration, we ask the customers to prioritize the backlog based on the value of their projects. We explain that their projects would be done faster if we limit the work in progress (WIP) and allow Amy to focus on getting one project done at a time before she “pulls” the next one. As you can see, the numbers speak for themselves. Amy satisfies all customers in record time with no defects and a speed of about five to six seconds per customer. Amy even completes the last customer project before many of the others in the previous scenarios. Time to market is excellent, and customers are happy to have Amy's focus.

So why go through this example in so much detail? Well, this simple game has been transformative for many executives and PMO leaders who understand at a gut level the reality and cost of multitasking. These “players” were happy to see a clear illustration of how cost, frustration, defects, and time to market impact an enterprise in one simple activity.

2. Don't Prioritize Full Resource Utilization over Project Delivery/Velocity

The root cause of multitasking is that many organizations don't have a clear view of their enterprise capacity. Many PMOs look at capacity in a manner similar to that shown in Table 1. The focus here is on tracking capacity at the resource level and attempting to maximize resource assignment to projects based on hours. While tracking hours is beneficial for cost measurement, we've found that too many PMOs and resource managers believe that splitting someone (such as Adam or William in the example in Table 1) across several different priorities somehow adds up to 100%. They don't understand the impact on the enterprise with such cross-project allocation and shuffling. In most cases, this “push” to maximize resource utilization results in the completion of less valuable work.

Table 1 – Example PMO Capacity View

3. Don't Start All Your High-Priority Projects at the Same Time

If you ask your customers, most if not all of their projects are “high” priority. Rarely does anyone, including the PMO, want to tell someone “no” to his or her great project idea. Usually, the popular prioritization and approval method of WSTL is in effect, and there is no process in place to determine the true strategic value of any initiative. Ideas are approved, project managers are assigned, and then those project managers attempt to beg, borrow, or steal resources assigned to other teams to form their project team—or the organization assigns the same three key resources to every approved project.

4. Don't Allow Unapproved Projects to Start or Continue

In many organizations, teams seem to begin projects regardless of whether their executives have officially approved them. It would be interesting for such organizations to build a list of all their active projects—which is a hard undertaking—and determine how they were initiated and if they align with the organization's strategic objectives. Many times, we've found a large disconnect in alignment between projects in execution and what executives hope or assume their teams are working on. Root causes include projects started with multiple entry paths, projects begun due to staff availability, and, sometimes, projects resulting from PMOs that have such heavy idea-qualification processes that the projects get bypassed by business owners (they request an “exception”). Or, similar to Don't #3 above, nobody wants to say “no,” thus all projects are approved as high priority.

5. Don't Prioritize Processes and Forms over Delivering Value

Some PMOs talk about becoming agile but find themselves stuck in a very non-agile mindset and not ready to let go of any traditional processes or documentation: “Sure you can run an agile project as long as you complete all the requisite forms and deliverables for each step in our (waterfall) SDLC,” or, “Yes you can be agile but you still need to attend the two-hour weekly status meeting.” We're not advocating that agile teams bypass processes and forms. Rather, PMOs must review these processes and documentation from a value perspective, and should make decisions around simplifying or eliminating those with the least value.

6. Don't Use the Command-and-Control Leadership Style

This is a rather serious issue. In many cases, the PMO, and sometimes the entire leadership team, has operated with a command-and-control leadership style for years. Project team members often view this top–down mindset as the PMO trying to control all agile teams. Specific behaviors could include: dictating to teams versus letting teams self-organize; pressuring teams to perform at a higher velocity, comparing team velocity among the teams; making unilateral changes to team members, including ScrumMasters; or using any other direct-control method that undermines the team's ability to self-organize and perform.

7. Don't Think You Can “Do Agile” Without Training or Coaching

In some organizations, there is a lack of true understanding and buy-in to agile. Management tells teams to “do agile,” but they expect those teams to learn on their own, read a book, or follow the company's “Agile Guide.” The problem is that agile is a mindset shift more than it's about learning specific practices and tools. This lack of education and coaching could result in teams giving agile lip service, or adopting only a few techniques, such as the daily stand-up meeting, and then proclaiming to be agile. The other issue is that each team begins to create its own processes (e.g., some teams skip planning and iteration zero all together), and many begin to revert back to form, which slowly begins to erode the effectiveness of an enterprise agile transformation.

8. Don't Focus on Agile Techniques and Ignore the “People and Culture” Transformation

We've seen many organizations that have invested in agile learning for their teams, but few that have also invested in the “people” side of the transformation. Agile requires soft skills in servant leadership, collaboration, conflict resolution, and effective facilitation to support the creation of high-performance, cross-functional teams. Understanding that an Agile Transformation requires cultural change management and having a plan for this early will set you on a successful path.

You may be thinking that you have experienced some or many of these don'ts in your own organization. Left ignored, these don'ts will become impediments—or, at least, significant challenges as your organization move toward enterprise agile adoption. The first two don'ts (project multitasking and lack of enterprise capacity measurement) are hands down the most significant impediments and also the ones with the “biggest bang for the buck” in terms of the value achieved by addressing them.

THE NEW AGILE PMO ROLE: TOP 8 DOs

Let's take a look at the flip side of many of these issues: the things that agile PMOs should do to support true enterprise agile adoption.

1. Do Create a Ranked Enterprise Backlog That Teams Can Pull From

The idea here is that all projects go through a value assignment and ranking system, from top to bottom. To create your ranked enterprise backlog, take these four steps:

1. Gather your current projects in execution along with a list of future qualified candidates into one list or backlog.
2. Go through this list to see which projects align with your yearly vision, objectives, and goals. (Note: this assumes your executives have provided you with a strategic direction.)
3. Determine an objective method for allocating business value that is better than the WSTL method. (In a future Update, we'll be sharing an agile method that uses business value points.)
4. Rank all candidate projects from first (top of the list) to last (bottom of the list) based on business value, risk, and dependency. For example, a low-value, government-mandated project may have high risk due to a pending deadline; this may push it higher on the backlog. Some organizations use weighting of these factors and some use other factors. In any case, you should rank the final backlog literally from top to bottom, based on criteria set by the organization.

2. Do Facilitate Enterprise Backlog “Grooming” with Executive Leaders

“Grooming” is an agile term for revising, cleaning up, and prioritizing. The idea is to establish a cross-functional enterprise backlog grooming leadership team that determines the order in which the enterprise will complete projects. This team will also be accountable for limiting WIP and maximizing value delivered by the enterprise execution teams. Traditionally, PMOs ran this entire function by themselves. When moving to agile, we suggest

• Using the PMO as a facilitator (or enterprise ScrumMaster) that engages a core group of executive steering committee members to frequently make decisions that move projects/deliverables up or down the backlog, removing those with no value or stopping those in progress when needed.
• Putting up a big Kanban wall (physically or electronically) that tracks the current backlog of strategic initiatives and where they are in their lifecycles, showing the stable team executing the project and providing visibility into any major impediments.

3. Do Define and Gain Consensus on an Idea-Qualification Filter

Organizations need to develop a single point of entry for all ideas needing qualification. They should define and gain consensus on a common qualification filter in order to determine if any particular idea is worth investigating more, which means approving it for initiation. If the idea passes initiation and approval, prioritize it on the backlog. Don't allow it to go immediately into execution! Not prioritizing is the root cause and source of multitasking. For example, here are some agile filter questions that could help determine if a project/idea is qualified:

• Does this idea align with our current strategic goals?
• Does it deliver measurable business value?
• Does it have the “right” committed product owner who is willing to engage with the team?
• Does it have a roadmap and has it been broken down into three-to-six month deliverables?
• Is it feasible? Do we have the technology, skills, tools, and resources to support it?
• Did it get enough “confidence votes” by our team?

4. Do Establish Stable Cross-Functional Teams and Communities of Practice

This may seem like an impossible task at first, but we promise it will be worth the effort. Begin by keeping your existing cross-functional project teams together. This means you shouldn't break them up at the completion of their project; instead, let them pull the next-highest-priority deliverable from the enterprise backlog on which they are qualified to work. The team may need some tweaking of roles based on the new deliverables (perhaps even the addition of a new business SME or analyst with a specialty in that area). When you're ready to take a stab at designing stable enterprise teams, schedule a couple of days for this activity, prepare a structured agenda, and invite the right people from both management and the functional team to contribute.

Communities of practice are similar to your traditional “functional” teams. However, instead of a project management or business analyst team, you may have an enterprise requirements community of practice, where anyone interested in this subject can participate and generate backlog ideas for improving requirements across all teams. Resource managers can become product owners of these communities and various members typically rotate the facilitation of the activities.

5. Do Measure Enterprise Capacity by Team and Velocity, Instead of Resource and Hours

This is where you'll need to keep an open mind, since this recommendation goes against the traditional view of capacity. Velocity is a measure of the amount of work completed in a sprint or iteration. Agile teams use their average iteration velocity to project how much work they might complete in the future. Similarly, you can use the organization's average velocity per quarter to estimate how much work it can complete in the upcoming quarters.

Measuring enterprise capacity requires the establishment of stable teams, as noted in Do #4. You will also need to have processes in place to measure and track velocity by team. Allow the teams to execute for at least a quarter and determine their average velocity (see Table 2). (Note: do not compare team velocity. Doing any kind of comparison of velocity among teams will result in teams “gaming the system” to make their performance look better.)

Table 2 – Example Average Velocity of Teams

6. Do Learn and Adopt Agile Servant Leadership

Agile teams are high-performing, self-organizing teams that can predictably deliver high business value. To unlock their potential, the organization needs a style of leadership that empowers the team and encourages self-leadership. This style looks closer to servant leadership, rather than the more traditional command-and-control style. The role of any leader, including the PMO, is to set a clear vision, define necessary boundaries, and then empower the team to self-organize around completing work. The PMO and leadership team should be listening, removing organizational impediments, and identifying ways to help support the team—not dictating or imposing solutions. We highly recommend that all department managers, PMO leaders, and senior executives invest in learning more about servant leadership.

7. Do Invest in Agile Training and Coaching

We've seen too many companies face major challenges and churn with their agile adoption due to not investing in agile education and coaching. Agile methods require a different mindset since they challenge how we've done things before and force us to look differently at our relationships and how we collaborate with others. Agile also challenges our fundamental understanding of planning, sizing, progress, and what we value. Lack of initial training and coaching often leads to the following:

• Teams and managers giving lip service to agile, but not really buying in.
• Teams applying agile practices, but executing with a waterfall mindset.
• Teams applying agile inconsistently. (While we wouldn't expect different teams to operate exactly the same, they should be similar in their agile adoption.)
• Teams experiencing churn and struggles with applying agile, resorting to applying only a few techniques and reverting back to form, or saying, “Agile doesn't work for us.”

8. Do Lead the Organization's Agile Transformation

It may come as a surprise to expect the PMO to lead the agile transformation, but we think that for organizations to reach the full potential of the approaches outlined in this update, such as managing the enterprise-level portfolio and creating stable teams, the PMO will need to be engaged and lead the way. The biggest impediment to the PMO's success with driving the agile transformation is rigid adherence to previous
processes/documentation/templates/metrics and a heavy-handed leadership style. If the PMO can keep an open mind and engage the right executive team (from IT, business, finance, and HR) to create a champion enterprise agile team, then the transformation will be set up for success.

SUMMARY

Influencing the success of an enterprise agile transformation will require flexibility, trust, and a willingness to change the way the organization delivers value. PMOs will have to choose between “talking agile” and “being agile.” If PMOs are ready and willing to transform, they can greatly influence the success of their organization's agile transformation. Stayed tuned for upcoming updates on agile portfolio planning with Kanban, a six-month roadmap on enterprise agile transformation, and designing stable agile teams.

*This paper originally appeared in the Cutter Consortium Agile Product & Project Management Advisory Service. Vol. 13, No. 8. Reprinted with permission. To download an electronic copy of the article in PDF format, visit www.cutter.com/offers/agilepmo.html.

About Sally Elatta

Sally Elatta is the President of Agile Transformations and a dynamic coach, trainer, and public speaker. She is passionate about transforming individuals, teams, and organizations into improving project management and software development practices and delivering business value early and often. Ms. Elatta has trained thousands of individuals and has coached several mid-sized and Fortune 500 organizations on adopting Agile and Scrum methods. Sally is also the publisher of a library of videos on AgileVideos.com that enable organizations to scale and accelerate agile transformation. Ms. Elatta is a Certified ScrumMaster, Scrum Practitioner, and holds the PMI-ACP Agile certification. She can be reached at [email protected].

About Anthony Mersino

Anthony Mersino is an Agile Coach and Agile PMO consultant specializing in helping project teams and organizations reach their full potential. He has deep experience in project and program management and has started and led several PMOs. Mr. Mersino has also helped train and coach Fortune 500 organizations through their enterprise agile transformation. He is the author of Emotional Intelligence for Project Managers; the People Skills You Need to Succeed. Mr. Mersino has an MBA and holds PMP and PMI-ACP certifications. He can be reached at [email protected].