Agile, sprints, project management, and architecture change
Agile delivery cadence and TOGAF architecture work can support one another rather than conflict, once the enterprise is explicit about which decisions need central coordination and which can be delegated. The ADM adaptation patterns from G20F, the sprint integration model from G210, and the project-management bridge from G188 all turn on the same practical question: which architecture decisions should stay stable while delivery iterates. No prior knowledge of agile methods is assumed beyond what a newspaper technology section might contain.
By the end of this module you will be able to:
- Explain why the conflict between agile delivery and enterprise architecture is usually exaggerated and identify what causes the real friction
- Describe the G20F tailoring patterns that allow the ADM to adapt its depth and cadence to the enterprise context
- Explain the G210 architecture runway concept and how ADM work integrates with sprint-based delivery without waterfall sequencing
- State which architecture decisions should remain stable and which can iterate safely through delivery learning
- Describe how architecture outputs connect to project-management discipline through the G188 integration guidance
- Apply agile/architecture coexistence logic to the London Grid case, identifying where sprint delivery needs architecture guardrails and where architecture should step back
Real-world case · 2022
High velocity. Three competing identity models. Eighteen months to reconcile.
An energy retailer adopted agile delivery practices across its technology teams in 2022. Within six months, sprint velocity was high, feature throughput was visible, and stakeholder satisfaction with individual team outputs was good.
What was less visible was that three delivery teams had independently built competing customer-identity models, two teams had adopted incompatible event-messaging patterns, and the data platform team had no mechanism to challenge design decisions that created downstream integration debt. Each team had delivered exactly what its product owner requested. None had checked whether its local design was consistent with any other team's local design.
The architecture team had been told not to slow things down. The result was not speed. It was divergence that took eighteen months to reconcile. The total rework cost exceeded the entire first year of delivery spend. The lesson was not that agile delivery is wrong. The lesson was that agile delivery without architecture guardrails is not actually faster; it simply moves the cost to a different quarter.
If three delivery teams can each build a different customer-identity model during sprint-level work, does the enterprise have agility or divergence?
That story illustrates the cost of unbounded local autonomy. The challenge is to keep the delivery cadence fast enough to learn while keeping the enterprise design coherent enough to trust. The G20F tailoring patterns, the G210 sprint integration model, the G188 project-management bridge, and the practical question of what should stay stable versus what can iterate safely are how that balance is held.
If you are already confident with agile/architecture integration, use the knowledge checks to confirm your understanding and move to Module 50: Readiness assessment and adoption sequencing.
49.1 Why the conflict is often exaggerated
Teams often talk as if architecture and agile delivery are natural enemies. One side argues that architecture creates unnecessary overhead. The other argues that agile teams produce ungoverned chaos. In practice the real conflict is usually weaker than either caricature suggests. The problem is not agility itself. The problem is unclear architecture on one side or unbounded local autonomy on the other.
The ADM does not require waterfall delivery. It requires that the enterprise know what problem it is solving, what the target state looks like across domains, and how exceptions are governed. Those requirements are compatible with any delivery cadence. The friction arises when the architecture function tries to review every local decision at the same depth as it reviews cross-domain decisions, or when delivery teams refuse to accept any constraint that did not originate inside their own sprint planning session.
The resolution is scope clarity. The enterprise needs to decide explicitly which decisions need central coordination and which can be delegated safely. When that boundary is clear, architecture and agile delivery stop competing for the same territory and start operating in their respective strengths.
Three conditions usually explain most agile/architecture friction.
- Unclear decision rights. Nobody has defined which decisions the Architecture Board owns, which the domain architect owns, and which belong to the delivery team. The result is that every decision becomes a negotiation, which slows delivery without improving architecture quality.
- Over-centralised review. The architecture function reviews every technology choice regardless of consequence. Minor decisions queue alongside major ones. Teams perceive architecture as a bottleneck because it is behaving like one.
- No feedback path from delivery to architecture. Delivery teams learn things during sprints that the architecture should absorb. If there is no mechanism for delivery learning to update the architecture, the architecture becomes stale and teams stop trusting it.
“The ADM is intended to be used flexibly and tailored to the needs of the organisation.”
The TOGAF Standard, 10th Edition - C220 Part 3, Applying the ADM
The key phrase is 'flexibly and tailored'. TOGAF does not mandate waterfall sequencing. It mandates architectural discipline. The delivery cadence is an implementation choice, not a method constraint. The standard gives explicit permission to adapt.
49.2 The G20F ADM adaptation patterns
G20F (Applying the TOGAF ADM: Iteration and Levels) is the TOGAF Series Guide that provides endorsed patterns for tailoring the ADM to different enterprise contexts. The guide recognises that rigid, one-size-fits-all application of the full ADM creates the exact overhead that delivery teams complain about. G20F offers four adaptation strategies.
Iteration across phases
G20F supports iterating through ADM phases at different levels of detail. A strategic-level pass may touch all phases lightly to establish direction. A segment-level pass may focus on specific domains in depth. A capability-level pass may address a single bounded problem within an existing target architecture. Each level adjusts the depth of analysis and the weight of governance without abandoning the method's structure.
Phase selection
Not every initiative requires every ADM phase. A narrow change within an existing target architecture may start at Phase E (migration planning) rather than repeating Phases A through D. G20F makes this explicit: the enterprise should enter the ADM at the point that matches the problem, not at the beginning every time.
Artefact selection
G20F supports producing only those artefacts that serve a decision or handoff purpose. The content framework is a menu, not a mandatory checklist. If an artefact does not change a delivery decision or feed a governance review, it should not be produced. This single principle eliminates more unnecessary weight than any other tailoring choice.
Governance scaling
G20F supports scaling governance from a full Architecture Board with formal compliance reviews to a lightweight review and escalation path. The scaling should reflect enterprise risk and scope, not a default assumption that every initiative deserves the same governance weight.
“G20F provides endorsed patterns for tailoring the ADM to different enterprise contexts through iteration, phase selection, artefact selection, and governance scaling.”
The TOGAF Standard, 10th Edition - G20F, Applying the TOGAF ADM: Iteration and Levels
The guide does not weaken the ADM. It acknowledges that proportionate application is better architecture than rigid application. A strategic pass through all phases produces better results than a full-depth pass through the wrong phases.
49.3 The G210 sprint integration model
G210 (Applying the TOGAF ADM using Agile Sprints) addresses the specific question of how ADM work integrates with sprint-based delivery. The guide introduces four concepts that make the integration practical.
Architecture runway
Architecture work runs ahead of delivery sprints, producing just-enough architecture to guide the next sprint cycle. The architecture team maintains a runway of decisions, views, and constraints that delivery teams can consume. The runway is not a complete target-state document. It is a rolling buffer of architectural direction that is always slightly ahead of where delivery currently sits.
The runway concept prevents two common problems. First, it prevents the architecture function from trying to define everything before delivery starts (the waterfall trap). Second, it prevents delivery teams from sprinting into territory that has no architectural guidance at all (the divergence trap from the opening story).
Sprint-aligned reviews
Architecture reviews happen at sprint boundaries rather than in separate governance cycles. This integrates architecture into delivery cadence rather than creating a parallel process. The review at each sprint boundary asks two questions: did the sprint stay within the architecture guardrails, and has the sprint produced any learning that should update the architecture?
Emergent detail
Early ADM phases produce lightweight strategic views. Later phases and subsequent iterations add detail as delivery evidence emerges. This matches the agile principle of progressive elaboration: the enterprise does not try to know everything before it starts, but it does maintain a coherent direction while learning.
Decision-point governance
Rather than reviewing every sprint output, governance focuses on decisions that cross the board-level threshold defined in the decision rights matrix. Sprint-level decisions that stay within published guardrails do not need board review. Decisions that affect cross-domain boundaries, change the target state, or introduce a material deviation do need review, and the sprint boundary is the natural point to escalate them.
Common misconception
“TOGAF is fundamentally incompatible with agile delivery.”
TOGAF can work with agile delivery when the enterprise is explicit about which decisions need central coordination and which can be delegated. G210 shows exactly how ADM phases integrate with sprint cadence. The conflict comes from unclear scope or rigid implementation, not from the method itself.
How decision ownership shifts from the agile team to architecture as the horizon widens
Four cadence steps run left to right. A team lane on top and an architecture lane below show who owns the decision at each step, so neither owner is bypassed as scope widens.
Daily and sprint decisions belong to the team. Programme increment and quarterly decisions cross teams and domains, so architecture owns them. The swimlane forces the handover.
49.4 What should stay stable and what can iterate
The practical question at the heart of agile/architecture coexistence is: which decisions must remain stable across sprints, and which can evolve through delivery learning? Getting this boundary wrong in either direction produces the divergence of too little stability or the bureaucracy of too much stability.
Usually stable across sprints
- Architecture principles. The fundamental rules that constrain design choices across the enterprise. Principles change through governed review, not through sprint-level decision.
- Major boundary decisions. Which domains own which data, where the OT/IT boundary sits, which integration patterns are approved, and how identity is managed across services. These decisions affect multiple teams and cannot be revised unilaterally by one delivery team without creating the divergence problem.
- Authority rules. Who can approve changes to the target architecture, who can grant exceptions, and what the escalation path looks like. These governance rules must survive sprint cadence because they are the mechanism that prevents local convenience from overriding enterprise coherence.
- Transition-state logic. The sequence of transition architectures and the dependency relationships between work packages. Individual sprints deliver within a transition state. They do not redefine the transition sequence.
Often iterative through delivery
- Detail design within guardrails. How a specific service implements an approved integration pattern, which libraries it uses, how it structures its internal data model. These choices can evolve through sprint learning as long as they stay within the published guardrails.
- User-facing refinements.Interface design, workflow optimisation, and feature prioritisation that do not change the architecture's cross-domain boundaries or data authority rules.
- Performance tuning. Configuration changes, caching strategies, and scaling decisions that operate within the approved technology platform.
- Feedback-driven corrections. When delivery learning reveals that an architecture assumption was wrong, the correction should flow back to the architecture through the sprint-aligned review, not be implemented silently as a local override.
The boundary between stable and iterative is not fixed. It depends on the enterprise's risk profile, regulatory context, and the maturity of its governance. But the enterprise must draw the line explicitly. If the boundary is implicit, every sprint planning session becomes a governance negotiation.
49.5 The G188 project-management bridge
G188 (Integration of TOGAF and PRINCE2) addresses the relationship between architecture outputs and project-management discipline. Although PRINCE2 is the named method, the integration principles apply to any structured project-management approach including PMI, MSP, or hybrid frameworks.
G188 establishes three connection points between architecture and project management.
Architecture outputs as project inputs
The Architecture Roadmap, work packages, and transition architectures from Phases E and F become inputs to project initiation. The project inherits the architecture scope, constraints, and conformance criteria. This prevents the common problem of projects defining their own scope independently of the architecture and then claiming compliance after the fact.
Stage gates as compliance checkpoints
Project stage gates become natural points for architecture compliance review. At each stage gate, the project demonstrates conformance with the architecture contract and reports any deviations through the exception process. This means compliance is built into the project cadence rather than being a separate activity that runs in parallel.
Change control alignment
When a project needs to deviate from the agreed architecture, the change request flows through both the project change-control process and the architecture exception process. G188 recommends that these two flows be aligned so that architecture exceptions are recorded in the project risk register and project changes with architecture consequence are escalated to the Architecture Board.
The practical value of G188 is that it prevents architecture and project management from operating as parallel universes. When the connection is working, the project manager knows which constraints come from architecture, and the architect knows which delivery realities are changing the project's ability to conform.
“Architecture decisions provide inputs to project initiation and stage-gate control, creating a traceable link between architecture intent and delivery behaviour.”
The TOGAF Standard, 10th Edition - G188, Integration of TOGAF and PRINCE2
The integration is not administrative. It is the mechanism that prevents architecture from becoming a separate, ignored process. When architecture outputs are project inputs and stage gates are compliance checkpoints, the architecture stays connected to reality.
Agile-to-governance handoff: the escalation ladder a concern climbs
A concern starts with the team and climbs only when a trigger widens its scope. Three triggers promote it across the governance line to an architecture board decision.
Most concerns stay with the team. The ladder names the four triggers that widen a concern's scope until it must cross to the architecture board, so the team knows exactly when to escalate.
49.6 London Grid Distribution: agile coexistence in a regulated utility
London is an interesting agile/architecture case because it has both strong reasons to be agile (the pace of connections reform, customer expectation, and regulatory timescales) and strong reasons to maintain architecture discipline (safety-critical operations, regulatory compliance, and cross-domain dependencies between OT, IT, telecom, and cyber domains).
What should stay stable in London
- The OT/IT boundary architecture and the separation principles that protect operational safety.
- The information authority model that determines which data sources are authoritative for regulatory publication.
- The architecture principles governing interoperability, data publication quality, and customer service coherence.
- The transition-state sequence and the dependency logic between work packages defined in Stage 6.
- The governance escalation path and the decision rights that determine which changes need board review.
What can iterate through delivery in London
- The internal design of individual connection-offer calculation services, as long as they use the approved integration patterns and data authority rules.
- Customer-facing interface refinements that do not change the underlying data model or authority rules.
- Configuration and performance tuning of approved platforms within the published technology standards.
- Process optimisation within individual operational workflows that does not change the cross-domain boundary definitions.
How the architecture runway would work in London
The London architecture team would maintain a rolling runway of decisions and views that delivery sprints consume. Before each sprint cycle begins, the architecture team confirms that the relevant guardrails, integration patterns, and data authority rules are published and accessible. At each sprint boundary, the architecture team reviews whether delivery stayed within guardrails and whether any sprint learning should update the architecture.
The critical discipline is that sprint-level decisions that stay within guardrails do not need board review, but decisions that cross the guardrail boundary must be escalated to the Architecture Board through the sprint-aligned review process. The board meets on a cadence that supports sprint delivery (fortnightly at most, with an emergency path for urgent decisions), not on a quarterly cycle that would block sprint progress.
Three delivery teams in the same enterprise each adopt a different customer-identity model during sprint-level work. No guardrails existed. What does this situation illustrate?
G210 describes an architecture runway that runs ahead of delivery sprints. What is the primary purpose of this runway?
An architecture team requires formal review of every sprint planning session. Delivery velocity drops significantly. What is the most likely cause?
G20F supports entering the ADM at Phase E for a narrow change within an existing target architecture. Why would the enterprise skip Phases A through D?
Key takeaways
- The agile/architecture conflict is usually caused by unclear decision rights and scope boundaries, not by fundamental incompatibility between the methods.
- G20F provides four ADM adaptation patterns: iteration across phases, phase selection, artefact selection, and governance scaling.
- G210 integrates ADM work with sprint delivery through the architecture runway, sprint-aligned reviews, emergent detail, and decision-point governance.
- Some architecture decisions (principles, boundaries, authority rules, transition-state logic) should remain stable across sprints while local design detail iterates.
- G188 connects architecture outputs to project-management discipline through project inputs, stage-gate compliance checkpoints, and aligned change control.
- London needs both agile pace and architecture discipline. The resolution is explicit guardrails with sprint-aligned review, not a choice between speed and governance.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
Part 3, Applying the ADM: adaptation to iterative delivery
The core standard covering how the ADM adapts to iterative and agile delivery contexts.
G20F, Applying the TOGAF ADM: Iteration and Levels
Full guide
Endorsed tailoring patterns for adapting ADM depth and cadence to different enterprise contexts.
G210, Applying the TOGAF ADM using Agile Sprints
Full guide
Guide to integrating ADM phases with sprint-based delivery through architecture runway and sprint-aligned reviews.
G188, Integration of TOGAF and PRINCE2
Full guide
Integration of architecture outputs and project-management discipline, applicable to any structured delivery method.
G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM
Full guide
Practical guidance on proportionate ADM application and delivery integration.
You now understand how architecture and agile delivery can coexist through explicit decision rights, the G210 architecture runway, G20F tailoring patterns, and sprint-aligned governance. The next question is how readiness assessment shapes the migration sequence before the enterprise overcommits. That is Module 50.
Module 49 of 64 · Migration and Delivery