The Recurring Agile Myth Article

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

    The notion of incorporating the "right" amount of documentation is in the eye of the beholder. Actually its in the eye of the IT Governance Committee. Good IT development processes has the "right amount" of documentation. This "right" amount is rarely defined by those developing the software - the "developers."

    Having been a developer in a former life - embedded control systems for products ranging from refineries to missiles. I personally would do only the bare minimum of documentation. It's the standard approach. But in fact I wasn't writing software for my self, I was writing software for the air force, for Exxon, for Boise Cascade, for the Navy. It was their software in the end, since they were paying for it. They wanted documentation that described the Who, What, When Where, Why and How of the delivered product.

• Agile Myth Number 2: Agile doesn't follow any PMBOK compliant processes

    Agile is a provider of technical solutions. Agile is a engineering process. Take a look at the CMMI-DEV V1.2 process areas to see there are many other activities involved in building software products that writing code. There is process in Agile. Agile is a process. A disciplined process. PMBOK is a description of Process Groups and Knowledge Areas.

    PMBOK is NOT a project management method. In the same way Agile is NOT a project management method. Agile is a software development method. If the software is the one an only outcome of the project, then agile can be substituted for the project management method. But I have never in my life - and it's a long life of software and project management - been on a project where the software was the business outcome. The business outcome is the business outcome.
    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

    Planning is in the eye of the beholder, just like documentation. When Andrew says there is more planning in an agile project than in a waterfall project (what ever that means), I'd like to see the waterfall project. It's probably a bad waterfall project. We (our firm) provides program planning and controls staff to a manned spaceflight avionics program. This program is a mix of software, firmware and hardware. The current rolling wave for all this work runs about 30K lines of MSFT Project schedule. For about $500M worth of development. This is a big project. Smaller projects have 5K to 10K lines of activities for $20M to $50M worth of software and hardware development.
    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

    Most of the programs we work are distributed. Most are software intensive programs. Coordinating the actions of teams across the continent or across the world has pretty much the same problem. If you can't look someone in the eye then it is a narrow band communication channel.
    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.

    Agile is a software development method

Putting "project" in the title of an article, a training course or a certification does not make it so.