When an organization wants more than the Agile process requires, it is easy to show the additional cost each iteration, and as the team builds credibility the customer/stakeholder(s) might be less inclined to want to spend money each iteration producing documentation.

So have some courage, tell your stakeholders that they can have it (whatever "it" is) if they want it and then make sure you follow up with giving them a good picture of the cost and value they get from "it". It’s their money - let them blow it if they want to. Let them slow the velocity by asking for non-code related items. All you can do is make it visible and help them down the path of figuring it out.

The sooner you start delivering some working code, the sooner you’ll have the credibility to address their real process issues. "It" will become less important the more iterations you deliver working tested code.

The hard part is getting code started, right? Maybe you can disguise the first few iterations as "prototyping" and use TDD as the process for your prototyping? :-)

 >Reciprocity is not guaranteed on airlines (or toll bridges - it
 >has always amused me that the toll on the Severn Bridge between
 >England and Wales is GBP 4.20 for a car to enter Wales but there
 >is no toll the other way, ie entering England). (Maybe it shows
 >how the two countries value themselves?)

All of the bridges in the San Francisco Bay area only charge toll in one direction. Some genius realized that, on the average, just about as many cars went each way for the obvious reason that most trips across the bridges are round trips. So they doubled the toll and took down the toll booths going one way (except for the Golden Gate Bridge where the toll booths remain, unattended). There has been considerable saving in toll collection costs and the toll booth traffic jams in one direction are gone. Is it possible the Severn Bridge does similarly?

Phlip:

 During the planning game, you review last week's
 finished stories, and they inspire you to write some
 new cards, to edit some cards, and to toss some cards.
 Then you (the Onsite Customer) re-sort all the cards,
 and draw off the top batch for the next week.

 But another input into this system that affects the
 planning game - the competition.

 The USA occupied Iraq using an effective new battle
 technique. In traditional advances, you send a
 diversionary force against one of your enemies flanks,
 draw them that way, then send your main force against
 their other flank.

 Modern soldiers, with cell-phones and such, follow a
 more agile approach. You simply send two forks of your
 forces, probing towards both flanks. You use sensitive
 algorithms to detect the defending commander's
 decision which flank to defend. If you can rapidly
 turn one advance into the diversion, and the other
 into the main attack, you will soon collapse the
 opposition's ability to effectively make decisions.

 Agile onsite customers can play this card too. If you
 detect your competition's marching orders, in
 real-time (using either sensitive algorithms,
 good-old-fashioned industrial espionage, or just
 reading their self-congratulatory Web site), you can
 then request iteration features which provide the
 minimum amount of code needed to start your project
 towards blocking the competition's advance. This
 technique will, again, collapse the competition's
 ability to make decisions.

 Or convince them to hire an XP coach or three. So
 either way it's a win-win-win for us! ;-)

Steven’s reply: :-)

 Or you could follow the agile strategy that Microsoft
 pioneered - announcing products with your competitions'
 features before you even start implementing them.

About the $200M Oracle-Ford Desaster: the management did not give them enough power to go fully agile

Chet Hendrickson:

 It was a very frustrating situation.  The team asked Don and me
 to help with preventing the Oracle consutants from making changes
 directly to the production system.  This was about $150 million into the project.

 We tried to sell them on a more agile approach (as you might imagine), but by
 this time they were pretty far gone.

 It was unfortunante that we were not operating at a level in the organization
 that would have allowed us to get the plug pulled sooner.

 chet

Georg Tuparev has a nice case story, too: speak out if you are put on a death march.

 Few years ago I was called to lead a huge team stuck in one and half
 year design phase. The team was supposed to build a control software
 for a network of telecom satellites. Cannot disclosed names and
 resources, but one could imagine ...

 Three days in the project I had a phone conference with the CxO's of
 both companies involved. Told them that the way it is going no
 satellite will ever fly and that I know a better way. After getting
 green line, the design document was burned with a small celebration at
 a BBQ, and 85% of the initial team members were sent to an indefinitely
 long vacation. With the rest (15%) of the team we had the first
 functioning version 2 months ahead of the schedule and 50% lower then
 expected expenses.

 So the lessons:
 - it is never late to change direction of a project in order to save it.
 - I do not agree with Kent that this is a sad story. If you are a good
 programmer put on a death march project you should speak out! If no one
 listens - walk away. There is just one very precious life in front of
 us - do not waste it! And if these folks wasted 2 years of their lives,
 well, it is their business ... but they should not expect my
 sympathies.

 BTW, Philip is right - the project I was telling about had a 9 months x
 40 people "Big Requirements Up Front"!!! Then the design started...

 Just my 0.02

 Georg Tuparev

 I assume this popped up on everyone else's RSS aggregator as well, but...
  From Darrell Norton's blog [1] and Artima developer forum [2]: the
  current issue of CIO magazine is all about agility:
  http://www.cio.com/archive/081504/index.html

How can software development productivity be increased? Through the same approaches used in operations: a focus on customer value, a short, effective supply chain, healthy discipline, and innovation. Mary will discuss techniques that businesses have used for decades to jump-start an increase productivity, and show how they can be used to increase software development productivity. pdf

example graphs

 Will this company be successful and become another Google?
 First, graphical data mining has never been a big hit. And second,
 there are lots of competitors in the business intelligence sector,
 including at least Business Objects, Cognos, Hyperion and MicroStrategy.
 So make your bets and wait for the next multibillion-dollar IPO.

• Skolelinux is a network architecture tailored for use in schools.
• Skolelinux is designed to be easy and cheap to maintain.
• Skolelinux gives the students their own usernames, home directories and services.
• Skolelinux includes OpenOffice.org