Scaled Agile Framework (SAFe) has become the dominant delivery methodology on large defense and federal programs. Programs using SAFe organize delivery around Agile Release Trains (ARTs) with coordinated Program Increments (PIs) — typically 8-12 week intervals with synchronized planning, execution, and review ceremonies across all teams. When subcontractors are part of the ART, they must integrate with SAFe cadences, not operate independently beside them.
Here's how Rutagon integrates as a cloud engineering subcontractor in SAFe-aligned defense programs.
What SAFe Integration Means for a Cloud Sub
A subcontractor on a SAFe program isn't just delivering work — they're a team within the ART. The practical implications:
PI Planning participation: Every PI cycle (8-12 weeks) begins with a 2-day PI Planning event where all teams identify their objectives and interdependencies. As a cloud infrastructure sub, Rutagon teams identify their PI objectives (what cloud capabilities will be delivered this PI), flag dependencies on other teams (API consumers who need environment readiness), and make capacity commitments visible to the prime program manager.
Sprint ceremonies: SAFe teams run 2-week sprints. Sub teams participate in sprint planning, daily standups (or asynchronous equivalents for distributed teams), sprint reviews, and retrospectives. Sprint reviews must produce demonstrable working software — cloud subs demo deployed infrastructure, working pipelines, or new monitoring capabilities, not status updates.
ART sync: Weekly or bi-weekly ART-level synchronization surfaces impediments and cross-team dependencies. Cloud infrastructure teams frequently surface as dependency owners — other teams can't complete their features until the environment is available. Proactive identification of infrastructure dependencies at PI Planning prevents last-sprint scrambles.
Inspect and adapt: End of each PI, the ART conducts an Inspect and Adapt workshop. Subcontractor performance, including cloud delivery reliability and dependency fulfillment, feeds into ART-level retrospective actions.
Sprint Delivery Structure for Cloud Engineering
Rutagon's sprint delivery structure on SAFe programs:
Sprint planning (Monday, 2-4 hours): Review PI objectives, pull user stories and technical enablers from the team backlog, estimate capacity (accounting for ceremony time and unplanned work budget), and commit to sprint goals.
Execution (Days 2-8): Infrastructure development, code review, STIG scanning, and automated testing. Cloud changes managed through IaC review + automated compliance gate before apply.
Demo preparation (Day 9): Identify demonstrable artifacts — deployed environment, working CI/CD pipeline, monitoring dashboard, successfully completed migration milestone.
Sprint review (Day 10): Demonstrate to prime stakeholders and program team. Cloud demos must show working functionality, not architecture slides. A new EKS cluster with STIG-compliant configuration deployed via Terraform + passing CI pipeline is a demo; "we configured the cluster" is not.
Retrospective: Capture what slowed delivery, what worked well, and what process changes are needed. Recurring infrastructure impediments — unresponsive firewall change request processes, slow cloud provisioning approvals, missing environment access — get elevated to ART-level impediment lists.
ATO Evidence in SAFe Cadence
A challenge unique to SAFe cloud delivery in defense programs: ATO evidence generation must align with the sprint cadence without creating a compliance drag on delivery velocity.
Rutagon's approach: evidence is a pipeline output, not a manual process. Security scan reports, infrastructure compliance scan results, and container signing attestations are generated automatically during the CI/CD pipeline and tagged to the Sprint commit SHA. At the end of each PI, the ATO evidence package is assembled from sprint artifacts — no manual document production required.
The benefit for primes: continuous evidence generation means ATO packages are always current. Instead of a 3-month ATO evidence sprint before authorization deadline, the evidence is ready daily.
# Evidence collection stage in CI/CD (runs on every deployment)
collect-evidence:
stage: .post
script:
- bundle-evidence.sh \
--sprint=${CI_MERGE_REQUEST_MILESTONE} \
--pipeline=${CI_PIPELINE_ID} \
--scans=reports/ \
--infra-scan=terraform-compliance-report.json \
--sbom=cyclonedx-sbom.json
artifacts:
paths:
- ato-evidence-${CI_PIPELINE_ID}.zip
expire_in: 365d
Explore teaming with Rutagon on SAFe defense programs → rutagon.com/contact
Frequently Asked Questions
Does Rutagon hold SAFe certifications?
Rutagon cloud engineers have worked within SAFe-aligned program execution environments and are familiar with PI Planning, ART ceremonies, and sprint-based delivery within large program structures. Rutagon's delivery methodology aligns with SAFe sprint cadences regardless of specific team certification level — the ceremonies and artifacts are the same.
How does a cloud sub handle dependencies with development teams in SAFe?
Cloud infrastructure teams are dependency owners for environment readiness. Best practice: cloud teams identify environment-level dependencies at PI Planning (e.g., "Team A needs the dev/IL2 environment ready by Sprint 3, Week 1"), commit to those dates as PI objectives, and communicate proactively if timeline risk emerges. The biggest SAFe failure mode for cloud subs is undisclosed dependencies surfacing mid-sprint.
What does PI Planning look like for a cloud engineering team?
Cloud teams bring their team backlog to PI Planning — typically a mix of infrastructure user stories ("As a developer, I need a STIG-compliant dev environment"), technical enablers ("Implement automatic STIG scanning in the CI pipeline"), and program-level features ("Complete GovCloud migration for Service X"). During the 2-day session, the team capacity-plans against the PI calendar, identifies feature dependencies on other teams, and declares PI objectives with a confidence vote.
How does SAFe handle unplanned work for cloud teams?
SAFe teams reserve a portion of sprint capacity for unplanned work — typically 10-20%. Cloud teams often face higher unplanned work rates than application teams due to infrastructure issues (security patching urgency, cloud service changes, environment degradation). Rutagon's practice: track the unplanned work percentage each sprint in the retrospective, and if consistently above 30%, advocate for a program-level recognition of the cloud team's operational responsibilities and adjust PI commitments accordingly.
What reporting does Rutagon provide to prime program managers?
Rutagon delivers sprint review documentation (demo artifacts + sprint goal completion status), PI-level progress against PI objectives (feature delivery, enabler completion, ATO evidence milestones), and standard program status reporting in the format required by the prime's program management office. Rutagon adapts reporting formats to the prime's tooling — JIRA dashboards, SharePoint status reports, or program management tool exports.