Home / Aerospace and defense program execution
Your engineers want to move fast. Your contract demands traceability, earned value and an integrated master schedule. Both are right. Set Boundaries helps engineering programs run agile where it speeds delivery and traditional controls where the contract and the hardware require them, with clear rules for how the two connect.
Why is agile hard on defense and hardware programs?
Agile methods grew up in software, where a working increment can be built, tested and shipped in weeks and changing direction is cheap. Hardware is different. Long-lead materials are ordered months ahead, tooling is expensive to change, qualification testing is formal and slow, and design reviews are contract events. Defense contracts add earned value reporting, data deliverables and requirements traceability. Programs that apply agile everywhere, or nowhere, struggle. The programs that succeed decide deliberately where each approach belongs.
Where does agile fit, and where does it not?
| Work type | Best approach | Why |
|---|---|---|
| Embedded software and firmware | Agile iterations | Frequent integration and testing catches defects early |
| Early design exploration and trade studies | Agile iterations with timeboxed spikes | Fast learning matters more than detailed prediction |
| Test planning and automation | Agile iterations | Test assets evolve alongside the design |
| Long-lead procurement and manufacturing | Integrated master schedule | Lead times and supplier commitments are fixed and must be planned ahead |
| Qualification and certification testing | Integrated master schedule | Formal, sequenced and gated by facilities and witnesses |
| Contract milestones and design reviews | Integrated master schedule, fed by agile outputs | Contract events with defined entry and exit criteria |
How do agile teams connect to the integrated master schedule?
The integrated master schedule holds the program-level structure: milestones, reviews, procurement, manufacturing, test and the dependencies between them. Agile work appears in it as capability-level tasks or planning packages, each representing a set of features planned for a release, with start and finish dates that reflect the release plan. The agile team manages the detail inside each release in its backlog. When a release slips, the capability task in the schedule moves, and the program sees the effect on everything downstream. That single connection is what lets leadership trust both views.
How does earned value work with agile?
Earned value measures completed work against planned work, and agile delivers completed work in increments. The two fit well when earned value is measured at the capability or feature level. Each capability planned for a release becomes a work package with a budget and objective completion criteria, typically meeting the team's definition of done and passing its acceptance tests. Earned value is claimed when the capability is complete, not when story points are burned. Story points stay with the team as a planning tool, because they are not comparable across teams and should never become the program's unit of measurement. The Department of Defense desk guide on agile and earned value management describes this approach in detail.
Which agile metrics should leadership see?
| Metric | What it tells leadership |
|---|---|
| Capabilities completed versus release plan | Whether the release will deliver what was committed |
| Delivery predictability | How consistently teams complete what they plan each iteration |
| Escaped defects and technical debt trend | Whether speed is being bought with future rework |
| Demonstrations to customer or user | How often real feedback reaches the program |
| Dependency status against the integrated schedule | Whether hardware, supplier and test dependencies will be ready when agile work needs them |
What does a hybrid release cycle look like?
A typical rhythm starts with release planning every few months. The program and the teams agree which capabilities the next release will deliver, checked against hardware availability, supplier deliveries and the next contract milestone. Those capabilities become planning packages in the integrated master schedule and work packages in the earned value baseline. Inside the release, teams run short iterations, usually two weeks, each ending with a demonstration of working capability and an honest review of what was and was not completed. At the end of the release, completed capabilities earn their value, unfinished ones are replanned openly through change control, and the schedule is updated so everything downstream reflects reality. Leadership sees capability-level progress every iteration and a firm picture at every release, which is more frequent and more concrete than most traditional programs provide.
How do design reviews work on a hybrid program?
The formal reviews stay, but agile changes what goes into them. Instead of a design described on slides, the preliminary and critical design reviews can include working prototypes, simulation results and test data from earlier iterations. Teams plan their releases backward from each review's entry criteria, so the evidence the review needs is a planned output rather than a last-minute scramble. Done well, this makes reviews more substantive and reduces the risk of surprises after them.
What goes wrong most often?
Agile as a reason not to plan. The program still needs a credible plan to its commitments. Agile changes how far ahead detailed planning goes, not whether planning happens.
Story points reported as progress. Points measure a team's own estimates, not value delivered. Reporting them upward invites gaming and misleads leadership.
Hardware dependencies ignored. A software team that plans sprints without the hardware delivery dates in view will be blocked at integration.
Traceability lost. Backlog items must still trace to requirements, or verification and data deliverables become a reconstruction exercise at the end.
How is agile used in the Department of Defense?
The Department of Defense has formally embraced iterative development for software through the software acquisition pathway, established in DoD Instruction 5000.87, which emphasizes frequent delivery of working capability and continuous user engagement. Many hardware programs use agile inside a more traditional acquisition structure, particularly for embedded software and systems integration. Contractors increasingly need to show customers that they can deliver iteratively while still meeting earned value, schedule and data requirements.
How does the Set Boundaries method fit teams that work in sprints?
Set Boundaries is not an agile coaching firm, and Holly's programs have been run on integrated schedules rather than formal agile frameworks. But the way she leads engineering teams has a lot in common with what agile teams value, which is why the method sits comfortably alongside teams that already work in sprints.
The core idea is autonomy on how, with clarity on what and when. Holly does not micromanage how engineers do their work. She makes sure the destination, the priorities, the boundaries, the commitments and the escalation paths are clear, then gives people room to use their expertise. A sprint team needs exactly that: a clear view of what matters and what done means, without being told how to build it.
What does the rhythm look like?
The structure is tailored to the program, the customer and the level of risk rather than applied from a template. When the work is critical, the interdisciplinary team holds a short daily stand-up on what moved, what is blocked and who needs help. Once a week the team looks two weeks ahead at the critical path and the decisions it needs. For a team that runs sprints, that fits naturally:
- Each sprint is planned against a look-ahead that already shows hardware, supplier and test dependencies.
- Sprint outputs feed the integrated schedule at the capability level, so leadership sees their effect on milestones.
- Customer requests reach the backlog only through a controlled path, so the team is not pulled into unplanned work mid-sprint.
- Anything that threatens the critical path is raised immediately rather than held for the sprint review.
Why does this matter to engineers?
According to Holly, what former team members valued most was knowing what was expected, working to realistic plans, not having everything treated like an emergency, being able to take a vacation without guilt, and being protected from uncontrolled work while everyone was held accountable. Those are the same conditions good agile teams ask for. Holly puts it this way: "My job is not to make everyone's decisions. My job is to create an environment where good people can execute successfully."
How does Set Boundaries help?
We start by mapping the program's work into what benefits from iteration and what must be planned sequentially, then design the connection: release plans that feed the integrated master schedule, capability-level work packages for earned value, traceability from backlog to requirements, and a reporting set that leadership and the customer can trust. We coach teams and program managers through the first releases until the rhythm holds. The result is the speed engineers want with the control the contract requires, supported by the schedule and baseline management discipline behind it.
If your engineering teams and your program controls are pulling in different directions, schedule a call.
References
- US Department of Defense, Agile and Earned Value Management: A Program Manager's Desk Guide.
- US Department of Defense, DoD Instruction 5000.87, Operation of the Software Acquisition Pathway.
- SAE International and the Electronic Industries Alliance, EIA-748, Earned Value Management Systems.
- US Government Accountability Office, Agile Assessment Guide: Best Practices for Adoption and Implementation.
- National Defense Industrial Association, Integrated Program Management Division, guidance on agile and earned value.
Questions
Common questions
Can agile work on a hardware or defense program?
Yes, in the parts of the program where it fits. Short iterations, frequent demonstrations and prioritized backlogs work well for software, firmware, design exploration and test planning. Hardware procurement, long-lead manufacturing and formal design reviews still need an integrated master schedule and earned value. Most successful defense programs run a hybrid: agile teams inside a controlled program structure, with clear rules for how the two connect.
How does agile fit with earned value management?
By measuring earned value at the level of features or capabilities rather than story points. Each planned capability becomes a work package or planning package with a budget and completion criteria, and earned value is claimed when the capability meets its definition of done. Sprint-level detail stays with the team. The Department of Defense publishes a desk guide on combining agile and earned value management that describes this approach.
Do design reviews still apply on an agile program?
On most defense hardware programs, yes. Reviews such as the preliminary and critical design reviews remain contract events with entry and exit criteria. Agile teams plan their iterations to produce the evidence those reviews need, which often improves the reviews because working prototypes and test results are available earlier than on a purely sequential program.
What is the DoD software acquisition pathway?
It is a Department of Defense acquisition pathway, set out in DoD Instruction 5000.87, designed for software-intensive programs. It emphasizes iterative development, early and frequent delivery of working software and continuous user engagement. Hardware-centric programs usually follow other pathways, but many contain software elements where the same practices apply.
Which agile metrics matter to program leadership?
The ones that predict delivery against commitments: planned capabilities completed versus the release plan, how predictable each team's delivery is sprint to sprint, the trend of defects and technical debt, and how often completed work is demonstrated to the customer or user. Raw velocity is useful to a team but misleading when compared across teams or reported upward on its own.
What is the biggest mistake teams make when adopting agile on a defense program?
Treating agile as a reason to stop planning. Agile replaces detailed long-range task planning with rolling, near-term planning, but the program still needs a credible plan to its commitments, an integrated schedule for the dependencies agile teams do not control, and traceability to requirements. Teams that drop those lose the customer's trust quickly, however fast their sprints feel.
Is agile still relevant in 2026?
Yes. Agile remains the default way most teams build software, and defense acquisition has leaned further into it through the DoD Software Acquisition Pathway and continuous delivery programs. What has changed is the expectation: agile is judged on delivered capability, not ceremonies. On hardware and mixed programs, the question is no longer whether to use agile but where it belongs alongside earned value, design reviews and formal qualification. Set Boundaries helps aerospace and defense programs draw that line deliberately, so software teams iterate quickly while hardware and contract controls stay intact.
What is the 20-30-50 rule in agile methodology?
The 20-30-50 rule is not part of any formal agile standard. It does not appear in the Agile Manifesto, the Scrum Guide or SAFe, and different sources use it to mean different splits of effort or capacity. The useful idea behind most versions is to avoid committing all capacity to planned feature work, and to reserve deliberate portions for discovery, technical debt and unplanned work. On engineering programs we set those reserves explicitly per team, based on measured history, and tie them to the program schedule rather than borrowing a fixed ratio.
What are the four pillars of agile?
The four pillars of agile usually refer to the four values of the 2001 Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The manifesto states that the items on the right still have value, which matters on defense work where contracts, documentation and plans are obligations. Set Boundaries applies those values within contract constraints, keeping the traceability and data deliverables the customer requires while shortening feedback loops wherever the work allows.
Is EVM a KPI?
Earned value management is a management system, not a single KPI, but it produces several metrics that programs use as KPIs. The most common are the cost performance index (CPI), the schedule performance index (SPI), cost and schedule variance, and the estimate at completion. A CPI below 1.0, for example, means the work is costing more than budgeted. On agile programs, these indices work best when earned value is tied to completed, accepted features rather than hours spent, which is how Set Boundaries connects agile delivery to EVM reporting.
What are the 5 phases of agile project management?
The five phases most often cited come from Jim Highsmith's Agile Project Management model: envision, speculate, explore, adapt and close. Envision sets the product vision and team, speculate builds a feature-based release plan, explore delivers increments, adapt reviews results and adjusts the plan, and close captures lessons and completes the work. It is a widely referenced framework rather than a formal standard. On defense programs, these phases have to line up with contract events such as design reviews and test milestones, which is where Set Boundaries focuses its integration work.
Have a question that is not here? Ask Holly on a short call
