Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 WaterfallScrum
   
Fundamental AssumptionsSystems are fully specifiable, predictable, and can be build through meticulous and extensive planning.High-quality, adaptive software can be developed by small teams using principles of continuous design improvement and testing based on rapid feedback and change.
ControlProcess centricPeople centricPredictive: decisions are based on forecastsEmpirical: decisions are based on realities you observe in the actual project
Management StyleCommand-and-control (amber organizations)Leadership-and-collaboration (orange and green organizations)
Knowledge ManagementExplicitTacit
Role AssignmentIndividual - favors specializationSelf-organizing teams - encourages role interchangeability
CommunicationFormalInformal
Customer's RoleImportantCriticalProject Cycle
Organization of WorkGuided by tasks or activitiesarchitectural level and tasks (vertical slices by architectural level)Guided by product features (horizontal slices through each architectural layer)
Development ModelLife cycle modelEvolutionary delivery model
Desired Organizational StructureMechanistic (bureaucratic with high formalization)Organic (flexible and participative, encouraging cooperative social action)

...

We recommend using Waterfall if: 

...

  • Customers know exactly what they want in advance and will not change their mind
  • You know exactly what your customers want
  • You know that your users will like your initial design
  • Any feedback from users is not addressed or can be addressed in a subsequent project
  • You’re working with fixed-price / fixed-bid contracts
  • The project is very simple or you’ve done it many times beforeRequirements are very well known and fixed
  • Customers know exactly what they want in advance
  • You’re working with orderly and predictable simple, unchanging projects
  • You anticipate zero errors throughout the project

And you should use Scrum if:

  • Your customer does not know exactly what they want at first or could change their mind
  • You don't always know exactly what your customers want or they're needs aren't always communicated perfectly
  • Your users provide feedback on your design and you'd like to act on it
  • You prefer to address user feedback during the project rather than after (or never)
  • The final product isn’t clearly defined The clients/stakeholders need the ability to modify the scopeat first
  • You anticipate any kind of changes during the projectRapid deployment is the goalthere will be changes in scope, requirements, opinions, priority, environment, people, or technology during the project
  • Some part of the project is different or is of moderate complexity
  • You want the option of calling a project "done" once sufficient value is created (avoiding "everything but the kitchen sink" pitfall)
  • Errors during the process are typically identified and corrected quickly

When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or expect any changes throughout the project, go with Agile. If you know the project is fixed, unchanging, and predictable, Waterfall may be a better choice.