It’s over 7 years since my first post on contracts for agile projects. During the years since I’ve worked almost exclusively on agile projects with fixed scope, learning some real-life lessons along the way.
So here are some of the key points that now I keep in mind when considering estimation, pricing and contracts for agile projects. These points are particularly relevant when customers have asked for fixed price and fixed scope.
1. It’s a valid thing to ask for…
It’s perfectly natural for customers to want some up-front insight into likely cost and scope. In the spirit of good negotiation, we should take their concerns seriously.
2. … but many agile teams successfully dodge the issue.
I asked someone recently what they were doing about this, and their reply was that they don’t really find themselves doing many contracts with fixed price and fixed scope. That certainly solves the problem ;-) I suspect it depends on the kind of company you work for. If you’re an in-house IT shop (i.e. customer and supplier are the same organisation) then I would imagine that there is little call to fix both scope and budget. However if you work as I do, in a company that undertakes development projects for other organisations, then you’re more likely to be asked to fix both price and scope. It also depends on the “purchasing culture” in the city where you work. For instance I work in Wellington, where government procurement processes heavily influence the way people expect contracts to be framed. But in Auckland, which is only an 8 hour drive away, there’s a very different procurement culture that’s dominated by private companies.
3. There are lots of different kinds of contracts which you might consider
Alistair Cockburn has a big list of suitable contract types here.
4. Flexible pricing is probably good
Rather than absolutely fixing both price and scope, it makes the project run better if you can allow at least one of them to “flex” in a controlled way. This still gives the customer early insight into commitments and benefits, but avoids the harsher downsides of absolutely fixing both. Here’s an approach that I’ve tried and liked. It’s not for everyone, but in cases where it’s understood and embraced by both parties, I do believe its better than fixing everything.
5. Here are my favourite “ingredients for success”:
- Use a “discovery phase”. This is a timeboxed phase at the start of the project where you learn more about what the customer needs, and prepare an itemized breakdown of functionality. That itemized breakdown is the scope that you then commit to. A discovery phase is good for both parties, because it results in much better-informed scoping than projects which attempt to fix the scope without such a phase. The discovery phase should be paid, rather than delivered for free – both because the customer gets value out of it, and because adequate discovery is too big to do for free. In terms of sizing the discovery phase, the Feature Driven Development community uses a rule of thumb that this phase should last for 2 weeks for every 6 months of development (IIRC). I think that’s about right. For example, I used 3 weeks for a 6 month project once, but during those 3 weeks we also built a prototype.
- The bigger the project, the more coarse-grained your discovery phase must be. (Within a realistic timeframe, you simply can’t drill down into as much detail as you might in the discovery phase for a smaller project. And if you do, it turns into BDUF, which is counter-productive for all the well-known reasons. So I’d suggest making do with a coarse-grained breakdown on large projects.)
- The itemized breakdown of scope should be tabular rather than prose (i.e. a table rather than a document). This is a lesson I learned the hard way – the document was too ambiguous. One good way to organise the tabular breakdown is with a story map.
- Ideally, that itemized breakdown of scope will actually serve three purposes: it will define the scope, it will form the basis of your estimate, and it will be what you track your progress against as you work through the project. IMHO, if you’re not using the same list for all three purposes, you’re risking trouble.
- Typically, your cost estimate will be based on summing up points for every feature that’s in scope. Make sure you add a “buffer” of additional budget over and above that. There are two reasons why you might need such a buffer: (a) the inherent uncertainty in estimation and (ii) the need to allow time for for Validation (i.e. ensuring fitness for purpose, rather than merely compliance to spec).
- Adding this buffer will typically produce an estimate which feels too high. So my rule of thumb is as follows, “if your estimate feels about right, its probably not.” ;-) Add the buffer!
- A buffer that adequately accommodates both estimation uncertainty and validation effort tends to unfeasibly large. (Unfeasible in the sense that some manager somewhere won’t accept it ;-) So I prefer to use a target cost contract. Some of the necessary buffering is built into the target in the target cost contract, but the rest is provided by the (controlled) flexibility.
- Important: Know how you’ll draw the line between “this is an addition to scope, and therefore requires a budget increase”, versus “this is something we should just do, and therefore requires no change in budget”. You always need at least some of the latter, certainly for Validation and probably also for convenience (its too much paperwork for formally increase the budget for every tiny change). I’ve outlined one suggestion for drawing this line, part way down the target cost page.
- Important: It’s not enough for you to know how you’ll draw that line. Your customer must understand too. And agree. This applies to both management and subject matter experts, to both ‘gold owners’ and ‘goal donors’. All must understand what kinds of changes will affect the budget and what will not.
- Use a project tracking and management tool that gives you a “whole of scope” view. If your tool only shows the current iteration or release, but your commitments are for the whole-of-scope, then you’re flying blind.
6. “If I do all that, will it work?”
Maybe. Maybe not ;-) Fixing price and scope of agile projects is fiendishly difficult. But there is a genuine business need for it so we, as agile practitioners, owe it to our customers to continue trying (and learning).
7. Understand Estimation
When I finally started studying estimation, I was shocked to discover how little I, and my colleagues, really knew about it. We’d been getting by for years with little more than a grab-bag of misconceptions. And we didn’t even realise. So read Steve McConnell’s Software Estimation: Demystifying the Black Art. I haven’t found any other book that combines all the necessary material into one readable volume.
8. Understand the bit that Steve omitted from his book
If you’re bidding for work, in a competitive situation, then you’ve got to read this post from Steve McConnell (including the comments) and my follow up here. It’s not entirely comforting, in that it describes a problem which software vendors can’t easily solve on their own. (The obvious solutions require engagement from purchasers.) On a more positive note, the US engineering profession did successfully solve this problem.
I hope to eventually blog more about this in years to come, particularly some thoughts on what we can do in the absence of a purchaser-side solution.
9. See what others are doing.
A great example is Atomic Object in Michigan. Here’s a post on their corporate blog to get you started. (You’ll notice they also like to introduce controlled flexibility. In Atomic’s case, they flex the scope rather than the price.) You should also check out their whole series on estimation.
PS. Is there a tool that can help?
Mostly its not about tools, but since you asked ;-) …. I think several things help: taking a whole-of-scope view; using story mapping; using the same artefacts as the basis for scoping, estimating and tracking; and keeping the user story/feature descriptions concise in order to prevent BDUF.
But, mostly, this is not really in tools problem. Its more about understanding, attitude, negotiation and communication.