What's New in the Agile Practice Guide Second Edition
By Christopher Scordo, PMP, ITIL · Last updated: August 6, 2026
Nine years is a long time in this profession. When PMI and Agile Alliance published the first Agile Practice Guide in 2017, hybrid delivery was still treated as a compromise, most teams shared a building, and story point velocity was the number everyone rolled up to management. The second edition arrived in July 2026, and it reads like a document written by people who spent the intervening nine years watching all three of those assumptions fail in the field.
This is not a cosmetic refresh. Entire sections were added, others were quietly relocated to appendices, and in one case the guide walks back reporting advice that a generation of teams built their status meetings around.
On this page
The short version
The changes that matter most, in one pass:
- Product management became a prerequisite to approach selection. Section 3 now spends six pages on products before it discusses life cycles at all.
- Psychological safety earned its own section (4.2), five pages with peer-reviewed sourcing behind it.
- Story point velocity is no longer recommended outside the team that produced it.
- "Servant leadership" disappeared, replaced throughout by "supportive leadership."
- "Hybrid" was deprecated in favor of "a continuum of approaches."
- Every major section closes with a GenAI callout, and every one of them attaches cautions.
- Remote and hybrid teams gained four new subsections (4.7.2 through 4.7.5).
- Two brand-new annexes: DevOps, DevSecOps and DORA metrics (A2), and sustainability (A4).
- Procurement and contracts moved to an appendix, essentially unchanged from 2017.
PMTraining synthesis of the Agile Practice Guide (PMI and Agile Alliance, 2017) and the Agile Practice Guide—Second Edition (PMI and Agile Alliance, 2026). Section and page references are to the second edition.
The center of gravity moved from projects to products
The single largest structural change is one the table of contents barely telegraphs. Section 3 was renamed from "Life Cycle Selection" to "Development Life Cycles and Approach Selection," and before it gets anywhere near life cycles it works through product management in agile environments, product life cycle phases, the difference between product and project teams, product portfolio management, and customer experience metrics (pp. 18 to 23).
The framing sentence is worth quoting: "While projects are temporary initiatives in a unique context undertaken to create value, products are enduring, evolving entities without a defined end date" (p. 18). From there the guide draws the distinction that matters operationally. Product teams are continuous and funded based on outcomes. Project teams are temporary and scoped around a specific outcome with fixed time and resource constraints. One is a standing capability, the other is a bounded effort, and they are funded, staffed, and governed differently.
If you have spent the last few years watching your organization stand up "product teams" that are really just project teams with a new nameplate, this section gives you the vocabulary to name the gap. It also introduces the customer experience metrics the guide now expects agile practitioners to care about: customer acquisition cost, retention rate, churn rate, Net Promoter Score, OKR progress, and average revenue per user (p. 23).
Psychological safety became a named requirement
Section 4.2 did not exist in the first edition. It now runs from page 40 to page 44 and opens by defining psychological safety as the "shared belief among team members that the environment is safe for interpersonal risk-taking," crediting Amy Edmondson's operationalization of the construct.
That sourcing is not decorative. Edmondson's original study in Administrative Science Quarterly examined 51 work teams and found that learning behavior mediated the relationship between psychological safety and team performance, and a later meta-analysis in Personnel Psychology pooled 136 independent samples covering more than 22,000 individuals. This is one of the better-evidenced constructs in organizational research, and the guide treats it accordingly.
What makes the section useful rather than aspirational is that it operationalizes the idea. It adopts Timothy R. Clark's four stages (inclusion safety, learner safety, contributor safety, challenger safety) as a diagnostic ladder, and Table 4-1 maps psychological safety onto specific agile events. It also names concrete threats, including one that should land uncomfortably for a lot of teams: "Agile teams that drop retrospectives are especially at risk" (p. 41). And it notes that remote environments "can undermine psychological safety by diluting informal check-ins, masking tone, and amplifying bystander silence."
The vocabulary changed, and the vocabulary is the argument
Section 1.1.1 is titled "Agile Terminology Changes," and it tells you plainly that "terms once considered standard are being replaced with more inclusive and respectful alternatives" (p. 2). Backlog grooming is now backlog refinement. Daily standups are now daily coordination meetings, daily syncs, or daily scrums. Servant leadership is now supportive leadership, and on that last one the guide is candid that the profession has not settled the question: roles such as scrum master and concepts like servant leadership "are being reassessed, although no universally accepted alternatives have been agreed upon yet."
That substitution is worth watching closely, because the concept survived intact even though the label did not. Section 4.3 still describes "the practice of leading through service to the team" (p. 45), and the seven characteristics carried over unchanged. What was removed is the word, not the idea.
The most consequential rename is subtler. The first edition's Figure 3-1 was "The Continuum of Life Cycles," a two-dimensional square with predictive, iterative, incremental, and agile in four quadrants. The second edition replaces it with Figure 3-4, "The Continuum of Approaches," a single spectrum from predictive to agile, and a TIP box on the same page argues against "hybrid" outright: "while the term hybrid may be helpful shorthand for labeling mixed ways of working, a more accurate term is a continuum or spectrum of practices, with more detailed explanations of the components selected" (p. 25).
That is a real argument, not a style preference. Saying a project is "hybrid" tells a stakeholder nothing about which practices you actually selected. Given that Digital.ai's 18th Annual State of Agile Report found 74% of respondents now use hybrid, blended, or homegrown models, the profession has been leaning hard on a word that carries almost no information.
Velocity lost its management role
This is the change most likely to start an argument in your organization, and it is stated more directly than PMI standards usually state anything. Section 5.5.1 defines velocity, describes it as "intended only as a lightweight, team-specific planning aid," and then catalogs three ways it has been misapplied: weaponization (using velocity to compare, rank, or threaten people), false precision (treating story points as interchangeable across teams), and perverse incentives (inflating estimates or sacrificing quality once velocity becomes a target). Then it commits:
"The originators of the metric now advise against making velocity a management performance indicator. Consequently, the Agile Practice Guide—Second Edition no longer recommends tracking story point velocity outside the team that produced it or using it to assess performance, forecast at scale, or set delivery targets." (p. 76)
What replaces it is a flow-based measurement set: throughput, cycle time, lead time, work in process, escaped defects and rework, and queue length, visualized on cumulative flow diagrams or run charts (Table 5-4, p. 77). Sponsor reporting moves to probabilistic forecasting, with the guide supplying its own example phrasing: "There is an 85% chance we deliver the remaining 45 stories within 10 iterations," and an instruction that forecasts be presented "as ranges or confidence curves—never as single-point commitments" (p. 79).
Notice what quietly vanished along with velocity. The first edition's measurement section was built on burndown and burnup charts and agile earned value management with SPI and CPI. None of it survives. In its place you get outcome metrics, an extended treatment of OKRs and the Goal Question Metric framework, and a warning about "vanity targets" that names names: social likes on release posts are "a popularity proxy and easy to spike" (p. 82).
GenAI runs through every section, and so do the cautions
Each major section of the second edition closes with a "GenAI Insights" box, and the preface flags them explicitly as "ideas, not endorsements or instructions."
The pattern is consistent and, to the committee's credit, unusually balanced. Each box opens with genuine capability, then turns hard on the failure mode. In Section 4, GenAI can summarize chats, gather anonymous retrospective input, and analyze sentiment to spot early burnout signals. Then: sentiment analysis "may feel more like surveillance than support," people may engage in "sentiment stuffing" by performing enthusiasm for the tool, and "overautomation of agile practices can stifle learning and dialogue, reducing team collaboration to an 'AI says so' exercise" (p. 62). Section 5 warns that AI-generated charters "may shortcut the difficult but essential conversations that build trust, alignment, and ownership" (p. 83). Section 6 lands on the framing that governs the rest: "AI works best as a firewalled input step, providing relevant data for human decisions, not a replacement for established practices... When outputs are accepted without question, agility becomes mechanical" (p. 108).
That caution is well calibrated against what the data shows. Google Cloud's 2025 DORA report found 90% of nearly 5,000 technology professionals surveyed use AI at work and more than 80% believe it increased their productivity, while 30% report little or no trust in AI-generated code. McKinsey's 2025 State of AI survey found 88% of organizations report regular AI use in at least one business function while just 39% report EBIT impact at the enterprise level. Adoption is close to universal. Realized value is not. A practice guide that pretended otherwise would have aged badly within a year.
Remote and hybrid teams finally get real guidance
The first edition handled distributed work in a few paragraphs on team workspaces, fishbowl windows, and remote pairing. The second edition devotes four subsections to it (4.7.2 through 4.7.5) and opens with a flat statement of fact: "What began as a temporary solution during the COVID-19 pandemic has evolved into a long-term approach for organizing work" (p. 58).
The guidance is practical. It distinguishes remote teams from hybrid-location teams, catalogs challenges including proximity bias affecting recognition and advancement, then walks practice by practice through what changes: working agreements, daily coordination meetings that may go asynchronous, digital information radiators replacing physical boards, rotating retrospective facilitation with anonymous feedback available, and ensuring equal participation for remote members in hybrid reviews (p. 61). The closing line is the right one: "Adapting agile for remote work is not about reinventing practices. It is about preserving core values like collaboration, transparency, and continuous delivery."
The underlying reality supports the emphasis. The U.S. Bureau of Labor Statistics found that in 2025, 35% of employed people did some or all of their work at home on days they worked, rising to 51% among those with a bachelor's degree or higher. And a randomized controlled trial of 1,612 employees published in Nature found that hybrid working reduced quit rates by one-third with no measurable effect on performance grades over the following two years of reviews. This is settled enough to design around.
The enterprise chapter grew up
Section 6 roughly doubled in ambition. Procurement and contracts left for Appendix X1. Multiteam coordination and scaling moved forward into Section 5. What filled the space is enterprise-scale material the first edition never attempted.
Lean portfolio management (6.5) is entirely new, covering strategy and investment funding, agile portfolio operations, and lean governance, with a portfolio kanban funnel, participatory budgeting reviewed quarterly, and portfolio sync sessions every six to twelve weeks. The line that will resonate with anyone who has sat through an annual planning cycle: traditional models keep teams working an initiative "even if the value decreases" (p. 96).
Agile and xMOs (6.7) is also new, and it is a genuinely useful reframe. The guide observes that the unit once called a PMO now appears as a value management office, agile transformation office, strategy realization office, or portfolio enablement office, and adopts "xMO" as a neutral label for all of them (p. 100). Table 6-2 lays out the shift: success measured by outcome OKRs rather than on time and on budget, funding in incremental outcome-based tranches rather than annual capital parcels, flow metrics rather than earned value reports. The antipattern list is sharp, starting with "vanity dashboards" where "charts abound but no decision changes are made" (p. 103).
The timing is not accidental. Digital.ai's most recent State of Agile found 76% of respondents citing increased scrutiny on the business impact and ROI of agile, though that survey covered roughly 350 participants skewed toward coaches and consultants at large enterprises. The pressure to connect team-level delivery to enterprise outcomes is exactly what these sections are answering.
Two new annexes worth reading on their own
Annex A2 covers DevOps, DevSecOps, low-code and no-code platforms, and DORA metrics. The four DORA metrics are stated cleanly as deployment frequency, lead time for changes, change failure rate, and time to restore service (pp. 119 to 120), but the interpretive guidance matters more than the list: track them over time, "compare teams to themselves, not to each other," and frame them "as part of a continuous improvement conversation, not a performance evaluation."
Annex A4 covers sustainability, anchoring to the PMBOK Guide—Eighth Edition principle "Integrate Sustainability Within All Project Areas." It names a regulatory watchlist including the EU Corporate Sustainability Reporting Directive and IFRS S2, offers a try-and-avoid quick reference (add an eco-impact bullet to the definition of done; avoid labeling sustainability as "Phase II" work), and lists antipatterns including greenwashing metrics and "efficiency tunnel vision," described as "maximizing sprint velocity while wasting resources" (p. 139).
What got cut
Not everything grew. The first edition's Annex A2, which mapped the four Agile Manifesto values and twelve principles to guide sections, is gone entirely. Annex A1 shrank from roughly six pages of Knowledge Area mapping tables to two pages of narrative bullets against the PMBOK Guide—Eighth Edition performance domains. Sections on team workspaces and overcoming organizational silos disappeared, taking named practices like fishbowl windows with them. And procurement sits in Appendix X1 as it was written in 2017, with no discussion of outcome-based contracting, sustainability clauses, or AI vendor considerations.
What this means if you are certifying
For PMP candidates, the alignment is stronger than it looks. The exam that launched in July 2026 moved Business Environment from 8% to 26% of the content outline, with PMI describing a shift toward "outcomes, value and business impact" and incorporating AI and sustainability into project scenarios. The second edition's new material on portfolio management, outcome metrics, and sustainability maps onto that shift directly, and its Annex A1 realigns to the PMBOK Guide—Eighth Edition's six principles, seven performance domains, and five focus areas.
For PMI-ACP candidates, the fit is even tighter. The current exam content outline weights Mindset at 28%, Leadership at 25%, Delivery at 28%, and Product at 19%. The new product management material in Section 3 and the reworked leadership material in Section 4 speak to more than 40% of that outline between them.
In practical terms, the changes most likely to show up in scenario questions are the ones where the guidance actually reversed: measurement that no longer treats velocity as a management indicator, leadership language that no longer says "servant," and life cycle discussions framed as a continuum rather than a hybrid label.
PMTraining framework. Positions reflect our editorial weighting of the Agile Practice Guide—Second Edition against the July 2026 PMP exam content outline and the current PMI-ACP exam content outline. They are a judgment, not a PMI classification.
The honest assessment
The second edition is a better book than the first, and it is better in the specific way practice guides usually are not. It removed things: velocity as a management metric, the four-category life cycle taxonomy, the Manifesto mapping tables, six pages of Knowledge Area crosswalks. Guides typically accrete. This one edited.
It is not flawless. Annex A1 promises a crosswalk "to assist readers in locating related guidance between the two publications" and then does not provide one. The antipattern list in 6.7.7 supplies corrective actions for two of its four entries and stops. And the servant-to-supportive substitution is made without a single sentence explaining the reasoning, which is a strange choice for a change practitioners will be asked about constantly.
But the core judgment is sound. A guide written in 2017 could treat remote work as an edge case, velocity as a reasonable rollup, and products as something other teams worried about. A guide written for 2026 cannot. This one does not.
The sixty-minute read
If you only get one sitting with the second edition, read these six passages in this order. Roughly 60 minutes, 32 pages.
☐
10 min
Section 1, pages 1–6
The committee’s own account of what changed and why. Section 1.1.1 is where the terminology shifts are stated outright.
☐
15 min
Section 5.5, pages 75–82
The measurement rewrite. Read 5.5.1 twice, then decide what your status report is going to say instead of velocity.
☐
10 min
Sections 3.2–3.7, pages 18–23
Product management. Table 3-1 on page 20 is the page to photograph if your organization is renaming project teams into product teams.
☐
10 min
Section 4.2, pages 40–44
Psychological safety, including Table 4-1, which maps it onto specific agile events rather than leaving it as a value statement.
☐
8 min
Sections 4.7.2–4.7.5, pages 58–61
Remote and hybrid teams, practice by practice. Page 61 is the one to bring to a working agreements session.
☐
7 min
Annex A2.4, pages 119–121
The four DORA metrics and, more usefully, the guidance on how not to weaponize them.
PMTraining reading plan. Page references are to the Agile Practice Guide—Second Edition (PMI and Agile Alliance, 2026).
The Agile Practice Guide—Second Edition is available to PMI members through PMI.org and to Agile Alliance members through agilealliance.org. PMTraining is a PMI Premier Authorized Training Partner.
Frequently asked questions
When was the Agile Practice Guide Second Edition released?
July 2026. It was developed in partnership between PMI and Agile Alliance, the same collaboration that produced the 2017 first edition, and it is available free to members of either organization.
Does the Agile Practice Guide Second Edition still recommend tracking velocity?
Not as a management metric. Section 5.5.1 states the guide "no longer recommends tracking story point velocity outside the team that produced it or using it to assess performance, forecast at scale, or set delivery targets." It recommends flow metrics such as throughput, cycle time, lead time, and work in process instead, with sponsor forecasts presented as probabilistic ranges.
Why did the Agile Practice Guide replace "servant leadership" with "supportive leadership"?
The guide does not explain the substitution directly. Section 1.1.1 notes only that concepts like servant leadership "are being reassessed, although no universally accepted alternatives have been agreed upon yet," as part of a broader move toward more inclusive terminology. The underlying concept was retained; Section 4.3 still describes leading through service to the team.
What are the four DORA metrics in the Agile Practice Guide Second Edition?
Deployment frequency, lead time for changes, change failure rate, and time to restore service. Annex A2 groups the first two as delivery speed measures and the second two as delivery quality measures, and instructs teams to compare themselves against their own trend rather than against other teams.
Do I need the Agile Practice Guide Second Edition to pass the PMP or PMI-ACP exam?
Neither exam tests a single publication. That said, the second edition's new material on product management, outcome and flow metrics, and sustainability aligns closely with the July 2026 PMP exam content outline, which increased Business Environment from 8% to 26%, and with the PMI-ACP outline, which weights Product at 19% and Delivery at 28%.
Is "hybrid" still the right term for mixed delivery approaches?
The second edition argues against it. A TIP box on page 25 notes that calling an approach "hybrid" conveys no information about which practices were actually selected, and recommends describing delivery as a point on a continuum or spectrum of approaches with the specific components named.
Sources:
Agile Alliance and PMI, Agile Practice Guide—Second Edition (2026)
PMI, Agile Practice Guide (first edition, 2017)
Edmondson, A. C., “Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly, 44(2), 1999
Frazier et al., “Psychological Safety: A Meta-Analytic Review and Extension,” Personnel Psychology, 70(1), 2017
Google Cloud, 2025 DORA Report: State of AI-assisted Software Development
McKinsey & Company, The State of AI (2025)
U.S. Bureau of Labor Statistics, American Time Use Survey—2025 Results
Bloom, Han & Liang, “Hybrid working from home improves retention without damaging performance,” Nature, 630, 2024
Digital.ai, 18th Annual State of Agile Report (October 2025)
PMI, “Learn what the new PMP exam, launched in July 2026, means for you”
PMI, PMI Agile Certified Practitioner (PMI-ACP) certification