The tech world is littered with tricky terms, jarring jargon and convoluted concepts which are hard to keep track of, and often make your mind go into a spin of computational buffering. Waterfall? Scrum? Agile? If these terms mean absolutely nothing to you then not to worry, your friendly team of WeAreBrain tech nerds are here to help explain exactly what the differences are between these important stages of the development process in order to get you in the know.
Ready to defeat your tech ignorance? Let’s do this!
Throughout the duration of a project, you and your team will either choose or be forced to make a series of important decisions which could affect the outcome of the entire project. The first of which usually revolves around which type of project management methodology you wish to follow.
There are a variety of different project management frameworks to use, but for the purposes of this article, we will focus on Waterfall, Agile and Scrum principles. Some processes are rigid and structured, while others are more flexible and adaptive. Each has its own strengths and weaknesses depending on the project and your development team. By understanding the vital elements involved in each process you will be able to choose which process best suits your requirements.
Waterfall methodology follows a step-by-step, linear process and is the most straightforward and popular version of the system development life cycle (SDLC) for software engineering and information technology.
It is often planned-out using a chart showing start and end dates for each task in the process. Only once one task is complete can the development team move on to the next, but only after being reviewed and approved by the client. Due to Waterfall’s linear nature, it is impossible to go back a step or jump forward without starting the entire process again from scratch.
The term ‘waterfall’ is used as a way of describing the process which involves each step of the process beholden to the previous one, building upon previous foundations to create a process flow headed in a single direction. Waterfall is best suited to projects with a fixed scope, deadline and budget.
Due to its rigid, linear nature, the Waterfall method is best suited to simple, unchanging projects. It also makes it a fairly easy process to follow and document as it follows the same sequential pattern for each project. Each phase of each step has specific goals and deliverables, including the review processes, and thus it is a very easy process to both manage and control. Because of its intended simplicity, development teams require little to no onboarding prior to starting a project.
Because each step contains pre-determined start, end and review dates it naturally lends itself to being a highly disciplined process. This means that clients and stakeholders are able to chart and review progress at each step, allowing for transparency and communication throughout the entire project. Before any code is written, all design and peripheral requirements are set out to reduce the risk of missing deadline deliverables. This means that each phase of every step of the entire project is documented so everyone is aware of every detail, which helps tremendously for posterity purposes.
The most glaring problem facing the Waterfall method is its inability to adapt to change. When issues arise at any stage it is almost impossible to go back a step or jump between them, rather you have to start from the beginning as each phase informs the next.
Code can only begin to be written once two or three phases of the project have already been completed. This means that stakeholders are only able to review software very late in the project, once a lot of work has already been completed. Problems can naturally arise from this delay. For instance, clients may begin a project without clarity on what exactly is needed, and usually, identify issues and requirements as the project is approaching the middle of its life cycle. If clients realise certain changes need to be made, these changes are difficult to perform due to the sequential, rigid nature of the Waterfall method.
In direct contrast to the Waterfall method, Agile software development is based on an iterative, incremental approach. Agile opts for a more free and fluid approach with the ability to perform changes and iterations as and when they are needed. Requirements can change at almost any phase of the project and so not as much in-depth planning is required before beginning a project. Agile encourages constant feedback from its users in order to adapt to their changing requirements. Development teams are organised into cross-functional units which work on iterations over time, with the goal of each iteration to produce a working product.
Agile leadership encourages teamwork and face-to-face interactions between development teams and stakeholders to meet the needs of the end-user. This creates a culture of accountability which breeds ownership and excellence. The goals of Agile are perfectly presented in the 12 Principles of Agile and in the Manifesto for Agile Software Development.
The most defining aspect of Agile is that it wholeheartedly embraces flexibility, speed, and above all else, continuous improvement. Because pre-project planning is lightweight, it means that teams are not beholden to a rigid system based on pre-defined restrictions and are therefore free to adapt and change as and when the need occurs. This flexibility at any stage breeds creativity and freedom within processes. Development teams are able to refine and re-prioritise the backlog, meaning ad-hoc changes are able to be implemented in a short space of time.
And because of Agile’s lightweight pre-project planning, it is not uncommon for development teams to begin a project without having a predefined end-goal in mind. This may appear at first to be counterintuitive, but what it actually means is that teams are given a fair amount of freedom and flexibility to shape the project in new directions according to the work already done. If teams stumble upon a great idea they are free to pursue it. Project elements can adapt easily to new goals which means the possibilities for each project are almost endless.
Agile involves breaking the project down into easier, more manageable units (or iterations) which leads to higher quality output from all teams, including improved and detailed development, collaboration and testing. With testing being conducted at each iteration, bugs and inconsistencies can quickly and easily be identified and resolved. Iteration consistency is key to improving the quality of the output.
Because Agile relies heavily on communication between development teams and stakeholders it breeds a strong work ethic, both individually as well as collectively. We don’t need to explain how stronger teams produce greater results.
Due to the continuous review process at each stage, clients remain up-to-date with the latest developments and are encouraged to provide feedback to the development team in order to get the best possible results for each project. The team listens to the feedback and incorporates it at each stage of the project, ensuring that the clients’ input is recognised and realised throughout the project lifecycle. This means continuous improvements are made to the project, resulting in a far more detailed and sophisticated project being released.
The cons of Agile may not necessarily be seen as cons as such if you enjoy flexibility, as they are just the downside of flexibility and freedom. Meaning, the cons can be easily avoided if you keep your affairs in moderate order. Let us explain:
Planning the project before commencing with any tangible work is less in-depth than the Waterfall method, and so certain issues of keeping sight of the end goal may arise. Some see this as a pro, others a con. For those who prefer concrete deadlines and timetables then they would intuitively see the fluid nature of Agile as a con. Because a project using Agile may pivot in direction and jump from one idea to the next, this can naturally cause delays in deliveries and conflicts in schedules. It basically makes the project manager’s job more tricky. It also means that the end result may differ drastically from the initial goal. But hey, if you want to bake a cake you have to break a few eggs, right?
Due to the small size of Agile development teams, individuals need to be very knowledgeable (at the very least) and highly skilled (at best) to be able to work on a variety of different tasks. Of course, having a highly skilled and brainy team is a good thing, but having teams filled with Jacks-of-all-trades is hard to come by, and pricey.
Time allocation to an Agile project can become problematic. The nature of Agile is that it involves continuous iterations and improvements, meaning it is often cumbersome to keep each member of the team dedicated to one specific component of a project.
Scrum is a sub-group of Agile, and regarded as the most popular framework for implementing Agile. There are a lot of frameworks, methods, practices, and tools that relate to Agile, and Scrum is just one of them. The model is based upon iterative software development and is used to manage complex software and product development. Sprints (time-fixed iterations) allow the development team to ship software on a regular cadence, resulting in new plans and steps being created by stakeholders and teams at the end of each sprint, bolstering performance. Check out the 5 scrum values and why they are important.
Scrum is seen as a rigid, plan-orientated process within the flexible Agile stable as it follows a defined set of rules outlining roles and responsibilities that remain constant throughout the project lifecycle. For instance, each sprint comprises 4 steps: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective (including refinement activity). During these meetings team members will elaborate on what they have done, what they are doing, and what they plan to do so the team is aware of everyone’s role and can provide feedback on each element of the project they are involved with. Scrum is great for product development in complex environments.
(Interesting fact: The term ‘scrum’ refers to a set piece in the sport of Rugby, where 8 brutes of the same team interlock to form a single unit, called a scrum, and push against the opposing team’s scrum in order to sink the basket to remain below par for a Birdie.)
Scrum adds a level of structure in Agile with its specific framework outlining rules, roles with responsibilities, events and artefacts. Through this, it allows for continuous improvement. Daily team meetings focus on the state of work in progress with the goal to plan the working day ahead. This helps provide overall transparency of the project and leads to early detection of issues that need to be resolved. When everyone is on the same page it creates a level of cohesion which allows proficiency to thrive.
Scrum teams don’t have a project manager (they do have a Scrum Master) but rather opt on collective decisions made by the team to face challenges. Collaboration is key and the team works as a unit to deliver what is needed during each sprint. Scrum is all about teamwork — each team member has a specific role, yet they all work in unison with each other toward a common goal, hence the name Scrum (see side note above).
With regular and shorter sprints allowing for constant feedback and greater communication, changes are able to be implemented faster. As in all teams, Scrum relies on the cohesion of each team member to serve the whole. This means that when a team operates as a single unit, they are able to work better, faster and smarter, saving time and ultimately money.
Because Scrum is a subset of Agile it means that the lack of a set deadline for the completion of the project can lead to additional work being added continuously, further delaying completion. And, as with any team relying on the strength of the sum of its parts, the commitment of the entire team to the project is paramount. If one person slips, the entire team follows suit. So individual, as well as team commitment and focus, is of the utmost importance.
Scrum teams don’t have a project manager or leader, but when a Scrum Master confuses their role with that of an authoritative figure it could lead to mutiny and project failure. So the Scrum Master has an important line to walk, to keep the team in check but also allow the team to make decisions as a whole.
If you have followed everything and understood the differences between Waterfall, Agile and Scrum processes thus far, then you should already have a good idea of which approach is best suited to you and your team. If you enjoy rigid rules and structures and find that they provide clarity then the Waterfall method may be your best bet, as this is for projects with a fixed scope, deadline, and budget. If, on the other hand, you find inspiration in the freedom and flexibility that Agile provides then that may well be where you need to focus.
If, however, you prefer a bit of structure within a fluid framework then Scrum is the way to go. But these methodologies must be weighed up against your project at hand and your desired end-goal.
An executive’s guide to AI and Intelligent Automation. Working Machines takes a look at how the renewed vigour for the development of Artificial Intelligence and Intelligent Automation technology has begun to change how businesses operate.