Over at Gantt Head Dr. Andrew Markar has a column titled "Debunking Agile Myths." (You'll need a free account to read this.) Andrew is a frequent commenter here and has contributed to advanced the profession of project management.
Andrew's article makes some good points, so please sign up and read this and other articles. I'm always troubled though by some items that are missing from discussions like these. So here's my additions to Andrew's good content.
- Agile Myth Number 1: Agile is just an excuse to code with no documentation
- Agile Myth Number 2: Agile doesn't follow any PMBOK compliant processes
The software was the means to achieve that business outcome. Even when the business outcome is to fly to the moon or kill people on purpose, the software is just the means. The project or the program provides the means, the software is just one piece. When you substitute Agile for Project Management you're confusing development with management.
- Agile Myth Number 3: There is no planning in agile
Having a plan means you not only know where you are going, but how long it might take to get there and how much it might cost when you arrive.
- Agile Myth Number 4:Agile Won't Work with Distributed Teams
Other ways of increasing the bandwidth are needed. Agile addresses some of these, but others are needed. NASA solves this with full fidelity simulation - Simulation Based Acquisition is the official term.
In the end here's the issue if have with the agile view of the world. In the right hands agile is a wonderful paradigm for developing software. In the right context and the right domain it remains a wonderful paradigm for developing software. But software is a product. The product is NOT the project. The product is the means to the delivering value to the project. The project (or program) may be commercial - process insurance claims. If may be scientific - point the orbiting telescope at a distance galaxy. It may be industrial - process tall skinny pines trees into money (paper) at a rate of $4B per year in southern Louisiana. Or it may be more dark - fly the missile to a target in a distant land and delivery it's cargo.
But in all cases, the project is larger than the software. While to Scrum folks would have us believe Scrum is a project management method, when you map Scrum to the PMBOK Process Groups and Knowledge Areas you come up with empty cells. When you map Scrum to CMMI-DEV V1.2 Process Areas you come up with more blank cells. When you map Scrum to a DoD 5000.02 Integrated Product and Process Development map you come up with loads of blank cells.
Putting "project" in the title of an article, a training course or a certification does not make it so.