# How I change delivery when scope stops being honest Source: https://manaienko.com/how-i-work/delivery-when-scope-stops-being-honest/ Author: Artem Manaienko A date that keeps moving is a decision nobody made. One primary capability defines a release, a material scope change forces re-estimation, and the trade-off gets picked in the open by the people who own it. ## My principles 07 operating rules 1. [01 A date that keeps moving is a decision nobody made](#practice-delivery-when-scope-stops-being-honest-principle-1) 2. [02 One primary capability defines the release](#practice-delivery-when-scope-stops-being-honest-principle-2) 3. [03 Compatible work rides along, it does not expand mandatory scope](#practice-delivery-when-scope-stops-being-honest-principle-3) 4. [04 A material change to the primary feature forces re-estimation](#practice-delivery-when-scope-stops-being-honest-principle-4) 5. [05 The trade-off belongs to the people who own it](#practice-delivery-when-scope-stops-being-honest-principle-5) 6. [06 Expect the delays to stay](#practice-delivery-when-scope-stops-being-honest-principle-6) 7. [07 Baseline it before you change it](#practice-delivery-when-scope-stops-being-honest-principle-7) ### A date that keeps moving is a decision nobody made When a schedule absorbs every scope change, the choice between scope, date and quality never reaches a person who can make it. The date is doing the deciding, and it is deciding badly. ### One primary capability defines the release The release is that capability and the condition that says it is ready. Without a single purpose nothing defines readiness, so readiness becomes whatever the calendar says it is. ### Compatible work rides along, it does not expand mandatory scope Fixes and secondary changes ship alongside the primary feature, which keeps them from becoming blockers. What they may not do is grow the set of things the release cannot go out without. ### A material change to the primary feature forces re-estimation The moment a changed requirement invalidates an architecture assumption, the estimate is gone. Redoing it out loud, right then, is the whole mechanism. Absorbing it into the schedule is the failure. ### The trade-off belongs to the people who own it Scope, date, quality. Someone has to pick, and it should be the people accountable for the outcome rather than whoever is closest to the deadline on the day. ### Expect the delays to stay A hard primary feature can still hold a release, and it did. What changes is that the delay is now a visible decision instead of a schedule quietly moving, which is a smaller claim than predictability and the one I can actually make. ### Baseline it before you change it I never measured release predictability or scope churn before the change, so everything I can say about the result is qualitative. That is my own miss, and it is the first thing I would do differently. ## What that looked like 02 cases ### Six months for a two-month MVP ASKfm · 2016-2021 **Situation:** A feature planned as a roughly two-month MVP took roughly six months. Product requirements kept changing after engineering had designed the architecture around the earlier assumptions, so parts were rebuilt and scope grew mid-flight. Product and engineering started blaming each other. The feature itself landed well, which made it harder to talk about, not easier. **What I did:** - Called the delivery a failure while the feature was being celebrated, because the process that produced it would produce the same result again. - Traced the failure to the release model rather than to either function. A date-driven bundle absorbed every scope change into the schedule, so nobody ever had to choose between scope, date and quality. - Named the missing rule out loud: when a changed requirement invalidates an architecture assumption, the estimate is gone and has to be redone in the open. - Used the episode as the argument for changing the model, instead of as evidence that the team had performed well under pressure. **Outcome:** The change to the release model came out of this. What I took from it is that a delivery process fails silently as long as the outcome is good, so somebody has to say it failed while everyone is still pleased. The product numbers are approximate historical recollection and they sit on the ASKfm chapter. How the change was actually communicated to product and engineering leads is on the practice about decisions people will not like. ### Making a release mean one thing ASKfm · 2016-2021 **Situation:** Releases were date-driven bundles. A date was chosen, then work kept being added to it, so the date moved. Repeatedly. Product blamed engineering for being unpredictable while resisting any scope reduction, and no rule existed for what made a release ready in the first place. **What I did:** - Moved to feature-centred releases: one primary capability defines the purpose and the readiness condition of a release. - Allowed compatible fixes and secondary changes to ship alongside it, so not every item became a blocker. - Stopped unrelated work from expanding the mandatory scope indefinitely. - Required explicit re-estimation when the primary feature changed materially, instead of absorbing the change into the schedule. **Outcome:** Releases got a clear purpose and an explicit readiness boundary, and the scope-versus-date conversation became structured instead of adversarial. Delays did not disappear. A difficult primary feature could still hold a release. But the trade-off was now visible to the people making it. Qualitative outcome. I never baselined release frequency or lead time before the change, which is the first thing I would do differently. Release model Before ### Date-driven bundle - A date was selected, then work was added to it until the date moved. - A release had no single purpose, so nothing defined readiness. - Scope growth was absorbed into the schedule rather than surfaced. - Nobody ever explicitly decided between scope and date. After ### Feature-centred release - One primary capability defines the release and its readiness condition. - Compatible fixes ride along; unrelated work cannot expand mandatory scope. - A material change to the primary feature triggers re-estimation. - The trade-off is visible to the people who have to make it.