Scrummaster's pitfalls

During these years I've noticed that many scrummasters are falling in the same pitfalls (and well, I've fallen in some of those too). In my opinion those are the potentially most dangerous for the team:

Scrummaster committing to the sprint backlog
When a scrummaster commits to the sprint backlog he/she starts having a dual role: scrummaster and team member. The team then might get confused and start misunderstanding things said as scrummaster as things said by the team member and viceversa. Two things then might happen:
1. Team starts doing blindly whatever the scrummaster says, even in matters that the team should decide by itself. In that scenario the scrummaster becomes the biggest team's bottleneck, as all the decisions will pass through him/her.
2. Team stops listening to the scrummaster, making almost impossible to him/her coaching the team.
There's one easy trick that might help in this situation: having the scrummaster wearing 2 different hats: one when he/she's acting scrummaster and one when he/she's team member. This would make visible which role he/she's playing, but on the other end I think it's better not to have the scrummaster as team member at all.

Scrummaster telling the team what to do instead of coaching
This happens many times when the scrummaster is a former project manager, but not only in that situation. Also in this case the effect is that the team might become completely dependent on its scrummaster (who will then be the team's bottleneck).
I've fallen in this pitfall too. At that time I was scrummastering a quite joung team who had just put their first made product to production. A bug has been found in that product affecting their customers so the team started investigating it. As many young teams would do they started trying out things without any structure, running many different (manual) tests in production and not getting any result. After half an hour of that I stood up, blocked all the work they were doing and started telling them how to proceed (I had the most test-oriented person testing in production, the most senior developer checking the code and the rest of the team trying to reproduce it in a staging environment). The problem has been found and fixed, but the team didn't learn how to investigate things and had the feeling that whenever there's an emergency situation I tell them what to do. What I should have done in that case was to start challenging them by asking questions that could have made them realizing they were proceeding in the wrong way (usually asking "why?" is a good starting point for that). On a side note, this is still an argument of discussion between me and the team's product owner, who thinks I made the right thing (but then again, in his point of view fixing the product was the top priority while in mine making the team growing should have been the right one).

Scrummaster acting as proxy between the team and the product owner
This is a sneaky pitfall, luckily not that common (or at least I haven't seen it only once) but really distructive for the team. What I've seen started with a team having a product owner knowing exactly what he wants but not having so much time to spend with the team, as in that organization the person acting product owner has a lot of other things to do. Because of that lack of time he started delegating to the scrummaster things like "this is not what I want, tell the team that what I want is that" and such. Eventually the team, who already was in a conflicting situation with their product owner (as their product vision is different than the product owner's one) is now seeing the scrummaster as "the other side" in that conflict. That situation is still ongoing so I can't tell how it ended, but if I would be that team's scrummaster what I would do is offer the team to step down and have one of them replacing me in that role.


I'll go on talking about this topic in the future, stay posted ;)