A needle of Hope
amid a haystack of Chaos.

SDLC: Waterfall Expectations vs. Agile Expectations

Created: Wednesday, May 16th, 2012
17:53:14 UTC

NOTE: In these scenarios, assume that the project will take at least 200 hours and that the tasks have been trimmed to only the mission-critical and cannot be reduced further.

The Waterfall Method Scenario:

  1. Come up with the project plan. 
  2. Have the devs come up with estimated time estimations for each task.
  3. Multiply that number by the number of projects your team must maintain in paralell with active development, plus one.
  4. Double the estimated hours because developers are usually overly optimistic of their ability to churn out stuff by about that magnitude. The primary reasons for this are that when they estimate time, they expect to be uninterrupted, fully inspired, and being able to fully focus on the given task at hand. In reality, they are often interrupted by others (particularly side chatter), inspired only a few hours every day (and struggle to get into The Zone the rest), and are frequently sidetracked onto other tasks by their managers. That's when they aren't browsing the Net to cope with all the stress and lack of inspiration.
  5. Assume 6 hours of 100% productive work a day with no weekend work, optimistically, and 4 hours conservatively. If you are understaffed or there is a tight deadline, this number will probably be even worse.
  6. Plot the date on the calendar.
  7. Prepare to blow past that date (almost all Waterfall projects go substantially over both time and budget). Also prepare for geometrically increasing fatigue from your team members and impatience from the business.
  8. Set a new date and repeat Steps 5-9 until the project is finished or abandoned (15% likelihood).

The Agile Method Scenario:

  1. Come up with the project plan.
  2. Have the devs come up time and effort estimations for each task.
  3. Multiply those numbers by the number of projects your team must maintain in paralell with active development, plus one.
  4. Double the estimated hours and effort.
  5. Organize tasks from the highest effort to the lowest effort.
  6. Assign tasks with compassion and only at the beginning of the sprint:
    • Assign no more than 20 effort level to any single dev during a 2 week sprint. 
    • Allow them to snipe any ticket at any difficulty level or importance level that they want if/when they finish their assigned tickets. 
    • Explicitly allow them the option to take time off after assigned tasks are completed. This will increase morale early on and provide an incentive to finish assigned tasks in the grueling later days, as well as provide a much-needed restorative period if they decide to give it their all and work overtime and on nights and weekends.
  7. Regularly calculate completion percent based on Completed Effort vs. Total Estimated Effort.
  8. Calculate completion time daily based upon Total Estimated Time times the delta of Completed Tasks’ Actual Time minus Estimated Time (Estimated Completion Time = TET * (CTAT - CTET)).
  9. Double the estimated time due to developers' unrealistic optimism.
  10. Assume 6 hours of 100% productive work a day with no weekend work, optimistically, and 4 hours conservatively. If you are understaffed or there is a tight deadline, this number will probably be even worse.
  11. Notify the business every week as to the progress and percent complete with the newly revised target date for completion. Include a complete list of the completed tasks, when they were completed and by which developer(s); and the incomplete task list.
  12. Design the application in a way that allows for early, incomplete release.
  13. Allow the business the option to declare the project acceptible for release at their perogative.

The Agile Method may seem like it has most of the risks of the Waterfall Method. That is because it does. The differences lie in code quality, time to launch, probability of a successful project (in both quality and budget) and the morale of the team. In every one of those respects, Agile is usually the winner.