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.
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.
Some things to consider:
Part 6: Which method is better?