When it comes to software development or digital development the most popular project management and development methodologies in recent years are the waterfall and agile frameworks, along with a variation of the two called "hybrid".
The waterfall methodology has been around since the 1950s (the model was first described by Herbert Benington in 1956) and quickly became standard practice for software development and project management for years to come. The premise of waterfall is fairly simple: steps and tasks are happening in a sequential and linear structured approach. The most common steps are the following:
Detailed requirements and documentation gathering early on in the project provide a clear scope to the project, enabling project managers to communicate budgets, timelines, and key milestones to stakeholders.
Because of the detailed requirements, documentation and project plans, new team members (especially new programmers) can be added to the project and onboarded quickly and easily without derailing the timeline.
Well-defined roles and responsibilities for all team members.
Infrequent releases can be carefully planned and rolled out, and properly messaged to stakeholders.
It's difficult for the stakeholders to outline all of their requirements at the beginning of the project. As a result, when new requirements are uncovered halfway through the project it's difficult to add them to the pre-approved scope and timeline.
Changes are difficult to be made after the project moves past the requirements gathering and documentation phases.
Minimal or no customer collaboration and interaction during the development process can lead to costly changes when the project enters the testing phase (close to the end of the project) and the stakeholders realize that the product does not meet expectations.
Since all testing is done at the very end of the project, testers may uncover issues and bugs which could have informed an alternative architecture if they were discovered earlier.
Bureaucratic change management process.
When the project requirements are well known and understood at the project start and remain more or less fixed throughout the entire process.
In cases where a strict budget and timeline need to be prepared and followed, without alterations.
When the client wants to be minimally involved (or not involved at all) in the development process.
When there are many junior team members, or if team members change often (and there's a need for constant knowledge transfer throughout the project lifecycle).
When the timeline and budget are fixed and rigid.
The agile methodology was born in 2001 with the publication of the "Agile Manifesto". In theory, agile is the opposite of waterfall development and project management. Agile follows an iterative approach where instead of drafting lengthy project requirements at the start of a project, an agile team breaks down larger projects into more manageable tasks and specific features. They then tackle each one under a specific time constraint, known as a sprint.
Agile methodologies are also defined by the ways in which a project team comes together. There are specific meetings that help facilitate the workflow across the team. Some of them include a bi-weekly sprint planning and retrospective, a daily standup, and a weekly or bi-weekly demo.
Agile is more flexible, and project teams are able to adapt to new client requests and changes much more rapidly.
The client is usually very involved in the whole process, participating in weekly or bi-weekly planning sessions and demos, so they are able to provide immediate feedback. This more intimate involvement also helps forge a closer relationship with the client.
Encourages continuous improvement, as lessons learned from one sprint are then applied to the next.
Allows self-organizing teams and resource allocation.
Constant planning takes time.
Since agile allows for constant change and adaptation, it can lead to scope creep, impact the timeline and budget, and also resourcing.
Clients may not be as available for meetings as initially assumed.
Even though agile allows for a lot of flexibility and adjustments on requirements, there are no opportunities to make changes during a sprint.
No, or little, documentation.
Project team members must be highly skilled and possess good communication skills.
When the client doesn't have clear goals and requirements at the beginning of the project and wants to leave the possibility open to adjust along the way.
When the project can be broken down and produced in incremental deliveries.
When the client/product owner is comfortable with change and flexibility, and they're available and willing to collaborate and be involved and provide feedback throughout the project.
When the project team is highly skilled and well-disciplined.
When the timeline and budget are flexible.
In real-life situations, project teams may choose to use elements of both methods (Waterfall and Agile) to deliver a project. What we call “Hybrid project management” refers to methods that combine planning strategies from the traditional waterfall methodology, combined with the agile methodology's flexible approach. The elements selected from the 2 methods may vary from project to project, depending on the client's and project's needs.
In theory, the hybrid model is the best of both worlds. It allows project teams to select those elements most important for the successful delivery of the specific project. However, as with any model, the hybrid model has some pitfalls as well, most commonly that since this is not a "defined" approach and process it's important for the project team and the client to discuss, understand, and agree upon the "hybrid" process and elements that will be used.
As an example in our world, the world of web development, it's common to gather most requirements up front, then work on the wireframes and design (and functional requirements) using the waterfall method, and then switch to an agile process when we go into development and delivery. A hybrid approach could then look something like this:
Or there could be variations of this approach whereas an example - requirements gathering could be done in a waterfall fashion, while design and development could be done in sprints using an agile process. Anything is possible when choosing to go with a "hybrid" model. What's most important is that the "new" process is clearly defined and agreed upon, and then explained to everyone involved (project teams and clients/stakeholders).
Project management is changing. Teams that were once siloed are now asked to work together to increase visibility across all types of work. Choosing Agile vs Waterfall seems to be less of a choice in recent years, as more and more organizations require a mix of the two - a hybrid approach - in order to achieve optimal results.
Sign up to our bi-weekly newsletter for a bite-sized curation of valuable insight from the Sitecore community.