Bruf Predicts Failure

The following text, between the pairs of double horizontal lines, is reposted without permission from a thread on the XpMailingList (except for PhlIp's contribution, which he has given permission for). Please append comments after the reposted thread, to prevent distortion of the original text.

Now this is a a good laugh!

http://www.theregister.co.uk/2004/08/18/ford_ditches_oracle/

Should we help the big boys?

-- GeorgTuparev

It doesn't sound funny to me. It sounds like a sad waste of time and resources. I'm sure the people involved were doing their best as they saw it. ExtremeProgramming might have helped in this situation, applied by people who understand the problems involved. -- KentBeck

It was a very frustrating situation. The team asked Don and me to help with preventing the Oracle consultants 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 unfortunate that we were not operating at a level in the organization that would have allowed us to get the plug pulled sooner. -- ChetHendrickson

Before they started the project, did they indulge in BigRequirementsUpFront? Sadly, that's a major indicator for failure (per recent threads by UncleBob). However, the number 1 thing that appeases the GoldOwners is "due diligence", and TheAlmightyThud of paper (which they can't read) indicating what a project will do... -- PhlIp

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 too 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, PhlIp is right - the project I was telling about had a 9 months x 40 people "BigRequirementsUpFront"!!! Then the design started...

Just my $0.02

-- GeorgTuparev

It seems to me that big requirements up front is not an issue. BRUF still seems to me to be a necessity sometimes. Even XP has its own version of BRUF with the release meeting.

BRUF allow for estimates to be made, such as the cost of the project. This is likely to be the determining factor on if a project should be done. A better science in BRUF and estimates would serve any company in allowing them to make this decision with more accuracy.

Without BRUF I'm not sure how yesterday's weather tells you when you'll be done because you don't know how big the total project is or what's left to accomplish.

Now do the requirements change in an XP project? Sure. As do the tests, and the design, and often everything else. That's why people choose agilty. It's an answer to the problem of not being perfect and getting everything right the very first time. We understand that the requirements can and will change.

But I don't see knowing the scope of the project to a reasonable level of depth as being a bad thing, especially when it helps us decide if the project should even be approved. The "last responsible moment" for making that decision seems early on and requirements seems to be one of the things needed in order to make that decision accurately.

-- KenBoucher

It seems to me that big requirements up front is not an issue. BRUF still seems to me to be a necessity sometimes. Even XP has its own version of BRUF with the release meeting.

I wouldn't call that Big. Larman, in his AgileAndIterativeManagement? book, shows the research. There is a lot of it, peer reviewed, covering thousands upon thousands of projects. The results are that up front requirements lead to an overwhelming amount of project failure. The numbers are terrifying. (Sorry for all the superlatives but I think they are warranted.)

The research cited is mostly the ChaosReport? (See summary: http://net.educause.edu/ir/library/pdf/NCP08083B.pdf ).

BRUF allow for estimates to be made, such as the cost of the project.

Consider the research that shows that well over half the required features on a project are never used. Should the estimates of cost really have been made on those requirements? Or consider the reseach that showed that 46% of project that met their requirements "so egregiously did not meet the real needs of the customer that they had were never used." What good are estimates of requirements that won't ever be used?

The point that Larman makes is hard to refute. It's the same point that FredBrooks made in his report to the US Department of Defense about 2167A. To-whit: "The requirements is the most difficult and crucial part of the software building process, and one that requires iteration between the designers and users." Up front requirements aren't to be trusted, and are a strong predictor of project failure.

-- UncleBob