Managing an Agile program? Consider an AMO has been added to your bookmarks.
Adopting Agile doesn't mean sacrificing appropriate project oversight. An organization can use an Agile management office to effectively steer the ship while empowering and engaging Agile project teams.
A common misconception is that adopting Agile means embracing chaos, where planning, well-defined processes, and project oversight are abandoned in favor 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 program management office (PMO) to better support programs executing (or experimenting with) Agile.
The traditional PMO took on its contemporary form in the 1950s, and was established to centralize management of business projects. Built on a command-and-control model, a traditional PMO emphasizes 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 schedule—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 centered 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 schedule 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, organizations 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.
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:
The net result of these four characteristics is accountability for delivering the desired result.
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 odd, but in practice, they can lead to more accurate planning estimates than predefined resource hours or task durations.
Shared language is essential
Numerous methodologies, each with its own vocabulary, have emerged to define a delivery process based on the Agile Manifesto. While the AMO approach does not prescribe any particular methodology, it is compatible with popular approaches, such as Scrum and the Scaled Agile Framework.
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 emphasizes the rapid creation and frequent demonstration of working software to allow business leaders to react to the software early in the process.
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 coordination among Agile delivery teams.
In lieu of 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 serving as 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 program and project coaching to observe, capture, and socialize leading practices and guard against common pitfalls without prescribing a rigid delivery approach.
In line with Agile values, an AMO does not coordinate Agile project teams so much as it enables the teams to coordinate among 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.
An AMO guides the prioritization 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 prioritize 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 prioritize epics in the pipeline, which are then allocated to one or more cross-functional teams for implementation. For example, organizational leadership may call for expanded cybersecurity coverage in light of recent cyberattacks on similar organizations. 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 prioritized cybersecurity enhancements can be scheduled for implementation more rapidly, and with less disruption, than in the traditional model.
Delivery is synchronized among teams along a shared iterative cadence in which teams release and integrate work at a frequent and predictable pace. A direct line 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 organizations, 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.
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 program 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 programs 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.
The decision of whether or not to establish an AMO will often depend on an organization’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 prioritizing strategic objectives. At organizations that decide to move forward with an AMO, the potential benefits include greater visibility into the work being delivered and the ability to reprioritize delivery to meet business needs. The bottom line: An organization can use an AMO to effectively steer the ship while empowering and engaging teams, recognizing that the best ideas often come from those closest to the work.