...
Waterfall | Scrum | ||
---|---|---|---|
Fundamental Assumptions | Systems 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. | |
Control | Process centric | People centricPredictive: decisions are based on forecasts | Empirical: decisions are based on realities you observe in the actual project |
Management Style | Command-and-control (amber organizations) | Leadership-and-collaboration (orange and green organizations) | |
Knowledge Management | Explicit | Tacit | |
Role Assignment | Individual - favors specialization | Self-organizing teams - encourages role interchangeability | |
Communication | Formal | Informal | |
Customer's Role | Important | CriticalProject Cycle | |
Organization of Work | Guided by tasks or activitiesarchitectural level and tasks (vertical slices by architectural level) | Guided by product features (horizontal slices through each architectural layer) | |
Development Model | Life cycle model | Evolutionary delivery model | |
Desired Organizational Structure | Mechanistic (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.