In the eighth installment of my blog series on “20 Controversial Topics of Debate in Agile“, the topic of debate is whether Agile and Waterfall approaches can co-exist within the same organization.
I think they can co-exist, but it may be with some difficulty. Here are a few pros and cons of having both exist at the same time in a company:
Pros
- The reality is that most organizations will likely have need of both
- It provides the flexibility to choose the best approach for the project
- The organization has the option to take a hybrid approach, if needed (program run traditional, development run Agile)
- It also gives employees the opportunity to choose the best fit for them
Cons
- Project Management Offices (PMOs) have a hard time accommodating Agile and managing both
- It can introduce confusion and inconsistent terminology and experiences
- It may create an “us” versus “them” mentality between teams
- Inconsistent delivery may result
- Can be difficult when there are dependencies
The bottom line
Most companies will need both
A project to move from one office building to another is not going to be the same as a project to create a new custom mobile application. The former is a very structured project, in which all the primary tasks are known. But the latter involves a lot of complexity and unknowns and would be poorly suited to a traditional approach.
Having both options available provides flexibility
You should always pick the right tool for the job, rather than trying to ram a square peg into a round hole. There’s no one-size-fits-all solution for project delivery. By making both traditional and Agile approaches available, you allow the project team to choose the best approach for the situation.
Because not all projects are suited to Agile…
Not all projects are well-suited to be run in an Agile fashion. Projects that may be more appropriate for a traditional approach include projects or products that:
- Have physical components to them that must be installed in a specific order
- Are like other projects that have been done by the organization in the past
- Have requirements that are well-known
- Little change is expected
- Have timing dependencies
…and not all projects are suited to Waterfall, either
Waterfall, or Traditional Project Management, is very appropriate for certain types of projects, and not others. For anything that is complex and there is more unknown than is known, an Agile approach would be a much better choice. Agile is built to adapt to change, whereas Waterfall is resistant to change. Check out the Stacey Diagram for a visual on how to pick the right approach.
Project Management Offices must adjust
This one is usually sort of a bitter pill for a Project Management Office (PMO) to swallow. I don’t want to talk badly about anyone, but from experience with PMOs, the people who run them are used to being in control. When you have both Agile and Waterfall happening at the same time, the PMO leaders will feel like they no longer have control (which they don’t).
In order to be successful using both project approaches, PMOs must change their processes to adapt to Agile practices. Gating systems won’t work well with Agile, but they could still be used on traditional projects.
Not all employees are comfortable with both approaches
Being Agile tends to expose poor performers or people who just don’t play well in the sandbox with others. And that’s a good thing. Poor performance can be addressed by the team, or those individuals will find themselves voted off the island. The same thing goes for people who prefer to work alone versus being on a team. Teamwork isn’t for everyone. Hopefully, you’ll still be able to put that person to work in a way that is best for the individual and the organization.
So, what do you think?
Do you work at an organization where both Agile and Waterfall approaches are being used? Is it problematic, or does it work well? Are there any other pros or cons you can think of? This blog series is meant to spur conversation and debate, so say something in the comments if you have an opinion. Thanks!
Next up in this blog series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can agile co-exist with waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?