cooperation between development team members
When a member of a development team is not cooperating well with other members, is a scrum master responsible for this situation and allowed to remove the member from the team?
I don't think that the Scrum Master is responsible for the situation...however given a Scrum team is a self-managing and collaborative, I think the Scrum Master could have a conversation with the team member to find out what's up and what possible barriers to cooperation exist. Based on the discussion - and what the team member wants, you might get other team members involved to resolve the issue. I would only consider removal if the barriers that exist cannot be resolved.
As I perceived from the definition, the scrum master should (timely) train the development team how to do self organization and how to manage cross functional responsibilities.
The definition gives us a hint how a Scrum Master could possibly handle your concern. He might try to figure out what in hindering for the team member in responding properly or what is hindering him to respond properly. The scum master can try to solve the problem together with the other team members or at least from his experience motivate them to reunion as before but he should not try to remove the team member from the development team.
One more thing, does the Scrum Master selects candidates for the development team? .... I believe NO. Then he should not be the one to remove the team member.
Finally, after all its the game of humans ..... handling with human behavior, misunderstandings, communication gapas will always have solutions :-)
+1 to Jill's and Usman's answers, though the context by the original poster is small. AMoni, if you could tell us more, perhaps we could help you more.
Scrum does not address this particular problem directly, which means that the users of Scrum are expected to come up with their own solution.
The Dev Team is self organizing, so my first questions would be: Has this topic come up in a retro? If so, what was said? If not, why not? Has it come up elsewhere? What was said? How many of the Dev Team feel this way?
If the Dev Team doesn't seem capable of resolving this impediment, then maybe the Scrum Master needs to help get it resolved. However, the Scrum Master only has authority over the Scrum implementation, and removing a team member is not part of the Scrum implementation. Further, by allowing the SM to have this "fire" authority, you will probably be encouraging the team towards a "command and control" approach instead of a self organizing one, so this is almost always a bad idea. The only real authority the SM has here is to make sure that the impediment is removed.
I would conclude, again based on limited context, that the SM is responsible for ensuring that the "impediment" gets removed, but I would expect the SM to facilitate the impediment removal by others, rather than acting upon their own to do so. Further, "removing the impediment" doesn't necessarily mean removing the team member, as Jill mentioned above.
Well said Charles.
AMoni, remember that the Scrum Master serves the Development Team (& PO), while the Development Team serves the Product Owner. That Product Owner has every right to expect the team to resolve their issues. As much as we want to dance around with Development Teams ruling the roost, they had better act like professionals. That PO may just find a new team.
Thanks everybody who gave a reaction. The question is just theoretical. I'm new at scrum and thinking about adopting scrum in our organization.
A lot of questions are entering my mind, like the one I put on the forum. I think scrum doesn't say explicitly something in this matter.
So it is up to the company how to work out these things. However it is the scrum masters' task to remove impediments. Can you speak of an impediment?
Is it the task of a scrum master to inform the management about the undesirable situation, so that management can undertake the necessary steps?
I think your theoretical question was a valid and not uncommon impediment. Did the answers not convey the purpose of the SM role? What is it that you are trying to do with the answers?
I think your example was a great and common one. With regard to your last question - I think the SM would work with the team to get the team to resolve the impediment - either individually or together and not have the manager resolve the impediment. My manager is always saying ....figure it out yourselves....I know you can do it - if we 'forget' and bring things to him to resolve. And I am constantly parroting this to the team....when they bring problems to me. Deep down...I truly believe they can do it, too.
That's not to say that Scrum Master's wouldn't actually resolve it, especially with teams new to self organization. An objective would be to instill the skills necessary to resolve impediments in the team. The best quote I've heard: "Scrum Masters are constantly trying to put themselves out of a job."
I would extend that to leaders as well. Leaders should always be fostering new leaders; transferring their skill and knowledge.
> "Scrum Masters are constantly trying to put themselves out of a job."
I've heard this quote before. My concern is the implication that a Scrum Master is eventually un-needed or unhelpful to a Scrum Team.
I think that the consensus is that the Scrum Master is acting in a facilitation and coaching role. In my experience this tends to be a little more directive during the initial adoption to help the team understand how to work in self organising way.
Over time there is a natural transition to a more coaching and facilitation role - in a similar manner to rubber duck debugging http://en.wikipedia.org/wiki/Rubber_duck_debugging.
That helps with the intellectual aspects - but for the human aspect we often need an unbiased third party to defuse any emotional context. This is where I have seen very effective conflict resolution in Retrospectives and after Daily Scrums, to help the team understand and then resolve the issue.
As such, I would suggest that a scrum master becomes redundant when there are no possible further improvements - which is a highly unlikely scenario!