Scrum is Definitely Not Project Management

The following is a reply to a post by Tobias Mayer, on his blog “Agile Anarchy.”  In it, he makes the point, “Anyone who is laboring under the misapprehension that Scrum is some form of “Agile Project Management” is seriously missing the point.”  I agree.

Scrum is certainly an effective software development method, practiced widely and producing useful software products for many organizations. However, project management is most assuredly not about software development; it is about managing “temporary endeavors undertaken to create a unique product, service or result.” Some of those products happen to be (or include) newly developed software; others might be bridges, or data centers, or implementations of packaged software, or whatever ever else an organization might decide to commit funds to.To your point, Tobias, Scrum is not project management; it acknowledges no stakeholders other than the product owner, and no products other than software. It does not contemplate procurement, or human resource management; instead, it assumes all resources, people and otherwise, are present and dedicated for the duration, and no other activities matter. Risk management is limited to whatever actions the team can take. Still, Scrum is effective, for organizations that are willing to commit to it, but it is not a substitute for project management, even for software development projects.

Those of us who actually do it for a living approach project management as the study and practice of a mix of skills, techniques, and processes. We select those appropriate for the work at hand, the organizations and people who will do the work, and the stakeholders. PMI publishes extensions to the PMBOK for construction and the public sector; perhaps they will soon publish an extension for software development. But the PMBOK will not be optimized for software development, because it represents only a small fraction of all projects. In the meantime, skilled project managers will manage effectively using appropriate methods and poor project managers will manage ineffectively, just as good software development teams will produce good software, and bad ones will produce defect-laden crap.

Final point: credentials only matter to those recruiting new talent, and those seeking to be recruited. Practice standards, such as Scrum and PMBOK, matter only to those who wish to take a rigorous approach to their work, and share information with other practitioners using a common vocabulary. Those who approach their work like a game of Calvin Ball, just shouting out new rules whenever they feel at a disadvantage, have as much disdain for authority and rigor as the rest of us have for their sloppy work, and dismiss credentials and standards out of hand. Over time, they will be filtered out of the work force by the recruiters, and the rest of us will move on.

This entry was posted in Best Practices and tagged , , , , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources and in benefits administration. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.

2 thoughts on “Scrum is Definitely Not Project Management

  1. what a great article; well written and to the point. As a PMP (PMBOK) who is working heavily on Agile projects I have found the cultural move from the rigour and structure PMBOK provides, to the rolling up of the sleeves and getting on with the code that Scrum provides, a little hard to get used to, but we have been delivering the value and getting the software released quickly through the engergy from a team that is empowered and freed from the heavy beurocracy often found in waterfall based projects. Managing the quality of the code using Agile works well, however I would like some suggestions on what scrum masters and Agile PM’s have determined is a minimum set of project documentation that needs to be maintained to ensure quality is not compromised. With PMBOK we have an extensive Proj Mgmt Plan that provided the project framework and communication and documentation expectations, however with Scrum, other than documenting your code, stories (requirements) and release deployments, is there anything else that should be filed away as part of the work package and a record of the knowledge asset ? thanks

  2. Thanks, Harry. The Agile Community of Practice on the PMI web site has several thousand members, and they share a lot of best practice information. If you haven’t stopped by yet, give them a look. Also, check out and some of the other resources on my blog roll – there’s a lot of information out there.

Comments are closed.