In February 2001 the Agile Manifesto was signed by 17 people. The Manifesto is comprised of four values and 12 principles. The Manifesto acted as a lightning rod for what became the Agile movement. It provided a new framework to think about how work should or could be approached. That framework challenged the standard thinking of how software should be developed, enhanced, and maintained. 2001 was a year of transition. Even though most organizations were successful, the US economy was on the verge of a recession (the NERB tracked the 2001 recession from March 2001 to November 2001), many IT jobs were being outsourced, and the oft-quoted Chaos Reports suggested that software (and by extension hardware and systems) projects were late, over budget and did not deliver what was needed by the business. Anyone who was related to the broad software development industry had numerous war stories about projects that were death marches or abject failures. That said, all was not a wasteland. Most organizations were successful and most practitioners had also had success stories. If everything was doom and gloom most have us would have left software development, because constant failure is debilitating. Needless to say, the change was in the air in the late 90’s and early 00’s. The Agile Movement caught fire.
As the Agile movement was born, early adopters showed great passion for embracing the concepts of experimentation to find better ways of working, breaking work into small parts, and self-organization and self-management so teams could work together better. The success of the early adopters influenced whole organizations to embrace Agile, which espoused the idea that there was not just one perfect way to develop, enhance and maintain software but rather the complexity of team and organization capabilities, business and technical factors and macro-environmental concerns (such as competition and regulation) required teams to have the flexibility to address. In some cases, where organizations frowned on Agile, stories circulated of development teams revolting. It was said that teams changed how they operated while hiding the fact from their process overlords (that was at least the perception). I have always assumed that these stories were apocryphal; however, they made great stories to salt conference presentations with and I know I sat in rapt silence as I heard them recounted.
Over the past 15ish years Agile has taken off. If we use the output of Google Book Ngram Viewer as a proxy for the popularity of Agile we see an extraordinary growth curve.
That said, the movement driven by values and principles has faded replaced by a focus on frameworks and techniques. A little over a year ago, I witnessed an early advocate for Agile in an organization (someone that I had a lot of admiration for) stand up in front of a team he was part of and say, “I do not want to hear or talk about principles anymore, let’s just do BDD (behavior driven development).” He was tired of fighting for keeping teams together over time, he was tired of being pressed for up-front requirements documents and in reality, he has tired of fighting to try new ways of working in his department. (Side note: the person in question now sells real estate). The level of frustration is rife in many quarters of the software development community.
Today many organizations have accepted what Ken Schwaber, co-creator of Scrum, called “ScrumButt” and others now call blended/hybrid Agile (or worse). Acceptance is the pragmatic approach and possibly the natural evolution of Agile. However, there are complications that while will ensure that Agile techniques are the go-to tools for a long time spell the end of Agile as a movement.
Planned essays in Post Agile Age Arc include:
- Prescriptive Agile
- Tool Centric Agile
- The Return of People Versus System Management
- Method Lemmings
- The Age of Aquarius (Something Better is Beginning)
PS – I use Agile techniques in my writing, evaluating on daily basis and re-planning weekly. This is the long way of saying your comments and input are important to shaping this and all of the work I post on the Software Process and Measurement blog.