Educating Business Users

[Eric Hindle]

We are fairly new to Agile and our business users think all their Christmases have come at once.
They can (and do) ask for everything and anything and never seem to be refused however absurd the direction in which they drive the project.
They still want to set infeasibly short, rigid deadlines driven by events outside the business without any regard for the practical demands of development and testing.
Previously we would have had a document that the users had agreed to that meant we could limit the scope of the project and therefore have a reasonable expectation of meeting the deadlines.
How can we best educate the business that giving them almost day to day control over the development goes hand in hand with an acceptance that they pay for it in other ways?

[John Voris]

If a "sign-off" document is the only thing that your users understand for "limiting the scope" of a Sprint, then by all means tape it next to the board next to the user stories. A main tenet of Agile is to spend energy on delivering "Something" instead of "Negotiating". Having it up on the board during the morning Standup can help focus energy. They may see it as "Stifling", but you have to push the focusin gaspect of such a document.

Software development is hard. And remind them that even as before, straying from the promised deliverables affects the team and affects them too.

[Shane Warden]

Originally posted by Eric Hindle:
We are fairly new to Agile and our business users think all their Christmases have come at once.
They can (and do) ask for everything and anything and never seem to be refused however absurd the direction in which they drive the project.
They still want to set infeasibly short, rigid deadlines driven by events outside the business without any regard for the practical demands of development and testing.

How can we best educate the business that giving them almost day to day control over the development goes hand in hand with an acceptance that they pay for it in other ways?

Hi Eric,

Are you using XP's Planning Game or something similar to manage and the amount and priority of work you will do in each iteration?

[Eric Hindle]

We don't use the Planning Game as such (we're not really embracing XP entirely), we are creating stories, producing running software in short iterations, but never quite achieving a release because the users often want to change the requirements at the end of each iteration.

The problem is that they see it as an opportunity to add on every bell and whistle they can think of.

[Ilja Preuss]

Scrums approach to this is simple and elegant at the same time:

The product owner (= your customer) provides a list of features, in order of priority. That is, the top feature will be implemented first, the next second and so on.

Then he sets a deadline, and the developers determine how much can be done until that deadline. They draw a line on the list - everything above that line will be done for the deadline, everything below won't.

Now, when later the product owner changes his mind - for example when he gets a new idea that he wants to be implemented - he can add the new idea to the list. Of course the developers can't do more just because there is a new idea, so they have to move the line so that something else - some of the least important features that were just above the line - now are below the line, and therefore won't be done.

Does that make sense?

[Shane Warden]

I agree with Ilja. It's completely okay for your customer to change his or her mind, provided that:

* you maintain a consistent release schedule (Jim and I recommend an iteration length of one week)

* you implement stories in terms of customer priority

To my mind, it sounds like your current difficulty is delivering a new release every iteration. With a week-long iteration and some discipline, you can probably get away by asking your customer to add new feature requests as stories and set the priority of stories for the next iteration.

I realize that a Scrum tends to be a month in length, but I wonder what would happen if you handed your customer a fresh CD every Wednesday morning with the freshest build on it.

[Eric Hindle]

I thought that you might be interested what happened to this project. Well, as was obvious to me but apparently no-one else, the project went completely out of control. The company ran out of patience and money before anything was delivered. They abandoned the development two weeks ago at a cost of approx. 26 million GBP. (see Telegraph newspaper article)

[Ilja Preuss]

Originally posted by Eric Hindle:
I thought that you might be interested what happened to this project. Well, as was obvious to me but apparently no-one else, the project went completely out of control. The company ran out of patience and money before anything was delivered. They abandoned the development two weeks ago at a cost of approx. 26 million GBP. (see Telegraph newspaper article)

That can only mean that the important people didn't understand what Agile Software Development is about at all. Otherwise they should have known that the project is in serious trouble when it didn't deliver the most important functionality after four weeks.

Did you have any training on Agile development? Who said that you were doing Agile?

[Scott Ambler]

Talking about techniques, tools, ... often will lose the game for you. You need to be able to talk in business terms to them, the explain the real benefits of doing agile.

What are they concerned about? Quality? Spending the money wisely? Time to market? Without knowing what the really want, how they define project success you're merely shooting in the dark.

They might be concerned about issues that developers generally aren't interested in, such as governance (which is good news because it is easier to govern agile projects) or documentation.

You might also need to make it explicit to them that traditional approaches aren't as effective as people hope. For example, writing a big requirements document up front isn't such a good idea. They inherently know this, but might not know that they have better options.

- Scott