Scott Ambler's current post titled Agile Practices Require Discipline restates the core principles of all successful projects. The framework described by Scott can be found in many other project domains, from heavy construction, to spaceflight, to weapons systems, to process control and even well implemented ERP systems.
The time scale may be different from Scott's typical agile projects for important reasons, not the least of which is the scale of the project itself, the business rhythm of the project, and the technological structure of the project.
Bending metal into spacecraft is not a process that takes hours to days. Building the I-25 corridor in Denver was 4 years, but had nearly identical behaviours around daily meetings, teams of collaborators. Same for my beloved Rocky Flats (see Making the Impossible Possible) where for the last year had the Plan of the Day for a multi-billion $ D&D program.
From Scott's nice list around the development of software, there are other domains and contexts in those domains - many times software - where these processes are not only common, they are baked (mandated) into the work process.
These are found in defense, space, nuclear power, process control systems, navigation, command and control of remote machines, intelligence systems - also heavy software - or pretty much any product or system considered mission critical.
- Hold short, focused, and to the point daily coordination meetings rather than infrequent and time consuming status meetings.
In the ANSI-748-B culture weekly EV is common. This means there is a review meeting every Tuesday (or your favorite daya). And a status meeting some days prior. These are Tuesday the prior Thursday in our case. The review meeting walks through the tangible evidence of progress to plan. The evidence is the physical percent complete of the planned activities. This means working products, completed documentation, installed materials, and the like.
It's always "show me" the results of the work from the preivious efforts. No discussion of "I'm working hard." Only tangible evidence of progress.
During the meeting there is a discussion of "coming due," or "coming start" for all the planned work. Then the project members share their commitments to fulfilling these starts and completes.
- Commit to delivering a set of work items each iteration rather than letting deadlines slip.
The is an Integrated Master Schedule that shows what the deliverables are, when they are planned to be delivered. This can be iterative, rolling wave, "drops," or any fine grained incremental deployment. This structure is mandated by the guidance for Earned Value Management through a simple statement - "no work package (or in some cases a work activity" shall cross more than one accounting period." This is the 44 day limit called out in the DCMA training materials.
This answers the question "how long are you willing to wait before you find out you're late?" The answer to this on the current manned spaceflight program is 2 weeks. There is the mandated month-end contract performance report and a mid-month flash for the forecast of the month end performance.
- Remove impediments in a timely fashion rather than procrastinating in pursuing a solution.
This is he role of program management, risk management, the Control Account Manager (a mini project manager), and the program planning and controls team.
Tim Lister's quote "risk management is how adults manage projects"
- Take the time to write tests before code rather than writing code, It takes discipline to consistently work in a test-first manner instead of leaving testing to some time in the (distant) future.
&The Integrated Master Plan defines the increasing maturity of the produced product - a flying machine, an ERP system, a space craft, an environmental cleanup. The measures of this maturity are stated in Technical Performance Measures. In order to measure the TPM, you need a test. These are incremental assessing of increasing maturity for all work performed under the IMP/IMS paradigm
- Reflect on the team’s experiences and improve their processes proactively rather than relying on process dictated by project managers or external governance bodies.
Weekly progress to plan provides tangible evidence of progress. Keeping the program GREEN requires that corrective action be taken when there are variances. This is the source of the retrospectives in the agile work. But it's mandated on a weekly basis in 748-B domains.
- Have a continuously working, integrated, and tested solution rather than waiting to do so when you’re “done” at the end of the life cycle.
The measure of continuous is domain specific. But answering the mail of knowing how long to wait before we find out we're late means you have to determine what the business rhythm. Typically this is monthly and many times twice a month.
- Work together in a common area rather than in comfortable but isolated workspace.
This is likely domain specific. Virtual environments are common. Video conference, shared resources, and technical interchange meetings where people sit face to face.
- Collaborate constantly with the stakeholders or their representative(s) to ensure that their expectations are met.
Team based projects are mandated in the 748-B world. Share outcomes are defined in the Integrated Master Schedule and the Integrated Master Plan.
- Create and evolve deliverable documentation continuously throughout the project. It takes discipline to accept that there’s more to successfully solution delivery than producing potentially shippable software.
The job's not done until the paper work is done. Aircraft can't fly without manuals. Software can't be operated without manuals. Test articles can't be shipped to the test facility can't be dome without the installation and test procedures. "Cut and Go" ASICS can't be shipped to the silcon foundry without the net-list and gate descriptions. The FPGA's can't be burned without the Handel-C scripts.
In many domains documents are the deliverables. Interface Control Documents (ICD), Systems Engineering Management Plan (SEMP), Program Management Plan (PMP), all the CDRLs for Preliminary Design Review (PDR) are all "shippable" documents. Documents are the product in many instances and are called at with part numbers.
- Self organize and plan the team’s work amongst themselves rather than relying on a traditional project manager to define, estimate, and assign work. It takes discipline to take responsibility for your own work and to respect the collective decisions of your team.
Self organizing teams is a powerful idea, IF the members of the team can work in the presence of self-organization. This is rarely stated as a condition of self-organizing. Much the agile or agile-like management literature speaks to all the joys of self organizing processes in the absence of the per-conditions for success.
For example, one of our clients is building molecules to drugs. The "team" self organizes around chemistry, biology, analytical, QA and other lab processes. These are Masters and PhD level science folks, and they organize their work around the deliverables. But when we move out to the production facilities, the policies and procedures needed for GMP (Good Manufacturing Practices) from the FDA are lock step procedures needed to produce product. No deviation, no making it better, no touching anything. Self-organizing in that environment is chaos and possibly death.
So when you hear - "self organizing teams are the best," ask in what domain, what context in that domain.
So in the end what Scott is so nicely describing - minus some very small details around the domain of software development - is simply good project management. At least any project and program I've ever successfully worked.
This type of discussion is similar to those when agile first started. When Scrum and XP were propossed as new and exciting. When in fact the principles and many of the practices are simply good project management. There is lots of BAD project management out there. But does not mean it should be the example of how PM has failed. Just the opposite, BAD project management is just that BAD PROJECT MANAGEMENT - period. Don't do it. Look for examples of good project management. In fact good project management is agile. It has to be. Projects are disruptive events, fraught with changing, emerging processes. It's just part of the domain of a project. If you're not "agile" - in the way a 285lb linebacker can be agile - then your project is going to fail.
Scott shows that the agile paradigm can be directly traced to good project management.
