Understanding Agile vs. Waterfall

Often, we conceptualize Agile as merely a shorter version of Waterfall, characterized by smaller timeframes. However, the reality may be more nuanced.

I experienced a revelation recently.

As you may know, besides my consulting work, I also teach at a university. Just this past Tuesday afternoon, I delivered a talk at a local meetup focused on Test-Driven Development (TDD).

It had been a while since my last event, and the audience was fantastic. After the talk, we engaged in discussions, and I discovered two former students among the attendees. I inquired about how they had been doing, and they shared an intriguing insight with me.

They mentioned that my courses had completely altered their understanding. My discussion centered on TDD—I must admit, I aimed to cleverly guide them toward mastering TDD—so we delved into the topic of testing. They revealed that prior to my course, another instructor had also covered testing, but with a contrasting approach. While I advocated for writing tests before coding, the previous teacher encouraged testing only after the code was complete. This represented a fundamentally different perspective!

The earlier instructor prohibited writing any tests prior to coding and employed code path analysis as a means to ensure test completeness. Unsurprisingly, the methods proposed by that teacher were impractical without the code in hand first.

From my experience as a TDD practitioner, I prioritize creating tests first, or what I prefer to refer to as relevant business examples. My emphasis lies not on the code itself, but rather on the business objectives. Consequently, the tests must mirror those business rules.

In my view, any additional tests that are based solely on the code, rather than the business rules, become a liability. They constrain flexibility: every time a modification is needed, I must also adjust the tests alongside the code. When tests reflect the state of the code rather than the business logic, I lose the ability to ascertain if I'm compromising any business rules when altering the application’s behavior. Thus, they cannot serve as a reliable safety net.

From an Agile perspective, responding to change is crucial. Therefore, when we craft tests, they should facilitate easy modifications to the code. Hence, tests should always be written prior to the code.

This realization struck me once again after countless times. I continually find myself evolving my teaching based on my experiences in Agile environments, which starkly contrasts with the university's curriculum that is predominantly Waterfall-oriented.

Reflecting on Winston Royce's Waterfall diagram, we can see that testing traditionally follows coding:

Thus, if we adhere to TDD principles, which emphasize testing before coding, the diagram would require modification:

This isn’t the first time I've encountered this revelation. TDD also transforms program design. With TDD, we initiate with tests, then proceed to code, and afterward, we refactor. Refactoring is the phase that shapes the design. Since we commence with no pre-existing code, we also lack a design, which naturally emerges as we strive to enhance code maintainability. This paves the way for more intelligent architectures, altering our workflow once more:

One might argue that an essential difference lies in the cyclic nature of refactoring and testing:

Such cycles were already anticipated in the Waterfall methodology:

However, another significant adjustment I incorporate into my teaching is Lean principles. I advocate for Lean because it is vital for students to comprehend the disparity between expectations and reality. Traditional teachings, largely Waterfall-based, often presume that software requirements are flawless. Yet, a major critique of Waterfall is its propensity to yield products that do not meet market needs. This is precisely where Lean becomes relevant.

Lean emphasizes that we cannot assume our product concepts are inherently sound. Instead, we propose experiments to validate our ideas, which can subsequently be formalized as requirements if successful. To gauge success, we must analyze user interactions with the product. This once again alters the order of operations:

You might be thinking that Agile isn't synonymous with Lean or TDD. I concur. However, the underlying philosophy behind these methodologies has caught my attention. TDD significantly enhances our ability to adapt the code for rapid changes, thereby increasing agility. Lean takes it a step further by improving our capacity to adapt in a meaningful direction. Thus, while neither TDD nor Lean are explicitly part of the Agile Manifesto, they seem to represent the next logical progression in Agile practices.

People often discuss concepts like mini-waterfalls or water-scrum-fall because differentiating between them and pure Agile can be challenging. There exists a gray area between classic Waterfall and true Agile methodologies. Perhaps understanding this will help us enhance our journey toward Agile practices.

So, the lingering question remains: is Agile merely Waterfall turned upside down?

Chapter 2: The Impact of TDD and Lean on Agile Practices

This video discusses the fundamental differences between Waterfall and Agile methodologies, emphasizing the benefits of adopting Agile practices in software development.

In this video, the Agile and Waterfall methodologies are explained, highlighting key distinctions and offering tips for non-project managers on how to navigate these frameworks effectively.