A common misconception is that adopting Agile means embracing chaos, where planning, well-defined processes and project oversight are abandoned in favour of uncontrolled madness. Given that projects launch without detailed specifications and comprehensive schedules, management may fear that an Agile project will be the IT equivalent of the Wild West.

After all, how can you manage a project in which the final output is not based on an initial design, but emerges over time through iterations? Without detailed specs and hard deliverables, how can you ensure the accountability of contractors? Senior leaders also tend to be reluctant to abandon the comfort of traditional project reporting due to concerns that a lack of control could result in a costly failure.

The concern is legitimate. Indeed, if Agile is attempted without proper oversight, a project can decay into a chaotic and unproductive collection of activities with disappointing results. Agile projects can fail like any other.

If done well, however, Agile methodologies can provide greater visibility for management into how a project is progressing, more enforceable process controls for how the effort is conducted and a stronger correlation between a customer’s needs and the work delivered. And Agile can provide all of this while also cultivating a culture of innovation and employee empowerment.

An “Agile management office,” or AMO, represents a way to transform the traditional programme management office (PMO) to better support programmes executing (or experimenting with) Agile.

Common pitfalls of a traditional PMO

The traditional PMO took on its contemporary form in the 1950s and was established to centralise management of business projects. Built on a command-and-control model, a traditional PMO emphasises consistent process execution from the top down—and reams of documentation. The discipline of “project management for IT” matched up reasonably well with the waterfall approach to development, focusing on controlling a project’s project scope, cost and time-table—all three of which were predetermined at a project’s start and served as the basis for performance reporting.

In essence, the PMO was established to answer questions centred on process: “Did we meet spec?,” “Did we deliver on time?,” and “Did we meet budget?” Missing was any metric regarding working software that actually met the end user’s needs.

The risks and shortfalls of a traditional PMO in a waterfall setting are significant. Oftentimes, step-by-step plans don’t play out as originally designed; yet the PMO continues to report against them. As a result, waterfall IT projects and their PMOs are often blindsided by problems that come to light very late in the project. Indeed, too often, business customers are disappointed with the traditional approach’s results, where slow development times yield systems that technically meet spec but fail to deliver value for users.

The mismatch between traditional PMO techniques and an Agile project manifests itself from the very start. An Agile project isn’t born with detailed specs or a comprehensive time-table for completion. Instead, the final product emerges through a collaborative and iterative process in which business users provide continuous feedback to developers. However, in order to satisfy the PMO’s demands, organisations often perform impressive contortions in an attempt to fit Agile development’s square peg into the PMO’s round hole.

The question facing senior management is thus: How do we adapt the PMO to survive (and thrive) in an Agile development world? How can we maintain visibility into project delivery using metrics appropriate for Agile? How do we maintain a coherent set of processes while enabling innovation by the project teams? These are critical questions, because the ability to coordinate multiple workstreams running in parallel can often determine the success or failure of an IT effort.

What makes an AMO different?

The switch from a PMO to an AMO is much more than a superficial name change. An AMO is designed to operate as an effective way to monitor the progress of Agile projects. It measures success in terms identical to the Agile development teams’ goal: working software that meets users’ needs. Because of this, an AMO, while performing an oversight function similar to a PMO, operates in a fundamentally different manner.

Four key features distinguish an AMO from a traditional PMO:

• Tracking. An AMO tracks team productivity and product delivery by applying lean estimation techniques, emphasising the delivery of working software.
• Coordination. An AMO fosters collaboration between teams, ensuring that efforts are coordinated and aligned.
• Prioritisation. An AMO ensures that teams focus on the important things first—features that will drive working software that delivers business value. (These features may change over the course of the project, however!)
• Governance. An AMO provides a lightweight form of governance that focuses squarely on the project’s strategic vision while allowing flexibility at the task level.

The net result of these four characteristics is accountability for delivering the desired result.

Tracking

An AMO can track delivery during an Agile project in two distinct ways. The first is by documenting the work delivered by each Agile team in terms of “story points” completed during each time-boxed iteration, each of which typically lasts two to four weeks. Story points reflect a relative estimate of task complexity, estimated directly by the development team. The number of story points each team produces per iteration, known as “velocity”, can make it possible to more reliably forecast future iterations’ output and to estimate the time required to deliver functionality. For those unfamiliar with Agile, these terms may sound peculiar, but in practise, they can lead to more accurate planning estimates than predefined resource hours or task durations.

The other measure of progress is the demonstration of working software. Unlike a traditional waterfall approach, where working software is often seen for the first time months or years into a project, Agile emphasises the rapid creation and frequent demonstration of working software to allow business leaders to react to the software early in the process.

Co-ordination

In projects involving multiple teams, it is critical that teams are aligned in their efforts. An AMO serves to shepherd the work planning process, facilitating co-ordination among Agile delivery teams.

Rather than a command-and-control model, an AMO enables and empowers project teams to make decisions and select enabling tools and processes within AMO-designated guidelines. Instead of being the focal point for all communication, the AMO creates communication channels that enable and promote the free flow of information among project teams. Cross-project dependencies, process improvements and the outcomes of “failed” experiments and retrospectives can thus quickly disseminate among teams. The AMO also provides programme and project coaching to observe, capture and socialise leading practises and guard against common pitfalls without prescribing a rigid delivery approach.

In queue with Agile values, an AMO does not coordinate Agile project teams so much as it enables the teams to coordinate amongst themselves. This is a subtle but important difference, as it empowers the teams, enabling a thriving culture of innovation and experimentation, rather than putting a central management entity in charge. By empowering teams to drive the day-to-day activities, the AMO is better able to objectively monitor delivery from end to end and identify impediments and process bottlenecks, with a view to eliminating waste and delay. For instance, the AMO can champion productivity-enhancing initiatives or update project delivery guidelines to implement system-wide improvements.

Prioritisation

An AMO guides the prioritisation of work in a manner consistent with Agile execution at scale, using a product backlog that includes all business, technology, or infrastructural capabilities to be developed. The business and IT work collaboratively to create, maintain and prioritise the backlog, typically in a shared, integrated life cycle management tool.

Product planning provides a long-term vision at a conceptual level. A high-level road map depicts the sequence in which the strategic objectives should be developed and provides a high-level timeline for the business value the software delivers. Strategic objectives enter the backlog as “epics,” a conceptual depiction of desired business functionality. At regular intervals, a combined panel of business and IT leaders review and prioritise epics in the pipeline, which are then allocated to one or more cross-functional teams for implementation. For example, organisational leadership may call for expanded cybersecurity coverage in light of recent cyberattacks on similar organisations. This work may entail significant refactoring across multiple IT systems, requiring resources to suspend new development work. Because Agile development teams plan frequently and with a shorter-term view (two to three months), these prioritised cybersecurity enhancements can be scheduled for implementation more rapidly and with less disruption, than in the traditional model.

Delivery is synchronised amongst teams along a shared iterative cadence in which teams release and integrate work at a frequent and predictable pace. A direct queue of sight can be established from the day-to-day work at the team level to the progress made towards meeting enterprise strategic objectives. For many organisations, the introduction of collaborative progress-tracking tools can yield unprecedented visibility into the results of their investment as well as enabling more engaging interactions with the business customer.

Governance

An AMO adopts a lean approach to governance, streamlining the delivery of planned work while ensuring alignment with business priorities. Regular product demonstrations at both the programme and project levels take the place of traditional phase-gate governance reviews, freeing teams to rapidly release functionality without requiring formal approval. Risks, cross-project impacts and dependencies are identified and mitigated in regular integrated planning sessions without formal governance board review. Instead of funding projects and programmes designed to deliver one specific product or system, the AMO allocates funding to long-standing value delivery streams, a network of teams that shepherds a constant flow of strategic objectives from conception through business use. The AMO ensures that the flow of new requirements to the value streams aligns with the enterprise strategy and monitors delivery throughput using highly visible Agile metrics and reports.

Is an AMO for me?

The decision of whether or not to establish an AMO will often depend on an organisation's experience with Agile, the scale or complexity of the work being delivered and leadership's willingness to help drive a sometimes difficult journey of culture change. Before committing to an AMO transformation, leadership should be willing to cede control of day-to-day team-level processes and refocus on more frequently identifying and prioritising strategic objectives. At organisations that decide to move forward with an AMO, the potential benefits include greater visibility into the work being delivered and the ability to reprioritise delivery to meet business needs. The bottom queue: An organisation can use an AMO to effectively steer the ship while empowering and engaging teams, recognising that the best ideas often come from those closest to the work.

Deloitte Center for Government Insights

View