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.