I don't think I've ever seen a software project hit a deadline, that includes early delivery as well as late.
I found the constant focus on time estimating in management disciplines incredibly contrived and frustrating. It's an incredibly wrong headed effort at taking mass production estimate techniques (where zero creativity is required) and applying it towards a creative endeavor. It makes as much sense as asking "how many innovations per hour can the team accomplish?" "or how many paintings can a team of painters crank out per day?".
What I think bothers me the most is how this is treated in management education. At its simplest, you start with a roll of the die, because any estimate is essentially a Wild Ass Guess (WAG). But then, realizing that software deadlines are never met, the management discipline tries to use various structured techniques for estimating, like complex work breakdown structures and critical path analysis blah blah blah, which of course simply use WAGs at a finer level of granularity and do little but generate busy work for the managers. Instead of one WAG, we now have dozens or hundreds of small WAGs.
Of course none of this provides a better estimate of time, but might include gems like when aggregating your WAGs from a work breakdown structure to derive a total project estimate, add 20% to each small WAG to build in "slack time" which is another way of saying "we don't really know how long it'll take, so we're going to over estimate as a Check Your Ass (CYA) maneuver, if we estimate out long enough, all work will get done early!". Brilliant. Modern management practices have now turned from coordinating and organizing complex efforts into professional CYA endeavor.
I think there's light at the end of the tunnel, most of this nonsense is a result of trying to scope box projects, which makes sense when building a bridge, or making millions of widgets, but makes little sense when building new software. There's obviously a need for setting deadlines, as anybody who's ever managed a "when it's done" software project knows...that only asks for "Duke Nukem Forever" problems. Setting deadlines keeps people on task and motivated.
So the solution? What do your business needs dictate in terms of delivery time? Then timebox to that. If features don't get built by that time, too bad. Software, unlike building a bridge, is a continuous practice. You can build, deliver and then rev to fix, extend, addend software that didn't hit the desired scope. It eliminates lots of the CYA and WAG nonsense, and forces people to try and get as much as possible done in the allotted time anyways. It keeps the development team from going into (what I consider) largely unethical extended crunch periods near or after a WAGs arbitrary deadline. They'll simply focus on what they can deliver. It's descriptive of their job instead of proscriptive. It implicitly creates the understanding that full functionality is not the goal for a milestone.
"Build as much as you can by x" makes more sense than "How long will it take to build all of Y?".
> "Build as much as you can by x" makes more sense than "How long will it take to build all of Y?".
As a developer this makes total sense and I love it.
The problem is when the rest of the company that exists outside of the development world (i.e. creating new things), like sales and marketing, is that they would rather the whole company align under the "build all of Y" type of scenario because it makes their jobs fantastically easier. At the expense of the devs, of course.
As "agile" development practices continue to spread, I am hopeful that this re-framing of development around short development iterations and continuous delivery begins to transform the processes of the "clients" of development teams as well.
In my experience, when sales and marketing hear 'agile' they think it means you can deliver everything in a week. They don't hear 'iterations' or 'a certain amount of functionality' they hear 'completely done, faster'.
You're absolutely right and I have no idea how to best solve this communication problem. The rest of the world is simply trained to scope box. They probably don't even know what their technique is called.
I've found time boxing works much better the deeper in the bowels of an organization you work in.
If you have a receptive customer, try and start with a regular release cycle as part of the overall project management. "During development, we'll do regular releases every x-number of weeks. We'll meet every 2 release cycles to see where we are with respect to overall scope vs. the last release(s), spot bottlenecks or readjust scope and requirements as needed". This gives them lots of input into the process without getting too involved in the day-to-day and let's you timebox. They get regular insight and feedback as the product progresses, and you can emphasize or deemphasize requirements as things go on.
I found the constant focus on time estimating in management disciplines incredibly contrived and frustrating. It's an incredibly wrong headed effort at taking mass production estimate techniques (where zero creativity is required) and applying it towards a creative endeavor. It makes as much sense as asking "how many innovations per hour can the team accomplish?" "or how many paintings can a team of painters crank out per day?".
What I think bothers me the most is how this is treated in management education. At its simplest, you start with a roll of the die, because any estimate is essentially a Wild Ass Guess (WAG). But then, realizing that software deadlines are never met, the management discipline tries to use various structured techniques for estimating, like complex work breakdown structures and critical path analysis blah blah blah, which of course simply use WAGs at a finer level of granularity and do little but generate busy work for the managers. Instead of one WAG, we now have dozens or hundreds of small WAGs.
Of course none of this provides a better estimate of time, but might include gems like when aggregating your WAGs from a work breakdown structure to derive a total project estimate, add 20% to each small WAG to build in "slack time" which is another way of saying "we don't really know how long it'll take, so we're going to over estimate as a Check Your Ass (CYA) maneuver, if we estimate out long enough, all work will get done early!". Brilliant. Modern management practices have now turned from coordinating and organizing complex efforts into professional CYA endeavor.
I think there's light at the end of the tunnel, most of this nonsense is a result of trying to scope box projects, which makes sense when building a bridge, or making millions of widgets, but makes little sense when building new software. There's obviously a need for setting deadlines, as anybody who's ever managed a "when it's done" software project knows...that only asks for "Duke Nukem Forever" problems. Setting deadlines keeps people on task and motivated.
So the solution? What do your business needs dictate in terms of delivery time? Then timebox to that. If features don't get built by that time, too bad. Software, unlike building a bridge, is a continuous practice. You can build, deliver and then rev to fix, extend, addend software that didn't hit the desired scope. It eliminates lots of the CYA and WAG nonsense, and forces people to try and get as much as possible done in the allotted time anyways. It keeps the development team from going into (what I consider) largely unethical extended crunch periods near or after a WAGs arbitrary deadline. They'll simply focus on what they can deliver. It's descriptive of their job instead of proscriptive. It implicitly creates the understanding that full functionality is not the goal for a milestone.
"Build as much as you can by x" makes more sense than "How long will it take to build all of Y?".