The first principle in the Agile Manifesto states:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Now, I don’t know anyone, nor have I ever heard of anyone, who spoke out against the concept of satisfying the customer. Look at any company’s mission statement and you’re likely to find a phrase in there like “the customer is our top priority” or “customer satisfaction is our number one goal.” Is there anyone who hasn’t heard the expression, “the customer is always right”?

And it’s a fine sentiment. Satisfying the customer is a good thing. But is satisfying the customer really the main goal of your business? I’d guess not. You could satisfy your customer by, for example, giving away your goods or services for free. Talk about satisfaction! (At least for your customer. You would probably not be quite as happy about it for very long.)

That’s not to say that satisfying the customer is not your top personal priority. It may very well be, as we tend to derive a lot of personal satisfaction from satisfying others.

But the main goal of a for-profit business is to make money. For many the goal is not just to make money, but to make more money. Satisfying the customer is simply an effective means to that end.

I don’t mean this in a cynical way, mind you. I run a business, and I want it to make money. No apologies. And it really helps to remember that if I want to make money, I must satisfy my customers. That direct association is a lot more meaningful to me, especially when it comes to making business decisions.

So, then, how is it that satisfying the customer helps your business make money? Through repeat business and referrals. If a customer comes back, that’s more money for you. If a customer recommends you to someone else, and you get them as a customer, that’s more money for you. If this keeps up, you stay in business.

But disappoint your customer, and your customer goes away. Even if you’re currently a sole source for a customer, as soon as another, more satisfactory provider appears, you’ve lost a customer. And even while you’ve still got that captive customer, will that customer recommend you?  Would you?

So how can early and continuous delivery of valuable software satisfy your customer? By helping your customer make money. Remember, your customer is also running a business, and the goal of that business, just like yours, is to make money. Early delivery of valuable software to your customer can help them start earning sooner. Continuous delivery of valuable software to your customer can help them adapt to a changing market.

And what makes software valuable? Simply put, software is valuable if the cost of the software is substantially less than the cost of the problem it solves. So if you can provide your customer with a software solution that costs substantially less than the problem you’re solving, your customer makes money and is likely to be satisfied. The earlier and more often you do that, the more satisfied your customer will be.

So in addition to the first principle of the Agile Manifesto, you might also consider applying a business-oriented version of the “oxygen mask rule”:

“We take care of our business first, so that we can continue to provide valuable software to our customers.”

My own earliest attempts at estimating predate the Agile era by a couple of decades. In the beginning I used a technique that has probably been tried (with varying degrees of success) by many others:

1. Break the development effort into as many small tasks as you can think of
2. Estimate each of the tasks in hours
3. Add all the estimates together
4. Apply sufficient “padding” for comfort
5. Hope the boss buys it

Estimation’s main purpose

There’s no doubt that the more recent Agile estimating techniques are much better than what I started out with, and I’m glad that so much effort has been put into developing these methods. Even so, I believe it’s easy to lose sight of the purpose behind estimating, which can be summarized as follows:

The purpose of estimating is to provide the customer with a predictable development schedule.

Predictable is the operative word here. With a truly predictable schedule, the customer can derive the information that is most important from his or her point of view. Given a predictable schedule, the customer can answer important questions, such as:

• How much will this development cost?
• Will we be able to hit the market window?

In other words, the customer is probably not interested in the accuracy or precision of your estimates in and of themselves. The customer is more likely interested in the predictive power of your estimates. Given that, you want to focus your estimating efforts on things that provide predictability.

Duration should be derived, not estimated

I like to encourage teams to focus on estimating User Stories in Story Points, and to discourage them from estimating tasks at all, largely because coming up with Task Hours doesn’t seem to contribute much to the goal of providing the customer with a predictable schedule. Admittedly, estimating Task Hours may help to inform the team about how good or bad it is at estimating duration, but that’s a metric that’s not directly useful to the customer.

What is directly useful is duration that is derived from a team’s demonstrated velocity. Given a velocity in units of Story Points per iteration, plus knowledge of how many Story Points remain in a development effort, the customer can quickly and easily predict the development schedule.

I’ve also heard it misquoted as “do the easiest thing that could possibly work” and even “do the quickest thing that could possibly work.”

It’s not necessarily the easiest thing

Although the simplest thing that could possibly work might sometimes also be the easiest thing, it often is not. For example, the easiest thing might be to copy and paste a section of code in order to duplicate its functionality in another part of a program. But is that the simplest thing? I believe it is not.

It’s not necessarily the quickest thing

The simplest thing that could possibly work might sometimes also be the quickest thing, but there aren’t any guarantees. The use of short variable and method names might be quicker (because it saves typing time) than the use of longer, more meaningful names, but is it simpler? Again, I don’t think so.

What does simple mean?

Here’s my working definition: Something that is simple is neither complex (meaning having more parts) nor complicated (meaning difficult to understand).

In the first example above, the easiest thing is not the simplest thing because doing the easiest thing (rubber-stamping the code) introduces complexity.

In the second example above, the quickest thing is not the simplest thing because doing the quickest thing (using short names) introduces complication.

Conclusion

If you want to do the simplest thing that could possibly work, look for a solution that is both easy to understand and lacking in unnecessary complexity.