Is Scrum a Project Management Methodology?
Tobias Mayer wrote a post recently that Scrum has nothing — or very little — to do with project management, and backs it up with the fact that Ken Schwaber has stated often that there is no Project Manager role in Scrum. This got me thinking, because my first reaction is that Scrum actually has quite a lot to do with project management.
I’d like to exam this a little closer. I’ll start with a few definitions.
A project, according to “A Guide to the Project Management Body of Knowledge — Fourth Edition” (PMBOK), is “a temporary endeavor or undertaking to create a unique product, service, or result.” (p. 5). According to the same publication, project management is “the application of knowledge, skills, and techniques to project activities to meet the project requirements.” (p. 6). That’s pretty broad stuff, but you should be able to get the idea from it.
The Scrum Alliance offers: “Scrum is an iterative, incremental process for developing any product or managing any work. “ The Scrum Alliance defines a product or more accurately a product backlog as “a list of requirements prioritized by business value.”
So let’s take a look at this — the PMBOK tell us that project management is a way to manage work which is encapsulated in a project and the end result of which is a product or some other result which meets the project requirements. Scrum is a process for developing a product (which is a list of requirements) or for managing work. Pretty damn close so far.
What about a project manager versus a ScrumMaster? Now, I know that a ScumMaster isn’t positioned as being a project manager, but there’s no denying that this role is at least more closely aligned to the concept of a project manager than anyone else on the Scrum team. Onwards … .
According to the PMBOK, the project manager “is the person assigned by the performing organization to achieve the project objectives (p. 13). PBMOK elaborates: they manage and control change, progressively elaborate information, manage the team to meet objectives, and monitor and control the work (p. 9).
The ScrumMaster, on the other hand, “is a facilitative team leader who ensures “the team is fully functional and productive … .” In addition, they remove barriers, shield the team from external influences, ensure the process is followed, tracks work, and resolved conflicts.
There are some differences in the description of these two roles. I think the ScrumMaster description provides a little more detail, and in some ways just defines what the PMBOK calls “manage the team”. I know the idea of ‘managing’, though, goes against a key concept of Scrum and agile — that of self-organization. But in the end I think it would be easy to interpret these two definitions as being fairly closely aligned.
Looking at the thing (projects/products), the process (Scrum/project management) and the people (ScrumMaster/project manager) it’s hard not to come to the conclusion that Scrum is very similar to a project management methodology.
There are some key differences. Scrum is intended to help deliver software development projects, not buildings or events or whatever. Project management is intended to be applied in any area it’s needed. The leads to another question, though — can Scrum be applied outside of software development? I think it can (if I think back to courses and workshops I’ve been on, I know that Scrum can at least be applied to created a game and making paper airplanes), although that isn’t as clear a path.
In the end, Scrum clears away a lot of what traditional project management brings to the table — no stringent change control, no big designs up front with scope statement set in stone, no central project manager balancing all the spinning plates. It definitely feels different, but I’m not sure it is.
Scrum has no projects, only lean story flow. If you have projects, you’re doing something wrong.
Story flow in lean development – which Scrum follows at least parially – is more resource (money) efficient than traditional projects.
I guess the next thing after Scrum is Scrumban, and the difference to waterfall and classic project managment will be more clear to most people.
Cheers
Stephan
–
http://twitter.com/codemonkeyism
http://www.codemonkeyism.com
I’m not sure I understand. Are you saying I’m doing something wrong by using Scrum to execute a project? That doesn’t make any sense to me. Most business want to understand the scope of an undertaking (i.e. “project”), how much money it will cost them, and when they can expect it to be done. If I’ve encapsulated the work within these constraints, I’m not using Scrum?
@Stephan – I’m not suggesting Scrum is the same as traditional project management. I know very well it is different, and agree with everything you’ve stated. But I don’t think what you’ve said necessarily counters what I’ve said. For example, the project I’m running does actually have a scope, but that scope is somewhat flexible (with several production releases), which allows us to better apply Scrum processes to it. But the fact that there is a scope of work doesn’t negate the value of Scrum.
There are many, many things which are different (and better!) in Scrum that in waterfall or other traditional project management methodologies. I guess in the end I’m just wondering what the drive is in the Scrum world to state that it isn’t a project management methodology.
Just some of my thought on Scrum and lean, this is not Scrum canon.
- Scrum prioritizes small stories and cuts out stories without enough business value (last 30% of the wishes). A project has a fixed scope, if you can’t cut stories out, your not doing Scrum
- Scrum does not want to create waste – e.g. estimations for stories which will not be done. If the business sponsor does want a cost estimation for the project beforehand, you need to estimate everything
- Developers do the estimation. For several month projects with several developers this will take some days. If the developers don’t estimate the scope in Scrum fashion, you’re not doing Scrum
- In classic mode, the project manager is responsible for the outcome. In Scrum the developers are responsible for the outcome. If the developers are not responsible, you’re not doing Scrum
Scrum is not about fixed projects. If you have fixed projects with a fixed scope and a fixed time frame, use classic project managment.
Scrum is about changing requirements, just-in-time adatption to market conditions, maximizing story flow.
Most business are incompatible with ther wishes for Scrum, they need to transform themselves to adopt Scrum. This is the hardest part, following the Scrum rules in the development team is easy.
Cheers
Stephan
–
http://twitter.com/codemonkeyism
http://www.codemonkeyism.com
In a comparison such as the one you’ve done here I agree that Scrum begins to sound very similar to project management. But I believe by extracting quotes from a brief overview of Scrum you are missing something. Scrum is both far more and far less than you describe it here.
Scrum is not a process and not a management tool. It is simply a framework for surfacing organizational dysfunction. When such dysfunction is apparent, people can do something about it. That something is rarely more management — usually it is less; it is about releasing old behaviors and embracing new ideas.
Scrum Masters are not managers; they are servants to the team and jesters within an organization. Scrum Master is altogether a new role, and to map it to the PMP role is a mistake, as it will keep us trapped in old ways of thinking… it may even move us backwards.
@Tobias – I also agree with everything you’ve said, although I do think there’s value in looking at definitions. I think you yourself started to touch on the power of words and the role they play in oppression. All I did was focus on some words.
I can appreciate what you’re saying, as well, with the idea that this may be a dangerous path to go down. But it was an interesting exercise for me and helped me to get a better perspective. I appreciate everyone’s feedback. Maybe next week I’ll write another post taking a contrary position.