The ScrumMaster should not be a people manager – 2
This is a continuation of this post.
Before we start, some more basics…
1. The PO has an important role.
Especially key in deciding which PBIs or user stories the team will get next, and important in many other ways, too.
2. The ScrumMaster has a key responsibility in making the ‘continuous improvement’ engine work in Scrum, and for the team.
This is so important, and so seldom does it really happen.
3. Each team is different, each SM is different.
So, while we can describe the SM (or any role) based on the ‘normal desirable’ state, we must also deal with people or groups that are different, or unusual, SMs. These are NOT included in this overall discussion, but are always something we must deal with, sooner or later.
4. Scrum is not the only way.
It is about the only way I advise, for many reasons, and there are some caveats, but that assertion is too much to discuss here and now. So, even though something else may work or ‘be better than we were before,’ that does not mean one should not have done ‘real Scrum’ and have been yet better than that alternative. (Which is what I think you will find, if you test.)
Still, one can do something else, and maybe often get somewhat better results than you had before.
But the question should be: could we have gotten even better results with a different approach?
And, to the degree you are not doing ‘full Scrum,’ I am suggesting trying full Scrum first, or as soon as possible, and seeing if the results are not even better.
So, here are some issues:
A. The PO role is important, and the SM role should not challenge it.
It is true to say that the SM is a kind of leader in the team. The PO is a different kind of leader, but it does not help if the SM challenges the PO in the PO domain. (I will call that domain: deciding which work is most important).
The SM often must teach the PO how to be a good PO, sometimes by helping him for a time, but this is not taking over the PO job permanently.
B. The SM must get the team to own the success.
Talking as though the SM owns success is not going to help. As soon as the SM gets very powerful, compared to the other team members, it is not likely to be good.
In my opinion, as soon as you say the SM is responsible for success, everyone else in the team drops down some in motivation and energy, and self-organization is not happening as well anymore. Sometimes this is very subtle. Sometimes it is ‘seen’ in the lack of increased productivity that we would have seen if they had continued to self-organize.
Just asking the team (‘do you own success?’) is not sufficient, especially if they know that the ‘right’ answer is yes.
C. The SM must get the team to self-organize.
We have said this before. The point now is, this is difficult, and almost on a knife’s edge. If the SM moves much away from the servant leader, it is very likely that this will inhibit the self-organization of the team.
Again, the change can be subtle, and people may barely perceive it at first and not talk about it. If the SM pushes the team, it may be mainly seen in the lack of improvement in productivity in the Team, rather than a clear decrease in productivity.
D. The team needs transparency.
The team must self-organize, self-direct and self-control itself. (Outside people can have some role and some influence. More on that in a later post.) To do that, the team (that is, each of its members) needs to know where it is. The facts need to be transparent, or more transparent, to enable the team to use that information to self-organize more usefully, to make better decisions based on better information.
It is the SM who must foster transparency. It is human nature to want to hide things. So, the SM should be making it OK to tell more of the truth.
Again, the trendline on transparency is subtle. It is usually either getting better or worse, but is hard to identify the things that are not said, simply because they were not said. People like to pretend they are very honest and open with each, and yet that is not really always the truth. We know this without consulting Dr. Freud’s ideas about the unconscious mind.
So, if the SM has power over the team, especially all the team, as the one who gives them reviews and compensation increases, then we should expect reduced transparency, and yet, the SM will never know that the transparency is reduced. If the team kind of likes him, they typically will never say ‘I am not telling you everything.’ Often, they will not even admit to themselves they are withholding information, and yet that is happening.
We think there are a few people who will say almost anything to almost anyone — that is true — and if their ‘boss’ is the SM, they will still say (almost?) everything to him (or her). But we think these people are fewer than some of us want to think, and even then these ‘brave’ people are not quite as brave as they say, in our opinion.
Hence, we never advocate that the boss become the SM — never. It might work, but we do not advocate it.
E. The SM is essential to continuous improvement.
Even 100% dedicated SMs often ‘slack off’ in driving that impediments are being fixed every day.
If we give George additional roles, George is even more likely to not devote enough attention to impediments.
Impediments are all the things we can work on to become better, to improve, and semi-naturally the team will address really key impediments, e.g., the system is down. But often they ignore impediments and focus on real work (as they call it).
So, the SM is key in making sure someone is working on the top impediment now. Hence, the team does not improve nearly as much as it could have.
Can a team improve without an SM? Yes, just in the fine art of working better together, a team can get noticeable improvement, and this can happen almost as if by magic. But to get real continuous improvement, and start to get more of that faster, you must have a full time SM.
Can we live without doing all these things?
Well, certainly. We did not die even though most of us a few years ago did not even know about Scrum.
Let me give one concrete example.
You have a person, George, who is the boss of the team. You look at the team, and there is no one who would be a good SM. You talk to George, and discover that in most respects George would be a good SM, but he is the boss of the team. You look at the relationships between George and the team members, and you find that George is an ‘open’ manager, that his team, by most standards, is very open with him.
Well, in this case, because there are so few options, it may be best to let George be the SM. It is not the preferred state, and it should be fixed later, but one judges that it is probably the least bad of several options, at least for now.
But, this would never lead us to recommend that the boss become the SM. We might live with it as an accommodation to ‘today’s realities,’ but we are not happy with that part of the situation. Of course, we might be a lot less happy with other, bigger problems.
Broader suggestions. The SM must act on the following:
- The ‘rules’ of Scrum are not as well known as we would like.
- You may be forced to break the rules of Scrum, but try to do so knowingly, rather than without any thought.
- Try to measure or in some other ‘open’ way, identify your team’s biggest problems, and then do something about them.
- If breaking some of the rules of Scrum turns out to be a big problem, identify that, and fix it soon if it is a priority.