Taking the Temp on Agile by Ivar Jacobson

A couple of weeks ago Kent Beck delivered the keynote at a conference in Gothenburg, Sweden.  He began by saying that, in the US, agile already starts to get old.  Programmers are tired of all these daily meetings where they have to be social.  They want to code – they don’t want to talk. This being said by the father of XP and the individual who is probably most associated with triggering the whole agile movement – a fantastic accomplishment that has my greatest respect.

We also have had many indications that, at least in the US, people are getting tired of talking about agile.  A CIO of a large company with whom we work won’t use the term “agile”.  A CTO from another very large company with thousands of developers where we have been rolling out practices, says he doesn’t care about approaches – agile, RUP or whatever - only the result count.  He has distanced himself off from agile since it creates religious zealots in his organization and this zealotry only gets in the way of achieving results.

This is inevitable - we have seen it before as ardor for the latest trend begins to cool. The real question is “should we throw out everything we have done to become agile?” And, for those people who have not yet started to become agile, should they skip to whatever is next? No, not at all! There are many good things in agile that will continue to be useful.

We work with many large companies around the world to scale agile from the small project to the large program to the enterprise.  We sometimes find resistance to agile in larger companies, partly because of the opinionated zealotry of some agile proponents doesn’t sound serious to experienced developers, managers and executives.  Statements like ”No architecture, no modeling, just code and refactor later” don’t sound credible to anyone who have seen problems with lack of architecture before.  And poorly explained concepts such as ”No requirements - the tests are your requirements” and “pair programming” don’t help matters.

Fortunately agile has grown up a bit - and the zealots have mostly been replaced by more reasonable proponents who know that there are many good things in agile approaches, but they need to be blended with other things to really be successful.

It is now quite silent about these individuals.  They start to become passé, if I should allow myself to be harsh.  They are not anymore the obvious speakers at large conferences, not even at agile conferences.  They are not engaged as consultants as much as before.  They sound a bit tired.

What about Scrum? Scrum is having serious problems around the world.  It is starting to suffer a backlash.  This is not really because of Scrum itself, but because of the tail of Scrum (all the people that want to profit on Scrum without real competence).  All hypes will sooner or later suffer from this problem.  And by making everyone a Scrum master who pays $2,000 and who sits in a class for two days with 50 other students, you really ask for trouble. Scrum is still popular but if you blow up a balloon without a break, it will sooner or later burst.

Nevertheless there are some good ideas in Scrum.

Instead, now the evolution of agile is lead by those of us with a strong anchor in successful delivery of many different kinds of projects and programs in many different organizations, large and small. We understand that “agile” is not just a patch that you paste onto what you already do. Instead, agile changes your attitude about everything you do, with a focus on achieving good business results.  Agile has different meaning to CXOs (good software, quickly at low cost) than it does for software developers (Scrum, TDD, continuous integration).

I would like to see an end to the cycle of boom and bust and see us learn from and preserve the many good practices that the agile movement has bought into focus and not throw them all away in our quest for the next big thing.

My advice is that you should take the good practices from agile and combine them with other good practices, as we did when creating the Essential Unified Process from the core concepts in RUP. Most important you should not throw away the things that are working in your quest for improvements.  Be smart!

  1. Gerald | May 12, 2009 at 5:18 am Reply


    Good Evening, Mr. Jacobson.I’m Gerald Velasquez, undergraduate studend of System Engineering at National University of Engineering. I want to contact with you for a Conference of System Engineering in Lima, Peru. It will be from 9 to 14, in November. You can reply this message to [email protected]. I’m pleasure to write to you.
    If there are mistakes, I’m sorry.

  2. Richard Karpinski | April 30, 2009 at 6:10 pm Reply


    Many good points are made here. I would add praise for the culture exemplified by Toyota and the notion of Lean. I first learned of the idea of confronting reality early and often from Tom Gilb. It’s a key feature of Agile and well worth retaining.

    I don’t much care what you call it, but I especially like lists of worthwhile books and authors. Gilb’s “Competitive Engineering” is chock full of great ideas to chose from, and the Poppendiecks both give simple and clear advice in everything I read of theirs, including interviews and mailing list discussions.

    The proof of the pudding is in the eating. Taste often and try accumulating knowledge, understandings, and skills. Using wikis can help. Honoring people can help. Celebrating successes can help. Encouraging sharing and discouraging personal attacks can help.

    Still true success always comes in kit form, you have to put it together yourself. It’s easier with good coaches. Some good coaches are called managers, others are called Scrum Masters. Some bad ones have the same titles. It works better if you choose good ones.

  3. Nguyen Phuc Hai | April 27, 2009 at 3:16 am Reply


    Thank you for your excellent post. I agree with you about the smart applying practices. For me ( and almost the people), we aim to the project result (balance among quality, delivery date, scope) and applying Agile practices help us to achieve the goal more easily. However, we do not fix with one process but combine the best from each and it is depended on our team maturity, our customer. They are some example:

    – With the customer who is not familiar with Agile and they have no much time to interact us daily basic, we use use-case to describe the requirements and request they review the whole package at one time and send the feedback to us.

    – If we have many un-experienced employee, we tend to use checklist to check their works, peer review with them regularly. However, we limit to hold the daily group reviews because some of them are afraid to show their undone works to other people (it belongs to the culture and the manager must fix it but we need time).

    We, Agile practioners, know that Agile process is not the silver-bullet but we should say ‘No process is the silver-bullet’ also ‘set of practices are not the same in different projects.’

  4. Ivar Jacobson | April 21, 2009 at 4:03 am Reply


    Sorry, but I must clarify my English to avoid misunderstandings:

    Every methodology, process, approach or whatever we call it, is a soup of ideas. We should not brand soups of ideas such as Unified Process, CMMI, Agile, whatever. If we do that and if such a soup is successful it will grow to incorparate all good ideas out there and eventually it will die under its own weight. Using agile as an adjective is of course fine.

    Practices are not soups, they are the ingredients of soups. Here, I won’t go into the detailed semantics of practices. Practices include logically related things to do and things to produce. Thus they are understandable.

    For instance iterative development from Unified Process is a practice. Another (competing) practice is Scrum (as originally described). (In fairness Scrum also includes a number of agile work patterns). You can use any of these two practices in combination with other practices such as use cases/user stories, components, tdd, continuous integration. However, you don’t need to brand and advocate each such individual combination (soup).

    Essential Unified Process is just a package of practices. The contained individual practices are what is interesting, not the whole package. I don’t push Unified Process (or RUP for that matter) any more. However, I think it contains a set of useful and proven practices. Take what you like, but don’t throw out all what you already have. Replace what is broken or what doesn’t work so well anymore with a new practice addressing you specific painpoint.

    Daniel, it is hard to argue with you because I don’t think we are far apart. Still, thanks for your continued interest.

  5. Ivar Jacobson | April 20, 2009 at 10:38 pm Reply



    Dropping everything you have learnt from agile is exactly what people shouldn’t do because a new fashion. However, something they should drop because it didn’t really pay off the way that was expected.

    It is not me that won’t like to hear the term agile anymore. It is the people who have suffered from bad implementations of agile.

    Moreover, the meaning of agile has been sliding over the last five years. Now agile basically stands for “everything good in software development”, so today we obviously all support agile.

    I truly don’t believe we should use brands like Unified Process (my own baby), CMMI, Agile as identifiers for all encompassing methodologies or processes. I believe every such brand is just a soup of ideas…or say practices. Instead we should identify the good practices out there – coming from any camp, and people could use the ones the think makes the most sense as an addition to what people already have. I support getting rid of fashions and fads.

    Essential Unified Process is not a brand like RUP that I push. It is just a set of practices (most coming from the Unified Process) that people can use if they want. They don’t need to use all of the practices. They can mix and match with practices coming from other sources. That is smart!

  6. Daniel Wildt | April 20, 2009 at 9:20 pm Reply


    Hello Ivar,

    First, why would you drop everything you may have done so far to become Agile?

    Agile is based on a different attitude, not different artifacts. If you do the opposite, focusing on artifacts, you will have problems, big problems. The artifacts will start to change, maybe, because team will discuss about them and think about how those artifacts can be more useful to a project. They will improve based on lessons learned and new ideas.

    So it is based on a culture change, where you want to focus on prevention (not defects), you want to focus on quality, you want to deliver more ($$$) to your customer (+ satisfaction), and you want to continuously improve. This is the attitude.

    Now, when you go to practices, you can try FDD, Scrum + something (since Scrum does not focus on engineering practices), Crystal, MSF for Agile, eXtreme Programming, etc.

    When you say “I would like to see an end to the cycle of boom”, that you don’t want to hear the word Agile anymore. Agile is not something from last week, I mean, this movement started more than 10 years ago! And if you look at the ideas and practices, they are older, much older!

    So, if you want, you could drop the use of “Agile”. But “Agile” can mean a lot of things about this movement, and about this “attitude”. It’s like an identity.

    You use a lot the word Agile in your website and in your blog. If it does not work, why bother?

    I mean, if Agile is not good, you need a new brand for your team essentials package. And I don’t think that’s the case.

    But, if I start using Unified Process with all that attitude I mentioned before, would that work? According to your EssUP, yes.