My Initial Encounter with Agile

My first experience with Agile practices dates back to early 2001. I was grappling with a complex design issue, often overwhelmed by its intricacies. Up until then, my approach was strictly Waterfall, involving upfront class diagrams before any coding commenced.

In search of solutions, I turned to Craig Larman's "Applying UML and Patterns" (1997). This book introduced me to "Use-Case Driven Design," advocating for a spiral development model focused on continuous improvement through iterative implementation of use cases. A memorable quote from the book stated: "Each development cycle should take between two weeks and two months." Sound familiar?

My Initial Experience with Scrum

As mentioned in a previous article, my team began adopting Scrum in 2007, although the changes in our workflow were minimal. In retrospect, we were already practicing a form of Agile, albeit unknowingly. The adoption of Scrum merely provided terminology for our existing methods.

With a deeper understanding of Scrum now, I realize we were only scratching the surface. Despite working with multiple teams claiming to practice Scrum, I frequently sensed that something fundamental was missing.

Commonalities Among Agile Practices

Over the years, discussions with colleagues and experimentation led me to seek the fundamental essence of Agile. My initial experience was heavily focused on engineering, aligning with my background. However, my later engagement with Scrum felt more like project management, which sidelined the engineering perspective.

Yet, both approaches shared a common principle: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale." — Agile Manifesto Principles. So, are short iterations the crux of Agile? The answer is both yes and no.

Why the Term "Agile"?

Today, we refer to it as Agile, but before the Snowbird meeting that birthed the Agile Manifesto, it lacked a name. The creators viewed themselves as a counterforce to Waterfall, initially dubbing their approach "lightweight processes," which aptly contrasted with Waterfall.

In "Clean Agile," Robert C. Martin discusses the origins of the term Agile, indicating it wasn't the only contender, nor was it the most favored. Alternatives like "Light Weight" and "Adaptive" were proposed, but ultimately, Agile emerged as the most suitable option, albeit not without its flaws.

Could they have chosen a better name?

Rethinking the Name Agile

Reflecting on my feelings of incompleteness with Scrum, I realized it wasn't just a lack of engineering focus but something deeper. My early experience highlighted the issues of overengineering and overproduction. Working incrementally allowed for reassessment after each iteration, enabling me to plan based on results rather than mere expectations.

While Scrum partially addresses this, it often neglects to reevaluate the backlog after reviewing outcomes. Many are aware of this distinction, but they remain a minority.

This situation echoes Japan's economic struggles in the 1930s, where overproduction was a critical issue. The need to maximize value led to the birth of Lean methodologies.

Perhaps "Lean" would have been a more fitting name for Agile.

Agile's Lean Foundations

Agile is fundamentally rooted in Lean principles. The Snowbird gathering aimed to formulate an alternative to Waterfall methodologies, which were then dominant in the software industry, often dismissing other approaches as unprofessional. Waterfall represented the application of Scientific Management in software development. However, Lean soon began to replace it, emphasizing that delivering the right product held more value than merely minimizing production costs.

This principle resonates with the values articulated in the Agile Manifesto, which prioritizes the ability to pivot and avoid unnecessary features.

Many may be unaware of the connection between Agile and Lean, as I was until recently. About two decades ago, after Kent Beck described how Extreme Programming could be implemented, a CFO remarked, "Why didn’t you tell me it was Lean for software?" His experience at Boeing during its transition to Lean made him realize that this was precisely what software development needed.

So, what encapsulates the essence of Agile?

The Core of Agile

The essence of Agile lies in the acknowledgment that we can be wrong. To mitigate the impact of potential failures, Agile encourages taking the smallest possible steps, followed by reevaluating and adjusting plans after each one.

This is why all Agile methodologies emphasize short iterative cycles. Each delivery necessitates reassessment. Prolonged cycles risk overproduction and reduced competitiveness. By shortening cycles to two weeks or even less, we can genuinely embrace Agile practices and adapt swiftly.

Agile is not about adhering to a rigid plan; it's about the flexibility to adjust our course with each step. Achieving this is challenging, as it contrasts with traditional teachings, but it proves to be a more secure and valuable approach. We must accept the possibility of being wrong and strive for improvement—not through sheer quantity of output, but by enhancing value.

Though Agile methodologies may appear costlier than Waterfall—since Waterfall allows for larger batch productions with better optimization—Agile offers the potential for greater value delivery and a superior benefit-to-cost ratio.

Conclusion

It's essential to recognize that Agile is essentially a form of Lean thinking, acting as a stepping stone to rethink our industry practices.

Reflecting on my early experiences, the first methodology succeeded because it mandated reevaluation after each feature implementation. Conversely, Scrum faltered when teams adhered strictly to the backlog, ignoring results.

The crux lies in the ability to adjust plans. While frequent delivery is important, it loses significance without concurrent reevaluation. The real value emerges from continuous discovery of value or waste through iterative processes. Long-term plans often lead to cumbersome documentation and assumptions, while shorter iterations keep us aligned with reality, enhancing our chances of success.

When discussing Agile and its practice, we should focus less on methodologies and processes and more on how to iterate swiftly and adjust frequently in pursuit of value. Without regular reevaluation after each iteration, the practice cannot truly be considered Agile.