The second death of agile

The 10 year anniversary of the agile manifesto has just passed. As part of some kind of distributed retrospective, there has been a lot of discussion about what will happen with agile now. I think that agile will be dead in ten years – I just hope it will be a good death. This will actually be the second death of agile, but I need to set some other things in context before describing the first one.

The good death

A good death for agile is what Mike Cohn describes is his great post on the future of agile. Agile becomes so ingrained in the way we develop systems that it becomes boring. People often describe the history of software development as a succession of ideas that are discarded in favor of new fads. They forget that most great ideas have not been thrown out, we have just stopped talking about them.

In 1981 the magazine Byte published an issue that was completely devoted to the Smalltalk programming environment. This issue had a profound effect on many developers and is seen as a tipping point for the spread of Smalltalk and object orientation. In 1991 Byte celebrated the tenth anniversary of the the 1981 issue by running a number of pieces on the state of Smalltalk and OO. One piece was an interview with Peter Deutsch and Adele Goldberg; two very influential figures in both Smalltalk and OO. They were asked what they thought about the future of Smalltalk and object orientation:

“We hope that in 2001, objects will be boring. In comparison, radical ideas of past decades – that system software should be written in higher level languages with strong type systems, and that computers can and should be seamlessly networked – are thoroughly accepted today.”

At the time, this was an astounding statement. Object orientation was not mainstream yet and lots of people were using all the classic denialist arguments against it: “it wont scale”, “nothing new”, etc. By 2001 Byte had ceased to exist, but even if it had still been around, I do not think it would have bothered with a twentieth anniversary issue.

The bad death

In Agile’s Second Chasm, William Pietri paints a bleak picture of the state of agile. He fears that agile is dying the death of commercialization and trivialization. The essence of agile is being lost in the struggle to make it easily accessible to people that are not really interested in changing the way they think. I agree that there is a definite possibility that agile can die the death of snake oil, but the opposite is also a potent threat. Agile can be killed by trivialization, but also by over-ambition.

Most people have heard of the Peter principle: In a hierarchy every employee tends to rise to his level of incompetence. Fewer know about «The Generalized Peter Principle»: Anything that works will be used in progressively more challenging applications until it fails. A variant of this is what I call the “Peter Principle of Methods”: A successful process will be expanded upon until it becomes useless.

People are clamouring for all sorts of extensions to agile. They point to all the things agile does not address: How do we make sure that the systems we build are the right ones? How do we assure that the organization uses a new system the right way? Lets make agile work as a business philosophy, they say.  I fear that some of the people trying to “save” agile will inadvertently kill it. And it has happened before.

Does this mean that I want to freeze agile? No, that would not be very agile would it? Agile should evolve, but I think it should not loose its focus on software. If you are interested in “agile” outside of software you should study systems thinking. Why reinvent the wheel? The combination of systems thinking and agile is much more potent that some new bloated variant of agile.

The first death

So, has agile died before? In the late eighties I was one of the early adopters of object oriented development. By the early nineties object orientation had become a buzzword. Everyone wanted to do it but few understood how. What few people seem to understand today is that OO in that period was not just about creating good classes and methods. We were using incremental and iterative development, refactoring software and a whole bunch of other “agile” practices. If you look at the program of an OOPSLA* conference from that period you will be astounded by the similarity to an agile conference (except, we talked a lot more about programming then). The reason we loved OO was that it seemed to be a great way of creating value for our customers. We saw OO as a lightweight alternative to traditional development. Being responsive to change and continual learning were core values. I am not implying that everything in agile was a part of OO. What I am certain of is that the core ideas in agile were created by people working in object oriented software projects.

And then RUP came along. RUP wanted to be a unifying method that would bring together all the best parts from a number of different sources. RUP claimed to be OO, but in its grand compromise it lost the essence of OO. People were seduced since RUP had “everything” and did not see how empty that everything was. When RUP rapidly became a de-facto standard for software development I felt that the things I had fought for had been lost. The late nineties were the dark ages of software development for me.

Conclusion

In ten years agile will be dead (again). This does not worry me. I hope it will be a good death, but if it is a bad one; the ideas that are the essence of agile will not die with it. They will just pop up in some new form.

*Object-Oriented Programming, Systems, Languages & Applications, the leading conference on object orientation in the nineties.

  • http://twitter.com/flowchainsensei Bob Marshall

    Good insights.

    I agree that there are some number of parallels between Agile and OO, and some transferable lessons. But there is at least one fundamental difference, which makes direct analogies between OO and agile invalid.

    I too was involved in the early nineties in bringing OO to a wider audience. And I too saw it as being about much more than just objects. Yes, an alternative to traditional development and a great way of creating value for e.g. customers. But back then, introducing OO did not (much) disturb the status quo of the organisation as a whole. The development teams could adopt OO and realise much of the benefits without having to bump into corporate policies, etc., and the collective organisational mindset.

    This is much less so with agile. Adopting agile will quickly begin to flush out dysfunctions within the organisation, outside of the development teams themselves (Scrum in particular was expressly designed to do this). Thus agile is much more disruptive to the organisation-wide status quo. Without recognising this and anticipating it (through both plans and actions), any agile adoption will likely either fail to deliver any significant benefits *to the organisation as a whole*, or quickly come to be seen as far too disruptive and «alien» by the powers-that-be, and thus get canned or converted into Wagile, Badgile, Scrumbutt, or the like.

    I too hope for a «good» second death for agile, but expect, sadly, it will rather more like be a «bad» death as alluded to by William Pietri’s article. I myself strive to raise these issues in the belief that, armed with the vital awareness, and suitable mitigations, we can collectively achieve the former rather than the latter.

    - Bob (@FlowchainSensei)

  • http://www.coregroup.no Niklas Bjørnerstedt

    Thank you Bob (I know you are not an easy person to please.. :)

    I am not sure that we are in that great disagreement. Yes, agile goes deeper than OO did (even if some of the OO projects I was on did have profound effects on the way the business worked). My core point is that the solution to getting better results with agile does not have to lie in an ever expanding scope for what agile should address. It can be better served by people becoming aware of and using things like systems thinking and (the good parts of) lean.

    Niklas

  • http://twitter.com/flowchainsensei Bob Marshall

    Ah. As to that core point – I agree.

    My dissent (if any) stems from repeated observation that focussing on agile as a purely local optimisation of the development teams does not (and cannot) effect the kinds of transformational benefits that many promise (and many others therefore seem to expect). So, keep the scope tight, yes, but realise that the tight scope extends outside the the dev teams into the wider organisation. A diagram might have allowed me to explain a little more clearly :}

    As the old saying goes: «Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.» (Antoine de Saint-Exupery). It might be nice, too, if folks involved in adopting agile thought a little more for themselves, in context, rather than looking to find their answers in books and (other people’s) methods.

    - Bob

  • http://www.coregroup.no Niklas Bjørnerstedt

    Bob, your last point touches on a problem that is a lot more general than just agile. Just look at the way many lean consultants copy the solutions of their lean heroes without any perspective on the context where these solutions worked. Some call it «cargo cult». I find that term too limited.

  • http://www.mountaingoatsoftware.com Mike Cohn

    Hi Niklas–
    Interesting post. One of the things I’ve always believed is that agile was the second phase of the object revolution. First, we had to learn how to program with objects. Then we had to learn how to manage OO projects. That became agile. It’s also why so many of the leading OO thinkers were involved with the advent of agile. This totally supports your view about the early 1990s OOPSLA conferences.

  • http://www.coregroup.no Niklas Bjørnerstedt

    Hi Mike,
    We have similar views then, only I see it more as a gradual shift from one to the other. Iterative and incremental development came early, automated testing and continuous integration came later.

  • http://Deborahpreuss.com Deborah Hartmann Preuss

    Re: Mike C’s note: My initial feeling upon discovering oo was that it was about «healthier boundaries» and that is what I see as helpful in Agile too.

    Perhaps that is why we keep trying to apply Agile further and further out into dysfunctional businesses. Agile is not the only way to get better boundaries/communication/accountability/collaboration. I guess «When all you’ve got is a hammer, everything looks like a nail» so we need to keep looking for useful tools to add to our toolkits, and using the right ones in the right places.

  • http://www.akeirou.com Bruno Borghi

    Waterfall is still alive and well. I don’t think that Agile will die before Waterfall. And Waterfall protects Agile from trivialization: Waterfall reminds us of the essence of Agile. OO is a technical choice, Agile is a management choice. Poor management is sufficiently widespread, so that Waterfall will not be dead in ten years. So, my bet : Agile will be still alive and well in ten years.

  • http://www.coregroup.no Niklas Bjørnerstedt

    Bruno,

    I am certain the core ideas in agile will be alive in ten years but I am not so sure «agile» will be alive. Object orientation became boring long before everyone had adopted it. Agile can become boring in the same way but it also runs the risk of a bad death were the term itself becomes negatively loaded.

  • Pingback: Management Improvement Carnival #125 » Curious Cat Management Improvement Blog()

  • Pingback: Core group | Agile Development()

  • Pingback: The Shu-Ha-Ri model of Lean Procrastination | Lean Procrastination()