Waterfall VS Scrum

Waterfall VS Scrum

Are you getting ready to start a software development project and you keep hearing about “Waterfall VS Scrum”? Whether you know a bit about these two software development methodologies, or they are brand new to you, we are going to discuss some of the pros and cons of each one. We will also let you in on which we prefer and why. Every project is different. Every client is different. Every team is different. With so many inconsistencies in the software development world how can anyone stand behind just one method? Well, some of it is individual philosophy, however, some is based in cold hard fact. Lets start by explaining the facts before moving into our beliefs.

The Waterfall Method

 

Much like a drop of water cascading down a cliff, the path of the waterfall method is very linear. The various phases of build, test, review, and launch, are all carefully planned out ahead of time so that when development starts there is a clear roadmap to work from. Because of its linear process, this long-practised method requires very specific details to be plotted out ahead of time and does not allow for changes or revisions to the plan along the way. This also means that phases like testing are slated for late in the process, leaving no room for revising the plan should something come up.

However, this rigidity means predictability and waterfall allows for more accurate predictions of both project length and budget. This predictability can be useful is meeting specific time or financial constraints – a big benefit for clients.

With waterfall, if the predetermined plan was perfectly laid out then the resulting completed project will likely be a smooth success. However, how often can any of us say that things were perfectly laid out ahead of time? That is where the “Scrum Method” comes in.

The Scrum Method

 

If the waterfall method is defined by its linear and rigid approach, then scrum is defined by both its flexible and unpredictable nature. The focus of the scrum method is to learn and adapt during the development process. A large project will be broken into specific parts or features and tackled individually during short “sprints”. These sprints allow room for feedback where any changes can be assessed and applied on the fly. This allows for projects to begin development even before a clearly defined end result is in place. As the project quickly passes through phases – often multiple times – regular building, testing, and reviewing can help steer towards a clear result.

This flexibility and openness to adjustments does have some drawbacks. Because feedback is welcome and revisions essential, a project’s timeframe and budget can often be hard to predict. True, every problem is met with a careful solution, but problems often arise in ways and numbers nobody can foresee. For this reason, the scrum method of software development can often be difficult to explain to a client who would rather have a guaranteed delivery date and budget amount.

Our Philosophy

 

With countless years of project development under our belt we have created successful projects using both methods. However, when thinking about overall product quality and success our experience has led us to one method we prefer. While the waterfall method can be useful for projects with explicitly defined goals we find it often limits the ability to give very valuable feedback. We have carefully built a team of both creative and technical minds whose expertise is invaluable in guiding a project from conception to completion. Developing software is a lot like raising a child. Your initial plans for it, and what it wants to grow up to be, can often end up being very different. Allowing for feedback along the way from the consumer, client, and developer alike is the perfect formula for making sure a project launches with success.

If you have a software project you would like to explore please contact us and we would be happy to discuss more about our scrum development process and how it applies to your goals.

Robert Patrick

[email protected]

Founder & Chief Architect Robert ("The One") started writing software at 12 years old, and founded PhD in the 1990′s at the age of 18. His philosophy is that working hard/playing hard, honesty and pursuing your true passion will lead to success and happiness.

No Comments

Post a Comment