> Do you find that this really works out, in practice?
Of course it works. You just redefine the project (or parts of the project) as you go, shrinking (or occasionally growing) the scope.
There's nothing wrong with a fixed delivery date, provided you can adjust scope and/or resources (to some extent) to compensate.
1. Wait until the date is close. Redefine scope in a panic so that success can be declared.
2. Wait until the date has arrived or is past. Have rounds of tears and/or shouting; pick a new date and scope, often as illusory as the first.
3. When the date arrives, ship whatever terrible garbage you happen to have and declare victory. Spend the next N months "fixing bugs", which mostly means "finishing half finished features".
The key is to over communicate. When I'm managing a project like that in a situation like that I send an email similar to this:
As it currently stands our team will not make the deadline. In order to meet our priorities, I would like to redefine "feature A" to exclude "component Z". This means we will have to do manual work around X. The following alternatives are available: (A) change the deadline, (B) move feature A to next release, (C) remove some other feature". In the absence of any other guidance I'll direct the team to follow the plan above. Happy to discuss further.
I've always found this is a pretty effective strategy. Big companies aren't often dumb, you just need to know how to operate in them.
The outcomes I describe above aren't some strange, rare occurrence. They are the normal outcome for projects formed around arbitrary scope/date choices. But people keep doing it. Indeed, they often can't even conceive of alternatives. Why is why, as here, people speak of the choice as an intrinsic property of the project rather than a consciously made decision among a variety of approaches.
This isn't a human universal, by the way. All of this is an outgrowth of western 20th century business culture and management techniques. But it is so much the dominant culture now that alternatives are literally unthinkable for a lot of people.
So until there is stable consensus among everyone up to even late adopters about how software work should be managed, any opinion built into the tool will end up being an obstacle for users who are still yet to learn agility the hard way.
The real value of an opinionated tool is the opinion itself. And that is something that has to be instilled first. Build a knowledge-base, a following, a community, then make the tool a companion piece.
No. Good luck persuading the management to try something else!
> It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process.
> More importantly, like all good games they are passed on from generation to generation by "children" I.T. people learning from "adult" managers who of course learnt the games from their adults when they were children and so on. Of course, none of the academic institutions [our preschools] prepare the new I.T. graduate for these games but rather, leave it to the cold reality of the work environment to teach graduates [the new children] that estimation techniques are only good for teaching in university.
> The good news is that I.T. can estimate better. The bad news is that there are lifetimes of games and refining of games that have to be avoided to do this.
There used to be a good copy of it easily visible on the web, today the best I can find for you is this PDF copy of the article: http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F...
Previous HN discussion (~200 days ago): https://news.ycombinator.com/item?id=9182814
Also worth a read for a chuckle: http://www.dadhacker.com/blog/?p=2267
We often worked for clients that had media advertising booked and paid for. The product had to be ready.
So you make it work. Reduce scope, phase the releases, whatever it takes.
beginning with Salesforce.com downwards you have vendors releasing on a fixed schedule.
your valve is scope, but even that is fairly fixed as customers drive what needs to get released when (not "stupid" managers).
In order to get schedule to change, you'd have to convince salespeople to do something. They are generally the ones doing the convincing.
In order to get the features to change, you'd have to get a product manager to give up what they want to build "because of technical reasons". That doesn't happen often.
But if the product ships with the new features on the agreed upon date, the only people hurt are the developers and the customers. Most people in the business who pretend to care about the customer experience are perfectly happy to do this because it gives them a big club to wield over the engineering team in future iterations.
Do you find that this really works out, in practice? Joel has argued[1] that the only schedule worth anything is the one set by the developers themselves. Management can set relative priorities (X is twice as important as Y), but trying to force a faster deadline on the developers is like trying to make your Linux box run faster by renice-ing every process to -20.
Now, the problem with developer-set schedules is that they tend to underestimate how long things will take. Hence, FogBugz figures out how much each developer underestimates on average, and builds bell curves for the realistic completion time.
[1] http://www.joelonsoftware.com/items/2007/10/26.html