The ScrumMaster should not be the ‘people’ manager -1

At Agile Carolinas we recently had a good meeting tonight about the ‘iteration manager’ role that one firm is using.  And with a good discussion of the pros and cons. Many thanks to Ike Eichorn and Brad Ball.

I do not wish to discuss all the ideas raised, but make a few observations about how I see the ScrumMaster being effective.

First, Iteration Manager in the Agile community is often another name for the ScrumMaster. With this firm, the Iteration Manager is an ‘expanded’ role.  It includes ScrumMaster, people manager (here called HR manager), project manager, etc., etc.

 

---

 

First, some people at the organization, maybe many, feel that the new ‘iteration manager’ role is more successful than what they were doing before.

This of course may still be true, even if the ‘iteration manager’ role were seriously sub-optimum.  And I think it is sub-optimum, although to be fair, I am not there, and I do not know what they are really doing, but only what people say and how I hear that.

So, we cannot really talk about the specific situation. We are forced to talk about the principles and other experiences.

 

---

 

Let’s look at three key factors.

1. We need a real team to get real success.

What is a real team? Well, many people do not know, because they have never experienced it and it is true that some sets of real people cannot become a “real team” in the sense that I mean. But, we are strongly convinced that a strong, stable, dedicated team will give the greatest success.  And even better success if it becomes a real team.

A real team is, first, a small team of about seven who, due to a serious challenge, have taken on joint responsibility for a mission.

The team is of course multi-functional, dedicated, and has most of the knowledge domains and skill sets to accomplish the goal. So, while it may be a challenging mission, it is not truly impossible.

Can one have success without a real team? Of course, but it will be a much lower success and, in many situations, one risks outright failure.

The Scrum Team includes the PO and the SM. It is not one person that owns success, but they all do, jointly.

So, if we start to make the SM too powerful, it means that everyone sees that he (or she) is accountable for success — not the team, but one person.

As one example: to foster team responsibility and self-organization within the team, the team must decide how it will decide things.  But normally, with a good team, that decision-making process should not be ‘ask the SM, and let him decide everything’… or anything close to that.

2. We want the team to self-organize, self-manage and self-direct.

There is something magical in this. It is hard to explain, and the team never self-organizes perfectly, but we find that if decent or better teams self-organize, self-direct and self-manage, they can perform miracles.

Again, the self-organization is unlikely to be the same if one person is clearly more powerful.

And the SM is ‘making’ the self-organization happen. It is a funny sentence, because it is almost like saying: I will make you free. Still, the SM is enabling self-organization.  Or should be doing that.

The SM is mainly a servant leader. One way of saying it: he does not tell the team what to do, but helps the team fulfill its potential (e.g., by removing impediments). So, if the SM has many roles, he is unlikely to be performing his role as impediment remover in chief.  It is this role of removing impediments that makes the SM effective, makes the team more effective, and is key to real success, to the highest levels of success. For, by removing impediments, the SM can enable the team to double and triple their productivity without the team working any more hours, or working harder (from a ‘too stressed out’ perspective).

3. The SM is responsible for greater transparency.

In most or maybe all companies, there is a conspiracy of silence. An agreement to ignore many things. Often this has to do with the biggest impediments, which might be people issues.

One of the roles of the SM is to help the team see its biggest impediments and then see that these can be mitigated or eliminated.

One of the key problems having the SM as the people manager is that the person can no longer increase transparency. In fact, due to power issues, one can be pretty sure that that person (or that role) is decreasing transparency. Things that might be mentioned in the Daily Scrum, for example, will not be said.

It is hard to notice what is not said. It does not always mean that suddenly everything is obviously opaque, just that things are not becoming more and more transparent.

 

---

 

Can it be that some of these effects will not happen or will be minor? Well, experience shows that people will not notice. It is certainly true that for some teams power issues are more clearly pronounced than in other teams. We suspect mainly due to the character of the people. Still, this does not mean the effects are not important.

So, if the effects are not visible, does that mean the negative effects are not there? No, that is not proof.

Can it be, again, that even though these negative effects are there and substantial, can it be that still this approach is better than what they were doing before? Yes, I believe experience shows that it can, sadly, be better than what they were doing before. (Ex: They were doingh regular waterfall before — easy to beat that.)  Yes, to have an expanded iteration manager role may be better than a having waterfall and all that stuff.

Now, let us assume that we still disagree: that some people still believe that ‘the expanded iteration manager’ is better than a ‘true’ SM. If that is the case, the best way to prove one or the other of the hypotheses is to do tests, and get real evidence. To be fair, several tests will need to be done. It will take some time and some work, but the difference is worth knowing about.

There is much more to say on this topic area, but enough for today.

Your comments and observations, please.

 

« « The Organzation of our Scrum course – 1 || The Organization of the Scrum Course – 2 » »