The Projects@Work site has an editorial titled "Agile, by any other name." (Registration required). There is of course the original Agile Manifesto. Then 7 additions clarification points:
- Develop in short cycle times
- Plan short term (the next cycle)
- Develop only what is needed
- Close collaboration with the user
- High visibility and daily reporting
- Empower the project team
- Test in parallel with development
These approaches are also found on large space and defense programs. There the Integrated Master Plan / Integrated Master Schedule (IMP/IMS) paradigm is mandated for programs greater than $20M. $20M sounds like a lot, but in that domain it's not. Most firms then push this paradigm down onto all programs. As well DID 81650 is mandated along with an Earned Value Management process.
Using the Agile Guidance for Managing Projects
While the 7 items above are usually applied to software development activities, they are generally applicable to any project domain and context. Here's how they are applied on 1/2 billion dollar manned spaceflight software programs, multi-billion dollar Army combat systems and many multi-billion dollar Air Force integrated world wide "everything over IP" program.
- Develop in short cycle times - the primary role of this behavior is to ask and answer the question. How long are we willing to wait before we find out we're late?
Short cycle times have different meanings to different domains. But all defense and space programs have monthly earned value assessment of physical percent complete. Nearly every Earned Value Management System - System Description (SD)
- Plan short term (the next cycle) - rolling waves are used for all non-trivial programs.
This means the current rolling wave is being executed from the Performance Measurement Baseline (PMB). The PMB is a time phased description of the cost, work, and deliverables. The current rolling wave consists of Work Packages, with a duration, resource "spreads" and a single deliverable.
Planning packages are used for "out year" (yes years) work. These Planning Packages has durations and cost spreads, since the the critical path must be identified from Contract Award to Contract Closeout.
- Develop only what is needed - the rolling wave work package process defines explicitly what is to be produced.
In the federal contracting world if you work on things that are not needed for the next Program Event - see Integrated Master Plan / Integrated Master Schedule Preparation and Use Guide - you wouldn't get paid.
It is critical for the program to work on only things that increase the maturity of the deliverables "as planned" in the Integrated Master Plan (IMP). Otherwise the program is decreasing the probability of success. There is an urban myth that programs like this have Big Design Up Front. That is simply a lie, er "red herring." Change is constant in Pre-Milestone C programs. These are System Development & Demonstration. The milestone after that (D) is Low Rate Initial Production (LRIP). SDD is emerging requirements driven.
- Close collaboration with the user - this is not as easy as in small team IT projects.
But Technical Interchange Meetings (TIM) occur frequently for all the obvious reasons - emerging requirements. As well there is daily if not hourly contact with the customer for SDD style programs for again all the obvious reasons. But requirements are flowed down from the customer to the supplier. There is more formality in the development and management of these requirements. This is driven by the production mature of the products. If you're building a one off is a test vehicle in a DARPA style program (a science project), the requirements management is much different than if you're upgrading all the F-18's in the fleet with new GPS navigation systems.
IT projects are almost always "one offs."
- High visibility and daily reporting - well maybe not daily, but certainty weekly.
Most programs we work, do weekly earned value. Monthly is mandated. NASA requires "mid month flash reports." So if you're going to do that, you might as well do weekly. What this means is a weekly "interview" with the Control Account Managers (CAM) to assess the physical percent complete of the planned deliverables. The critical concept is the "physical percent complete." You never confuse effort with results. So the passage of time and consumption of money is not a measure of progress. Physical, tangible evidentury materials are the only measure of progress. How do you assure that the deliverable meets the spec? Why test it silly. Yes Test Driven measures of physical percent complete are the way large defense programs work.
- Empower the project team - teams work as "teams." usually with a lead and a collaborative staff.
This is how engineering works. For some reason the software world is just figuring this out. No credible engineering firm would work in a command and control manner for long. The product would not get out the door.
- Test in parallel with development - test driven development is the standard system engineering approach.
It can't really be anything but this and have th ability to hold the schedule and meet the cost target. Rework is unfunded in the DOD procurement processes. ANSI-748B does not record BCWP for rework. How do you avoid rework? Built it right the first time. How do you build it right the first time. Test the living !@#$ out of everything as you go.
