... The organization has committed to adopting Scrum, and is now transitioning to Scrum. But Scrum is considerably different than traditional organizations, and people used to the old culture, particularly managers, are now trying to find their place in the new culture.
✥ ✥ ✥
The manager keeps meddling in the affairs of the Scrum team, distracting the team, and generally making a nuisance of himself or herself. In extreme cases, the manager might even take on technical work, or tell the team how to do their job.
The root of this problem is usually that management are unsure of their role and their responsibilities. They hear "self-organization" and think they have no place.
People want to contribute, but managers are in a difficult position. As supporters (see below), they contribute only indirectly to the success of the team, yet this is hard for many to do – to succeed only through others’ success. Therefore, some managers try to contribute directly to the team, doing technical work for example. But this disrupts the team.
In many companies, managers become managers by being promoted from technical positions. In other words, they likely excelled in technical work, but they are now doing non-technical work. They may not be suited for it, so they may try to return to what they are good at – doing technical work.
If the manager has personnel responsibilities over the team members (e.g., performance evaluations or raises), having the manager work side-by-side with the developers creates strained relationships, and tends to put trust in jeopardy. (See Community of Trust [Coplien and Harrison]).
Managers who have feel a loss of control or career opportunities might react by sabotaging self organization. They don't necessarily do this out of malice, but most often out a feeling of self-preservation.
Note that this problem is a special case of the larger problem of identifying roles and responsibilities in the new organization. Everyone has to learn what their new roles and responsibilities are. Roles such as developers are relatively easy: they still are developers. But the manager role is particularly difficult, because their role changes dramatically, and may even seem superfluous. In particular, traditional managers are used to a command and control culture, and the culture of self-organization is foreign to them. Thus the managers have special problems in making this shift.
True story from one of the authors: “I was once debugging my code in the lab. My boss came up behind me and watched over my shoulder for a while. Finally, he couldn’t stand it any longer, and said ‘Let me drive.’ He took over debugging my code.”
Help the manager shift to their new role by giving them the work they do in their new role. Focus management on their level or responsibility, rather than the details, the things that can move the whole organization further ahead.
The goal is to help the manager become a team member and know how they are a productive member of this new team structure. Thus the activities below focus not only on helping the manager understand what to do, but also on preserving the manager's dignity.
It is important that they receive real work, not made-up tasks to keep them busy. They will see through that in an instant. One way to do this is to provide the manager with a list of impediments that the team cannot resolve themselves; an impediment backlog.
It’s important to approach the manager in the right way. Don’t tell the manager what to do, instead ask for help to remove the impediments. It helps maintain the mutually supportive relationship that is necessary in any healthy organization. For example, give a list of impediments (to go on the impediment backlog) and that will give the manager things to do that are useful, and keep them from doing things that get in your way. This may include helping the manager order the problems to solve.
You (the team) focus the manager on the most important work and keep the manager working on the things they should be doing that they don’t have time to meddle in things they shouldn't.
It is also important to make sure that the manager knows what is going on in the organization (transparency and sharing information.) Of course, everyone should have information, but you might have to give special attention to the manager. The reason is that the manager is used to having a lot of information, and without it may not make realistic requests.
A manager is a supporter role, rather than a producer role; for more information about it, see Producer Roles [Coplien and Harrison].
A manager is most effective when he or she fills the role of Firewall (see [Coplien and Harrison, “Organizational Patterns of Agile Software Development.”] This pattern helps them fill this role, and can be especially helpful when the manager doesn’t understand the Firewall role.
True story: A team was complaining about their manager who wasn't removing impediments for them. I asked if the manager knew what the impediments were and they said they assumed he did. I had the team write the impediments on fluorescent postit notes with the work "Block" in bold at the top, and took them to the manager. As he wasn't there I plastered them around his monitor so he couldn't miss them. Half an hour later he called out looking for me. He came up and asked if these were blockers from the team. I responded Yes, and he smiled saying it was great as he now knew what he needed to be working on."
✥ ✥ ✥
The chief result should be that the manager now fits into the team, and the team's stability over time increases.
Over time, the manager figures out how to be most effective, and begins to handle the impediment backlog proactively.
This is a transitional pattern: over time, the team will use this pattern less and less, and eventually will not have the need for it at all. In fact, the manager role will diminish, and eventually should go away altogether.
Note that this pattern is very similar to Product Owner Trainer. There are some key differences. The main difference is that the manager is shifting to a new role, and needs to understand how to be of value to the team. The new role might well be to a Product Owner, but could possibly be to a ScrumMaster or even perhaps to a development team member (or maybe the organization retains managers in some sort of hybrid role.) On the other hand, the relationship between the Product Owner and the development team is special and very well defined. The Product Owner Trainer pattern focuses on that special relationship.