This article is part of the Agile Manifesto 10th Anniversary series that is being published on InfoQ.
Agile - 10 Years On would have been a good title in the hacker years of the early 1960s, before management started piling on the processes that Agile later stripped off in the early 1990s. But the return to basics had already begun in the mid-1980s, when Smalltalk, Objective-C and C++ set the scene for object-oriented programming. Anthropomorphic programming, object-oriented GUIs, end-user mental models, and ease of change were the watchwords. Those folks were Agile before Agile was cool.
From the hacker culture of 1960, to objects in 1980, was twenty years. Fast-forward twenty more years and we approach the Agile Manifesto. Twenty years is a human generation. It’s an eternity in Internet years. That seems curious in an industry whose technology cycles range from 3 to 7 years. We’ll ponder the time constant later. Today, we have now come 10 years hence - uncomfortably midstream across a 20-year cycle. It’s a treacherous but nonetheless interesting perspective from which to take stock.
As with most landmark publications, the Manifesto is more a recognition of established practices of its time than a vision for the future. Almost every important document in history has ratified status quo rather than fostering revolution. The Magna Charta, for example, only captured the common social practice that had emerged in the twelfth century. It only asked King John to formally recognize that new reality. Written culture tends to lag oral culture (as we know from Agile requirements). As for the Manifesto, it captured Scrum’s practice of eight to ten years, a decade of practice in Borland QPW, and the longstanding mores of many leading software projects world-wide. The Seventeen Boys’ Choir had in fact done a good service for the community. And they weren’t even certified yet. Where things went from there wasn’t their fault.
Perhaps the Manifesto’s key value isn’t so much its insight, originality, and certainly not prescience, but in its connection to programming populism. It became the main instrument of broad, mainstream change. It attacked the sometimes faceless, un-rationalized resistance by which Kuhn characterizes a paradigm shift. In that sense it truly was a Manifesto. It was a dangerous document. If you distill the four dichotomies of the Manifesto, they concern only two principles: self-organization, and the feedback to support it. Self-organization really rubbed against the prevailing business culture of the 1960s.
One sign that it was a populist movement was the lack of public push-back. The Manifesto was rarely held up as a pointed attack on any method or language. XP was Agile. Scrum was Agile. RUP was Agile. Google was “doing Agile. “ And Microsoft and IBM were “doing Agile. “
The Manifesto is not only a reflection on the direction of change, but on the need for change itself. That made it a difficult target for potential rhetorical detractors. Its most important tailwind was the progressive spirit of the 1960s. No one dare stand as an enemy of change. And Agile’s hidden memes of self-organization and feedback hark back to the anti-establishment1960s - a value that carried through the anti-establishment thinking of the object movement between hackerdom and Agiledom.
However, as with most trademark-able labels, manifestos, and other documented ideals, the reality of the trumpeted practice often missed the mark. “Agile” became a label for a wide collection of otherwise unrelated practices, a collecting point that empowered people to justify their favorite practice. Pair programming - around since Lister talked about it in the 1960s - now became de rigeur. Boehm’s Spirals from 1986 became sprints and episodes. We re-invented teams. The old JAD idea of bringing all perspectives to the table resurfaced as collective ownership.
Elsewhere, a vocal cult of well-intentioned hijackers promoted Agile principles with an Orwellian ring to them. We have test scripts and jUnit trumping individuals and interactions. More Agile papers and chapters were written about the need to write comprehensive tests than ever were written about writing good, working code; only Uncle Bob and friends of late have come to the rescue. (And as much as the literature talks about tests, it offers precious little about what makes a good test.) As for embracing change, don’t you dare threaten the XP practices, and don’t look for a place to suggest improvements to the Scrum framework. Freedom is slavery. (There is, on the other hand, a process for adding new CMMI practices.)
Beyond that, Agile became a substitute for thinking. That the Manifesto said X was adequate to justify doing X. To be non-Agile was to be a Communist. I’ll never forget the black arm bands at OOPSLA one year. (Today, they seem to have devolved into more innocent and prettier woven wrist bracelets.) Agile was not so much a response as a reaction - a reaction against the excesses of the management practices that arose in the 1960s and 1970s, and again among the CASE tools and methodologies of the 1980s. And it was a violent action. As Mary Poppendieck envisions the movements of our discipline as being a pendulum that is rarely centered, so the more extreme (to coin a phrase) programmers slammed the pendulum as far to one end as possible. While the 1980s methodologies were preoccupied with plans, and by inference the thought and planning behind them, the Agile world frowned on anything but doing. Each of the Manifesto’s dichotomies relates to doing. None of them are fundamentally about the thinking we find in Lean. Just drop the first step of the Plan-Do-Check-Act business cycle. Ignorance is strength. The proverbial baby and bathwater come to mind.
Why do we seek this freedom on a 20-year cycle? My student Julie Beata researched patterns in fashion trends across the generations back in 2004. Her conclusion was that fashion followed generational cycles of 20 years because enough children shop with their parents to be subject to the nostalgia-fueled approval of their purchases. Does Agile remind your boss of the high-minded ideals of the early object era in the 1980s, just as the early advocates of object orientation yearned for the pre-methodology days of software development a generation earlier?
This cycle’s length is noteworthy. Most computing fashion follows technological cycles: from Ada to C++ to Java, for example, or between Oracle, Sybase, DB2, and MySQL. These cycles are rarely of any consequence at the level of fundamental industry value or paradigms of development. What may be noteworthy is that Agile bespeaks a value system. Value systems change slowly: at the pace of the turnover of societal generations.
What will the future bring? Likely, more dialog that is based in good research and dialectic of social process, as well as bickering that is based in posturing. Such is the fate, I fear, for a discipline that is not a discipline, a science that is not a science, and an art that is not an art. The panel debates will be viewed as valuable, and the next Manifesto will probably show up on schedule to launch the next war against ineptitude: the next pendulum slam. Oh, well. War is peace.
About the Author
Jim ("Cope") Coplien is the father of Organizational Patterns, is one of the founders of the Software Pattern discipline, a pioneer in practical object-oriented design in the early 1990s and is a widely consulted authority, author, and trainer in the areas of software design and organizational improvements. As one of the founders and proponents of Agile software development, one of Cope's passions is to root out dysfunction in widely but naively adopted software practices such as TDD and On-Site Customer, that look good on the surface but which do harm in practice. He also is actively leading the work in Agile Architecture in conjunction the Scrum community.