The Figuring Dance

Reason #32 for not going agile: your client wants to know how much the developments are going to cost, how long they are going to take -- and they don't want to hear the "I can't tell you now, I'll know for sure in two months, meanwhile you'll get the highest value in return for the bucks you've invested" argument.

Take a deep breath and admit it -- you may hope to successfully change the way a team develop software, but it's a long way before you may hope changing the way your client organization works. And one of its most structuring habits may be the way they allocate money to projects. Many organizations require their managers to ask for yearly budget estimations, based on how much they estimate their projects will cost. This seems very uncompliant with agile processes, but hey -- there's so much you can change at once. Sometimes you have to pick your battles.

Estimating is a social convention. It isn't about figuring (numbering) the project cost, it's about figuring (considering) the other party. Estimating is a courting dance in which the contractor and the contracted feel each others and decide whether their collaboration seems pregnant enough. Think about a date. It's not so much about the activity you'll do together than about the deciding whether there's going to be a second time together.

Let's pretend you have supernatural powers and you can predict for sure how much a project will cost. Your estimations will be right and yet, the client might prefer contracting a competitor who predicts the project will cost 30% less. The game has an end, of course. There'll be a point where your cost estimations will be so cheap that even the dumbest client will realize something is wrong. And he will prefer listening to someone that gives more sensible estimations.

There are two lessons here.

First, the client always has an idea (although sometimes very skewed) about how much the project should sensibly cost. The cost the client has in mind reflects the value they attach to the software to be developed, and under which deadline they need it.

Second, your estimating precisely won't help you to close a deal. Guessing right how much the client is willing to pay and for how long he's ready to wait, will. Of course, you may not want to close the deal on conditions that sound unrealistic to you.

We're getting close to a solution. Estimating is about feeling a promise of fruitful collaboration. Guessing the price and the deadline the client has in mind will get you his trust. Confronting the client estimate to your own estimate will tell you whether you could sensibly bet on the terms of the deal.

So -- instead of guessing what the client wants to hear, ask them what numbers they have in mind. Call it their expectations. Make them your official estimations. Then (and then only) you may go on. Propose your client a contract. You commit to do your best to live up to their expectations. At any time, you'll have at hand an indicator that'll give them a fair idea about how many chances you actually have to finish on time and on budget. They may stop the project at any time and yet get value in return to their investment. You expect them to have some responsibilities, such as re-prioritizing the features every few weeks, validating what's released at the same frequency, and write acceptance tests prior to developing a feature.

Your client may still refuse the deal, but at least your grounds for negociation are more rational than a budget or a deadline.