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.

Got something to say?