Scope Management 101
“Good, fast, cheap—your choice of two.” Yes, but…
This motto reveals one truth while concealing two more.
Limits of Control
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.
Not Necessarily A Tradeoff
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.
Only For Fixed Work
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.
Skills
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.
Conclusion
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.
There is a lot to say about scope, quality and features (either discovered or planned), but the main things in my opinion are that:
- we don't know what is important, what is temporary and what will stay.
- whatever we do, we are likely to get it wrong the first time. Only time will tell us if we are right.
And sure, that's discouraging. But the solution out of it is stands on that criteria:
- always build things to minimize the cost of error, including the time passed to build the wrong thing.
From there, you get a whole lot of principles, practices and methods to minimize such cost, from iterative development to TDD, rapid feedback, Scrum, Lean, refactoring, continuous delivery, backlog, feature management, pair programming, weighted priotization, YAGNI, MVP, etc. All of them with their own flaws and high dependency on the circumstances, but with this common criteria to evaluate them: how good they are to reduce the cost of error in my own work.
I have a couple other dimensions I sometimes highlight - quality of life and future capacity. Yes, maybe I could work extra hours this week for a critical thing, but it erodes my quality of life - burns out my relationships and health. Similar for future capacity - (which interacts w/QOL) - cut out learning, collaboration, etc. and maybe you finish this project, but you can end up with a team that falls behind what you need for the next project (or version:)