Life, Liberty, and the Pursuit of Agility

NOTE: This was a lightning talk proposal for Agile 2013 in Nashville.  My main purpose in this post was to have a chance to give a lightning talk on “No Estimates” at that conference.  An additional purpose is to encourage people to be thinking about the sort of estimates we use in software development, why we think they are useful, why we depend on them so heavily, and some of the reasons we might want to re-think our dependence on estimates.

Fortunately for me, I was chosen to present this lightning talk, which challenged me to put together a focused slide deck and talk on the subject, which then grew into the talk which I gave at Oredev 2013.

Going forward, my is goal to expose the sort of thinking and questioning I have been doing over the last 10+ years so that others who have been asking can use these questions as a starting point in their own exploration of estimate-driven software development.

I am not offering to answer these questions for you.  Only you can do that.

I want to emphasize this: If you want to discuss these ideas with me, I am always happy to talk with almost anyone – either via Skype, or at a conference or developer meetup.  If you demand that I answer these questions for you, then you have misunderstood the purpose of this question list.  Again: I am not offering to answer these questions for you. I am offering these questions as a starting point for your own journey of exploration and learning.  I encourage you to use them.

Now: the original post:

I’m proposing an “idea” to present for the Agile2013 Lightning Talk stage under the Process At Scale theme.

Title: No Estimates

Talk summary: Ask a lot of questions, answer a few.

Please vote for it here: Agile2013 Lightning Talk On No Estimates

Here are the things I have been asking myself about Estimates:

• What are estimates, anyways?
• Are estimates useless? wasteful? harmful?
• Who needs them? Who is asking for them?
• Why do we think we need them?
• Can we have successful projects without estimates?
• When will this be done? How much will it cost?
• How can we decide if we should do a project without knowing the cost?
• Is NoEstimates better than MoEstimates?
• How expensive are useful estimates?
• How useful are inexpensive estimates?
• If it takes you “no time” to do estimates, are they of any value?
• If estimates are waste, would you still do them?
• Is the reason you do estimates because “someone requires I do estimates”?
• Why do they require you to do estimates – is it because someone “higher” is asking them for estimates?
• When someone asks for an estimate, what do you do?
• When estimates don’t work well for us, should we just get “better at doing estimates”?
• If estimates are useful and easy to do, why do we still have so many problems with estimates?
• How would you plan a project if you were NOT allowed to do estimates?
• Can you imagine any reason why estimates might be harmful?
• Can you imagine some better way?
• How important are predictions?
• Can you “sell” programming without estimates?
• What about estimating the “value” of a feature?
• Are there things where estimates make sense?
• What is “No Estimates” anyway?
• If estimates are good for some things, does that mean they are good for everything?
• Does “No Estimates” mean we don’t use estimates at all?
• What are “Whole Team Estimates” and does it help at all?
• If you are estimating about work you don’t yet understand to be done by someone you haven’t yet hired, is that meaningful?
• How much are you willing to invest in estimates to get useful information from them?
• Does it matter how good estimates are: are “wild guesses” good enough?
• Are the decisions you are making that are based on estimates good decisions?

We’ll ask some of these questions. Perhaps explore a few ideas. Maybe answer a few.

Stuff like that.

[NOTE: This post is about software development. You might need estimates in some other field or domain and this article is not related specifically to any other domain, and especially not the one you want to complain about.]

I’d like to do a little investigation about why we need estimates.

The following list contains some of the things people say when I ask “What do you use estimates* for in software development”:

• To decide if we can do a project affordably enough to make a profit.
• To decide what work we think we can do during “a Sprint”. (A decision about amount)
• To decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
• To decide which is more valuable to us: this story or that story.
• To decide what project we should do: Project A or Project B.
• To decide how many developers/people to hire and how fast to “ramp up”.
• To decide how much money we’ll need to staff a team for a year.
• To give a price, or an approximate cost so a customer can decide to hire us to do their project.
• So we can determine the team’s velocity.
• So marketing can do whatever it is they do that requires they know 6 months in advance exactly what will be in our product.
• Someone told me to make an estimate, I don’t use them for anything.

That’s enough for a start. So let’s start.

Let’s notice the most obvious common word in that grouping. To me, it is the word “decide”. Granted, the last few items don’t use the word “decide”, but we have to start somewhere. Besides, why would have I contrived that list and highlighted the word “decide” if it wasn’t fundamental to my main point? [At least I’m honest in stating that I have an agenda.  Hint: NO ESTIMATES]

It is significant to me that much of why we do estimates is that we need to make decisions: To decide something.

In other words, it looks to me that what we need are decisions, not estimates. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can,  and maybe we should explore other ways to make those same decisions. [Who are we kidding, I really think we need to find better ways to make those decisions].

So to restate: We don’t need estimates, we need to make decisions.

Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here…]

Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along.  That is an important point. Dwell on it.

Perhaps it would be advantageous to find ways to work where the quality of our decisions are not as important as our ability to learn and to adjust our course while paying as little as possible for the learning, adjusting, and “mistakes”.

To me, this is a “Lean approach” to making software. To me, this is the “Agile way”. Some people used to call this a “light-weight methodology” for developing software to indicate the process was “barely sufficient” rather than “cripplingly  comprehensive and depressingly dysfunctional”. I like “light-weight”, but someone picked the name “Agile” for this idea. I like that word even better. Regardless of the name, it’s an approach where we pay attention to what is going on and constantly adjust things based on what we learn.

One other thing about decisions

Sometimes decisions happen by default: If I forgot to bring my lunch, my options are to go hungry or eat cafeteria food today. If I forgot to bring money, then the “decision” was made for me – I go hungry. I prefer to not go hungry, but in some cases a default decision is sufficient. Make decisions on important things, resort to default decisions on less important things. Besides, I need to lose some weight anyway.

One other other thing about decisions

One little note: Of the items in the “What do you use estimates for in software development” list above, there is only one where estimates seem to make sense to me: To decide how much money we’ll need to staff a team for a year.  I’ll write about that someday if anyone is interested.  But I am confident you can figure it out yourself.  Also, there are only a couple of items in that list that seem like important decisions to me. But what do I know?

One other other other thing

As far as the “team velocity” question goes – you don’t need an estimate for that. To determine the velocity of a team simply drop them from a height of about 2000 feet and you can measure their speed just before they hit the ground.  I’ve never tried that, but I’ve worked some places where it felt like that.

In Conclusion… We need to make decisions, we don’t need estimates.  Did I say that already?

So the title of this post was “Why do we need estimates?”. The answer is, we need them only if we can’t find a better way to make decisions.

There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.

Some other posts I’ve written on the topic of estimating:

Perhaps you are now saying: So what? I don’t know of a better way, so I am going to use estimates. Besides, what’s so bad about estimates?  Well… I’ve written a little about that (although I’ve really just started – there is a LOT of potentially bad stuff about estimates we should all be aware of), and about a few alternatives to using estimates. Over time, I’ll keep adding more information, and share more about how to make decisions without estimates. In the mean-time, I know that many others are also finding ways to make great decisions without estimates, and some of them are writing about it as well.  Google that.  You can probably figure this stuff out better on your own, anyway.

• Estimation is Easy and Useful: Estimate a game of Chess
• Do Estimates Do What We Want Them To Do?
• No Estimate Programming Series – Intro Post
• No Estimate Approach For End-Of-Life Legacy Support
• Notes From A Conference Session On No Estimates in Software Development
• A Comment And Response from Estimate Chess Post
• Can We Code Without Estimates?
• If You Found Estimates Bring No Value – What Would You Do?

NOTES:

* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.