The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry.
Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted..[1]
Mr. Hatfield argues that the IT industry developed Agile and Scrum in response to easy-to-miss, seemingly small, changes to software that led to "configuration management nightmares." This led, according to Mr. Hatfield, to:
...the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda. But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary[?][2]
It seems, as one commenter noted, that Mr. Hatfield was baiting Agile and Scrum enthusiasts to debate the point. I should also note that Mr. Hatfield is only expressing his own opinions and does not represent PMI. One of the first of PMI's new "Communities of Practice" is dedicated to Agile.[3] With Agile now being applied to legal work, and traditional, "waterfall" style project management criticized as poorly fit for legal work, this is an interesting debate to follow.[4]
[1] Michael Hatfield, Taking on Project Management Myths, Part 5, Voices on Project Management, Nov. 11, 2009, available at http://blogs.pmi.org/blog/voices_on_project_management/2009/11/taking-on-project-management-m-3.html (last visited on Dec. 3, 2009); Michael Hatfield's profile is available at About Bloggers, Voices on Project Management, http://blogs.pmi.org/blog/voices_on_project_management/about-bloggers.html (last visited on Dec. 3, 2009).
[2] Id.
[3] PMI.og: Get Involved: Communities of Practice, http://www.pmi.org/GetInvolved/Pages/Communities-of-Practice.aspx
[4] Paul C. Easton, Dialexia Throws Down the Gauntlet: Agile versus the EDRM and PMI PMBOK, Legal Project Management, Sep.29,2009 (last visited Dec. 3, 2009).
Mr. Hatfield is certainly entitled to his opinion.
Bad project management is bad project management, whether traditional-style buttoned-down, agile, scrum, or benign neglect. A poorly run IT scrum project can certainly be a mess. So can a poorly run waterfall IT project.
However, what defines a successful project? Mr. Hatfield's answer appears to be a project under strict control. I disagree. Boeing and Airbus are project-managing the heck out of their new airplanes... but they're still failing projects, neither delighting their airline customers nor making money. Projects are successful if and only if the resulting solution truly benefits the customer. The project manager is only an enabler, neither the customer nor the beneficiary.
Steven, thanks for commenting. Yes, ultimately, your success is going to be measured by satisfied customers and more business. But to state that "bad project management is bad project management" doesn't really address the question of whether Agile is adding anything to the project management body of knowledge.
You raise, however, a more interesting point. At what point do our efforts to increase efficiency and and control begin to be counter productive. Think of Six Sigma and 3M. It brought 3M's shareholders a great deal of short-term value but eventually stifled 3M's once-vaunted culture of innovation.
In services industries, like the practice of law, project management is far more exposed to your client expectations. You can provide efficient, competent service and still have an unhappy client. This usually arises from a failure of communication and soft skills. You see this a lot in outsourced work: the scope is well documented, the close monitoring and measuring of the work is reflected in fancy reports showing all is on schedule and to spec. Everything is green lights according BPO/LPO technocrats. But the client is not satisfied and they lose out on repeat business.
High quality is a baseline. The truly exceptional project managers are always going to be those who intuit their customer's concerns, flesh out desirable outcomes from stakeholders who might not really know or are unable to articulate what they want, and who can maintain a sense of comfort with and trust in the processes throughout the life of the project. Agile enthusiasts argue that Agile Project Management can help keep the client relationship on track better than traditional "waterfall" project management.
Do you feel this is the case, or is it more about PM's personality than the methodology he uses?