|
Anyone relying on a medium-term estimate about a software project has clearly never been near one. A software system is an objective reality. It doesn't care what we want from it; it simply is. We can have intuitions about it, and use those intuitions to generate hypotheses about what will work, and ask the compiler / test suite to check them. But with a system of any real complexity, we're going to encounter surprising answers sometimes. We can't know how surprising, or how often, how long it will take to make sense of them, or what the ramifications will be for the rest of the project, until we actually get there. It's not like we were producing useful estimates and then decided against it. They were always lies. Refusing to provide a medium-range estimate is finally telling the business the truth, that we have no idea. Instead we can tell you what we do know: the functionality we delivered last sprint, and the functionality we're going to work on next sprint. That is what you pay us for. The software actually delivered. Not bullshit promises. But if you really do want a good faith, best effort forecast, then we need to plan the project in as much detail as possible upfront. Lock down the requirements, design the implementation, break down the work, and schedule it. Map out exactly what we're going to touch, so we can at least have a gut feel about how surprising it's going to be. That is waterfall. Own that, and do it right. Don't skip important steps and dress it up in agile clothing. |