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.
A walking skeleton works because it front-loads the discovery of environmental facts, and environmental facts are the ones estimates are worst at. An estimate is assembled from imagined work: the classes, the screens, the rules. It cannot contain the release train that runs twice a week, the sandbox that only answers an allow-listed IP, the migration that takes a lock, or the credential that requires a nine-day ticket. None of that is hard; all of it is invisible until something real travels the path. The skeleton converts unknown environmental cost into a measured cost in week one, while the plan can still absorb it.
Its second effect is habit. Batch size dominates delivery risk, and a path that has carried one change can carry a hundred; a path that has never carried anything will produce its first surprise at the worst possible moment, which is the day the deadline depends on it.
The boundary is straightforward: when the path already exists, the skeleton is redundant. Adding a feature to a live system with a working pipeline does not need one—the equivalent move is the thinnest slice through the new boundary only. And a skeleton that runs on a fake path proves nothing. If it deploys from a laptop script into an environment nobody else uses, you have measured the laptop.
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.
How the lead actually sequenced it
Week 2, before the story map is finished. The lead proposes spending the first two engineer-weeks on a skeleton that returns a hard-coded approved and a fake carrier label. The question she used to justify it was not “what is most valuable?” but what in this plan have we never done before? Two answers came back: deploying into the order platform's release train, and getting a carrier sandbox credential. Neither is a feature. Both are on the critical path of every feature.
Marta, the product manager, objects, and her objection is legitimate: two weeks with no user value, against a 30 September pilot date, is not obviously affordable. The lead does not win the argument by asserting engineering judgement. She reframes the spend—the skeleton is the pilot date's insurance—and then buys the objection off with a constraint: eight working days, with a stop rule that if the path is not walking by day eight, the sequencing problem is escalated rather than absorbed.
The alternative she rejects is the comfortable one: design the policy engine while platform access is arranged in the background. It feels efficient and it is exactly wrong, because it lets the unknown wait while the known progresses. Uncertainty does not shrink while you ignore it; it just arrives later, with more work stacked behind it.
Day 3 returned the first fact: the order platform's release train runs twice a week, not on demand. That single number changed the rollout stage durations in lesson 0049—a stage gate that assumes same-day reversal is a fiction when the next train is Thursday—and it is why the team invested in a configuration flag that can be flipped without a deploy. Day 6 returned the second: the carrier sandbox requires an allow-listed egress IP, a nine-day platform ticket. Discovered in week 2, it cost nothing; discovered in week 8, when the eligibility engine was ready and waiting for a real label, it would have cost the pilot date.
| 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. |
- The walking skeleton is a prototype.
- A prototype is thrown away; a skeleton is grown. Its code is production code with almost nothing in it, which is why it must go through the real build, the real pipeline, and the real boundaries.
- A skeleton is “hello world in production”.
- It must cross the boundaries you actually chose and emit the telemetry you will actually use. A page that returns 200 from a new service proves the deploy button works and nothing else.
- Risk-first means doing the hardest thing first.
- It means doing the most uncertain thing first. Hard-but-known work is schedule and can be planned around; uncertain work is risk and cannot. Teams routinely sequence the difficult, familiar work early and feel productive while the unknown waits.
- A forecast range is hedging.
- A single date is the hedge: it conceals variance the team already knows about and removes the sponsor's chance to trade scope while trading is still possible. A range with a named cause is the more accountable answer, not the softer one.
When this is the wrong move
Skip the skeleton when the path is already proven and unchanged—an existing service with a working pipeline, where the new work crosses no new boundary. Skip it when an identical environment already exists next door: copy the pipeline and spend the time on the boundary that is genuinely new. And notice the case that looks like a reason to skip it but is not: if the skeleton would take six weeks because the platform work does not exist, that is not evidence the skeleton is too expensive. It is evidence that the platform work is the initiative, and the honest move is to say so before the plan is built on the assumption that it is free.
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.
In the lab and the capstone. The lab's phase-4 checkpoint has you walk one request through the lab system end to end and prove it with telemetry rather than a screenshot. The worked artifact is the walking skeleton and delivery map in the strong capstone packet, where every milestone names the evidence it produces and every dependency has an owner, a date, and a fallback. Compare with the weak version: phases named after components, percentage-complete milestones, and a dependency listed as “waiting on platform”.
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.
- In two sentences, explain to a new lead why the first thing to build is the thing with the least business value.
- Take your current plan and answer one question: what is in it that this team has never done before? Then say where that work currently sits in the sequence.
- Predict the failure: if a team defers integration to the final three weeks, what does week nine look like, and which dependency will they discover they needed a month earlier?
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.
- Crystal Clear, Alistair Cockburn — the origin of the walking skeleton as a delivery strategy rather than a prototype.
- 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?”