How do I survive in a Waterfall world?

Question

I currently work in a company where the Waterfall model is deeply ingrained. We are pushing Agile principles but it's a long process. Meanwhile, I have to work in a Waterfall world with sequential projects phases.

My question is about the analysis phase. I must provide a list of task and how long they will take. What techniques can I use to improve the accuracy/precision of my estimates, while fulfilling the requirement of having a detailed estimate up front?

One example I know would be to use prototyping to get more knowledge before making the estimate.

Answer 1

Gather better, more specific customer requirements.

When you refine the requirements to the point where each requirement can be satisfied with a handful of classes, and you have a pretty good idea what those classes will look like in code, it will become much clearer how long things are going to take, and it will be much easier to declare success on each requirement.

Your requirements should include detailed specifications of all of the interfaces between components, so that it will be clear to each software developer exactly what they need to do, and it will be easier to divvy up the work, or move work from one developer to another.

One thing you might want to push is smaller waterfalls. Breaking up the project into phases will help everyone by providing checkpoints where you can monitor progress and get feedback from stakeholders (much like you would with agile). Agile succeeds where waterfall fails because waterfall often bites off more than you can chew.

Answer 2

In order to get better at providing the list of tasks and the time they will take, you need to practice and record your results. So first make every estimate fairly detailed (don't forget to include communications and meetings, requirements development, designing, tests, qa, deployment, documentation (always needed in waterfall), research and other non-coding tasks. The first thing people do wrong is they estimate only for the actual coding time. You think, "Well that will take me about 2 days so that is the estimate" and 12 hours of meetings later, you haven't even started to develop.

When you give an estimate, store it and the time somewhere and when you do the project, mark down how long each task actually took. Soon you will see a pattern (most people consistently estimate too low). You also will now have the data to say what time things take. It becomes harder to argue with your estimates when they are based on hard numbers of what it took for similar tasks in the past.

In a waterfall project, you can assume there will be last minute changes, so estimate for a percentage of time spent on that too! If a task is new (you have no similar tasks in the history), remember to add a more research and design time because figuring out what to do will probably take the most time.

In a waterfall project, the best thing you can do for yourself and your team is to slip the deadline and increase the estimate every single time they change the requirement after the requirements definition phase. If they get new estmates from you consistently that tell them how much that little change will cost, you will reduce the number of "Oh by the way" changes you get drastically. You need to manage the customer in a large project.

And spend the time up front in requirement development and design. That is the purpose of a waterfall project since it is far cheaper to change things at that point than after you have done the development work. There are types of projects that are more suited to waterfall than agile. So don't automatically think it is bad that you use it. Instead learn to use it well to manage projects. If you learn to manage waterfall well, you are ahead of most devlopers in either waterfall or agile environaments because the truth is most developers are lousy at anything involving management of a project and getting projects ouit the door is the name of the game.