Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Should the Customer Care about Agile?

Should the Customer Care about Agile?

In an interesting discussion on the Extreme Programming group, Gary Brown brings up a thought provoking question: how should a team react if suddenly after years of educating and motivating the customer on Agile it suddenly becomes obvious that the customer does not care about Agile development?

Though Agile software development places a lot of emphasis on customer interaction and feedback, members responded on the thread with interesting responses biased towards the customer. Most of the members seemed to agree that the customer is the best judge of the business value that he wants from the software. He may or may not be interested in the methodology followed to achieve that business value. Ron Jeffries mentions
Our Customers shouldn't care about Agile development. Our Customers have a business responsibility that includes but is not limited to development of software. They should be interested in ...

   -- getting software that the users need;
   -- software which will work reliably;
   -- software which comes into being as quickly as possible;
   -- getting software should take little effort on their part;
   -- they could work in ways that they find easy and natural.
Ron mentions that as software developers the teams should be interested in getting the software right and making sure that the customer is pleased. He proposes that if the team has already spent enough time educating the customer about Agile and still the customer is not interested then the team should just stop advocating Agile. He also suggests that this in no way means that the team should start panicking, they should identify what is working well and what is not. Later address the areas of improvement in small batches.

Zhon Johansen recommended showing the customer benefits of Agile in a subtle way, so that he feels that Agile is not being forced on him. He suggests an interesting example for things like prioritization of stories, which is of utmost importance. If the customer is not interested in prioritizing then the team should hand them a list of prioritizations based on their judgment and ask the customer if he is fine with that. This is much better than no prioritization.

J. B. Rainsberger seems to suggest a politically correct way, he mentions
I would invite them to a retrospective (and not call it "retrospective" if that might scare them off), proposing the theme "how we can better work together". My goal would be to find the top 3 things they expect from us and to tell them the top 3 things we expect from them. I'd propose we do those things for about six months and see how it helps the relationship.
Given the history and all the software projects that are being executed it is not difficult to imagine the inability of the customer to be fully involved with the team, however as the discussion suggested situations could be worked out without giving them an explicit flavor of Agile. The group seemed to agree that the customer knows best and the development team should not try to force Agile on the customer. The customer should be able to work in his preferred way and the development team should try to align itself in a manner which makes the customer succeed.

Rate this Article