A real user, in week three.
Software nobody has used is a guess with a burn rate. So the first slice goes in front of the floor early — usually the intake path, because that is where being wrong is cheapest to correct.
Thirty minutes · no predetermined package
Slices, not phases.
A phase ends with a demo. A slice ends with somebody's actual job being different.
The first slice is the riskiest assumption, not the easiest piece of work.
Tests, logging and error reporting ship with the feature rather than after it.
Everything goes to staging first, with a rollback path that has been tested rather than assumed.
Releases are small and frequent, so a bad one costs an hour rather than a week.
The people who will use it see it before it is finished, which is uncomfortable and correct.
What we learn from slice one changes slices two through five, on purpose.
Six things that predict whether a build goes wrong.
What people ask about delivery.
What is a slice?
A piece of software a real person can do their job with. Not a module, not a demo — the intake path working end to end for one team, then the next piece.
Why start with the riskiest part?
Because that is where the assumption is most likely wrong, and week three is a much cheaper place to find out than week twenty.
How often do you release?
Small and frequent, staged before production, with a rollback path that has been tested. Batching releases is how a bad change becomes a bad week.
What happens when the plan changes mid-build?
It is measured against the signed architecture rather than argued about. That document exists so a change is a decision.
Do we get access during the build?
Yes — to the repository, the staging environment and the release notes. It is your code from the first commit.
What about testing?
Written with the feature. Test coverage added afterwards tends to test what the code does rather than what it should do.