- Reduce scope by delivering small pieces incrementally as much as you can
- It will minimize the cost of the errors you may be making
Excerpts from Scope Management 101 by Kent Beck:
“Good, fast, cheap—your choice of two.” Yes, but…
This motto reveals one truth while concealing two more.
The truth revealed is that no one controls all the variables of work to be done. Anyone dictating all three dimensions at once is either:
- Not very ambitious, or
- About to be bitterly disappointed.
An intervention is to offer to fix any two dimensions & deliver the bad news about the third. IME this intervention is not appreciated, but I, in my geeky way, feel compelled to offer it.
The first truth concealed is that the relationship between the variables is neither simple nor linear. In particular, improving quality often results in lower cost & shorter timeframes.
Only up to a point, it’s true. You can have too much quality for your purposes & end up late & expensive. But if the time & money answers aren’t acceptable, think about what you can do to improve quality to reduce waste, rework, or variable delays.
The second truth concealed is that the motto “good/fast/cheap, pick 2” only holds for fixed quantities of work. If I want 100 posters printed, then absolutely I can have them Friday for $100 with one color of ink. If I want 4 colors, I’ll have to wait until next week or pay $200.
Software ain’t like that. We do the work to discover what work needs doing.
I always objected to the word “requirement”. I noticed that if the software shipped with the right half of the “requirements”, the customer would be delighted. Especially if most of the features were discovered during development. So that original list weren’t “requirements”, because they weren’t required. (Hence “stories”.)
To maximize the value of software, the most important dimension to control is scope—what features we include & which we leave out for now.
The whole reason I reiterate the above is because I realized in conversation with Jessica Kerr that the scope-first model assumes 2 skills which may or may not have been acquired by the team:
- Plan incrementally. The team, every week, must be prepared to decide what to do that week. Some planning processes are so painful, or require the sign-off of such overworked people, that contemplating planning weekly causes sweat to bead on foreheads. Learn how to plan lightly as to tactics & resolutely as to goals.
- Deliver incrementally. The team must be prepared to support production while developing. This in turn requires rock solid reliable tidying & prioritizing the fixing & preventing of defects.
Both skill sets are social first, tools & techniques second. Practice. Experiment. Squeeze the inevitable lemons.
And that’s why in XP we talk about scope management as the primary control variable. Quality we fix at “damn near the best we can do” (as long as lives aren’t at stake, in which case it’s “better than the best we can do”). Then we negotiate scope continuously & let time & money take care of themselves.
That’s the theory anyway. In practice folks on the upside of power differentials often pretend to fix all 4 dimensions & you know how that story goes. But we really can offer transparency & control, up to a point, by managing scope.
Subscribe to Software Design: Tidy First?
Software design is an exercise in human relationships. So are all the other techniques we use to develop software. How can we geeks get better at technique as one way of getting better at relationships?