by Jonathan W. Lartigue, PhD
August 2026
Organizations do not suffer from a shortage of plans. Most have strategic objectives, annual operating plans, multiyear investment roadmaps, transformation programs, regulatory commitments, and portfolios of proposed projects extending four or more quarters into the future. These plans are the organizational engine: they generate direction, investment, and the power needed to move the business.
Agile teams, however, operate much closer to the road. They deliver increments of value, discover technical constraints, receive customer feedback, and adjust their plans as new information becomes available. They are the organization’s wheels and tires—the point where strategic ambition encounters operational reality.
An engine and wheels are both necessary, but neither can move a vehicle independently. Between them sits the transmission: a system that converts the engine’s power into usable torque, adjusts to different operating conditions, and transfers that power to the wheels.
Organizations need an equivalent planning-to-execution transmission. Its purpose is not to convert multiyear strategic plans into equally detailed multiyear team commitments. Rather, it must translate strategic intent into progressively refined, prioritized, capacity-aware, and testable work. It must preserve the direction established by enterprise leadership while allowing Agile teams to learn, adapt, and determine how value should actually be delivered.
Agile Is Not the Absence of Planning
One of the most persistent misconceptions about Agile is that Agile teams resist planning. The Agile Manifesto does not reject plans. It states a preference for “responding to change over following a plan” while explicitly acknowledging that the items on the right still have value (Beck et al., 2001).
The distinction is important. Agile rejects neither strategic direction nor responsible forecasting. It rejects the assumption that a plan created before execution begins will remain correct despite emerging customer, market, and technical constraints become clear.
Martin Fowler describes Agile planning as a process in which “the plan changes frequently but in a controlled manner.” In a well-managed Agile system, introducing new work requires an explicit trade-off: when something is added, something else must be delayed, reduced, or removed. Agile planning is therefore disciplined rather than casual. It exposes the consequences of changing priorities instead of hiding them inside overloaded backlogs and unrealistic commitments (Fowler, 2005a).
Fowler further distinguishes between planning horizons. Long-term plans remain useful for establishing direction, but they should be comparatively fluid. Near-term plans become progressively more specific because they are informed by better evidence and are closer to execution (Fowler, 2005b).
This is analogous to driving. A driver may know the destination hundreds of miles in advance, but steering decisions are made continuously. The route provides direction; it does not determine every movement of the steering wheel before the journey begins.
The Engine: Enterprise Strategy and Long-Range Planning
The organizational engine answers consequential questions:
- What markets, customers, missions, or capabilities matter most?
- What outcomes must the enterprise achieve?
- Which investments deserve funding?
- What regulatory, financial, architectural, or operational constraints apply?
- How should scarce capacity be allocated across competing opportunities?
These decisions require a longer planning horizon than a team backlog. Executives may need Q+4 forecasts, multiyear capital plans, contractual milestones, workforce strategies, broad sequencing assumptions, and a mapping of all of this into annual strategic plans, OKRs, or improvement targets. The problem is not that such planning exists; the problem arises when long-range planning produces detailed scope, dates, and resource assignments that are treated as immutable facts.
Detailed plans created far in advance often contain more precision than the available evidence can support. Once these plans become business commitments, teams may be evaluated on conformance to assumptions made before discovery began. This can cause leaders to interpret learning as failure, scope changes as poor discipline, and evidence-based adaptation as resistance to planning or as the failure of an agile transformation.
The better purpose of long-range planning is to establish intent, investment boundaries, measurable outcomes, and decision guardrails. It should determine where the organization intends to go and why the destination matters. It should not attempt to prescribe every action teams will take after they encounter the road.
Eric Ries captured the risk of conformance-oriented planning with a powerful question: “What if we found ourselves building something that nobody wanted?” Delivering unwanted scope on time and within budget is not strategic success. It is efficient execution of the wrong idea (Ries, 2011; Scaled Agile, 2025a).
The Wheels: Agile Teams and Empirical Execution
Agile teams work in an environment of uncertainty. Requirements evolve, technologies behave unexpectedly, integrations expose dependencies, and users frequently react differently than planners predicted. Teams therefore need short feedback loops through which they can inspect results and adapt their approach.
The Scrum Guide states that Scrum uses “an iterative, incremental approach to optimize predictability and to control risk.” Its empirical foundation rests on transparency, inspection, and adaptation. These concepts apply beyond Scrum: uncertainty is controlled not by pretending that uncertainty does not exist, but by shortening the interval between action, evidence, and correction (Schwaber & Sutherland, 2020).
The wheel in the metaphor therefore represents more than rapid activity. Its Plan–Do–Check–Act cycle represents a learning system:
- Plan the next achievable increment.
- Do the work needed to produce an integrated result.
- Check the result through demonstrations, operational data, customer feedback, and outcome measures.
- Act on what has been learned by adjusting the product, backlog, architecture, or strategy.
Teams cannot perform this role effectively when they are treated merely as recipients of centrally generated tasks. Jim Highsmith argued that Agile organizations must do more than call people important; they must actually “act as if people were the most important.” Agile depends on trust, collaboration, and communities capable of making responsible decisions—not simply on ceremonies or terminology (Highsmith, 2001).
The Transmission: A Deliberate Planning-to-Execution Interface
The organizational transmission is the set of roles, practices, cadences, artifacts, and decision rules that connects enterprise planning to team execution. It performs several essential transformations.
First, it translates broad strategic aspirations into measurable outcomes. A goal such as “modernize the customer experience” is too abstract for execution. A fixed directive to “replace the customer portal by December” may be too solution-specific. The transmission should express the desired customer and business outcomes, the relevant measures, the investment boundary, and the constraints within which teams may explore solutions.
Second, it progressively decomposes work. Multiyear strategies should not arrive at teams as thousands of predetermined stories. Strategic objectives should become initiatives or epics; epics should be tested through analysis and minimum viable products; validated opportunities should become features or capabilities; and teams should decompose near-term features into executable work only when sufficient knowledge exists.
Third, the transmission matches demand to capacity. Strategy creates more potential work than the organization can execute. Without explicit prioritization and work-in-process controls, every initiative becomes urgent, teams become fragmented across projects, and cycle times increase. A transmission must force economic choices: what should begin, what should wait, what should stop, and what capacity must remain available for unplanned work, technical health, and emerging opportunities.
Fourth, it enables information to travel in both directions. A mechanical transmission does not merely send power outward; it responds to load, speed, and terrain. Likewise, an organizational transmission must return evidence from teams to portfolio leadership. Customer response, delivery performance, architectural discoveries, risk, and changing estimates must influence future investment decisions.
How SAFe Defines Elements of the Transmission
Scaled Agile Framework guidance provides several mechanisms that can serve as components of this organizational transmission.
At the portfolio level, Strategic Themes express portfolio-level business objectives and connect enterprise strategy with portfolio decision-making. Scaled Agile recommends stating these themes as concise, actionable, measurable goals—often using an Objective and Key Results structure—so that Agile Release Trains and teams understand the business context behind their work (Scaled Agile, 2025b).
This context matters because decentralized decisions are only effective when teams understand the direction of the enterprise. Strategic themes should not become slogans displayed above a portfolio board. They should guide prioritization, investment, trade-offs, PI Objectives, and decisions about which work should not proceed.
The Portfolio Backlog and its Kanban system provide the next stage of translation. Scaled Agile defines the Portfolio Backlog as a system for capturing and managing business and enabler epics. Its flow-based approach allows portfolio leaders and stakeholders to increase investment gradually as an epic moves through discovery, analysis, approval, and implementation. Initiatives may be advanced, revised, delayed, or stopped as evidence improves (Scaled Agile, 2025c).
This is a critical transmission function. Instead of converting every strategic idea immediately into a funded project, the portfolio Kanban creates decision points. Each stage asks whether the opportunity remains valuable enough to justify additional capacity.
SAFe epics also require explicit outcomes, business benefits, an MVP, a Lean business case, and cost estimates. These mechanisms shift governance away from approving a complete speculative solution and toward funding a testable investment hypothesis (Scaled Agile, 2025a).
At the Agile Release Train level, PI Planning synchronizes business context, priorities, dependencies, capacity, and team planning. Scaled Agile describes PI Planning as a cadence-based event that aligns teams and stakeholders around a shared mission and vision. Importantly, SAFe emphasizes that the people who perform the work participate in planning the work. PI Planning is intended to expose dependencies, match demand to capacity, establish objectives, and enable rapid decisions—not merely communicate a plan created elsewhere (Scaled Agile, 2026a).
Finally, the System Demo closes the feedback loop. It gives stakeholders an integrated view of working features and provides an objective measure of progress toward PI Objectives. Feedback from the demo informs subsequent team work and portfolio decisions. This replaces status reporting based primarily on completed activities with evidence based on an operating solution (Scaled Agile, 2026b).
Together, strategic themes, portfolio Kanban, epics, PI Planning, PI Objectives, and System Demos form much of the gearbox required to translate strategy into delivery and delivery evidence back into strategy.
Principles for Designing an Effective Transmission
An effective planning-to-execution system should follow six principles.
- Translate strategy into outcomes, not task lists. Leaders should define the problem, intended outcome, economic significance, measures, constraints, and investment boundary. Teams should retain meaningful authority over solution design and execution.
- Increase precision as work approaches execution. Long-range plans should describe direction, assumptions, major dependencies, and investment ranges. Near-term plans may contain greater specificity because teams possess better information. Precision should be earned through learning rather than manufactured through early documentation.
- Separate commitment to an outcome from commitment to fixed scope. The organization may firmly commit to improving an outcome while remaining flexible about which features will achieve it. Scope is a variable that can be adjusted as evidence emerges.
- Limit work in process at every level. Teams cannot compensate for an overloaded portfolio. Portfolio leaders must limit the number of initiatives entering implementation, just as teams limit concurrent stories. Starting less work frequently produces more completed value.
- Use synchronized cadences without forcing identical methods. Portfolio reviews, roadmap updates, PI Planning, system demonstrations, and team replenishment can operate on connected cadences. Scrum, Kanban, and other team approaches do not need to be identical, but their planning and feedback points must support enterprise-level coordination.
- Govern through evidence and guardrails. Governance should examine outcomes, working solutions, leading indicators, financial consumption, risk, and flow. Milestones should represent evidence-based decision points, not merely dates by which teams must report that planned activities occurred.
From Plans to Progress
The engine–transmission–wheels metaphor reveals why many Agile transformations stall. Organizations may create strong Agile teams while leaving portfolio planning, annual budgeting, project approval, and governance unchanged. The wheels become more capable, but the engine’s power still reaches them through a rigid, inefficient coupling.
Conversely, portfolio modernization without empowered delivery teams creates a sophisticated transmission connected to wheels that cannot turn independently.
Business agility requires the entire drivetrain. Enterprise leadership must provide purpose, investment, and constraints. The planning-to-execution transmission must translate that intent into prioritized, capacity-aware, progressively refined work. Agile teams must convert that work into integrated value while continuously generating evidence.
The objective is not to make long-range strategy Agile by eliminating planning. Nor is it to make Agile teams predictable by freezing their work years in advance. The objective is to create a system in which strategy sets direction, the transmission enables alignment, and Agile teams turn organizational power into measurable movement.
Dr. Jonathan W. Lartigue is an associate director for business and program management in the aerospace and defense industry. He is an engineering process expert and Advanced SAFe Practice Consultant with more than 17 years of experience in training and leading agile teams. He holds a master’s degree in software engineering and a PhD in computer science and software engineering from Auburn University.
© Copyright 2026. All rights reserved.
1. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile software development. https://agilemanifesto.org/
2. Fowler, M. (2005, October). Five pound bag. MartinFowler.com. https://martinfowler.com/bliki/FivePoundBag.html
3. Fowler, M. (2005, December). The new methodology. MartinFowler.com. https://martinfowler.com/articles/newMethodology.html
4. Highsmith, J. (2001). History: The Agile Manifesto. Agile Manifesto. https://agilemanifesto.org/history.html
5. Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Business.
6. Scaled Agile, Inc. (2025). Epic. Scaled Agile Framework. https://framework.scaledagile.com/epic/
7. Scaled Agile, Inc. (2025). Portfolio backlog. Scaled Agile Framework. https://framework.scaledagile.com/portfolio-backlog/
8. Scaled Agile, Inc. (2025). Strategic themes. Scaled Agile Framework. https://framework.scaledagile.com/strategic-themes/
9. Scaled Agile, Inc. (2026). PI planning. Scaled Agile Framework. https://framework.scaledagile.com/pi-planning/
10. Scaled Agile, Inc. (2026). System demo. Scaled Agile Framework. https://framework.scaledagile.com/system-demo/
11. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The definitive guide to Scrum. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
Artificial intelligence was utilized in production of the images associated with this article.
