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 impact

When 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 migration

Review 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.

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+.

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 impact

When 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 migration

Review 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

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.

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+.

Making the Process Work (Scrum/Kanban/SAFe)

Buscar en la documentación

Making the Process Work (Scrum/Kanban/SAFe)