Scrum Masters and Scrum Board Ownership
I am noticing a trend around where Scrum Masters are taking it upon themselves to change the function/layout of the scrum boards - both online and physical boards. They don't bother to ask the teams what they think or if they WANT to change the boards, they just do it.
My thought is that the team owns the boards and stories, so it is not up to me to decide how they use it. I can certainly give recommendations and coaching as to why I think something might work better than something else. But I don't see it as my place to push something on the team without their consent.
What do you think?
As a Scrum Master, your job is to make sure the team has the needed tools to accomplish their job effectively. Scrum, as it's written, doesn't allow the Scrum Master to push something onto a team and force them to adopt new tools. They are a servant leader, not a manager. And there's a good reason for this. If you take the board (are you referring to Kanban?) and change it around, how can you be sure that you're adding value and not just slowing things down? It might help to ask yourself two questions:
- Who determines what adds the most value to the process?
- Are these changes a necessary part of the Definition of Done agreed upon by the team?
Personally I think you're correct. If the Product Owner is satisfied with the delivered increments, and the Development Team isn't experiencing delays or problems, then why make changes for the sake of changes? Suggestions are always welcome, as is encouragement, but the ultimate focus of Scrum on delivered value.
It is true that Scrum Masters should refrain from command/control behavior, and not try to "push" anything to the team or organization. I would say though that while the Development Team owns the sprint backlog, and the Product Owner owns the product backlog, I'm not sure that either role owns the actual boards (electronic, physical) that they are represented on. This may fall to a more organizational tool/standard being utilized as opposed to the Scrum Team's preference.
That said, a key item in the Empirical Process is around Transparency, and an important focus for the Scrum Master is around effective communication and use of information radiators. In that regard, the Scrum Master should speak up and make improvement suggestions (along with observations and reasons) whenever they see something in the way electronic/physical boards are used that could be improved upon.
Have you asked those Scrum Masters about this behavior you have noticed?
What explanation do they give for it?
I haven't asked them yet. I guess I was sort of "making sure" that my mind was in the right place for the teams.
A coach brought up the idea of how one team was using a board, and the scrum master decided it was better, so she changed the physical board without consulting the team or taking input. I am in the process of turning this team over to her as a new scrum master, and some things just don't stick when I try to explain that the team makes the decisions in how things work.
I did set up the scrum boards - after talking with the team to get a sense of what they felt they needed and then we talked about it again after it was set up. She made the change and then gave it to them. No explanation other than "this is how we are going to do it, and this is how it works". I also will print off the cards for the physical board after the sprint goal is set, as well as anything in the backlog that is "ready".
One of the team members talked to me about the online scrum board and how he doesn't like the way it is laid out now. It's too spread out and not easy to use. But it is a change the new scrum master made to the board without checking in with the team first.
How much experience does this person have with the Scrum Master role? What is their background?
Based on your version of events, this person is exhibiting command/control behavior, which really does not have a place in Scrum. You are right in identifying this behavior as non-collaborative and anti-Scrum, and making it as visible as possible.