In many ways, agile principles seem antithetical to how Project-Management Office (PMO) systems operate. While PMOs exemplify structure, management and governance, agile developers focus on, well, agility. They plan in small increments, work quickly to solve immediate problems, and then move on to the next ones. This lends itself to a classic agile/PMO tug of war.
Still, many organizations are now marrying traditional PMO practices associated with allocation, planning and financial measurement to development teams following agile development practices. I’ve written in the past about water-Scrum-fall and how as agile crosses the chasm to be mainstream, the reality of modern development is a hybrid of traditional approaches and agile development. The first part of the phrase “water-Scrum” references the marriage between traditional planning and reporting life cycles with agile- or Scrum-based processes.
There are some in the agile community who say that the only way to create an agile enterprise is to discard all traditional planning models and embrace an approach that marries agile teams to the business through a “product owner,” allowing them to directly deliver business value in response to business need. Planning is done by the agile team at the business level, allocating development resources by business priority. The role of the PMO is removed, because the business plans the work, thus negating the need for a middleman.
But the reality is that “the business” is much more complex than one group, and the supporting applications are a spider’s web of interconnected, disparate systems. There is the need to manage the spider’s web, allowing agile teams to serve one set of objectives while managing the large number of cross-team dependencies. The PMOs and the practices they provide enable teams to bridge the gap between agile teams, focused on clear business and complex portfolio release problems. But it does require some level of structure and discipline.
Moving to a disciplined approach
Ironically, for many organizations the adoption of agile at scale requires them to introduce more rather than less discipline. Existing “traditional” processes provided only a limited amount of structure. They encouraged certain meetings and artifacts, but because they did not mirror the reality of modern software development and did not support the level of chaos created by software development. Often they require very skilled project managers or PMO staff to marry the processes together with manual, e-mail-heavy, spreadsheet-centric practices.
This knitting process happened at least twice: once in the translation of the portfolio plan to development activities, and second when status reporting is required. These heroes buzz around the collection of teams, setting them in the right direction and helping them report statuses in a way that makes sense to the original plan. But with agile, that process is bound to fail.
Not only do agile teams need to have a clear direction at the start, but work their work needs to be grouped into much smaller batch sizes, encouraging more frequent feedback into the portfolio. That means that the PMO heroes will become a friction point in the process, either greatly reducing the effectiveness of the development teams, or having to increase their workload. The reality is these roles burn out, or the agile teams get so frustrated that they ignore the PMO, providing limited information back to the PMO. This lack of information results in lack of planning of foresight, leading to last-minute decisions and lots of emergencies.
Instead, smart organizations are actually stepping up their game and putting in place an automated, disciplined process that enables agile teams and the PMO to work together. It requires a definition of what various artifacts mean and how those artifacts map together. For example, does development actually have a one to one mapping of projects to the PMO projects, or is a project just a backlog fed by many projects? By making real, implementable decisions about how the life cycles connect and then automating them, teams not only allow for frequent reporting, but also ensure that work flows from planning to development. It also enables—often for the first time—the ability to change a plan based on real feedback and data.
Resource management: Different, but manageable
It’s true that agile teams do not like to think in terms of people, instead focusing on team capability (known as velocity). But at the end of the day, people cost money and need to be accounted for.
One key debate when discussing the interaction between development teams and the PMO is the role of the resource and how timesheets fit into the model. And, the answer is that it depends, but you have to pick one model and follow it consistently. For some organizations, work comes in, is planned by the PMO, allocated to people, and those people happen to be in teams working in an agile way. Thus, tasks in PPM tools relate to stories in the development tool and work is defined by the story, time is tracked in that context. But it’s different for other organizations. For them, work is not really planned in detail within the PMO.
Instead, it is allocated to a team based on some sizing metric. That work is then planned in the development/agile tool of choice, stories are broken down into tasks, and those tasks are estimated so that development teams can work on them. All of that information is then passed back to the PMO, allowing a reconciliation of the original plan to the work in progress. Of course there are many variations on these two planning themes, but that is OK as long as the organization, or at least the team, does it consistently. Also, the different levels of planning can be taken advantage of, allowing an iterative, cross-life-cycle planning model.
The bottom line is that agile has grown up. I’ve spoken to many people who traditionally were anti-agile, but are now discussing not only the problems of agile development, but how they can make it work within the constraints of their existing planning, reporting and accounting processes as well.
Still, challenges remain both on scaling agile and connecting the water-scrum part of the life cycle. Fortunately, in addition to getting people and processes in alignment, we’re now seeing development teams take advantage of the third leg: tools to support the process. For example, high-level business requirements that PMOs create can be transferred to a development team’s tools, where they are translated into implementable user stories. And timesheet data that the PMO wants to collect can be auto-filled from information provided by the developer’s tools.
As a result, we’re at the point where we can move our tug-of-war participants from opposite ends to the same side of the rope. This means development teams engaged in agile practices, working in harmony with the PMO.
