Should you adjust the estimates to match? If you do this, then you can adjust the plan accordingly. How early can you test the correlation between the estimates in your plan and the actual rate of progress? When work is performed in large blocks and integrated at the end, it’s far too late for effective re-planning when the difference is noticed. How can you validate your plan earlier?
Working in small increments and continuously integrating can help, but you also need to know that those small increments are actually done. Using estimates of “the database layer is 90% done” won’t help, as you’re back to depending on unverifiable estimates. Rather than creating small increments based on the building blocks of your project, try using small increments of functionality. These functional slices will touch numerous building blocks, but can be tested unambiguously as to whether or not they work as desired.
After re-planning based on the reality you observe, you can attend to fitting that plan into your constraints. If progress is too slow to fit everything you want into your budgeted time or cost, consider trimming the scope of the work. This can be done by eliminating features, or by slimming features down into easier--though less capable--versions. You may have to make some difficult decisions about priority.
Observe where your delays and bottlenecks are. What makes the actual speed as slow as it is? If it seems that things “should be faster”, then it’s possible they would be--except for an accumulation of difficulties that impede progress. Perhaps there are some quick wins in outdated procedures that can be eliminated and speed up progress. Perhaps the internal quality of the code has been ignored to the point that everything is hard to change. It will take time to improve that quality, but it will eventually pay off in faster development speeds.
Make adjusting estimates easy. Estimate in artificial units, and roughly correlate the artificial units to the ones you need to examine. People use story count, story points, t-shirt sizes, animals and other analogs for estimation sizes. Try to be consistent, but be aware that estimation will vary over time. An advantage of artificial units is that you don’t have to go back and re-estimate when the apparent speed changes. If you were accomplishing 38 stories per month, and now you’re accomplishing 46, you don’t have to worry so much where that 8-story-per-month improvement originated. Merely project using the newer figure, and see what that does to your plan.
Don’t expect estimates to be precise. If you need them to be precise, you’re trying to plan too close to the edge of failure. Don’t rely on optimistic numbers. Also think about what a downturn would mean. Don’t validate your estimates with reality only once. Continue to re-check throughout your project. Work in priority order so that you can re-plan frequently to the end, but still deliver the highest priority functionality. And if you cannot prune the scope to fit and still achieve the project’s value, then you’re likely to be working on the wrong project.
As Tom DeMarco said, “Strict control is something that matters a lot on relatively useless projects and much less on useful projects.” [“Software Engineering: An Idea Whose Time Has Come and Gone?”, July/August 2009 IEEE Software, pp 96, 95] Projects with a high return on investment can survive a few inaccuracies in estimation. Projects that need precise estimates likely won’t return their investment.
No comments:
Post a Comment