Who is the Project Manager in scrum?

October 4th, 2009

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

  • Share/Bookmark

admin product owner , , , , , ,

Scrum Evolution Explored

May 13th, 2009

I’ve been using and studying scrum ever since I heard about it from Linda Rising 12 or so years ago. At it’s core Scrum is a pattern language (http://en.wikipedia.org/wiki/Pattern_language), and it’s been evolving as people find better ways of doing things, and thepatterns have changed. This post will give a very quick overview of what I’ve seen change. I believe that Scrum has gone through two significant versions, and I’m willing to guess what the next version is. To track these stages of evolution,  I’ll number them Scrum I, II, and III and then direct your attention towards the interesting points of evolution.

(Scrum I, Early Scrum, 1995-2004-ish) PO usually externalscrum-evolution-social-graph to team, negotiates sprint backlog with the team. The team self-organizes, produces “done” product, and has a Sprint Review with the PO, who either approves or disapproves the work. The only way to “officially” change requirements in the middle of the sprint is to have an abnormal termination and start over. After the sprint the team (sometimes including the PO) has a retrospective to improve its process, and the PO modifies the release plan.

This leads to a number of Issues/Forces:
 - adapting to business changes within the sprint is difficult
 - hard to talk to PO for additional guidance during the sprint
 - often caused the team to view the PO as “one of them” and not “one of us”
 - many teams created a “Product Owner Proxy” who represented the PO day-to-day on the team

(Scrum II, Modern Scrum, 2002-Present) PO internal to team, and negotiates sprint backlog with rest of team. The team (including the PO) self-organizes, produces “done” product that is accepted by the PO along the way. Teams develop various methods for reprioritizing and bringing in new work during a sprint (negotiating techniques, mid-sprint replanning, etc). The Team (including PO) reviews the results with external stakeholders during the Sprint Review and receives feedback that changes the release plan and is incorporated into the next sprint’s planning. After the sprint the team (including the PO) has a retrospective to improve its process.

Differences:
 - PO on team
 - more in-the-sprint changes to Sprint Backlog
 - PO is more a part of the team’s day to day work
 - Adaptive Evolution of the Product is finer grained
 - Focus on delivery to Stakeholders, not PO

There were/are some Issues/Forces:
 - Still not quite adaptive enough for some
 - “last few” stories on sprint backlog are always being supplanted by new ones
 - Sprint lengths got shorter to allow for more frequent feedback and planning
 - can’t make the sprints as short as we’d like to because some stories just “take that long”

(Scrum III (KanBan-ish version), 2007-Present) There is no Sprint Backlog, only Work In Progress (WIP), which is fixed length set of stories currently being worked on. There is still a Sprint, which is a fixed-length timebox that defines the time between reviews, the changes to release planning, and the setting of sprint goals. At the beginning of the sprint the Product Owner negotiates goals for the sprint with the team. The team is constantly grooming and reprioritizing the backlog. When a story is completed, a new one is moved up to the WIP and begun. At the end of the Sprint there is a Sprint Review for the Stakeholders where the completed work is reviewed.

Differences:
 - Sprint Backlog replaced by WIP
 - because is WIP, stories can go across sprint boundaries

Note that this evolutionary change is much smaller than the former. Perhaps we are converging on a final solution – I don’t know. I have no idea what comes after this. We’ll just have to wait and see what issues come up, and what patterns emerge.

Dan   ;-)

  • Share/Bookmark

admin scrum , , , ,

Release Sprint

April 9th, 2009

Imagine you are at the sprint review and the Sales Manager says “that looks good – I can sell the heck out of that – ship that puppy!” Now what? what do you need to do to get the system shipped, and how and when will you do it?

First of all, what does the Sales Manager mean when she says “ship that puppy!” anyway? Well, here is a list of things she might be expecting to see once the system is shipped:

  - The product is available to users. It provides value, doesn’t break or blow up in their faces, meets performance requirements, and so on. It has accurate documentation, and the Help Desk is prepared to answer questions about the new version.

  - Marketing has new materials and the marketing plan is implemented, including advertisements, YouTube videos, Google key words, and so on. 

  - Sales is able to sell the new version. The Sales System is updated to manage the sales, new sales forms exist, the website’s sales pages are updated, and so on.

How much of this is your team’s problem? What has your team done, what is it doing, and what must it do to make this happen? Good questions! In any case, It’s pretty likely that much (if not most) of this stuff has yet to be done, so let’s discuss how and when it might get done. To do this we need to understand the notion of “done” from a release’s perspective.

There are three definitions of “release done” that I’d like to discuss: ‘feature complete’, ‘code complete’, and ‘releasable’. We know that the Sales Manager believes that the system is feature complete; that is, it does what we want it to do in order to provide ROI. We’re not going to argue with that – she’s the boss!

What about code complete? Well, what does that mean? It means that not only does it do what we want it to do, but it doesn’t do what we don’t want it to do. The edge cases don’t blow up, and there are no surprises. It satisfies the “ilities” requirements, like security, performance and interoperability, and it just plain works. 

And what about releasable? Well, in order to be releasable there is lots of other stuff we need: user documentation, training materials, sales and marketing materials, training and documentation for the help desk, and so on.

We need to move our system from feature complete to releasable, if it isn’t there already. If it is there, congratulations! You are one of the few, and truly special, teams, and need read no further. If it’s not there (like most of us), you need a Release Sprint. It is generally accepted guidance in the agile community that it should take no more than one Sprint to move from feature complete through code complete to releasable, and we call this sprint the Release Sprint. 

The Release Sprint is at the end of the release to move the product from feature complete to releasable, and since most systems aren’t always in a releasable state, I am recommending it as a standard practice – at least for go-live releases. For alpha and beta releases we may release with lesser standards – we must determine that on a case-by-case basis. So, what sorts of things do we do in this release sprint? Let’s just look at the preceding paragraphs and make a list:

  - Exploratory Testing to find what things need to be done – what holes need to be plugged – in order to assure that the system doesn’t blow up, the edge cases are handled, and there isn’t something else going on we don’t want it to do

  - Performance testing (may need to be done in a test lab we don’t own) to find defects and holes to be plugged

  - Interoperality testing (may need to be done in a test lab we don’t own) to find defects and holes to be plugged

  - Plug those holes and fix those defects

  - Finish User Documentation

  - Finish Maintenance Documentation

  - Finish Help Desk Documentation

  - Finish Training Materials

  - Support Marketing and Sales as they finish their documentation and materials

  - Train the Help Desk to support the new system

  - Other stuff – it’s up to you…

I’m pretty sure that this is more than one sprint’s worth of work for most teams, so you’ll have to actually be closer to releasible – at all times – than you really want to be, in order to be ONLY one sprint away from releasable (for example, it is my experience that teams that think they are ready are often 3-6 months away from being releasable). Of course, there is NO ROOM to defer additional work to this sprint – that way lies madness and sure failure! You and your team must realize that the “release” Sprint is NOT about adding functionality, it is not about doing work you deferred, it is only about coming to closure and making the product releasable once it is already feature complete! 

Thanks, Dan  ;-)

  • Share/Bookmark

Dan Rawsthorne product owner , ,

PO is a Person and a Role

April 9th, 2009

There has been a lot of talk lately about the Product Owner, and people are getting quite heated about it. Here’s my take on it.

The Product Owner is the person (not role, person) who is held accountable for the success of the team. He/she is the boss, commander, one throat to choke, MFIC, single wringable neck, Big Cheese, etc. If you want to know who the PO is, just ask management who has the bullseye painted on his/her chest. Period… and that’s all I have to say about that.

Well, maybe not. Because of this unique relationship the ProductOwner has with both management and the team, some things should be obvious. Among these are:

 1. the ProductOwner has the right to be involved in every decision the team makes, and has veto power at all times, and

 2. the team has the obligation to give the ProductOwner all the information needed to make good decisions.

Wait a minute, though. Scrum has 3 roles (roles, not people) defined: ProductOwner, ScrumMaster, and TeamMember. Oh… so we have a person called the ProductOwner, and a role called the ProductOwner. How interesting… could this cause a problem?

Yes. It gets people confused. Don’t be one of them… just follow along. 

On a scrum team there are three sets of responsibilities:

 1. Whats and Whens: What are we building? When do we need it? What does that requirement mean? What provides value to StakeHolders? Etcetera. These are usually called the ProductOwner responsibilities.

 2. Hows and Dos: How do we do it? How do we verify it? Actually Do the work. Etcetera. These are called the Team Member responsibilities.

 3. Team and Process: How does this team work? What is the Process? Facilitation. Etcetera. These are called the ScrumMaster resonsibilities.

Here’s the rub – SELF-ORGANIZING TEAM. People have skills, people don’t play roles. THe scrum team makes up its own rules obout who does what – that’s the essence of the team’s process in scrum. That’s why the PO(person) writes the stories on some teams, and not on others… that’s why the PO(person) does acceptance testing on some teams, and not on others… that’s why the PO(person) does design and architecture on some teams, and not on others… the list goes on and on.

Of course, some organizations have attempted to “processize” the job of the PO(person), so that they all do the same things on the teams within the organization. Other organizations have insisted that just because you do some of the ProductOwner responsibilities, you must BE the ProductOwner. (do you really think an analyst is the “single wringable neck”? I didn’t think so…) It’s your team, it’s your organization, you do what you want to do… This is just my opinion.

But, as far as I’m concerned, here’s all you have to remember about the ProductOwner: 

 - the ProductOwner is the TeamMember who is the “single wringable neck”

 - what the ProductOwner does on the team is based on his/her skills and the needs of the team

 - all ProductOwners are different

Thanks,  Dan  ;-)

  • Share/Bookmark

Dan Rawsthorne product owner , , ,

Make-up Stories

April 9th, 2009

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  ;-)

  • Share/Bookmark

Dan Rawsthorne technical debt , ,

Scrum is Effective, not Efficient

April 9th, 2009

I’d like to rant a little bit on something that I find prevalent in the teams that I coach and in the classes that I teach. When I talk to people about scrum (and agility in general) I invariably hear things like “I’d like my teams to be more efficient,” “we’re using scrum so that will be more efficient,” and of course, “we’ll be more efficient with this process and save some money, right?”

The answer is “no” or “not right away”, and this usually leads to a conversation about effective versus efficient. By definition, effectiveness is “producing a powerful effect”, which in software means that we deliver something useful to the business. Efficiency, on the other hand, is “producing results with little wasted effort” which is a completely different thing, and is a totally non-agile concept.

Now, let’s look at what businesses usually do (Remember that you are what you actually do, not what you say you do). In my experience, most businesses are in the business of “keeping their people busy” rather than in the business of “producing product”. That is, managers get in more trouble for their people “wasting time” than they do for their organizations not producing the right product. This is a shame.

Agility is all about “inspect and adapt” cycles, or feedback. The more feedbacks that you have the more effective you’ll be, but the more effort you’ll be spending. This is inherently inefficient — we are sacrificing efficiency for effectiveness on purpose. In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?

This is where we get phrases like “fail fast, fail early”, which is a way of saying we like to be efficiently agile, by learning our lessons as fast as possible. Okay, I wouldn’t mind being efficiently agile, but I’d much rather be effective than efficient. And, in my view, it doesn’t do any good to even try to be efficient until you already know how to be effective. That is, if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.

To put it quite simply, “waterfall is efficient — agility is effective”, and when we try to be efficiently agile we often wind up introducing false predictability into our process that winds up hurting us in the end.

Enough for now, just my two cents, Dan ;-)

  • Share/Bookmark

admin scrum , , ,

Done Done Done Done

April 9th, 2009

I have worked in software for more than 25 years in many capacities, from coder to product/project manager. I have worked small (3 people working on an e-commerce web site) and large (500 people working on aircraft avionics) projects, and have learned many things about what works and what doesn’t. I’ve worked in small hack it out” companies and big CMM and ISO organizations and have been involved in process improvement in most of them.

At Danube I am a transformation agent I help organizations transform themselves through applications of common sense and agile techniques. My formal training (PhD in mathematics) guides me to look for underlying problems rather than focus on surface symptoms; my military background (retired reserve officer) helps me understand the importance of teamwork and empowerment; and my common sense tells me that change must happen in small manageable bites.

I am a Certified Scrum Trainer with knowledge of many software processes, procedures, and techniques and bring them all to bear on the problems I see. I’m a firm believer in agility, having been introduced to eXtreme Programming (XP) by Kent Beck in 1995, and to scrum by Linda Rising soon after. It was these experiences that led me to move from government consulting to become a coach and consultant.

Lately I’ve been doing a lot of bowling with my daughter, and thinking about large scale agility.

  • Share/Bookmark

Dan Rawsthorne Uncategorized , , ,