Agile and Waterfall are two distinct frameworks for managing projects. Waterfall is said to be old school, and Agile is the favored approach for modern projects. But is it true? 

Much has been written comparing the two methodologies, yet little has been done to consider the scale of projects adopting one or the other. And like many things in life, scale does matter. 

Nassim Nicholas Taleb addresses scale in multiple instances in his work. For instance, lifting 1 pound 500 times is not the same as lifting 500 pounds 1 time, or that a city is not a large village. 

At the center of the argument between the two methodologies is that Agile promotes short iteration cycles, collecting feedback at the end of each one, and possibly incorporating lessons learned into the next cycle, whereas Waterfall produces complete and detailed specifications then goes about implementing them until the product is ready to be released. 

Costs and misconceptions 

It would be naive to blindly advocate for one framework or another in the absolute. Agile, for example, has a high operational cost. By that I mean the time consumed in running the stand-up, retrospective, and planning meetings, and the team morale for having to take part in the rituals—loathed by some—when their value is not clearly visible. 

Progress is mostly incremental from one day to the next, yet everyone must “report” what has been done, whilst others try their best to remain attentive to the conversation. And retrospectives require reflecting on potential learnings or feedback that may or may not make into the product. 

Last, but not least, according to Metcalfe’s law, the complexity of communication grows proportionally to the square of the number of people in the group. 

Complexity ≈ (number of people)²

A team of four people has a communication complexity of 16. Adding a fifth person raises it to 25. (This is yet another reason for avoiding growing teams prematurely.) 

At the Waterfall camp, it is proclaimed that too much time is spent in writing the specification, and that as soon as the ink is dry, the document becomes immutable, and the project will be implemented verbatim to the blueprint. This is a misconception, as it would be unimaginable that competent teams would not course correct on lessons learned. 

Reality of scale

Most projects are too small to truly benefit from methodology A, B, or C. Argumentation on the merits of one versus the other in small teams or projects is time wasted. Differences become more perceptible for large scale projects.

	Pros	Cons
Agile	It creates natural opportunities where conversations and feedback happen.	The short cycles and constant feedback leave the door open for scope creep under a fixed deadline.
Waterfall	It imposes a discipline of thought to visualize the big picture.	The inflexibility on complete specifications leads to implementation divergence from the original intent.

Yet, like the yin-yang, each methodology has elements of the other within itself. For instance, building and launching a rocket into space has elements that are defined from end-to-end. The vehicle’s intent is to carry life and cargo off of Earth and to other destinations. One cannot begin by building a cargo van and iterate from there. At the same time, there are countless iterations, experiments, and cycles getting each part precisely right. 

Until projects reach a certain scale, it is difficult to distinguish the benefits of a project management methodology from another. Rather than pontificate on frameworks, jump into action and build. A spreadsheet or a to-do list is preferable to paralysis. 

Wrapping up 

Getting s**t done is far superior to squabbling over methodologies, especially for small-scale projects. Processes are meant to serve you and facilitate structured planning and organize the execution of the work. It should adapt to you and your team, not the other way around—save rare exceptions from heavily regulated industries. 

As Marc Andreessen would say, it’s time to build.