Hacker News Reader

Comment by wpietri | Hacker News Reader

My main trick these days for this problem is to discourage estimation by pointing out the costs of it and putting the burden on the requesters.

One great way to do that is to release early and often, allowing stakeholders to change plans in response to what they've learned. Instead of doing the work of (re-)estimating a bunch of stuff every week, their focus on what's actually going on lets them stop obsessing about arbitrary dates and semi-fictional plans.

People very rarely need estimates. They want a sense of control. They want to manage risk. They want to convince people that money is being well spent. They want to avoid looking like fools. If you solve those problems without using estimates, people generally stop caring.

View on HN

In the enterprise I work in, people need estimates in order to manage resourcing - which is not something unique just to the software industry.

We always have a prioritised list of projects but only a limited number of developers, so for us estimation lets us know when a developer is available to work on the next project.

Estimation is important and before any project is accepted we go through maybe a day or two working out the main application structure, breaking it down and providing rough, high-level efforts. Then we factor in the usual holidays, risk buffer (illness, estimation uncertainty), rigging, testing, release etc. Once the project's accepted then a more accurate plan is delivered after we have a design and task list ready.

The main thing I've learnt is people are far more willing to accept over-estimated plans at the beginning rather than extend a project that's run overtime.

Resourcing and estimating against plans is one approach, but it's not the only one. You can also use a flow-based approach. Basically, you have teams with queues; whenever a team is out of work, they pop something from the queue and work on it until complete. Or, if the organization is more subtle, you release early and often, ending a project when it looks like the team can be more usefully deployed elsewhere.

Mary and Tom Poppendieck cover this approach a fair bit in their books.

I agree that this is a good alternative; I certainly prefer it.

I prefer to think of it as a derived factory. It used to be that we thought of software projects as being like a factory, which eventually turned out the end product: a single piece of software.

Now we've taken the first derivative in a calculus sense and realised that the actual output of this conceptual factory is changes to software. The manufacturing analogy makes more sense in that respect; though concepts like SPC are hard to map because normal variation of software production can be very high indeed.

I agree with that estimates are largely about a [false] sense of control, but this is a tough sell when dealing any company with budgets and stakeholders that have to go ask their boss for a finite number of dollars to trade for software.

Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?"

If you are a startup or dealing with a 4-figure project from a local business, then sure, you can probably skip estimates.

Sure, but that's an artifact of traditional budgeting. In the Lean world (as in Lean Manufacturing), traditional budgeting is considered a dangerous and misleading activity.

Another way to work it is to have a backlog of valuable things to do that get handed out to teams. When somebody needs something to do, you pick the highest-ROI project from the backlog and give it to them.

In that context, detailed specs and careful estimates generally turn out to be wasteful. If you're trying to pick projects by expected ROI, then making the software estimate more precise than the (generally handwavey) business value estimate is pointless.

> you pick the highest-ROI project from the backlog

How do you calculate the return on investment without estimating the investment?

Well, one option is time-boxing. You say, "We'll put a team on this for up to two months: they get done what they get done." It's a fixed investment; it's up to the business stakeholders to judge what kind of return they can get out of that.

But in the this context, by "estimation" I mean "formal estimation". Having developers glance at something and ballpark it is basically a zero-cost activity. As long as that I number has about the same error bars as your R number, then it's perfectly fine for ROI. Especially given typical requirements volatility, and a project approach that sharpens ROI estimates as you go.

You don't have to know the ROI value of each project, just compare their relative sizes to select the best from the set of projects with the highest profit ranking.

This assumes, though, that the best of the projects is worth building in the first place.

How do you know their relative size? Isn't that an estimate?

> Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?"

This is an area where software engineers who've made serious profits and turn around to become investors have an edge over traditional that do not understand the levels of risk involved with large software projects.

Explaining the granularity in the types of risk that are involved is complicated to people that expect to write a check once and have a finished product come out of it.

That does depend upon your circumstances however.

Often there are hard dates that can't be moved - because they are external to your organisation; the autumn TV schedule, or launching at a particular conference are two that have hit me in the past.

Of course that does make the estimation a slightly different process - not "when will this be done" but "can you be ready before this date?"

Sure. But instead of estimation, one can take a risk-management approach to that.

For example, I'll get people to talk about everything they want. I'll put each thing on an index card. I'll have them lay the index cards out in order of importance (or ROI) on a big table. Then I'll ask: "Draw a line where, if you didn't get that far, you'd just bow out of the conference."

Typically, that line is pretty early, 10-30% of what people would really like to have by the date. So then you take the backlog, make sure it isn't too lumpy, and start working. Just by measuring cards/week, you can pretty quickly know whether you'll hit the date. And typically, the team will have something shippable well before the date.

The question then becomes: when is the ROI for the next week's work going to be lower than the ROI for something else we might do? And that question ends up being pretty easy, because you've pushed the decision off until you have a lot more data.

That's one thing I really like about agile: putting work in order of value, not in order of build efficiency.

It's a bit like nature-inspired computation approaches to problem solving. They tend to introduce a lot of overhead that more direct algorithmic solutions won't, but you can terminate them at any point and get something. That flexibility is often very useful.

but "can you be ready before this date?

IMHO right answer to this is, Yes we can be ready but we might have to scale down on some of the features. But in reality most of the time only the initial 'Yes' part is heard with the caveats being ignored. As mentioned many a times it is "quality, features, schedule" and one can pick only two.

There's a lot of research in various industries that suggests quality is correlated with schedule. Poor quality -> more rework -> schedule blowout.

It's not only about control and risk management. In external-facing products, other departments (sales, marketing) need time in order to prepare materials, etc. in order to plan their own projects. Telling these groups "it'll be ready when it's ready" doesn't really help them.

Reply on news.ycombinator.com