Manager 2.0 and Scrum: How can I fix the problem where multiple managers are responsible for different scrum team components?

Question

I just read this article, Manager 2.0: The Role of a Manager in Scrum.

I am a scrummaster, and as the teams go, my team is made of both developers and QE. QE has its own manager (I am also the development manager), which essentially means someone else can still assign work for QE in my team.

They can still say what can or cannot be done and in which way. Which means it essentially causes disturbance. Is there a way out? One way I could think of was to have one manager responsible for entire team (Development and QE), but I don't know whether that was the right approach.

How can I fix the problem where multiple managers are responsible for different scrum team components?

Answer 1

People working in teams that work with Scrum should only do work to accomplish their Sprint goals and not be assigned to other work on the side. The manager should consult the Scrum Master or get tasks on the Backlog of the Product Owner first.

In a Agile world managers should be facilitators who make sure his subordinates can work the best they can, skills, motivations, environment, etc... Its not his/her role to assign work, that is of his teams Product Owner during planning sessions for the next itteration.

Have a look at how line management works at Spotify, often the manager is in another team and it is per chapter/role: http://blog.kevingoldsmith.com/2014/03/14/thoughts-on-emulating-spotifys-matrix-organization-in-other-companies/

Answer 2

If i understand your description right, your scrum dev team consists of 2 parts: dev team, and qe team, and each has a manager, who is the ultimate decision maker for their respective teams, and who also has right to assign tasks to their team outside regular Scrum process (backlog, etc). Am i getting it right?

For the task assignment outside of Scrum, it should be avoided if possible. Talk with the QA manager and see if it's possible to follow the regular rules (new tasks should be added to the backlog, go through grooming, planning, and be accepted by the team at the right moment). There may be the case when it is not possible (high priority tasks that need immediate attention). In this case, it is best to track them outside of Scrum, so team's velocity will be decreased because they need to do outside work. This situation, of course, is an impediment, but it can go to impediment log, and retrospectives can be used to find a way to solve it.

For the other part, if the tasks are not evaluated by the team itself, but there are figures of authority who make decisions for their people, it is well against Scrum rules, but it happens most of the time. It reduces team commitment, and maybe precision of estimates too. In order to decrease those harmful effects, you can reinforce the following two things:

• Managers are empowered to make commitments instead of their teams, but then, they are solely responsible for keeping them. So you can replace the democratic team model with a hierarchical one, but they get the whole package, not only the benefits :) However, please be aware that this stretches the methodology so much that it will not be regular Scrum any more.
• You should help managers implement democratic team model at least on their subteam level (discuss decisions before making them, collect input from the team members, etc.)