It's not a secret anymore!*
The moose likes Agile and Other Processes and the fly likes Educating Business Users Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Educating Business Users" Watch "Educating Business Users" New topic
Author

Educating Business Users

Eric Hindle
Greenhorn

Joined: Feb 13, 2004
Posts: 5
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
Greenhorn

Joined: Jan 24, 2001
Posts: 7
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.


jvoris@axs2000.net<br />iSeries AS400 Java
Shane Warden
author
Greenhorn

Joined: Oct 03, 2007
Posts: 16
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?


Author of <a href="http://www.amazon.com/gp/product/0596527675?tag=jranch-20" target="_blank" rel="nofollow"><i>The Art of Agile Development</i></a>
Eric Hindle
Greenhorn

Joined: Feb 13, 2004
Posts: 5
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Shane Warden
author
Greenhorn

Joined: Oct 03, 2007
Posts: 16
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
Greenhorn

Joined: Feb 13, 2004
Posts: 5
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Educating Business Users
 
Similar Threads
Productivity
Tell Me about Yourself
How to prepare for interview?
15 Java Developers in NW
Project Folder hierarchy And Architecture