Is the Agile Manifesto Appropriate for My Domain?

A post by Jason Yip prompted a thought.

Is the Agile Manifesto Appropriate in my domain. Or for that matter, in what domains is the Agile Manifesto appropriate?

The continued issues of establishing a context and a domain never seems to be resolved when it comes to agile techniques. The first assumption of agile is that agile will work any where, any time, any place. It's just a matter of "becoming agile," or "listening to the master."
    The question of appropriateness still needs to be answered.

1. Individual and interactions over processes and tools - in our Earned Value based program management world with a heavy software development paradigm, the processes and tools are defined in the business process. Earned Value ANSI-748B and DID 81650 define exactly what processes and limit what tools can be used (only those that are DCMA certified).
2. Working Software over comprehensive documentation - the documentation is a contractual deliverable along with the working software. Both are needed. Neither can be deliverable without the other.
3. Customer collaboration over contract  negotiation - contract negotiation IS customer collaboration. The processes of collaboration are defined in the contract.
4. Responding to Change over Following the Plan - the Plan (the Integrated Master Plan - IMP) is "on contract." But the Plan is a Strategy for successful delivery of the program. The Plan has a chnage control process is the strategy is not working.

Replace OVER with AND
    In the domain i work in if you replace the work OVER with AND, you get a winning strategy of agilely developing software for mission critical systems. These systems range from ERP to Manned Space Flight avionics and ground systems. Then you can value both statements in the context of their importance and impact.

1. If the processes follow EAI-748 Earned Value, then no individual is going to make changes. The Defense Contract Management Agency simply does not allow it. If the Source Code Control system is defined by NASA for the embedded component, no one is going to change it. If SAP defines how the interface verification process works to get "certified," we're not going to improve it to our liking.
2. Working Software is where the business value can be measured. Comprehensive documentation is where the sustaining of the business value is anchored. In the domain of integrating components into systems and integrating system into systems-of-systems, both are mandatory. One without the other is not sustainable.
3. This is a touchy issue in many enterprise and government domains. Customers and suppliers must speak clearly and concisely all the time. But must do so within the protocols of the contract.
4. Managing "in the presence of change," is the key to success. This is one of the biggest red herrings of agile - the notion that a "plan is unchangeable." No rational project manager on the planet would support the notion that the plan can not nor should not be changed. Discovering what reasons are needed for change - that's the challenge.

Comments

[Glen B. Alleman]

Anthony,
I stated "in my domain," not in all domains.
The question was "is the agile manifesto applicable in all domains of sofwtare development?"
I'd say no, as defined above.
The notion that "unnecessary documentation" is an accepted project management nethod is wrong. Doing unnecessary things is simply bad project management - having little or nothing to do with agile.
In the end "good project management practices" are agile.

[Anthony Williams]

Glen,

It appears that your understanding of the Agile Manifesto differs from mine. By suggesting that the word "over" can be replaced with "and", you are implying that, for example, the Agile Manifesto says there is no value in documentation, and that all the value is in the software. This is incorrect, and indeed the manifesto says "whilst there is value on the things on the right ..." implying that "comprehensive documentation" and "processes and tools", do have value.

Any sensible agile practitioner will tell that of course they provide whatever documentation is required by the contract, use any tools required by the contract, and follow any processes required by the contract.

However, if you focus on "working software over comprehensive documentation", then you will avoid documentation *where it is unnecessary*. This avoids a trap that many projects fall into of drowning in excessive documentation. Obviously anything that is required contractually or legally will be produced. It is common practice to schedule production of such documentation as stories along with the writing of software.

Likewise, the purpose of focusing on "customer collaboration over contract negotiation", is to try and avoid creating an adversarial contract full of petty details and penalty clauses, and instead create an environment where everyone works together to produce the final system. Of course there will be a contract, and it will therefore specify the means of collaboration.

With regards to "responding to change over following the plan", it is clear that the project managers in your industry are indeed sensible, and acknowledge that things change. This is not necessarily the case elsewhere. I've met lots of project managers who strongly believe in managing by GANTT charts --- creating the charts at the beginning of the project, and trying to intimidate the developers into sticking to it, even in the face of a changed environment or additional information. The whole point of this item, as I understand it, is to make people recognize that they need to plan for things to change. Identifying the reasons for change, and the risks to the original projected timeline are sensible practices. The idea that the plan is a *strategy* is very much in tune with my understanding of the Agile Manifesto.

I see many of the practices you propose as being in the spirit of the Agile Manifesto. Whilst they are clearly not appropriate to all projects (as many individual practices are not), that doesn't make them "not agile". They are clearly different to the XP practices, but as I understand it, your projects are typically very large in terms of scope, budget and team size, whereas XP is built around 12-person teams, so it is unsurprising that the practices are different.

[Craig Brown]

Well said Glenn

[Glen B. Alleman]

Steve,
Having deployed Agile inside CMMI domains in a variety of defense and government firms, I have some experience in "mining the riches of Agile."
What's important is to see the Manifesto as a guide - as you suggest - not as a manifesto to toss out good project management practices and replace them with inappropriate practices, just because of some manifesto.
It's amazing how many times I've come across a broken project (IT project) that has done the wrong thing because they did not understand the core princples of managing a project.

[Steve Campbell]

To me, the whole point of the manifesto is that you can apply it as a litmus test to see to what extent you can be "Agile", and by extension, to what extent you can apply agile techniques.

Of course it is not appropriate in all domains.
You obviously work in (what I would consider) an overly regulated environment, where Agile has no meaning in the traditional (manifesto) sense.

What remains is for you to do what you are already doing - to mine the riches of Agile for the techniques that are applicable in your own domain.