The Greedy Manager

Agile Team challenge 1 - How to deal with a manager that doesn’t follow the agile ways

In my previous article, I’ve described, from my own and colleagues’ experience, five common challenges that Scrum Masters and Agile Coaches face on a regular basis in everyday customer environments. Over the coming weeks, I’ll be handling one challenge at a time, starting today.

No doubt, you recognize the following common challenge from your own work environment.

While the team is working on the sprint, a manager storms in, rushes to the desk of one team member and demands that the team member quickly arranges something for the manager.

This sort of event happens mostly in organizations that are quite new to an agile way of working, but certainly not exclusively. 

The question that the Scrum Master or Agile Coach faces, is, how does the team respond to this greedy interruption? Taking the roles of Product Owner, Scrum Master, and development team member into account, what would we want each role to act like, and how do you coach them to do so?

In an environment that has just started to switch from a traditional to a more agile way of working, you are likely to see a developer quietly discussing what is needed with the manager, while the rest of the team turns their heads towards their screens again, including the Product Owner and Scrum Master.

The consequences would be that the manager might actually get what was asked for, but not per se, and that the team gets in trouble for not being able to make the sprint, depending on how much time the involuntary intermezzo has taken in the end.

If this happens on an irregular basis, it will have a negative effect on each of the sprints it occurs in, and on the mood and way of working of the team in the long run. 

Even worse, if it happens on a regular basis, for instance in each sprint, things might not change at all. An inexperienced team might see the managers’ behavior as business as usual and let it slip each and every time, perhaps even reserving time in each sprint for such “unexpected” events, that just happen to occur each sprint. This might seem like a good situation, where the manager gets their wishes met, and the team expects work from outside their sprint backlog, and are therefore content with knowing upfront. The Product Owner and the stakeholders, however, should not be so happy, since the work done by the team each sprint is not just the work that delivers the most value for the business anymore, it’s also specific work for the manager that might not be so valuable in the bigger picture of the entire organization.

What we would like to see, is a team focusing on a short list of work that will presumably deliver the most value for the organization, at this particular time. Shortly after completion, the value will be checked through receiving feedback from the people who actually use what was delivered. What exactly will presumably deliver the most value will be assessed through the person of the Product Owner, with the help of stakeholders and the rest of the Scrum Team.

If a certain manager would like to have someone in particular from a team do something solely for that managers’ own agenda, the Product Owner should be the first to object.

Any claim on one team member is a claim on the team as a whole. And since the team should focus on delivering the most valuable, any claim on the team is a claim on what is most valuable to the organization. 

If the Product Owner is not that experienced yet and shies away from confronting the covetous manager, the Scrum Master should be there, right by their side, to help the Product Owner intervene. Sometimes, overly assertive Scrum Masters will jump right in, physically even, to tell the unruly manager off, citing the Scrum Guide as if quoting the scriptures from the pulpit. This might, I stress, might, work on that single occasion, but is not the right solution in the long run. Firstly, if faced with a truly rapacious boss, they will pull their trump card, namely, organizational hierarchy, to rebut the stout intervention of the ambitious Scrum Master. Secondly, if not straight away, the manager will certainly go around the Scrum Master at a later time or date. 

What the Scrum Master should do, is to help the Product Owner intervene. It could be done by simply asking out loud, really loud, if the Product Owner is okay with his team member being addressed solo. You can do this with a gentle smile and mild manners, but without a trace of doubt as to your intentions nonetheless. If the Product Owner doesn’t own up to their role, then a little chat afterward between the Scrum Master and Product Owner is due, so that the next time, the Product Owner steps up to protect that which is most valuable to the organization.

The Scrum Master, however, has some more talking to do. What you would really like to see, is the team member and their colleagues dismissing the grasping manager right from the getgo, and deferring the manager to their Product Owner, perhaps even shortly explaining that they are working on more valuable work for the organization. Appealing to the team spirit will certainly help in such situations.

The elephant in the room should also be addressed. Thus, the Scrum Master, perhaps even together with the Product Owner, should speak with the interrupting manager directly, face-to-face, explaining that the Product Owner would love to help the manager with their wishes. The manager, like everyone else, has only three things to take into account. For one, the acknowledgment that the Product Owner, and the Product Owner alone, has the organizational mandate to assess what is the most valuable to be realized by the team at any given time. Also, that the Product Owner will consult with both his team and stakeholders about what is to be realized. And lastly, that the manager is free to be a stakeholder in this process, thus gaining a warranted influence on what the team will actually realize.

If the conversation with the manager in question halts at the acknowledgment of the organizational mandate, you know you have your work ahead of you as a Scrum Master or Agile Coach. Hopefully, instead, the manager will have some questions around the process, lengthy from their point of view, no doubt. At least you will have something to talk about. The argument of delivering what is the most valuable to the organization can hardly be trumped, unless by willful ignorance or sheer stubbornness.

In coming articles, we’ll explore the different options a Scrum Master or Agile Coach has, to deal with the four other common Agile Team challenges, one at a time…