Lesson 0047 · Initiative Lead · Module 3
Plan the Walking Skeleton
A delivery plan should retire uncertainty, not arrange component tasks. Connect the real path early, then grow behavior through thin, demonstrable slices.
Mission tie-in: execution is where architecture meets sequence. The order of work determines how long assumptions can hide and how expensive integration becomes.
Knowledge: prove the path before filling it in
A walking skeleton is the thinnest production-shaped implementation of an end-to-end path: code enters the real build, deploys through the real pipeline, crosses the chosen boundaries, touches representative storage and integration seams, emits telemetry, and can be exercised by the team. Its business behavior may be deliberately tiny; its delivery path is real.
For returns, the skeleton lets an internal test customer submit one hard-coded eligible item, stores a return intent, calls a fake carrier adapter through the real port, shows pending label, and records a trace and outcome event in a production-like environment. It does not yet contain the full policy engine, all designs, or a real customer rollout.
Sequence the delivery map by four forces:
- Learning: put the highest-impact weak assumption where the team can test it early.
- Technical risk: exercise the unfamiliar integration, migration, load, or security boundary before easy screens fill the calendar.
- Dependency: obtain sandbox access, legal decisions, data contracts, and operational ownership before they block a finished feature.
- Value: keep each increment coherent enough to demonstrate in user language and release to a controlled cohort.
| Milestone | Evidence produced | Exit condition |
|---|---|---|
| Path walks | one request deploys, persists, crosses adapter, and traces | repeatable from clean build; failure visible |
| Policy works | sampled rules pass executable examples | domain owner accepts decisions and reasons |
| Team uses it | internal users complete accessible happy and refusal paths | no severity-one usability or security issue |
| Pilot learns | 50 real users expose outcome and guardrail measures | pre-agreed continue, change, or stop threshold |
| Scale earns | load, recovery, support, and ownership are proven | rollout gates from lesson 0049 pass |
Map external dependencies separately with an owner, needed-by date, evidence of readiness, fallback, and escalation point. “Waiting on platform” is not a plan. “Asha owns sandbox credentials by Tuesday; fake adapter lets skeleton proceed; escalate to platform lead Wednesday” is.
Forecast ranges from throughput and uncertainty; do not convert a feature list into false precision. State what is fixed—outcome, date, scope, or team—and which variable can move. For a date-bound pilot with a fixed team, scope is the control surface. Reforecast when evidence changes, not only when the original date becomes impossible.
Keep technical enabling work attached to the slice it enables. A small schema migration, contract test, alert, and adapter are part of “eligible customer reaches pending label.” A free-floating “architecture runway” becomes infrastructure nobody has yet earned.
| Planning smell | What it delays | Replace with |
|---|---|---|
| backend sprint then frontend sprint | Integration and usability evidence. | One end-to-end skeleton. |
| “carrier integration: 80%” | The unknown last behavior. | Demonstrable exit condition. |
| platform dependency, no owner | Escalation until too late. | Owner, date, fallback, trigger. |
| six-week infrastructure phase | Whether users value the path. | Enabling work inside slices. |
Skill: sequence for evidence
The walking skeleton should first prove:
Which milestone reports useful progress?
For a fixed-date, fixed-team pilot, vary:
Practice: redraw the plan around proof
Take an initiative plan organized by components or epics. Define its walking skeleton in one sentence. Replace percentage milestones with five evidence milestones. For each external dependency, add owner, needed-by, readiness evidence, fallback, and escalation trigger. State which planning variable can move.
Reveal: a useful skeleton sentence
“From the main branch, deploy one internal-user return request through the production pipeline; persist its intent, cross the carrier port with a fake, render pending status, and find the complete request by correlation id.” It is small, demonstrable, operationally real, and ready to receive behavior.
Your win
You can build a delivery map that integrates early, retires the largest risks first, makes dependencies actionable, and reports progress as working evidence.
Read and watch deeper
- Growing Object-Oriented Software, Guided by Tests, Freeman & Pryce — ch. 4: the walking skeleton and end-to-end feedback.
- User Story Mapping, Jeff Patton — release slices, learning strategy, and development strategy.
- Accelerate, Forsgren, Humble & Kim — ch. 4: small batches, deployment capability, and delivery performance.
- Reference: Initiative Playbook · skeleton, milestone, and dependency map.
Ask your agent-teacher to challenge every milestone with “what can we now demonstrate or decide that we could not before?”