Waterfall or Agile? Well…

One of my favorites phrases is “It depends”. Just like in most practices and disciplines, generalizing or having a blind faith on a “silver bullet” should be a red flag. Each case is different, as each project can be. Engaging the right methodology can be the key factor to have a successful project instead of a case study of “what not to do next time”.

The Waterfall approach, as explained by the PMI (https:/www.pmi.org/) considers a project as a “a temporary endeavor undertaken to create a unique product or service” where “projects are different from other ongoing operations in an organization, because unlike operations, projects have a definite beginning and an end - they have a limited duration”. The “traditional” approach has clearly defined phases (processes and areas) that are sequential and take things slow and steady. Under this methodology, the project outcome is achieved at the end as a result of following these processes.

It is mostly connected to large scale projects from manufacturing to building large endeavors under conditions that is assumed will not change during the project completion.

Agile practices, on the other hand, originated from software development and the need for flexibility and adaptability, as its manifesto highlights “Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan” (https://agilemanifesto.org/). Agile, by definition, fosters interaction and experimentation and particularly a fast-paced delivery of working products in an incremental way.

“How can I tell to go Waterfall or Agile?”

Answer A: Get a seasoned consultant on project and process management to help you (I am not saying you contact me or ping me on LinkedIn. There are many, many other consultants out there.)

Answer B: Analyze your project by answering a few questions.

·        Is my project meant to generate a result/outcome with a scope that will not change during the execution? (i.e. a bridge, a building, a new engine, a new car vs a mobile app, a new software that address a -current- market need)

If the answer is yes, Waterfall might be applicable.

·        Will my project outcome need of permanent feedback from stakeholders during the execution, instead of defining all fixed requirements at the start?

If the answer is yes, Agile is the way to go.

·        Do I have a set of goals for the project, I prioritize at the start, but I am willing to reshuffle them as we go in order to get the best value and speed-to-market, even if at the end I do not get all the requirements covered?

If the answer is yes, then most definitely Agile will be your right option

·        Will my project team work on permanent contact and communication, even daily, and it will require high self coordination and synchronization?

If yes is the answer, then go Agile. If instead your cadence will be defined by certain fixed touchpoints, Waterfall might do well.

·        Will my project be funded by costs agreed and signed upon at the start -by fixed priced contracts?

If your answer is positive, Waterfall is likely the right option (a fixed cost is a very common requirement on government contracts). If on the other hand you cannot tell the full scope at the start, using a “time and materials” approach or similar for funding, go Agile.

On today’s project management market most practices tend to be Agile, even when they are not always the best fit. Make sure you analyze your project goals in detail, how the team will work and who will be involved, what kind of product or service you wish to create, know your value creation process and market. All these will be in direct connection to your project methodology.

And when in doubt, ask an expert.