Project Management Methodologies - Agile or Waterfall?

When it comes to project methodologies, the answer is not as simple as just doing Agile or Waterfall. It often really depends on the project, the type of work, the stakeholder, and the types of people in the team.

There is one word which really gets under my skin and that is “Wa-gile”. There are companies who say that they are Wa-gile. It seems that this means that they have adopted some of the terminology, but have not bothered to read or understand the agile manifesto. So they use the terminology but not the practices.

Waterfall - What is it good for?

The type of work and the stakeholder may necessitate doing things in a Waterfall fashion. 

If you are working with design jobs (no development) they go from scoping to concept, to versions, to final sign-off. These types of projects are very much Waterfall by nature. You can however make them more efficient by reducing documentation in favour of "versions". In design projects you will typically go back and forth with multiple versions anyway. So there's little value trying to document every design element before you even do a mockup.

Government projects also tend to be very prescriptive, and front-loaded with specifications. Therefore Waterfall is quite common even with technology builds. This is a scenario where the stakeholder basically forces the start of the project to run in a certain way. 

Sneaking In Agile

In software development, running an entire project in Waterfall often leads to disaster. The projects over run, and the tail end of the project and drag on longer than the original project. Fear not though...

It's totally ok to have a front-loaded Waterfall project, because you can still run a Waterfall project in an Agile way. Some clever stakeholder hand-holding may allow you sneak in some agile principles to help the project run smoother.

Ways to sneak in some Agile

• Reduce the word length of any documentation in exchange for diagrams, and external links to definitions & other documentation
• Do sprints during the build
• Define a tangible sprint goal
• Each sprint must deliver a "done" increment of the product
• Demo to the client as often as possible
• Ask for frequent check-in points
• You can even call these status meetings
• Tell the client: Even though things are heavily scoped, there are always some stakeholders who wont like something at the 11th hour, so we want to try to be proactive so the project doesn't over run

If you can’t get the stakeholders time, then ask for someone to be in their place. If there is total resistance from anyone on the stakeholders side to be engaged in the project then I would suggest that you nominate a person in your organisation to be a surrogate stakeholder. This person would try to understand the stakeholder’s motivations. 

Hopefully you can see that even though a Waterfall project is very front-loaded, internally you can actually have a few rituals in place to run it in an Agile way.

Final Thoughts

I hope I have shown you that it's not always as simple as Waterfall vs Agile. Waterfall is ok for some types of work, and sometimes the stakeholder (eg. Government departments) forces this on the project team. In software development this can be a disaster, so in my opinion it is really important to add Agile principles into the project. You can still have a Waterfall project, while using Agile principles.