I was at a meeting of Mid-Michigan Agile Group this evening where we discussed how to better estimate software projects at a high level. At the heart of this discussion was the idea of trying to make an up front contract by which you agree to provide an agreed upon amount of content, by an agreed upon date, for an agreed upon price. The ScrumMaster in me starts to cringe at the thought of making commitments beyond the scope of a sprint, but the realist in me knows that especially when it comes to State contracts you end up having to promise just that. So what is so bad about it? Well, I would argue that when you make a commitment like this you will end up either not delivering on all of your content commitments or giving yourself too much time to get things done. I would say that I have always (at least felt like I have) been on the “cut content out” side of this approach, or at least on the “cut every corner possible” side, which of course leads to increased technical debt.
So what do you do?
I think a slightly better approach is to break done the monolithic contract into several smaller pieces and within each of these you prioritize the features that they want at the moment, with a commitment to (for example) half of what you think you can get done with the hope of delivering some other content, then repeat as many times as it takes to get the customer all that they need. Sound hokey? Consider these benefits:
1) At any point the customer should have something of value. Okay, so this is basic iterative design, Agile 101.
2) At any point the customer can decide they have enough value. This way they aren’t wasting money and you can move on to the next project.
3) The customer feels more in control of what they get, when. Customers will be able to pick the few things that they absolutely need with the next release and pick some nice to haves. They should be doing this at the sprint level too, but (I think) they’ll be less likely to feel empowered to change the road map of the “epic product” as they would the bite-sized release.
So what is the end result? You’ll (hopefully) end up with always having more to do, with you always working on the most valuable features, and always finishing right on time, because the customer decides when you are finished, rather than you deciding how to cram as much of what you think is most valuable to the customer into a predefined time box.
Here’s a though exercise. Imagine you in five years. Let’s focus on your house. Would you be comfortable picking everything that you want done to house in the next 5 years and deciding how much to pay for it now? What if your priorities change (you need the deck finished right away for the graduation party)? What if you have to move (you don’t want things looking half finished or unmatched but you don’t want to pay two mortgages while waiting for work to finish)? What if you decide that you don’t need certain projects any more (now the swing set isn’t needed due to a new park down the road)? In the end I have the luxury of being a developer… just give me work, and I’ll do it. It’s not my fault if it isn’t the “best” work I could be doing for the customer.