InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Should the Customer Care about Agile?

Posted by Vikas Hazrati on Mar 13, 2008

Sections
Process & Practices,
Architecture & Design
Topics
Customers & Requirements ,
Agile ,
Delivering Quality
Tags
Debate ,
Retrospectives ,
Planning ,
Criticism
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.
  • This article is part of a featured topic series on Agile
What ever you do, if it works for customer then processes do not matter by puneet jain Posted
Everyone is on the same page... by Stefan Marev Posted
  1. Back to top

    What ever you do, if it works for customer then processes do not matter

    by puneet jain

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

    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

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.