Waterfall, Agile, Scrum, Kanban, Extreme Programming… If you are in IT you probably heard one of these buzzwords. They are all referring to software development methodologies which define the processes used to build software. To give you a short introduction on how software development is structured, in this post we are going to compare the oldest and today most popular development methodology – Waterfall and Scrum.
The waterfall model is known as the traditional model, ie. for many decades this was how software was built. As its name implies, It’s building software one step at a time, with each step falling down into the next lower step until everything is downstream.
The logical nature of Waterfall’s sequential processes still keeps this model very much in use. It begins with customer specifications of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software. One of the main needs of this model is the user‘s explicit prescription of complete requirements at the start of development.
Implementation of waterfall is a pretty straightforward path that follows 5 basic phases that encompasses the broad scope of forming the idea of developing a full-scale software. In Waterfall you can progress through each phase only by moving forward, meaning you can’t go back to a phase once it’s finished.
Waterfall phases
Analysis
The initial stage starts with analyzing potential requirements, which results in a requirement specification document that describes what should the software do and what features should it have.
Design
Once all requirements and wanted features are known, the goal is to outline how exactly will the application/system be built. Design phase covers technical requirements, creating an architectural design for the software and generally deciding how the system/application is going to be built and work together.
Coding
The actual coding of the software begins. Any flowcharts or algorithms created in the design phase are translated into a programming language.
Testing
Once the code is complete, the software needs to be tested for errors. Testers discover and report issues within the software that need to be resolved. It is not uncommon for this phase to cause a “necessary repeat” of the previous coding phase, in order for revealed bugs to be properly resolved.
Maintenance
After testing, the software is ready for deployment to live environment. Once customers have been using the software in the real world, they may find additional problems. The development team offers subsequent support and maintenance that may be required to keep it functional and up-to-date.
Waterfall is appropriate for project where requirements are fixed and work proceeds to completion in a linear way. If the software work is fast-paced and subject to a never-ending stream of changes in features, functions and information content, then the most suitable approach is Agile. This model speaks the most to the Age of the internet, where products are in a permanent state of evolution.
Agile development
The introduction of Agile into software development came as a response to the main problems of Waterfall. Namely, projects were coming in over budget and over deadline. The most used example story that summarizes Waterfall’s downsides perfectly is the one with Microsoft who used traditional waterfall approach for the development of Windows 95, 2000 and Vista. All releases were extremely late. Today, Microsoft has fully embraced the Agile method.
Agile method encourages releasing software incrementally, as opposed to trying to deliver it all at once. Agile is not so much a methodology as it is a set of principles on which software is made. This set of 12 principles is outlined in the Agile manifesto, which defines on a very detailed level how software development should be done. Based on this principles a lot of methodologies emerged that are considered agile in its nature. One of them is Scrum.
What is Scrum?
As defined by its creators, Ken Schwaber and Jeff Sutherland, Scrum is:
“Scrum is a formalized and prescriptive methodology that defines specific roles on a software development team, the workflow for developing the software, and what specific meeting should take place in each iteration of development, also known as a sprint.”
How does Scrum work?
Scrum works by breaking up the project into smaller iterations called Sprints and focusing on the defined amount of work that needs to be executed in the specific time frame. The focus of the sprint is to create a usable product version. There are 3 roles in Scrum – the Product Owner, the Scrum Master and the Development team.
Product Owner is the person who understands how the product meets business and market requirements. As the person who knows the product users the best, Product Owner is responsible for describing project features in the Product backlog.
Development team is responsible for code writing and testing. Team’s optimal size is up to 8 individuals.
Scrum master acts as a liaison between Product Owner and Development team. He helps the team to decide on Sprint features, ensures right people work on right tasks and that work will be completed in the defined time frame. He’s responsible for setting up daily meetings with the team on which they discuss development progress and identify blockers. Scrum Master is not just a regular project manager, he also supports the Product Owner, coaches the team and makes sure that Scrum processes are adhered to. Therefore, good communication and management skills are vital for every Scrum Master.
All project features are documented in the Product backlog, similar to requirements document in waterfall. However, Product backlog is subject to change. Features in the backlog are prioritized by the Product owner based on its importance to the business. The more important features need to be defined enough in order for the development team to start working on it.
Once the requirements are prioritized and sufficiently described, the development team gets together in a Sprint meeting where they decide on a subset of tasks that could be completed in a sprint. Sprints usually last for 1-4 weeks, depending on how important is to get the new releases out. When deciding on a time frame of the Sprints, it is wise to think about the overhead time that goes with each deployment and release. Since sprints are all about focusing on the selected tasks, if there is a bug in the production, it will have to wait for next Sprint to be resolved.
When the sprint is done, the team has a retrospective meeting where they reflect on the past Sprint and discuss ideas that could improve the following Sprints.
Which one to chose: Agile or Waterfall?
In this age of the Internet where rapid customer feedback demands constant product evolution, Agile methodologies, including Scrum, seem to be the most logical answer when selecting software development approach. If you are a business who knows in advance what kind of product you want and you already did your market research on customer wants and needs, then Waterfall might not be a bad road for you to take. After all, it’s easy to use and manage, you can define a scope of work and important milestones and all this leads to knowing approximate development price in advance, which is a nice information for the CEO and finance department.
However, setting things in stone can be quite challenging if you discover in the middle of the development that some features are becoming obsolete or the used technology is being replaced by some new framework. This is where Scrum really shines up, because this kind of change can be implemented in a couple of Sprints, depending on the scope. Fast customer feedback and frequent communication between all members of Scrum team ensure that most promising features are being ranked as a top priority in the Product backlog.
Things get heavy in Scrum when communication is going south and the team is not committing enough to the selected tasks. Remember, Scrum works in a way that team needs to cooperate very tightly together in achieving the Sprint goal, which is a big to-do list that needs to be crossed of in a very tight timeframe. If one team member hits a roadblock on his to-do list, it impacts other. However, multidisciplinary culture is strongly encouraged in Scrum, meaning roles overlap between team members, so developers can help each other out through proper communication.
At the end of the day, every methodology has its share of trade-offs. Before stepping into this arena, businesses need to have a real view on itself, get acquainted with every approach, count in pros and cons and select the one which is most suitable for their organization.
If you aren’t sure how to handle your projects, contact us and our team at Farshore will be happy to assist you and direct you in the right way, according to your needs and preferences.
Mateja is a Project Manager at Farshore, responsible for managing multi-platform projects and teams. She holds a Master’s Degree in Finance from University of Ljubljana.
