Dan Rawsthorne

here has been a lot of talk about the Project Manager in scrum. Two of the more popular statements have been:

• scrum projects have no Project Manager, and
• the ScrumMaster is the “Agile Project Manager”

I believe that both of these statements are wrong. My position is that all scrum teams that are working on projects have on-the-team Project Managers, that this Project Manager is the team’s Product Owner, and this gives the ScrumMaster some interesting problems to manage. I’d like to explain this…

First, a little background. I started off my life as a mathematician – my PhD is in Number Theory. As such, I am used to pedantic, hair-splitting arguments that rely on definitions. This will be one of them. I think that such arguments are useful when trying to get to the core of something – when trying to understand the “One Big Thing” or OBT of something. Basically, it’s my contention that if you don’t have an OBT for something that you can clearly state, then you don’t really understand that something. When discussing something with somebody, I first like to see if we agree on the OBT, and start from there. I spend a lot of time trying to determine the OBTs of things. That’s me… as my friend Jim Coplien would say “damn those ENTJs!”

So, here we go.

First, before discussing scrum at all, let’s figure out what a Project Manager is – what is the Project Manager’s OBt? Well, we say that a person is a Project Manager if he/she is carrying out the Project Manager role, which is defined by a particular OBT. In the case of a Project Manager, the OBT is “The project manager is the person assigned by the performing organization (ed: business) to achieve the project objectives” according to the Project Management Institute (PMI). This definition is found in the PMBOK, or Project Management Body of Knowledge, so I’ll accept it as authorative. (personally, I would prefer the word “assigned” to be “recognized,” but there you are…) If you don’t happen to have a copy of the PMBOK handy, you can use Wikipedia’s definition, which is “A project manager is the person accountable for accomplishing the stated project objectives.”

Either way, I will summarize the Project Manager’s OBT as “The Project Manager is the person accountable to the business for accomplishing the Project’s objectives.”

So, a scrum team that’s working on a project has a Project Manager if there is a person who “is accountable to the business for accomplishing the Project’s objectives.” Does a scrum team have such a person? Yes. The Product Owner is defined as “the person who is responsible for what the scrum team builds and for optimizing the value of it” and “The Product Owner is responsible to those funding the project to deliver the vision…” (Schwaber, the Enerprise and Scrum, 2007). There are many other quotes from Ken’s books showing that the PO is “accountable to the business for accomplishing the project’s objectives,” including “[the Product Owner] is the single, wringable, neck” and “[The Product Owner] is the person who is officially responsible for the project,” and so on – so it is clear that the Product Owner is also a Project Manager for the scrum team, by the definition of PM.

Of course, the Product Owner is a member of the Scrum Team, so we would be more correct to say that the PO is the on-the-team PM. The formal “named” PM might not be on the team. But it does say that if you have a formal PM, and this PM is on the Scrum Team, then the PM is the PO. This isn’t a choice, it’s a definition.

So, either the PM is on the scrum team, and is the PO, or isn’t on the scrum team, and is merely a Stakeholder represented on the team by the PO, since “The PO is responsible for representing the interests of everyone with a stake in the project…” (Enterprise and Scrum) and the external PM is certainly such a person.

One common pattern is that there is a PM who manages the POs of all the teams working on the project, but is not on any of the teams. But, each of the team’s POs is an on-the-team PM – that’s my point. Once again, this is not an option, it is true by definition.

So, now that we know that the scrum team’s on-the-team PM is also the PO, this tells us something about how this PM must do work. No more “command and control” PMs on scrum teams, as the PO isn’t allowed to do that. The PM must follow the rules of scrum (and act like a PO is supposed to act) in order to be on the scrum team, or the scrum team isn’t a scrum team. If there is a formal PM outside the team, this outside-the-team PM must work through the PO to get stuff done, just like any other Stakeholder. No controlling team members, no destruction of a team’s self-management and self-organization. Sorry ’bout that for the PMs…

Finally, what about that “the ScrumMaster is the Agile Project Manager” thing? I think it’s just a simple misunderstanding of what the Project Manager is accountable for. According to (Schwaber, Agile Project Management with Scrum, 2004), “the ScrumMaster is responsible for the Scrum process, its correct implementation, and the maximization of its benefits” (pg 142). I think that the phrase “maximization of its benefits” gets some people confused and makes them think that the ScrumMaster is the on-the-team PM…

But, it’s clear that the ScrumMaster is not in charge of the team (or what it produces) in the following quote: “The ScrumMaster is responsible for teaching the PO how to most effectively manage the work of the Scrum team using the Product Backlog, Sprint Planning Meeting, and the Sprint Review Meeting. He or she teaches the Product Owner how to maximize ROI and meet their objectives through scrum” (Enterprise and Scrum, pg 78). In this quote it is clear that the PO is in charge and the SM is a mentor/advisor to the PO to help the PO get the most out of the Team (this isn’t all the SM does, of course…). Therefore, the SM can’t be a PM of any sort, as the SM has no accountability to the business for the team’s product or production.

In other words, the SM is not accountable to the business for the achievement of the project objectives; the SM is only responsible to mentor the PO so that the PO/PM can meet the objectives. In fact, since the SM can’t be the PO, there’s no way the SM can slip through that loophole, either. Unfortunately, the responsibilities the SM has in this area are very difficult ones: the SM must keep the PO/PM from acting like a traditional PM. It’s the same PM OBT, but with different implementation because it’s scrum. By the way, I think that this difference is the main reason we need certifed SMs… to make sure that SMs get it.

So, so summarize my position:

• scrum projects are projects, and thus have Project Managers (PMI definition)
• The scrum team member who acts as the team’s on-the-team Project Manager is its Product Owner (there’s only one wringable neck)
• if there is an outside-the-team PM, he or she is represented by the PO on the team (as the PO represents all Stakeholders)
• Since any Project Manager that is also on the team must be the team’s Product owner, any on-the-team PM must change the way he/she does work in order to conform to the scrum process
• The team’s ScrumMaster is responsible to help the PM/PO learn to use the scrum process to get the most out of the team and the process

That is all…

Good Luck!

Dan Rawsthorne

admin product owner agile, agile project manager, product owner, project, scrum product owner, scrummaster, team

Imagine our Product Owner says: “I want this feature by tomorrow, and I don’t care if you’ve got to hack it in – if we don’t deliver it tomorrow it will cost us millions of dollars!!” What do we do?

That’s a rhetorical question, I hope. Of course, we just hack it in – You intentionally create technical debt – because doing the “right thing” is not always the right thing to do. There could be a higher business value that overules quality, right? Now, I know that there are those that don’t agree with me here, but I certainly hope you’re not one of them

But, then what? We’ve got this part of your code that’s just hacked in, sitting there stinking up the place. We’ve got to live your values. The scrum values I teach are openness, focus, commitment, courage, respect, and visibility (this is a non-standard list). The values that are relevant to this situation are respect and visibility; we must respect our product, and make it visible that we just created technical debt. By the way, I should have the same feelings even if I was the one to put in the technical debt, and it wasn’t the fault of my Product Owner

So, I recommend that we add a “make-up” story to the backlog; a story that apologizes to our code base and promises to fix it. For example, let’s say that what we did while hacking the code was forget the unit testing and create some badly designed code (in module XYZ) that needs re-factoring. Then, what we would do is add a story to the backlog named “Fix up Module XYZ” in which we would explain what unit testing needs to be done and what code needs to be re-factored.

This story serves two purposes. The first is that it formally admits that we left a mess behind, and can be thought of as an apology to our product. The second is that it forces our Product Owner to make conscious decisions in the future NOT to “Fix up Module XYZ” in order to add other features. The first purpose proves that we are living our values, and the second purpose forces the product owner to make active prioritization decisions of features versus quality.

Both of these purposes are in the best traditions of scrum, but the second might be the most important. We need to “force” our Product Owner to make active decisions (both good and bad) about what our system should be. I have found that passive decision-making is almost always bad for our product, and reflects the fact that “all that is necessary for the triumph of evil is that good men do nothing” (Edmund Burke, 1790)

Thanks, Dan  ;-)

Dan Rawsthorne technical debt scrummaster, technical debt, technical owner