Agile, sprints, project management, and architecture change

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.

1. 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.
2. 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.
3. 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.

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.

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.

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 failures described in the opening story (too little stability) or the bureaucracy described in the 47-templates story from Module 56 (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.

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.

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.