The Agile PMO
The topic of an Agile PMO is a top of mind discussion. In recent years agile and PMO, when used in the same sentence, referred more to how PMO groups were helping their project teams resource agile skills but within the last eighteen months two words have found themselves linked more closely as PMO groups are looking to adopt agile and lean practices within their own functions including traditional portfolio management and SDLC frameworks. This article touches on a number of trends and real-world outcomes we’ve been a part of in relation to helping PMO groups advance.
Traditional PMO vs Agile PMO
Traditional PMO practices are fundamentally incompatible with agile because they are based on an entirely different set of premises. There is a wealth of evidence that combining agile delivery with a traditional PMO approach (and/or other traditional organizational practices) leads to big problems:
- Entrenched habits and existing processes often thwart change efforts.
- Failing to change wider organizational capabilities leaves agile teams unable to reap the benefits of faster delivery (Ref: HM Government Faster Delivery Report).
- Surveys have indicated that organizational conflict; resistance to change and non-agile frameworks are the number one barrier to adoption of agile practices (Ref: Survey & Leffingwell).
Organizations need a consistent Agile PMO to align and create visibility across the organization and remove barriers to delivering the most valuable ideas and policies quickly to market.
Agile PMO principles
By contrast to the current PMO, an Agile PMO would take a dynamic and adaptive approach based on these principles:
The fundamental goal is to assure delivery of maximum value for the time and money available with minimum risk while quickly responding to changing business needs across the portfolio.
- Maximizing value is done through the dynamic and continual prioritization of work based on live and visible measures of value-for-money, time sensitivity and risk.
- Risks are minimized and strong governance is provided through making work constantly visible and bringing the right people together early and often to take rapid decisions.
- Breaking down big projects into smaller, more frequently delivered pieces allows organizations to respond far better to changing business needs.
This goal is facilitated by ensuring there is close collaboration between the Agile PMO and key stakeholders from the business and IT. This approach will help to promote innovative solutions.
Day-to-day Agile PMO activities and focus are quite different
The key approach with an Agile PMO is not to manage and control teams in a traditional command-and-control top-down style, but instead work as part of service teams to:
- Enable and support the formation of sustainable teams that focus on delivering policies and improvements with more value, faster flow and better quality.
- Manage demand through facilitating objective prioritization of work based on value-for-money, time sensitivity and risk.
- Support and facilitate decision-making at key points around the existing P/SDLC, based on Feasibility, Viability, Desirability.
- Identify and eliminate obstacles for delivery teams, including wider organizational issues that are barriers to incremental delivery.
- Track and ensure strategic objectives are delivered across a combination of delivery teams and identify and help resolve dependency conflicts that cut across those teams.
- Use highly visual work management tools to efficiently connect senior management and the executive directly to work without expensive overheads of traditional reporting and review meetings.
- Produce and maintain a dashboard of leading strategic metrics (e.g. value delivered, operational impact, overall speed, quality and cost of delivery, lead time for delivery of urgent needs).
All of this looks and functions quite differently to traditional PMO approaches (Ref: CMU DoD & Mountain Goat).
Shifts in Agile PMO organizational structure and function
There are examples where the Agile PMO would not perform these functions:
It is not involved in approving funding for projects – organizations are moving to a business service aligned approach meaning that funding is decoupled from the work. Instead the maximum value is delivered in each service area for the funding available (no more “wooden” money moving around). Agile business cases are approved based on understanding of the required benefits, and confidence that an optimal solution can be delivered within time and cost constraints. Uncertainty is understood, accepted and managed.
- It is not involved in allocating resources against teams – organizations are moving to a structure of cross-functional business service aligned teams. With this structure, low-level resource management is no longer necessary because persistent teams sit and work together. Resource management simplifies to strategic questions of the number of teams and overall skill mix across disciplines.
- It is not involved in tracking, managing or reporting the day-to-day progress of delivery teams – this is provided by the teams themselves using simple visual approaches. PMO no longer need to go and find out what is happening, data is visible live and continuously from all teams to the PMO and whole organization.
- It does not define, manage or tamper with the delivery team processes or how they work. Nor does it enforce deadlines. Teams work with a predictable cadence and with highly visible progress.
- It is not a go-between for policy / operations and delivery. Agile delivery approaches already promote close relationships between all stakeholders and relevant groups. The Agile PMO role is to therefore enable, facilitate and foster this effective cooperation, collaboration and communication, but not to be the conduit, messenger or part of every conversation.
Supporting Evidence
In industry, it is accepted that the introduction of new practices and ways of working can be a significant challenge to the organizational DNA. For example when Silicone Engineering firm Dow Corning wanted to introduce a dramatically different approach to product development, the CEO appointed executive set up an experimental war game to test how existing staff and systems would react to the new customer value proposition. He got crushed as entrenched habits and existing processes thwarted any attempt to change the game.[1]
Similarly, Agile delivery brings a set of environmental requirements and skills often at odds with traditional methods of managing change and investment. In agile transformation care is needed to ensure that Agile benefits aren’t similarly ‘crushed by entrenched habits and existing processes’ within the organization.
As stated in the HM Government | Agile Faster Delivery Report:
It is important to recognize 3 distinct areas of capability required to reap the benefits of faster delivery:
- Team Capability – the ability for teams to effectively work together and apply principles of faster delivery, to demonstrate skills relevant to their roles, and to work within frameworks such as Scrum or Kanban.
- Organizational Capability – the ability of the surrounding organization to enable, rather than oppose faster ways of working and multi-release delivery.
- Technical / Supplier Capability – the ability to take advantage of 21st century technical skills, platforms and practices to be able to deliver, deploy and update solutions quickly.
Without all three elements taken into consideration it is unlikely that benefits will be realized. Simply training a team of people while ignoring the Organizational Norms and Technical / Supply relationships is unlikely to yield the benefits hoped for. Similarly, having a highly capable agile supplier, but not having team or organizational capability to work in a compatible way isn’t going to be effective.
Repeated experience has shown that this conflict is ignored at peril. A survey[2] of over 4000 individuals in 2012 cited organizational conflict, resistance to change and non-agile frameworks as the number one barriers to adoption of agile practices. The PMO is often cited as an area where the conflict of culture, practice and controls is acute:
“Many ‘impediments’ rise to a ceiling that is beyond the control of the teams. Sometimes the ceiling is represented by the PMO, a place many…perceive to be ‘the mother ship of all impediments’”
Dean Leffingwell: Agile Software Requirements (Addison-Wesley 2010)
When these conflicts aren’t addressed it both delays and frustrates the benefits of agile approaches, and dilutes the value that traditional PMO and other assurance bodies can bring. This has been evidenced in several organizations in private and public sectors.
2010 Carnegie Mellon report Commissioned by the US Dept for Defence summarizes some key issues well:
The PMO specifically needs to realize that while Agile provides many benefits, many of the traditional Waterfall activities, documents, etc. will not be present. In some cases, the data will be present but not in the anticipated form.Historically, the PMO’s role is to ensure orderly development progress, but with Agile the PMO has to relinquish control over how change is managed. Agile attacks high-value and/or high-risk user items first instead of making steady progress on all requirements. This difference in handling requirements can create unnecessary friction between the PMO and the contractor, leading to outright hostility.
Traditional Waterfall provides significant oversight and insight into the implementation details of the program; this method is very structured so that it provides predictability, stability, and high assurance. The execution of Agile is distinctly different from what the PMO has seen in the past on programs using Waterfall. The control and discipline comes from the Agile team itself rather than from control external to the team, that is project and higher management. As a result, the PMO will see a different way that the development is controlled, executed, and viewed.
We learned from our interviews that the PMO has to be prepared to relinquish some level of control and oversight of the program to allow Agile to operate effectively. What is needed is a system of program metrics that allows the PMO to have insight into the developer’s priorities and the development progress being made on a day-to-day basis, and this will allow the PMO to achieve an optimal balance between insight and oversight.
Traditional methods have well-defined oversight methods. Agile oversight methods are less defined and require more flexible oversight to accommodate the fluidity of Agile implementation. Resolution of the specific type of oversight needs to be done in advance. One aspect of the Agile management philosophy is that the primary role of manager is more of a team advocate than overseer. The management function of roadblock remover is critical to the success of an Agile team.
The composition of the PMO staff might look somewhat different in order to accommodate the use of Agile. While Agile concepts may not be new, the subtleties and nuances of each Agile method can be new to the uninformed PMO. To overcome this, train the PMO staff before starting and employ an experienced coach or knowledgeable advocate for the PMO to help guide them throughout the process. It is important to set aside funding for initial and ongoing training and support.
The overall organizational culture needs to support the Agile methodology in use. The Agile culture is counter to the traditional Waterfall culture in everything from oversight and team structure to end user interaction throughout development. This will require a mindset change for the PMO and other government entities such as OSD. In order to employ any of the Agile concepts, the DoD organization will have to plan for them, anticipate the changes needed in their environment and business model, and apply the hard work to make the changes a reality. Organizational change management is essential during the transition to Agile.
Project Management in an agile setting also functions in quite a different way:
Traditional project managers take on a great deal of responsibility. They are responsible for managing scope, cost, quality, personnel, communication, risk, procurement, and more. This has often put the traditional project manager in a difficult position—told, for example, to make scope/schedule tradeoff decisions but knowing that a product manager or customer might second-guess those decisions if the project went poorly.Agile processes acknowledge this difficult position and distribute the traditional project manager’s responsibilities. Many of these duties, such as task assignment and day-to-day project decisions, revert back to the team, where they rightfully belong. Responsibility for scope/schedule tradeoffs goes to the product owner. Quality management becomes a responsibility shared among the team, product owner, and ScrumMaster. Other traditional project management responsibilities are similarly given to one or more of these agile roles.
Source: http://www.mountaingoatsoftware.com/topics/agile-project-management
[1] Harvard Business Review, December 2008
[2] Version One, 7th Annual State of Agile Development Survey
Additional Insights
The importance of owning your transformation
Are you set up to successfully compete with experiences?
The power of setting clear expectations
