Working software over comprehensive estimation

Comprehensive documentation

A couple of months ago we where about to be finished with a project we've been working on for a customer. We had a meeting with the customer to discuss a couple of things. The customer then asked if we could deliver a system documentation. Instinctively, agile as we are ("Working software over comprehensive documentation"), we responded "Who is the receiver of this documentation? What is the purpose of the documentation? Remember that documentation tends to be quickly outdated." We also emphasized that we gladly produced the asked for documentation, but first we need that information to know what kind of documentation to produce. We haven't heard anything about the documentation since then...

Comprehensive estimation

I wonder: Isn't it the same thing with estimates? ”Working software over comprehensive estimations” - there is more value in developers writing code than developers doing estimates.
Shouldn't we, agile as we are, instinctively ask the same questions when asked for estimates? "Who is the receiver of this estimate? What is the purpose of the estimate? What do we do if our estimate turns out to be incorrect? Remember that estimates tends to be quickly outdated."
Those questions should come as natural and instinctively as we responded about the documentation.

"How much will it cost?"

Note that this has nothing to do with the customer wanting to know what something will cost. You always want to know - roughly - what something will cost you. Who wouldn't? And we should give our customers a rough sence of what it will cost. Is it $1.000 or $100.000. You want to know. If it is $100.000 or $120.000, is (almost) irrelevant. I think that a customer asking "How long will this take?" actually is asking, in a more discreet way, "How much will it cost?" Because we almost always charge our customers by the hour, they can then do the math by themselves of how much, approximately, it will cost them.

Time and cost are not (should not be?) the same thing

Personally, I would rather work on something knowing that I have "unlimited" amount of time with a given cost than to know that I have a limited amount of time with an unlimited cost. There is a psychological effect when working against time, a self fulfilling prophecy. If I start working on an item, knowing that someone (or meself) has said that it will take approximately 10 hours, I will focus on doing it in 10 hours. If I have worked 8 hours then I know it's only 2 hours left, let's skip some testing, let's skip some refactoring to be finished in 2 hours. I.e. I drop quality and creativity to prioritize the estimate. What value does that bring my customer?
But what if I am done in 6 hours? My customer will probably only be happy about it. But what value did it bring that I (or someone else) said 10 hours?

Estimates are promises

Estimates becomes promises. That's the problem. Stop promise result. Promise your own behaviour instead. Read more about it here: Promises, promises (in swedish though). If I instead say: "I think this will take between a day or two but I'm not sure, but I will let you know when I start working on it, and I will call you when I've worked on it for 4 (or anything) hours and tell/show you how I'm progressing, is that ok?" You haven't promised a result, you have promised to get back, and let the customer decide if we should continue the work or not, based on how we're actually progressing - real value. And you have promised to start working on it instead of trying to give a more detailed estimate.

Give them a rough feeling. Give them value - quickly

As I said, today we charge our customer by the hour. We almost never give them a fixed price (very agile! :-). If it takes 14 hours instead of 10 we charge them 14 hours. But this also means that the one taking "the blow" if our estimate is incorrect is: our customer. Is that fair? Well, I think it is. They paid what it actually costed to get it done. Nothing more, nothing less. The problem is that we gave them an estimate, a promise, an expactation, that turned out to be wrong. Stop giving them false expectations. Stop promise result. Give them a rough feeling, but only promise to get back to tell them if that rough feeling turned out to be correct or not. Ask if you can get 4 hours to start working on it and return with result and then discuss if we should continue or not.
The same thing if working on larger projects. Make sure to produce small slices. Ask "Can we start building this little thing to know more about how hard it seems to solve? Give us X hours and we will show you how we're progressing, and then we - together - can decide if we should continue or not".
The customer always want to know what it will cost, and we should give them that rough feeling. But don't spend hours and hours estimating. That rough feeling is almost instant. Dan North calls it Blink Estimation. Start working on it instead. Start giving customer a valuable product as soon as possible. Dicuss how we can deliver something to deploy live in 4 weeks from now: "What should we build/do if we deploy live in 4 weeks? How will it look like, what will it be?"

We need deadlines

I believe we actually need "deadlines" (note the quotation marks, I will get to that). Sounds kind of opposite to #NoEstimates? But I think it is true. There is another psycological effect here; if we don't have any deadlines I believe nothing will be produced. But create many deadlines. Keep them short (it's XP and Scrum, isn't it?) We are lazy by nature, and if someone says that you have unlimited time, it will take unlimited time. Remember the self fulfilling prophecy. But a deadline should not be 6 months or years from now, it should be like two weeks from now, or one month from now. Focus on and discuss what can be delivered and deployed live (or beta, concidered live) in one month from now. Then the customer will feel that we produce value as well. We can also get real feedback from real users, early! We have gained trust! Without promises of a big bang release and big bang estimates and plans.

Developers are physicians?

I don't really like analogies, but let's compare with a physician/surgeon. If I'm having an operation wouldn't I want to know what it will cost me? Of course! Does it matter how long it will take? No, not really. Some rough feeling, of course (can I expect 2 hours or 16 hours, that's important imformation). But I certainly wouldn't want the doctor to feel pressured by time. I want him to perform as good as possible, not rushing through the operation to be finished on time. But the surgeon has given me a price, no matter how long it will take. He/she takes the cost (probably added some risk to the price). But maybe, if it takes a lot more than he/she thought (because unexpected things happend), he/she could ask me to pay more based on the situation. And I would probably do, knowing the facts and if the operation was successfull and he/she did a great job.

#NoEstimates and #ImpactMapping - The goal is not to stop doing estimates

The #NoEstimates topic is a bit "infected" and my theory is that it's all about the hashtag - the word. Just like TDD got focused on tests, but the tests doesn't have most value in themself, the tests are just used as a tool for a higher purpose. And that's why the term BDD was invented. But this is another topic...
The same thing with #nosql. The "no" got focus, so the no was changed to "not only". Well, some may disagree about that, but it's unimportant in this post what nosql means.

What I'm trying to say is that the "no" has got the same focus in this #NoEstimates debate. The focus is not on the "no" but on the "estimates". I'm not saying no to estimates. I'm saying that there are possibly other ways to think. I'm not saying that you should abandon estimates, but perhaps focus on other things as well. And maybe you are (just as I am) focusing too much on estimates? Are there more important things to focus on? I do think so. And if you try to focus on other (more important) things, you might find that you move away from estimates more and more?

What am I saying really?

Well, I think that we (as developers and/or consultants) accepts estimates a bit too easily. Estimates are guesses (or even WAGs as Woody Zuill says..?). They can never be anything else since it's about the future and we can't (yet) look into the future. And do we want our customers (clients) to make business decisions based on (our) guesses? Maybe, maybe not... Because, even if we abandon estimates we still have to plan (the verb, not the noun) and planning is about guessing and making assumptions. But I believe the most common way is this:

1. Customer/client has some idea on what they want to do/achieve, i.e. the goal (usually not clearly communicated).
2. Client asks developers to do a rough estimate on how much work it is and how much it will cost.
3. Developers asks for a workshop (or similar) to get a clearer picture on what they want to do (so they can give a more accurate estimate).
4. Workshops are held, and then (after some work, going through the material from the workshops) an estimate (and a plan) is given to client.
5. Client makes a decision if it seems valuable to start the project.

Is this the most valuable way to decide if a system should be built? It's at least very focused around costs and estimates. I'm not sure, but I'm willing to try other ways.

This is where I think #ImpactMapping fits nicely. Read more about Impact mapping http://impactmapping.org/, and most important: read the book if you haven't.

Impact mapping is about discussing the right things, asking the right questions. It's about focusing on value instead of costs and estimates. A system will not be valuable in itself; someone has to interact with it for value to appear. It's about creating impacts! The only way to create value is if the system can impact someones behaviour; change the behaviour of the users interacting with it. Someone should do something e.g. faster, better, cheaper, more accurate, with higher quality etc. (or maybe do something less often or with lower quality?) It's about the change. Discuss: "How can we change X's behaviour so that we can acheive Y?".

Impact mapping is also about creating options. There is never one road to a goal. Create alternate ways to the goal, then focus on which way(s) we should focus on. "Which way do we assume is the best/easiest/cheapest (or anything else) way to our goal?" Follow up and see if the assumption was correct. Stop if it's not, continue (and maybe add the other options) if it is. Discuss what we think will happen if you choose one option over another, what are the tradeoffs?

Just like with a real map we can choose other ways if one way is blocked or leads to a dead end or we notice that another way is better. Or we can turn around and go back if we missed a turn. And we can do it when it happens! Just in time! But we don't have to if it's not necessary! We don't have to make a detailed plan (estimate) on the exact way to go - we have options and we can take actions when things happen! We can stop and look at the map. Create new options when needed.

And speaking of tradeoffs... do we ever discuss the tradeoffs when doing estimates? There are always tradeoffs when choosing one thing over another. If the customer (client) demands estimates, what are they trading off? If they want a fixed price, fixed date or a detailed plan, what are they trading off? Discuss it! And, if we're doing #NoEstimates, what are we trading off then? Remember: it's about creating options, and then decide what we think is best for us at this moment! And step back and validate the decisions and create new options if required.

Anyway, for me, the goal is not to stop doing estimates, it's about exploring if there are other ways (as well) - options! - to make our customers look on and think about value.