This is NOT another Agile Methodology posting.  I make no claims to any special agile expertise, nor am I interested in methodology wars.  I just want to say that fads are fads, and never substitute for analysis.  I completely understand the attraction to agile.  It is an excellent summary of what can work for some teams, on some projects.

It is my observation that all the named methodologies I have run into can map onto BABOK concepts, and the BABOK is a superset of them.   

Here is the manifesto itself for context (derived from the Agile organization’s own web site at www.agilemanifesto.org ):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

———————————————————————————

And here is one analysis, based on general knowledge, personal experience and BABOK concepts:

• BA Fundamentals (and hence the essential skills to perform Requirements Communication) have to be present before tools matter.  Tools can only support competent, effective behavior, not create it.  In a sense, all successful projects are “agile” – it is my observation that all successful projects are full of brilliant individuals who interact fast and freely.  This single factor seems to compensate for everything else – counterexamples are welcome, I don’t have any.
• Software over documentation is already the most common approach in software development, so it is hard to understand why it matters to “Agile”.  Since 65% “failure” rates are already being achieved in software development, it must be items 1, 3 and 4 that really matter, if Agile is effective at all.
• Substitute “Iteration of Requirements with Stakeholders” for “Customer Collaboration”, and substitute “waterfall requirements” for “contract”.   Contracts, at their worst, are an attempt to “lock in requirements” before they are understood, leading to excess change order profits for the contractor (when changes are allowed), or failed stakeholder acceptance (when they are not).  Waterfall requirements are best saved for “one shot” efforts like the moon program.
• Over planning, and reluctance to adjust plans as requirements are “learned”, is clearly a cause of certain project failures – it is mostly a failure of intelligence (see item 1).  What is missing from this concept is the idea of Enterprise Analysis (especially risk analysis, stakeholder analysis, and cost benefit analysis) and the Requirements Planning that must follow from these.  Another way to put this is – IF the project is simple and low risk enough, Agile may be a fit (see BOK tables 3.0 and 4.0 in the Enterprise Analysis section, and see if you can spot which projects might use Agile.

SO, from analysis to opinion (if you have your own opinion, send it in, we will tally responses and report on same):

IN MY OPINION:  Agile process fits certain kinds of projects, but hardly most.  Here is my list – what is yours?

“Small potatoes” – low risk, decent to high payback systems that only have to satisfy a small number of users with homogeneous interests, have low visibility, or represent proven, successful increments to already successful systems (yes, maintenance and enhancement).

 “Feasibility” or “Proof of Concept” trials, which could clear the way for more investment in a larger project?

 “Research” projects, where almost all is unknown, budgets are huge, and the paybacks considered indispensable, if they can be achieved at all.  These are really rare; one example was the “skunkworks” team that developed the unique (and ultimately unsustainable) Blackbird spy plane.

“Invention” projects for systems that can succeed “virally” and evolve, that represent completely new behaviors ,or huge boosters to behaviors, that people crave, regardless of how poorly delivered (e.g., cell phone service, social networking, 45rpm records).

WHAT AGILE PROBABLY DOESN”T DO is Enterprise level projects, projects that must organize the efforts of many people.  I am sorry to say that I hold this opinion in spite of the fact that I helped lead just such a success – an Investigation Management system for over 1400 government users.  We succeeded by using all four principles in the Agile Manifesto, AND this only worked because we were an A-1, Agile Item 1 team.

My advice – get the smartest team you can that actually CARES about their work, and put them under tremendous pressure – they will cut to the bone, and will NOT skip any critical steps, and you can call it Agile if you want, but I call it B.A.gile!

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!