February 2021 marks the 20th anniversary of the signing of the Agile Manifesto. Follow along as we reflect and look to the future.
In short—It works!
Happy Birthday Agile.
20 years is a lifetime in the software business! How remarkable that the simple set of principles embodied in the Agile Manifesto agreed to by the 17 pioneers in 2001 drove the vast and generally-positive change we’ve seen over these two decades. A grassroot change initiative that moved the industry; Agile grew out of the vast frustration experienced by software practitioners at the time.
Fundamentally, Waterfall and its myriad predecessors attempted to model software engineering after manufacturing-like processes. You can trace this thinking back to at least Hitachi’s creation in 1969 of its Hitachi Software Works Software Factory and perhaps further in history. While on the surface a logical approach to try to bring order to the wild world of software development, these approaches failed at a basic level to recognize several foundational realities.
First, legacy approaches failed to value highly enough that software development is a creative process. It is more aligned with creating a work of art that emanates from the mind and vision of its creators than it is with rapidly and efficiently producing multiple copies of a specified thing. The principles in Agile created an effective framework for embracing the idea that the creator does not know all the specifics up front. We paint broad brush strokes, we review what we have created, we learn, we iterate on that learning, we make another version. Simple, yet powerful, in its simplicity and aligned with how human beings operate.
…legacy approaches failed to value highly enough that software development is a creative process.
Second, legacy approaches valued process artifacts, like requirements documents, on par with and in some cases at a higher value than a view of the product itself. Conventional thinking was, ‘If we can just get the requirements all written correctly when we build the software it will meet what we need.’ This thinking fails to recognize that human beings are tactile creatures—we can much more easily react (positively or negatively) to things we can see, touch, smell, etc., than trying to visualize what a product might look like and how it might function from reading a pile of documents.
Third, anyone who has worked in pretty much any organization, whether they know it or not, are familiar with ‘Murphy’s Law.’ The short version is “Anything that can go wrong will go wrong.” A closely aligned saying from my military service days was, “No plan survives contact with the enemy.” Legacy approaches to building software attempted to manage away risk of failure by increasingly rigorous process definition, controls, specifications, and gates to forward progress; logical ideas in a manufacturing process where you are creating multiple instances of roughly the same item but it is the antithesis to making progress in a creative process. So, in Agile should you have a plan? Absolutely…but…the Agile founders created a framework for embracing the reality that things WILL go wrong and the team needs to be able to adapt to that change the same as in any other learning-based process.
…the Agile founders created a framework for embracing the reality that things WILL go wrong
Agile means many things to many people. I worked on teams that started experimenting with the concepts embodied in the manifesto soon after its publishing. As with many ‘new’ ideas in the technology and software fields, many are short-lived fads or repackaged concepts. We heard all these and more during the early days of Agile.
There were software engineers, testers, managers, and people from all walks of life in the software engineering world that attempted to use the ideas of Agile to not do certain tasks and activities they deemed not important. We heard: ‘Agile will make testers/testing not needed;’ ‘We don’t need project management any more because the team will manage itself;’ ‘Agile is only useful on small projects, it could never scale to enterprise class software engineering;’ ‘Agile is just an excuse by rogue developers to just sling code the way they want without testing’…all kinds of naysaying over these last 20 years.
Yet, Agile is still here! While not perfect, Agile is far better aligned with the way human beings think, work, and behave than anything before it. Of course, the principles need to be understood and pragmatically implemented in context. The bottom line is that the concepts in Agile, when well implemented, are the most disciplined and productive software engineering model I have worked in during my 25 years in this industry!
Happy Birthday Agile!
