The Agile project management framework, or APM, defines five phases that map onto the canonical project management lifecycle while preserving the iterative, customer-centric mindset Agile depends on. The five phases are envision, speculate, explore, adapt, and close. Each one looks different at enterprise scale than at team level, and understanding the difference is what separates Agile programs that deliver enterprise value from those that ship features without producing outcomes. This guide walks through each phase the way enterprise program leaders need to run it.
The framework, introduced by Jim Highsmith in 2004, is widely cited in introductory Agile material. The version typically explained in those materials describes how the phases work at team level. At enterprise scale, each phase demands more, and the operational reality of multi-team, multi-stakeholder, multi-quarter delivery has to be built in from the start.
Why the APM framework still matters at enterprise scale
Wellingtone research found that hybrid project management adoption surged by 57 percent between two consecutive annual reports, and the APM framework sits at the heart of how mature enterprises run the Agile portion of that hybrid portfolio. Most enterprise Agile programs fail not because the teams cannot deliver sprints, but because the program around the teams does not have a coherent operating rhythm. Teams ship features, but the program does not deliver outcomes.
The APM framework matters because it gives the program a structure that preserves Agile principles while making room for the governance, stakeholder management, and value realization that enterprise programs actually require. The five phases of envision, speculate, explore, adapt, and close are not a rebranding of the traditional project lifecycle. The phases are an operating rhythm designed to keep the program focused on customer value while accommodating the change that enterprise work inevitably produces.
Phase 1: Envision
Envision sets the strategic frame for the program. At team level, envision often shrinks to a one-page vision statement. At enterprise scale, envision is a structured discovery that defines the customer outcome the program exists to deliver, the business case behind it, the stakeholder landscape the program will operate inside, and the success criteria that will govern continuation or termination decisions later in the lifecycle.
Enterprise envision produces three explicit artifacts. A program charter that the executive sponsor signs. A stakeholder map that names every group whose support or veto matters. A measurable outcome definition that connects the program to the strategic objective it is funded against. Without these, the program drifts into feature delivery without a way to know whether the work is creating the value the business asked for.
Phase 2: Speculate
Speculate is where the program plans the work in a way that allows for the change Agile expects. At team level, speculate produces a backlog and a sprint plan. At enterprise scale, speculate produces a multi-quarter delivery plan that holds high-level milestones, dependency maps across teams, capacity projections, and an explicit risk register that the program will revisit at every checkpoint.
The speculate phase at enterprise scale also defines the governance cadence. Quarterly program-level planning sessions, monthly portfolio reviews, weekly cross-team coordination, and the escalation paths that activate when one team's slippage threatens another team's commitment. The cadence is what allows the program to stay coherent across teams operating in their own sprint rhythms.
Phase 3: Explore
Explore is where the work actually gets done. Teams execute against the speculated plan, ship working product in iterations, and surface what is learned. At team level, explore is the sprint. At enterprise scale, explore is a parallel set of sprints across multiple teams whose outputs have to integrate, sequence, and reinforce each other.
The discipline that matters most during explore at enterprise scale is integration. Teams that ship features independently without integrating produce technical debt and customer experience fragmentation. The program needs an integration cadence that aligns with the team-level sprint cadence, with explicit handoffs, shared definitions of done, and a continuous integration discipline that catches misalignment before it becomes expensive.
Phase 4: Adapt
Adapt is what separates Agile programs from traditional ones. At every iteration, the program reviews what was delivered, what was learned, and what the next iteration should change. At team level, adapt is the retrospective. At enterprise scale, adapt is a structured stakeholder review that operates at three levels.
Team-level adapt
Each team runs its own retrospective at the end of every sprint, focused on team-level process improvements, technical practices, and collaboration patterns. This level is the foundation, and skipping it tends to atrophy team performance over time.
Program-level adapt
The program runs a structured review at the end of every program increment, typically every quarter, focused on cross-team coordination, dependency management, and whether the speculated plan still reflects business reality. The program-level adapt is where teams renegotiate commitments, where the stakeholder map gets updated, and where the next quarter of work gets shaped.
Portfolio-level adapt
The portfolio reviews the program against the original outcome definition and the business case. McKinsey research has shown that around 70 percent of large-scale transformation programs fail to achieve their original objectives, and the portfolio-level adapt is where most enterprise Agile programs neglect to close that gap. Portfolio-level adapt is where the funding decision gets revisited. Programs tracking toward outcomes get continued or expanded. Programs that have drifted get redirected. Programs that have lost their business case get terminated.
Phase 5: Close
Close at enterprise scale extends past the moment the program ships its final increment. Closure includes the transition of operational responsibility to the team that will own the product or capability long-term, the documentation of what was learned across the program lifecycle, and the value realization tracking that measures whether the original business case actually delivered.
Value realization is the closure activity most enterprise programs underinvest in. A program that ended on time and on budget but did not produce the customer outcome, revenue lift, or cost reduction in the business case is a program that closed without succeeding. Mature programs build value tracking into closure with explicit measurement points at six, twelve, and 24 months after final delivery, and the PMO owns the framework that makes the tracking happen.
How Kissflow operates the APM framework
Kissflow gives enterprise program leaders the operational layer the APM framework depends on across all five phases. The platform holds the envision artifacts, the speculate plans, the explore-phase coordination across teams, the three-tier adapt reviews, and the value realization tracking that extends past closure.
Program managers use Kissflow to run the APM framework across teams, business units, and stakeholder groups, with the portfolio governance, cross-team visibility, and integration depth that allow Agile to deliver value at the scale the business needs. The platform replaces the fragmented tooling enterprise Agile programs typically run on, and it preserves the audit trail and governance discipline regulated industries require.
.webp)
