InfoQ

News

Should the Customer Care about Agile?

Posted by Vikas Hazrati on Mar 13, 2008 12:49 PM

Community
Agile
Topics
Customers & Requirements ,
Delivering Quality
Tags
Debate ,
Criticism ,
Retrospectives ,
Planning
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.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

2 comments

Reply

What ever you do, if it works for customer then processes do not matter by puneet jain Posted Mar 17, 2008 11:20 PM
Everyone is on the same page... by Stefan Marev Posted Mar 18, 2008 8:32 AM
  1. I agree with you on that the development team should not force agile processes on to the customers, I have observed so many times in my current company that the product owners and requirements gathering team are not interested in adopting agile processes because they have already doing great job in their work areas ( according to them ), so in these cases, i think its good for everyone not to force anyone to adopt agile practices.

    Thanks
    Puneet

  2. Back to top

    Everyone is on the same page...

    Mar 18, 2008 8:32 AM by Stefan Marev

    "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."

    Agile supports all of these. The customers shouldn't care if it is Agile or not as long as they contribute and are part of it. The team should do their best to engage them as little as possible i.e. they need to do their bit to help the customers make better informed decisions

Exclusive Content

Ruby.rewrite(Ruby)

In this RubyFringe talk, Reginald Braithwaite writes Ruby code to read, write, and rewrite Ruby. Demos include extending Ruby with conditional expressions, call-by-name and more.

Book Except and Interview : Aptana RadRails, An IDE for Rails Development

Aptana RadRails: An IDE for Rails Development by Javier Ramírez discusses the latest Aptana RadRails IDE, a development environment for creating Ruby on Rails applications.

Fast Bytecodes for Funny Languages

Cliff Click discusses how to optimize generated bytecode for running on the JVM. Click analyzes and reports on several JVM languages and shows several places where they could increase performance.

Scott Ambler On Agile’s Present and Future

Scott Ambler, Practice Lead for Agile Development at IBM, speaks on the current status of the Agile community and practices having a look at the perspective of the Agile’s future.

Manager's Introduction to Test-Driven Development

Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD).

Structured Event Streaming with Smooks

Smooks is best known for its transformation capabilities, but in this article Tom Fennelly describes how you can also use it for structured event streaming.

How to Work With Business Leaders to Manage Architectural Change

Successful architectures evolve over time to meet changing business requirements. Luke Hohmann presents how to collaborate with key members of your business to manage architectural changes.

Colors and the UI

In this article, Dr. Tobias Komischke explains how colors used in a GUI can influence our interaction with a computer and offers advice on using the appropriate colors for the interface.