Everyone wants to be Agile by Ivar Jacobson

During a recent trip to China and Australia I observed that everyone wants to be agile.   It may be that Northern Europe and the USA are a bit ahead but the trend is clear all over the world.  In a round table meeting with CIO’s, I usually ask what people are particularly interested in right now.  Five years ago a common answer was we are trying to adopt the Unified Process.  Now, the same question returns the answer we are trying to move to agile.  Thus you would assume that people know what agile is.     


The last month I gave four public presentations with around 100-200 people each.  I met with about twelve companies.  At every occasion, I asked what really is new with agile.  Here are typical unfiltered answers: “rapid iterations”, “working software”, “coping with change”, “communication”, “flexible”, “adaptable”, “eliminate waste”, “accepting changes”, “small iterations”, “feature-driven”, “continued integrations”, “test driven development”, “no documentation”, “people before process”, “adapt to change”, “the name”, “the team sets their own priority”, “early stakeholder involvement”.


An absolute majority, around 60%, said that agile is about iterations (or sprints to use the Scrum terminology).  It is a bit disappointing that people don’t know that iterative development was introduced more than 25 years ago by Barry Boehm.  He called it spiral development.

It is even more disappointing to hear that people think that RUP is not iterative, but based on the waterfall model.  In fact, if you wanted to use RUP for waterfall development you would have to make a real effort to restructure RUP.  We clearly said that everyone should move to iterations for the same reasons that people now like about agile: rapid, working software, change, flexible, risks, etc.


Given that around 60% think that agile is about iterations, and RUP was designed to support iterations, is RUP agile?  My answer is that RUP can be applied in an agile way but RUP itself is not agile.  Thus there need to be something more. 


20% of the answers were about technical ideas such as feature-driven, test-driven, user stories, etc.  However, none of these ideas would have created a revolution on their own.


10% of the answers were about light process – light to understand, light to use and light on documentation.  Now we start to come to the core of agile.  I truly believe that in the past we have been too ambitious in describing process, in adopting too much process and in documentation.  The reality is that even if people write a lot, very few people will ever read it.  Thus the trend towards light will sustain.  However, it is easy to be light.  The trick is to be as light as possible but not lighter.  I believe you will find our work on EssUP and EssWork new and fresh.


The last 10% were about how to work together daily, weekly, monthly, etc.  It is about communication, people and teams, about how to organize teams, how to take decisions, how to protect the team from the outside.  This is what we call social engineering.  Agile has put the finger on the fact that we need highly motivated and competent people to be successful with software development.  No process has ever developed software.  It has always been done by people.  We have of course always known this, but we have not pushed it as much.  The focus on people is really what makes agile unique, and this is why agile originally broke through.


Now, it doesn’t really matter what people think agile is.  Agile has become more of a philosophy.  It appears that everything good is now agile.  Thus it is not really easy to tell what agile is.  However, one thing we know.  Everyone will subscribe to being agile (as they should) so one day agile will go without saying. 


Let me though make a cautious reservation.  There is an obvious danger that as it continues, agile will be discredited because the concept is sometimes used as an excuse for doing shoddy work, for having no requirements, for developing whatever the developers feel like doing.  This is not in the spirit of "true agility" but if it continues it will give agility a bad name.


Whatever happens we will one day get a new fashion.  I can’t tell you what it will be but be sure of one thing: it will be smart, very smart.

  1. barry mcmanus | September 18, 2013 at 4:19 am Reply


    by the way that last line was not meant to be disengenious – I meant to say that I never thought I would ever have the courage and the execuse to write to a person who I only read about in University or in researh for companies…. it has made my day.

    Thank you.

  2. barry mcmanus | September 18, 2013 at 4:16 am Reply


    Hi Ivar,

    I’ve been reading some of your comments regarding Agile, above. Although we are now in 2013, several organisations I have met describe themselves as agilistas – and have appeared to grappled this new fashion to the detriment of any previous good practices. What I want to say is that I have seen at first hand this year, your reservation coming to fruition as I am meeting people in the software industry complaining about agile delivering shoddy work.

    I have also read some of your comments regarding the need for having a kernel of practices to produce good software – my own thoughts on this mirror yours. My company describe this as a Project Appropriate Quality Approach – utilising common practices (such as incremental releases, continuous integration) for a software project and bolting on any additional practice that limits the risk of project failure (and poor quality).

    My backgound originated in mainframe development, I moved into telecoms where I cut my “new” teeth in Ericsson’s AXE environment for a year, before moving into a Spiralled development environment and then into QA & testing. I enjoyed your description of the software world being akin to the fashion world, which I can relate to.

    As for the last 10% description inyour agile response, above, I always believed that the biggest risk to software projects are “people” – how they organise themsleves, behaviours, approaches – but to my mind it boild down to communication and a lack of effective communication at that.

    I’ve found your thoughts very interesting and I must say, I’d never thought I’d be writing a message to the man who was responsible for RUP.