You are quite right. If the entire environment isn’t aligned around truth, then there’s really very little developers can do on their end.

That being said, there’s so much stuff that needs to happen around the actual development – business analysis, testing, bug fixing, deploying, etc that takes time, and developers really don’t know how long those kinds of things tend to take.

Thanks for your comments.

most programmers learn early on that no matter how they try to qualify and contextualize an estimate, once given, their feet will be held to the fire

we also learn that managers just absolutely hate when we dont’ want to give an estimate on something without analyzing/digesting it first, and they really hate it when the requirements change and you try to adjust your estimate accordingly

the real problem is the deep dishonesty in all this, and the pathological games that managers play

all the writing and talk about good practice is worthless in the face of bad faith management, and bad faith management is the statistical norm

That’s the kind of estimation I like, both in the small and in the large (whole project).

BTW, 35-hour work-week? I envy you.

What if you’re the PM for a fixed price project in a non-agile company?

A lot of my clients are, and “just do agile” doesn’t solve their problems.

“Split the work up in smaller lumps”

Do you mean Big Design Up Front?! [Ghasp!]
And what if there’s more work out there that we don’t know about? Big Requirements Up Front?!

Just kidding.

If only it were that easy – we wouldn’t have so many failed projects.

In my experience the developers don’t protest because they’ve been beaten for doing so in the past. They know that management will not settle for anything less than a “reliable estimate”, and no matter how many times management assures them this is “only an estimate” and “won’t translate to an actual deadline”, it happens anyway. So the devs just give them a number they want to hear and get on with the work, with the full understanding that they will endure some token chastisement for not meeting the date later. Not that it matters because the customers won’t be ready by that date either.

There’s also the issue of management buy-in. Telling your manager that they need to loosen up their expectations and then cut resources or features to meet budget or timeline as development progresses, is often at best a waste of time, and at worst considered to be evidence of lack of skill or experience.

As a consultant, I and my team have the ability to say look, we’ve done lots of projects this way. Trust us, it works. We can’t guarantee the results if we do it differently. And either the client can agree to it, or fire us. Either way, we avoid being forced into a situation where we are doomed to fall short of expectations. An in-house team looking to change “how we do things here” doesn’t have that kind of bargaining position.

You say “The difference is that by working based on features, and measuring project progress by feature-units completed per iteration, I drive down variability.”

But what is the size of a “feature-unit”? Is it a constant? Is a project claiming “we have finished 90% of the features” 90% finished? Is it more safe and true to count features than hours/days? All in all it boils down to hours or days, calling it feature-unit only applies abstraction (and obscurity). It’s a good tool to group smaller tasks and to create an overview of the project. But, what do you report to the customer when there’s 1 feature left out of 10 features in all – knowing that the 9 finished features where sized between 1-3 days, but the last is two weeks…

Also, you say you trust your developers and testers – to me it sounds more like you don’t. Youv’e lifted yourself way above them and the only way you look at them is down?!? Remember, a developer is also working with pride!

PMs usually have a lot more experience and a broader view of the project so I think they should be able to make the estimations themselves. PMs who can’t estimate without basing their estimations on developers need to be more observant and aware of the complexity of implementing features.

You’re absolutely right, until we have to develop another project concurrently to the one with the smarty-pants team, or integrate with development done by other teams.

This post was more directed at PMs than developers.

PMs, do your job already.

The question is sometimes what to implement when, inter-dependencies between features, external inputs (like demos to be shown at trade shows), etc. Projects incorporate so many other disciplines than developing software, that it cracks me up every time I see management come to the developers with requirements (aka – a wish list) and ask for a schedule. The thing is that the developers don’t usually protest and provide an estimate (in other words – “yes, we will have it done in time for TRADESHOW next year”).

So… Split the work up in smaller lumps and have them estimate that! Scrum has, IMHO, a very nice way to handle this – which works like a charm after a couple of sprints.

In my defense, I’ll say that when I said trusting your developers I meant about actually developing (i.e. writing working code). If you’ve got developers very good at producing good, quality, working code; heck you’re already golden; estimation can indeed be done with good help from the PM or an expert like you; but if you can’t trust your developers or the code they’re producing, you’re already screwed and no amount of estimating is going to save your bacon