I have come across Organizational Constraints that involve a Scrum team where a Project Manager is assigned to the team^1. In traditional scenarios of this kind, the PM often takes on responsibilities that Scrum now assigns to other people on the Scrum team. Strictly speaking, this can be a violation of Scrum if the PM's responsibilities step on those that are now assigned to a Scrum role. However, in all practicality, there are often organizational constraints that are unlikely to change soon. Like all organizational constraints, it's important to create a Mitigating Practice by using "the art of the possible." The responsibility for making sure that this mitigating practice gets put into place is that of the Scrum Master(Why?).

Is There Really a Problem Here?

First it's important to determine if the PM will actually be an organizational constraint placed upon Scrum. There is no "Project Manager" role in Scrum, but there also is no specific restriction in Scrum against having someone who interacts with the Scrum team and has the title of PM. So, the mere interaction of a PM and a Scrum Team is not a violation of Scrum.
The next step to dealing with this potential organizational constraint is to divide up the PM's responsibilities(as seen by the wider organization) into two categories:
  1. Responsibilities that constrain Scrum in some way. (Category 1)
  2. Responsibilities that do not constrain Scrum in some way. (Category 2)

Category 2 Doesn't Really Hurt Scrum

From a Scrum perspective, we don't care about category 2. Examples of possible Category 2 responsibilities might be:
  • Tracking burn rates and other budget figures
  • Reporting team/product/project status to executives or external clients
  • Acquiring supplies for the team
  • Resolving impediments for the team in a "servant leadership" way
  • Trying to increase team morale, again in a "servant leadership" way. Implement team celebrations, give positive praise to the team in the wider organization, etc.
  • Helping the team in any other kind of "servant leadership" way.
  • Dealing with any time reporting issues (again, so long as those don't conflict with Scrum) and other organization administrivia.

Don't get me wrong. There might be times when the above responsibilities might actually conflict with Scrum in some way...That's why I said "...possible category 2..." above. It really depends on the organization and the PM, so a highly Scrum knowledgeable person will need to assess what really falls into Category 1 vs. Category 2.

If a highly Scrum knowledgeable person cannot find any examples of Category 1 responsibilities, then there is no reason to believe having a PM will be a violation of Scrum.

Category 1 Hurts Scrum

Next, we take a look at each PM responsibility that hurts Scrum. Examples of possible Category 1 responsibilities might be:
  • PM performs performance reviews on team members
  • PM is held accountable by the organization for meeting delivery dates, communicating delivery dates, or for quality of features delivered
  • PM assigns tasks to team
  • PM conducts status meetings
  • PM makes scope or feature prioritization decisions
  • PM is responsible for managing delivery risks
  • PM makes decisions or estimates instead of the the team doing this.

Are you noticing a trend? Almost all of these are typical of the "command and control" Project Manager of yesterday, and generally speaking, all of these are a violation of Scrum. I say generally speaking, because there may indeed be cases where these are not violations of Scrum. For instance, if the PM makes feature prioritization decisions, that is fine so long as the PM is also the Product Owner for the team. This person would be very wise, though, to make a distinction about which role they are implementing at any one time. For instance, they can say, "As a PO, I'll inform the stakeholders of the delay in our forecast release date, but as the PM, I'm also going to see how that impacts the project budget." Personally I don't like role sharing at all, and generally don't recommend it, but my point is that there are small exceptions to every generalization. A highly Scrum knowledgeable person can tell the difference between something that harms Scrum and something that doesn't.

But What Do We Do Now?

Now that you've identified the potential harm to Scrum, look to change the constraint.

Ideally, Remove or Minimize the Constraint Via Scrum Education

Ideally, we' like to lift as many Category 1 harms to Scrum as possible. Go the extra mile in educating your organization about the dangers of giving a PM Category 1 responsibilities on a Scrum Team, and explain to them how the organization can still get the operational support they need by utilizing Scrum principles.

For instance, you can explain the the responsibility for forecasting release dates is that of the PO (supported of course by the Scrum Team who actually creates the estimates that the release dates are based on). Then you can explain how a Release Burndown can forecast the likelihood of meeting a release date. You may also need to explain that since quality is always fixed in Scrum (via Definition of Done), we don't sacrifice quality to meet dates. If the organization insists that the PM communicate about release dates to the organization, then ask the organization if it would be ok if the PO calculates the forecasts, but hands them to the PM for reporting up. In this way, you're reducing the constraint to be as small as possible, and by extension, the smallest possible harm to Scrum.

Here is another example. Let's say that the organization expects the PM to handle any risks that might jeopardize delivery dates or delivery of features. The PM figures they can do this by attending the Daily Scrum and Sprint Planning Meetings. It might be good to break this into two mitigating practices. For the Daily Scrum, you can educate the PM that while we do sometimes talk about obstacles in the Daily Scrum, the Daily Scrum is for the Dev Team members only. Having said that, you could tell the PM that they are fully able to be a silent observer to that meeting, but that they need to stand outside the circle while the meeting is going on so as not to give the wrong impression that they are participating in the Scrum. Further, if any obstacles are mentioned that they'd like further info, they are free to talk to the Dev Team members just after the meeting, or any other time for that matter. One place organizations really rely on PM's to manage risk is by dealing with external (to the team) obstacles. To the PM, they are doing their duty to manage risk. To the Scrum Team, one can consider them helping to resolve impediments, and that's never a bad thing in Scrum, so long as the method the PM uses to resolve the impediment doesn't harm the Scrum Implementation. As for the Sprint Planning Meetings, you might just tell the PM to come to those, but be sure that they know that again they are observer. While they probably don't have to be silent at this meeting, they should probably should only comment sparingly. Again, it is quite ok for them to get details of risks or other issues outside of the Sprint Planning Meeting, but generally things of that nature should be taken off-line from that meeting. Also, if they're just checking to see which features will be done in a particular sprint, maybe they can either come to the end of the planning meeting, or just look at the Scrum board the day after the meeting, to know what is being forecast as being done that sprint. I actually coached a PM and Scrum Team this way, and it worked well. Over time, the PM began attending less and less of the Daily Scrums and Planning Meetings because she realized that the team was being responsible about executing the project(self organizing), and because she really wasn't needed very much. She still managed some risks and helped in that area, but she generally didn't interfere with the team because the team appeared to her to be "hitting on all cylinders." She was quite helpful in resolving some impediments, too.

If That Doesn't Work, Create a Mitigating Practice

If you can't





^1- I have come across several flavors of this constraint:

  • PM and Scrum Team work for same company, and stakeholders also within that company.
  • PM and Scrum Team work for same consulting firm, and stakeholders are clients of the consulting firm.
  • PM works for "General Contractor" consulting firm, Scrum Team works for "Sub-contractor" consulting firm, and stakeholders are clients of the general contractor.