Agile, Schmagile...

Here's an email I got from the Yahoo Business Analysis group I belong to:

From: "ginitram" <ginitram@yahoo.fr>
Reply-To: agileanalysis@yahoogroups.com
To: agileanalysis@yahoogroups.com
Subject: [agileanalysis] Article on Agile Adoption at British Telecom
Date: Wed, 26 Jul 2006 10:53:37 -0000
The Methods & Tools newsletter has just released in its archivesection the article "Agile Delivery at British Telecom". This articledescribes the approach used by British Telecom to move towards anAgile development process
http://www.methodsandtools.com/archive/archive.php?id=43

First, I recommend joining the group, it has a medium amount of intersting activity.

OK, here was my reply:

Hasn't this been published somewhere before? It looks familiar.

First, it's time that Agile proponents know that everyone gets it, smaller is better than bigger, delivery something on a regular basis is better than a big bang at the end of the project,... enough already. As I have said elsewhere, it's not that the waterfall is too long, it's that the river is too wide.

Ok, here are some snippets with my comments in brackets:

"Capturing requirements certainly isn’t a bad thing (well, duh). On typical large programmes however,
- Individual business stakeholders are anxious to incorporate all of their known requirements into the first / next release (sure, so the business must define the $ benefit of their pet requirements, while IT estimates the $ cost, and then present results in a cost-benefit analysis to the Sponsor, the one who is paying for the system, and it will be clear waht is in and out of the first/next release)
- "Gold users" generate hundreds, if not thousands of detailed requirements that often bear little relationship to the business problems that needs to be addressed (same answer as above, plus if you literally get hundreds of requirements, declarative statements I presume, then you need to partition the project)
- Most if not all requirements are given a high priority (so rank them by highest return on investment)
- The requirements themselves, at best, represent today’s view, which will certainly have changed by the time the requirements are actually implemented (good analysis include stability analysis, documenting potential business changes and how the system will accomodate change. A systems' ability to incorporate change after delivery is also a requirement for all projects).

Given the sheer number of requirements, the design community finds itself spending most if its time trying to figure out what they mean. Meanwhile,
-The requirements analysts move on to other projects, taking with them important tacit knowledge (this reflects poor documenting standards, all knowledge gathered by the Analyst must be documented.)
- Some stakeholders become concerned that their requirements are not being adequately addressed, and therefore refuse to sign off the designs (what raises the stakeholders concerns? In any case, requirements are to be traced through design and into testing, so stakeholders really know what requirement is being supported where...)
- Other stakeholders unearth more requirements or raise change requests, diverting scarce design expertise onto impact analyses (this is scope management, the first evaluation of a change request is to determine if it is in scope or not. If it is in-scope, can it be added to the release without material impact on cost or delivery date? If not, this should go on a change request list for re-consideration in the next release.)

That's all I have to say right now...dww