BT

Agile 10 Years On

Posted by James Coplien on Feb 18, 2011 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Thinking by Valentin Mocanu

Success is guarantee for frameworks that specify what to do (“Doing”) and not on what to think (“thinking”), or even “thinking” is specified, will be interpreted as doing.
Agile Manifesto is more about thinking (think how to implement principles) , but have some missing: what about cases when you cannot apply principles , shall you think to adapt de process ? Think that it is a world beyond Agile?
Scrum is popular because is embracing more explicitly “doing”. Peoples want to know what they need to DO, not to think. Yes, if you listen the Scrum authors, you shall think to agile principles, but the framework itself does not contain too much about that.
RUP has a key principle: “adapt the process”. It is this principle followed by “RUP users” ? NO, because that mean to think. A common RUP “adoption” is to copy-paste from the knowledge base.
On the 10th Anniversary of Agile Manifesto, there are other AM authors that put they signature to “think more” principle?

A path forward? by Adam Nemeth

What I like about Coplien is that he's someone who tries to hold up an outsider's view, tries not to be affected by fashions. We need people who actually think.

Even if we don't agree with them all of the time. I'd say for me, about the recent publications from him, it's more about disagreement than not ;)

I don't think however CASE or processes ever got traction: I think that we just tried to do them. We spoke about them. We tried to align to them. But it was the same mess-up.

Now we try to align to Agile. It's the same mess-up, I see some companies going absolutely nowhere, shouting agile patterns as mottos to each others instead of RUP mottos now. They still don't advance.

I also wouldn't say we're at a pendulum; Maybe we are, yes, in terms of mottos, but otherwise, we're just getting to understand ourselves.

This is the puberty of an engineering science, maybe even less, just early childhood. We don't really understand ourselves yet. We know some parts - like, actually getting things done might be more important at the end than having nice documents about them - but these are just guesses.

Once you understand how software engineering works, how engineering works, you'll just learn that as an engineer, you're in charge to balance between values given the context.

I hope, that 10 years on, in case this industry still exists, we will have a lot of people who embrace thinking and finding balances instead of following howto-s or let people go loose. That could be another direction of that pendulum, maybe better

Re: A path forward? by James Coplien

Adam,

Nice.

Speaking of engineering, which is, I think, a very small minority of the Agile crowd, though I count myself among them: www.computer.org/portal/web/buildyourcareer/blog/

I hope you find that these essays try to nudge engineers in the direction you envision.

Let's keep up the good work.

Re: A path forward? by Adam Nemeth

Thank you very much.

Would really like to comment there, but the 99 dollar price of the computer.org membership is a bit expensive for a comment.

I have collected some writings - one of them may fit Ars Gratia Artis post - at architect-things.blogspot.com ;the article mentioned can be found at architect-things.blogspot.com/2011/01/archive-s...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT