...
Both Waterfall and Scrum are widely used methodologies for different reasons. Although most projects adopt one methodology over the other, the non-traditional hybrid method of using parts of each methodology can also be effective in arriving at the desired project outcome. Table below provides some characteristics of both Waterfall and Scrum. Detailed Detailed information on each methodologies methodology tailored for OIT can be found in the following links.
| 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 | Predictive: 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 and documented | Frequent and facilitated |
| Customer's Role | Important | Critical |
| Organization of Work | Guided by architectural level and tasks (vertical slices by architectural level) | Guided by product features (horizontal slices through each architectural layer) |
| Development Model | Life cycle model | Evolutionary/Incremental delivery model |
| Desired Organizational Structure | Mechanistic (bureaucratic with high formalization) | Organic (flexible and participative, encouraging interpersonal interactions) |
Consider Waterfall if: When to Use Waterfall and When to Use Scrum
We recommend using Waterfall if:
- Customers know exactly largely what they want in advance and will not change their mind
- You know exactly what your customers want
- You know that users will have no concerns with your initial designdo not expect major changes.
- Business users involvement will be high during initial planning and testing phases and on "as needed" basis during development.
- Any feedback from users is either addressed in a subsequent project or not at all
- You’re working with fixed-price / fixed-bid contracts
- The project is very predictable or you’ve done team has done similar projects many times beforebefore and has a well-defined path to delivery
- You’re working with fixed scope unchanging projects
- You anticipate only minor mistakes throughout the project
And you should use Consider 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 instead of after
- The final product isn’t clearly defined at first or the definition may change
- You anticipate there will be changes in scope, requirements, opinions, priority, environment, people, or technology during the projectBusiness users involvement is recommended at daily scrum.
- Priority shifts can occur during mid-sprint
- The final product may not be fully defined and the details can unfold iteratively over multiple sprints.
- Some part of the project is different or is of moderate complexity
- You want the option of closing a project early once sufficient value is created (avoiding "everything but the kitchen sink" pitfall)
...