No matter which software project you commence with, nearly every company and team has to deal with this question: should they use waterfall or go with agile?
Software development projects -in best cases- follow a path which is clearly defined in the SDLC, or software development cycle. This ensures that the end product lives up to current quality standards from every aspect.
That being said, a good SDLC should identify not just the main phases of the development process but should also lay down the structure of the workflow while transitioning from one phase to another. In most cases, you will have six or seven phases in an SDLC.
Probably no need to mention that waterfall and agile are the two most popular methods even though they are pretty different approaches.
Waterfall can be regarded as more of a traditional development model. It’s originally based on industry project construction and manufacturing and when you apply the same method to software development, you get a development cycle that’s made up of specialized tasks that should be completed in a certain phased and thoroughly reviewed and verified once there done before commencing to the next phase. This is what you call a sequential and linear approach, where the phases follow each other in a logical manner and flow downward from one to the next – hence the name “waterfall”.
From this aspect, the Agile method is a vastly different approach with different principles, based more on results, people, collaboration, and flexible adaptation and responses to change. Instead of having to plan out the entire project in one great blow, agile breaks down the process into smaller increments that should be completed in iterations (short time frames). Each of these short iterations has all the SDLC phases making sure that the delivered end product working and up to par with modern standards.
Agile vs Waterfall: The Differences
Without any doubt, both of these approaches will be helpful for development teams in creating high-quality software. Knowing the specific project demands and requirements along with knowing the main differences between Agile and Waterfall can help teams and team managers alike to choose between the two different methodologies to deliver a successful project in the end.
As such, here are some of the key differences:
- As already mentioned, waterfall follows a linear, sequential path, while Agile sports an approach with iterations and increments.
- Waterfall projects are divided into phases, while in Agile, they are separated into sprints.
- Agile completes many small projects, Waterfall focuses on a single, large project.
- Agile sports a mindset where the product focus is more on customer satisfaction, while Waterfall concentrates that same focus on successful project delivery.
- You prepare your requirements all at once with Waterfall, Agile needs you to prepare your requirements every day.
- Waterfall has a more rigid approach in terms of requirement changes once the project starts, while Agile is more “agile” in this respect allowing for more shifts at any given stage.
- Agile supports concurrent testing during development. Waterfall has the testing phase only when the build phase is finished.
- Test teams get more involvement in Agile in terms of requirements change. With Waterfall, test teams are not involved at all.
- Agile gives teams the opportunity to manage the entire project without a dedicated manager while Waterfall needs a project manager who plays a key role in every aspect.
The Agile Methodology
Now that you know the basic differences, it’s time to scrutinize each method a bit more. As already mentioned before, Agile sports a team-based approach that emphasizes the development of a functional application with a more dedicated focus on customer satisfaction. It is made up of two-week-long sprints, which are time-boxed phases. Before each sprint commences, teams prioritize a list of objectives based on customer preferences and input. After two weeks, the teams review and evaluate the work with the customer and make notes based on their evaluation. Based on Agile, other, more specific methods have emerged, like Kanban and Scrum.
What are the pros of this team-centric approach? The known benefits are:
- The development life cycle speeds up.
- The sprints follow a predictable schedule.
- Better customer satisfaction since the focus is on them.
- A flexible approach that will adapt to changes.
- Helps learn teams to manage projects themselves.
- Helps with communicating more efficiently between teammates and on the team-customer channel as well.
- Ideal non-fixed funding projects.
Like every approach, Agile also has its drawbacks which might make it inappropriate for a certain project, team, or setting. They are the following:
- A high degree of involvement from the customer can ultimately slow down the project, especially when the customer doesn’t want to be involved or uncomfortable with it.
- The methodology assumes that every team member is professional and dedicated. Without that dedication, self-management issues are prone to happen.
- Time-boxed iterations sometimes simply aren’t long enough to complete all defined tasks. In these cases, oftentimes priority changes are required which can lead to the implementation of additional sprints which will also translate into larger end development costs.
- Agile requires co-location to ensure top-notch communication. Unfortunately, that’s not always feasible.
The Waterfall Methodology
As mentioned already before, this is a sequential approach that carves the SDLC into several phases, like gathering requirements, design and analysis, coding and testing, system and user acceptance testing, and finally, deployment.
In every case, the next phase can commence only when the previous phase has been completed, tested, and reviewed. Between every phase, the team is expected either to deliver something, or a document is signed off. The phases are completed and passed only once, meaning that all requirements should be gathered at the start so team members don’t have to implement sudden changes nor in plans, budgets, schedules, or resources.
All in all, the Waterfall method is a highly plan-driven approach giving little to no space to changes after the project kicks off as it would often offset the entire plan and path, requiring the entire team to restart.
After presenting Agile, now its time to see the pros of this less flexible method:
- Planning is more straightforward and streamlined because the deliverables are determined at the very start of every project.
- Better overall design with the whole-system approach
- The work process is better defined overall
- Easier cost estimating
- Easier to track overall project progress
- Better-defined and accented team roles
- Resources can work in parallel for a specific task
While Waterfall definitely holds a lot of positives, some of the negatives had such profound effects that new methodologies were created to combat them and to lay down an alternative.
As such, here are the known cons of the approach:
- The rigid structure can make implementing necessary changes near impossible.
- Uncertainty is not an option.
- Customer engagement is limited which can translate to poor satisfaction.
- Large projects might not benefit from a sequential approach as the end results are too far in the future.
- Testing can be only performed in later project phases.
So, which one you should use?
If you’ve spent any time tinkering with digital projects, you know that the project management industry is more or less obsessed with methodologies. There are executives who base everything on certain approaches, while others question their relevance after a certain degree.
Looking at the two main approaches, you can see that they cater to different management styles, sport different ideas, and as such, require different levels of dedication and involvement from teams, customers, and managers alike.
Having that in mind, every project requires you to start from step one. Until you know what the project is, you’re not going to be able to decide how to approach it, right?
So, before casting your vote on Agile or Waterfall, you should take the following factors into account:
- Overall project size
- Project duration
- Organizational details
- Project complexity
- Client details
After taking everything into account, here are a few projects where it might be a better idea to implement the tried-and-tested sequential method:
- Remote projects, or collaborations with other organizations.
- Fix-time, -budget, and -scope projects.
- Smaller assignments with well-defined details.
- Tasks where client-involvement isn’t necessary.
Here are the instances where the more flexible methodology should be your winning approach:
- Projects where your organization is in charge of the entire development.
- Assignments where requirements are known to change over time.
- Larger projects, with high complexity and often undefined nature.
- Projects with heavy client-involvement.
The (Ugly) Truth
When it comes to these approaches and assessing their requirements, experts often agree that organizations don’t really analyze every little detail before commencing with actual development, rather, they are mainly influenced by previous experience and already existing and hammered-out processes.
That being said, your current projects will most probably play a detrimental role in how you will run your next project, no matter how simple, complex, demanding it is.
The truth is that every project should be a new challenge and a fresh start.
In an ideal world, if you take into consideration everything (even the stubbornness that most companies display in terms of choosing their preferred methods) experts say that the Agile approach should be the go-to method when you face a purely digital project.
All Agile-principles seem to fit the digital landscape better. In such a dynamic world, needs and requirements are ever-evolving, making it a better overall choice.
- Regular iterations: periodical checkups and reviews can help teams to fix problems and bugs in smaller chunks before having to review the entire project. Also, regular evaluations can help with updating certain requirements without having to go back to phase one.
- Client-involvement: in the digital arena, companies have to cater to the needs of their clients and often to the clients of their clients. This might be a little bit too overwhelming to take in, however, it’s the nature of the game which immediately makes the rules of conducting successful business even more complex. In an industry where the success of the project does not depend only on the professionalism of the development team, but on customer satisfaction and user experience, teams should be always eager to hear customer/user feedback and tweak the project according to their preferences. The Waterfall method simply does not allow this or leaves little room for such a degree of involvement.
- Team collab: the analogy is similar – more input from every team member and better overall communication can help adapt to project shifts and can speed up troubleshooting.
- Evolving requirements: the entire nature of the digital industry is geared toward constant change and advancements which make linear projects hard to execute in one shot without any major re-hauls or scope shifts. Linear projects are more or less set in stone for months in advance and they oftentimes just aren’t applicable for the requirements of the digital realm.
In this last section, we will focus on some of the challenges companies face on an organizational level when it comes to implementing such a flexible approach as Agile.
Problems With Implementing Agile
In some cases, agencies are just not ready to move to a more “agile” approach. Other times, clients simply want less involvement and a more fixed scope. So, what’s the best option in these cases? A hybrid approach might do the trick.
What’s a Hybrid?
A linear project has predetermined key stages that follow each other in sequences: discover, define, build, test, and lastly, deploy.
The problem is that companies often use this same approach and name it Agile because they split everything into two-week sprints and hold meetings daily or every two days. A true “Agile” project will have all these stages within every two-week sprint which poses the biggest challenge for most companies. Apart from that, in most cases, efficient communication within the team isn’t feasible (remote workers), or client-involvement becomes sketchy because of a bad historical relationship with the client, etc.
Hybrid approaches serve the purpose of gradually moving toward Agile principles. Some experts even dare to say that the hybrid model serves as a more realistic overall solution, or at least, during the transition and accommodation process.
Implementing a Hybrid
If you, as a project manager, wish to introduce a more flexible approach but your company culture favors a more linear way of thinking and working, there are a few ways you can introduce more agility to your projects without sacrificing the “set ways” of the linear working culture of your firm.
- Client-involvement: a huge challenge is changing the mindset of your clients and making them more open to take part in development projects and hear their feedback and input. To help improve the relationship between your client and the development process, try not putting them in charge right away. Have them involved in meetings and discussions, make sure that they know that their input is important, but take charge in core decisions at first. This way, your clients will get used to participating in projects, and in time, they will be more precise regarding voicing their needs and views.
- Team collab: smaller firms often find that it’s difficult to work with a fully dedicated team where members already have to concentrate on different projects at the same time. To start the transition, try to include every team member in meetings, even though not everyone was involved with tasks during a particular sprint. The aim here is to make them talk to each other regularly.
- Continuous planning: linear approaches favor ahead-planning. To introduce a more continuous approach, try shaping a plan upfront but leave a fair amount of planning to sprints. Outline the positives that might stem from changes throughout the project, and coach your clients to embrace a model with continuous involvement.
- Designing: to make the transition more streamlined, try to design every possible element as late as responsibly possible. This way, you will avoid doing unnecessary work and ending up with items you won’t even need. To pull this off, you need your team to work closely together, so this can only work with your team collaboration efforts in place.
Considerations With Hybrid Approaches
The key to success with trying to move from one model to another lies in focusing on the right things and getting all the help you need.
That means, don’t shy away from training, mentors, online courses, books, and other tools that can give you the knowledge (both theoretical and practical) to pull this off successfully.
Also, make sure that the executives of the company are all aboard with your ideas. Prepare a presentation that will showcase the benefits of making the move from one methodology to another.
Lastly, be patient and admitted if you need to give up. You need to get real: sometimes, it’s just out of your control. If your team, executives, or client are just too rigid to change, it might be better to make the best out of a linear approach than to force something that simply can’t be implemented in the current company working structure.
To avoid this, make sure that you always know your next step within a given project process, or at least, have a structure. Keep things streamlined and as simple as possible, and make sure that your team is also working in a streamlined fashion to avoid chaos and slacking off.
So, does project methodology guarantee success? A lot of people in management often seem to be pretty obsessed with different approaches and even dead-sure that using a particular methodology will lead to success in the case of every project.
If you base your presumptions on previous experiences, you will quickly see that using a methodology isn’t the be-all-end-all to a successful project.
Sometimes, the skillset of the project managers plays the most important role, as they have to navigate between teams and clients while keeping everything in check from deadlines through budgets to organizing meetings, reviews, and evaluations.
Other times, clients, team members, or the nature of the given organization can make or break a project.
In such a complex setting project methodology is only a piece in the puzzle and not the glue that should hold together the jigsaw picture.
All in all, a lot of the success boils down to flexibility, leadership, dedication, and problem-solving skills. These are the most important factors that will help the different methodologies work, and can help create a collaborative sphere between executives, teams, and clients.