Welcome back to part 4 of Agile vs. Waterfall. Our first part introduced the Waterfall model, our second part introduced the agile Scrum model and our third part described the relationship between cost, functionality and time. In this part I will compare the positives and negatives of the two approaches and give our insights into when each method is suited and for which types of project.
If you have not read part 1 it can be found here.
If you have not read part 2 it can be found here.
If you have not read part 3 it can be found here.
No more hanging around, let’s get to the comparison!
The positives of Waterfall
Planning, designing and architecture is more straightforward since the customer and the developers agree on what will be delivered early in the life cycle. Since the full scope of work is known, progress is also more easily measured.
Depending on the phase of the project all team members do not need to be locked down in the project. As an example business analysts (BAs) can proceed working on other parts, or other projects entirely, after requirements are written and vice versa, developers do not need to be involved before the BAs actually know what needs to be delivered. Based on requirements from BAs, testers can prepare test scripts while developers are coding along etc.
After the requirements phase there is no strong need for customer presence and thus they can focus on other more pertinent things. The customer basically only needs to be involved for status reviews, approvals etc.
If multiple systems/components/software packages need to be integrated and launched at the same time (internal and/or external) an early design is often required. This is thus suited perfectly to the staged approach of Waterfall.
Architecture, a trade often forgotten or neglected in modern software development, can also be designed better for scalability, overall coherence and completeness since there is a more thorough understanding of all parts of the entire system. Code does not need to be rewritten over and over again, which sometimes can be the case in Scrum and which sometimes results in a piecemeal system.
Project resources are not as critical, since planning and documentation has already been done, thus if a developer drops out, it is easy for a new resource to fill the position and get up to speed quickly and following the plan.
Because the Waterfall method requires upfront planning, software can be launched quickly after development. Estimation of complete timetables and budgets can be done more accurately, which definitely tends to please customers.
The negatives of Waterfall
Gathering and documenting requirements so the customer understands what they mean is very difficult. Customers are often intimidated by details, and specific details must be provided early in the project before progress can be made. Customers are often not able to visualize an application from a requirements document. Wireframes and mockups will help, but most end users have difficulty understanding these elements in enough detail to clearly visualize the end product.
This problem means that customer might be dissatisfied with their delivered product once it is complete. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until large parts of the project are finished. At that point in time, changes are difficult and costly.
Feedback and testing are deferred until bigger parts of the project is complete. This means that problems or inadequacies can be harder to change without substantial amounts of time and effort.
The positives of Scrum
Since the customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the project, the customer gains a sense of ownership. The customer works extensively and directly with the project team throughout the project.
Scrum will produce a simple working base version faster than Waterfall, which for instance makes it suitable for prototyping.
Development is user focused and changes due to problems or inadequacies can be remedied quicker and less costly. Since design is flexible the project will run a more evolutionary and less stringent life. This has a number of advantages, especially in project environments where development needs to be able to respond to changes in requirements rapidly and effectively.
Scrum can be especially beneficial in situations where the end-goals of projects are not clearly defined. If it is not possible for the customer to provide a clear goal early on in the project Scrum will work well since this will be clarified as the project progresses.
Using Scrum there is typically more interaction and communication, which often takes precedence of design. Since stakeholders are more involved, it is especially conducive to teamwork oriented environments. Different developers work on different modules throughout the development process and then work to integrate all of these modules together into a cohesive piece of software at the end of the project.
The negatives of Scrum
Not all customers have either a wish or the time to be highly involved in the project. Scrum works best when all members of the team are completely dedicated to the project. Thus it is not generally a good idea to have less than 100% dedicated resources for this type of project.
Scrum focuses on time-boxed delivery and frequent reprioritization and thus some items might not be completed within the allotted project timeframe. Additional sprints might be needed to become feature complete, which of course will add to the total cost. Also, the high degree of customer involvement often leads to additional features requested throughout the project, extending the time to complete.
Customers often have difficulty keeping up with Scrum’s rapid development iteration and testing cycle. This can put the project at risk, since the longer developers go without feedback, the harder it is to recover if they are not developing what the customer expects.
Since Scrum is highly flexible it simply does not have the structure that the Waterfall method has. Scrum projects tend to be hard to predict, from timelines to budgets. Without a concrete plan and complete requirement set, everything remains a bit vague.
The close teamwork in Scrum is easiest to manage when the team members are located in the same physical space. Furthermore, the intense collaboration and less than complete requirements results in catastrophic problems if key team members leave the project.
Scrum has less emphasis on understanding the finished system as a whole early in the project which can lead to a reduction in overall system quality and performance. This is especially true for larger-scale implementations, or with systems that include a high level of integration points.
This method of development can be quite time consuming, much more time consuming than the Waterfall method. There is a lot of rewriting code due to changing requirements and bolted on functionality. Often the requirements are not clear from the beginning, which can result in suboptimal architecture that is not flexible enough to meet the final requirements. Often there is not spent much time getting into the true details and really flesh out what the users need before coding is commenced.
As the initial project does not have a definitive plan, the final product can be grossly different than what was initially intended. This also relates to the inability to give an exact launch date once a contract is signed.
When to choose Waterfall over Scrum
Some things to consider:
- Project size and complexity is large e.g. large system integration involving many different systems
- Customer cannot commit to extensive involvement
- External system integrations are numerous involving many points (incl. legacy systems)
- Budget and/or schedule are fixed or difficult to modify
- Full featured project/product required before launching
- Developers are in need of guidance, management and supervision
- Customer does not expect major changes in the scope
- Customer knows exactly what they want
When to choose Scrum over Waterfall
Some things to consider:
- Project size and complexity is small or not complex (can be used on larger projects under certain circumstances) e.g. smaller eCommerce, websites, app development
- Customer is available frequently through the duration of the project
- Customer is able to change scope of the project during progress
- External system integration is simple or not needed
- Budget and/or schedule are flexible and changes are welcomed by the customer
- Rapid prototyping and deployment required. Project/product can be launched without being feature complete
- No clear picture of what the final product should look like
- Developers are skilled, adaptable and able to think independently without constant supervision
- When the product is intended for an industry with constantly changing standards
This was the end of part 4. I hope it was understandable, informative and you now have a basis for choosing the right method for your project.
Come back and read the last part (part 5) of “Agile vs. Waterfall. Which model is then better?”, where I will give some deeper insights and consideration into how a combination of both worlds might be preferred.
Photo by The Chef!
By Dennis Kayser, CEO of Forecast.it
Find me on Twitter, Google+ and let’s connect on LinkedIn.
Let us help you optimize the value of your projects.