Making the Process Work (Scrum/Kanban/SAFe)
Agile frameworks should accelerate Rust delivery, not bury it in ceremony. Adapt Scrum, Kanban, or SAFe so CI compile times, migration gates, and on-call load are visible - Definition of Done includes staging deploy, not only merged PR.
Recipe
Quick-reference recipe card - copy-paste ready.
## Definition of Done (Rust squad)
- [ ] `cargo test` + `clippy -D warnings` green
- [ ] Integration test or acceptance from spec
- [ ] `tracing` spans on new user-facing paths
- [ ] Deployed to staging; PM acceptance or ticket waiver
- [ ] Rollback/flag noted in release notes if risky
- [ ] Docs/runbook updated if on-call impactWhen to reach for this:
- Process friction blocking releases
- SAFe PI planning overhead vs value
- Board columns do not match review bottleneck
- "Done" at merge but prod unchanged
Working Example
## Kanban WIP limits
| Column | WIP |
|--------|-----|
| In progress | 2 per engineer |
| In review | 4 team-wide |
| Staging verify | 3 |
## Blocked policy
CI >45 min: platform ticket; do not start new L migrationReview column limit forces pairing on large PRs instead of queue stall.
Deep Dive
Scrum Adaptations
- Sprint planning - Capacity minus on-call and platform %; no L migrations without spike done.
- Daily standup - Blockers include CI, DBA windows, security review.
- Sprint review - Demo from staging SHA, not laptop only.
- Retro - One experiment per sprint (e.g., smaller PRs, faster review SLA).
Kanban for Ops-Heavy Squads
- Visualize staging deploy and prod promote as separate columns.
- Class of service: expedite (hotfix), standard, debt.
- Measure cycle time merge-to-staging, not story points.
SAFe Trimming
Keep: PI objectives, dependency mapping, architecture sync. Cut: vanity metrics, duplicate status meetings, documentation no engineer reads. Rust platform team as enabler, not approval bottleneck for every crate bump.
Gotchas
- Done = merged - Prod unchanged weeks. Fix: Staging deploy in DoD.
- Infinite WIP - Review latency. Fix: WIP limits + rotate reviewers.
- Retro actions vanish - Fix: One tracked experiment ticket per retro.
- SAFe every ceremony - Engineer cynicism. Fix: Negotiate minimum viable with EM.
- Ignoring compile CI in planning - Fix: Capacity discount during workspace splits.
Alternatives
| Alternative | Use When | Don't Use When |
|---|---|---|
| Shape Up | Fixed appetite cycles | Heavy compliance gate per sprint |
| Trunk-based + flags | Continuous delivery mature | Weak test culture |
| Scrumban | Support + feature mix | Team wants fixed sprint commitment |
| No sprints, flow only | Kanban native team | External date milestones need forecasting |
FAQs
Story points for Rust migrations?
Use eng-days in planning poker anchor or separate migration epic tracking.
PI planning for Rust platform?
Show dependency graph: edition bump blocks three squads - align trains.
On-call in sprint capacity?
Deduct 10-20% when primary on-call that sprint.
Bug interrupt policy?
Kanban expedite lane with WIP 1; EM approves scope swap.
SAFe ART for one service?
Usually overkill; adopt dependency board only.
Remote ceremonies?
Async spec review; sync for planning and retro only.
PM acceptance on staging?
Required for customer-facing; waiver with ticket for internal debt.
Velocity after Rust adoption?
Expect 2-3 sprint calibration; do not compare to old stack prematurely.
Process metrics?
Lead time, review wait, CFR - not hours in meetings.
When change process?
Retro experiment runs 2 sprints; revert if worse on metrics.
Related
- Estimation & Risk - planning honesty
- Delivery Best Practices - shipping DoD
- Code Review Culture - review WIP
- CI Config for Rust - pipeline reality
- Product Collaboration Best Practices - summary
Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.