I just know this is going to seem like a fly in the ointment, but it's not and I'll state unequivocally that I'm a big fan of agile everything, but are the core principles stated in the Agile Project Leadership Network site really the distinctive attributes of "agile?"
- Relentlessly Focus on Value. Focus efforts on generating organizational value rather than managing tasks.
- Be Situational Specific. Use situationally specific strategies, not a one-size-fits-all approach.
- Manage Uncertainty. Manage uncertainty through client focused collaborative exploration and proaction.
- Continuously Align to Changing Situations. Choose strategies for leading within a dynamic environment.
- Lead with Courage. Confront reality with conviction and a dedication to purpose.
- Build Strategies that Leverage People. Challenge team members with opportunities to grow professionally.
- Design Strategies Based on Teamwork. Develop and sustain a collaborative team environment.
- Communication Through Immediate and Direct Feedback. Maintain control through feedback, not prescriptive plans.
If I look through the pile of Program and Project Management guides on my desk. The four on top are:
- Project Management: Systems Engineering & Project Control Processes and Requirements, JPR 7120.3, March 2004, Johnson Space Center, Houston Texas
- Program Management Handbook, Exploration Systems Mission Directorate, Version 1.0, March 9, 2005.
- Progress in Improving Project Management at Department of Energy: 2002 Assessment, National Research Council, 2003
- The CAL Trans Project Management Handbook, 4th Edition, September 2002.
The first thing that strikes me is that many of the words in the APLN Core Principles can be found in these documents. I'd go on a limb and state that the pile of guidebooks on my desk and in our library would not be characterized as Agile. But most, if not all (OK maybe not one or two) of the APLN principles are simply good project management principles independent of agile or not.
- Focus on Value - this is the core principle of any Earned Value Management System (EVMS). In fact the "value" of the work must be defined and agreed upon upfront. The Units of Measure of this value are usually dollars (sometime hours) and these dollars are connected directly to the customer's stated needs and the associated budget. No one EVER gets confused on one of our projects about "focusing on value."
- Situational specific (processes) - we have selection processes for our processes that ask first "what's the customer want us to do?"; "What's the specific situation of this project?"; and finally "How can we tailor our program management processes to this specific program?" There are of course some mandatory processes in order to maintain ISO, CMMI, government agency regulations. Safety is one of those "must have" processes situations. What is not realized is that any "extra" work comes straight out of project margin, since it is called overhead.
- Manage Uncertainty - is what any good project manager does for a living. It's how the uncertainty is managed. And more importantly the distinction between uncertainty and risk. Risk mitigation, reserve for uncertainty and all the "risk management" activities of project management can be found in any good project management practice.
- Align with Changing Situations - is done more formally than many projects, but change is a constant and evolving attribute of any project, not just agile projects. Managing in the presence of change can be done in many ways. There are agile ways and there are non-agile ways. Either way, change happens - it's how you manage in the presence of this change that's important.
- Lead with Courage - I'd suggest that launching the Space Shuttle in the presence of new or untried technologies takes some courage. So does tearing up and reinstalling 12 miles of Interstate Highway in the middle of a large metro-city, or installing an ERP system while the business is still running. All but the simplest waterfall projects take courage. This is not unique to agile projects.
- Leverage People - we're always short handed, misaligned on skills, over committed to the customer. Only the best people can be assigned to our projects. This is a core capability of any good project and project management process.
- Teamwork strategies - Integrated Product Teams (IPT) are the core of any non-trivial project in about any industry.
- Immediate and Direct Feedback - weekly earned value keeps you on your toes. Daily stand ups for the customer. The customer "on your team." Full electronic access to all design, cost and schedule basis. Those will qualify for Immediate and Direct Feedback.
Are there projects that don't have some of these attributes? Sure. Are they successful projects? Probably not. Will a project be successful if they follow these principles? If it were only so easy.
What I hope happens here is the APLN comes to understand that their defined principles are in fact Good Project Management principles - NOT confined to the agile domain, but general principles found in well run project organizations. As well, the recognition that because projects don't follow these principles it doesn't mean that Agile Project Management will solve their problems.
If we're going to have Agile Project Management be a distinct approach to managing projects (not just developing software with small groups of developers and a customer), then we need to discover what actually distinguishes Agile Project Management from the current Good Project Management practices found in the example guidebook above or dozens of similar examples in other guides for other industries.
Once I figure out what my $75 will go toward, I'll join this group - if they'll have somebody who asks really annoying questions about "why we're different?"
