What should I do as a Scrum Master in this scenario ?
We are working in client-vendor model where the whole organization are divided into squads( spotify Agile ) including the client ( internal ) also have their squads.And there are chapter leads and Tribe Leads from the client. There was an incident in one team like one member of the team has been removed from one team due to some misunderstanding. The incident happened as below :
(1) Chapter Leads are generally responsible to check the code for each team and give approval to merge it to GIT ( CI/CD ), since the request will always have an owner, that guy has raised that request on behalf of his team but the request was not good and it had a bad impact on approvers against that guy although the whole code is not done by him , it was done by 3-4 members from his team.
(2) Then there was a meeting with scrum master along with the Leads from client to escalate this and scrum master took the ownership to resolve this but he didn't try to break the wall between the leads and his team member, as a result of it, although he tried to protect his team member (by avoiding to create any request by him) , the lead's mindset for him has not been changed, hence they removed him from the team without any discussion or confirmation from the team.
(3) That guy was creating value for the team, now the team is facing problems without him but they have to agree with the decision of the client organization.
Is this a proper way to move someone from one team and what should the Scrum Master do in such condition ?
There is no “Lead” role in Scrum. Might the situation you describe indicate just one of the risks inherent with such a position?
@Ian Mitchel
It is a scaled scrum, as I told it is spotify agile and lead indicates chapter lead and tribe leads.
But the question is what should a scrum master do in this case while the client or stakeholders want to remove one member from his dev team although that member is creating values for the team ?
here the whole organization are divided into squads( spotify Agile )
Based on your descriptions it doesn't sound like you are doing a spotify model. For example, Chapters are formed around people that have similar skills and interests. They are formed cross squads and do not have to encompass all squads. Chapter Leads are similar to a line manager and are responsible for the salary, career development and so on. They are part of one squad and participates in the day-to-day work of that squad. But they are not responsible "to check the code for each team and give approval to merge it to GIT ( CI/CD )". Add to that the statement "since the request will always have an owner," also points to individual over team. In my opinion that is very anti-agile as it shows one person gating the activities of multiple self-organizing, self-managing teams.
The entire scenario you described is very command-control where 1 or more "management" entities decided something and then forced it upon a team. If you are doing agile, the team would have been involved in the decision and again based on your description the outcome would have been entirely different.
Is this a proper way to move someone from one team and what should the Scrum Master do in such condition ?
The "proper way" can only be determined by the team/squad in a true agile organization. Self-managed, self-organizing teams are empowered to take these matters into their own hands. It may require involvement from a manager (Chapter Leads in the published Spotify model) or HR representative but the entire team should be involved in coming to a decision. What should a Scrum Master do in such condition? In the published Spotify model there are no Scrum Master and instead Agile Coaches are used. The Agile Coach is focused on helping the team evolve and improve the way that they work. In this case, the Agile Coach should be focusing the team, and I would add the management organization, in how they can improve the way themselves in relation to agile practices.
It is pretty apparent that your organization has created their own form of agile. So our contributions are going to be based on the short situation you provided. In the end, none of us can tell you what to do. You will have to work this out within your own organization and it will most likely require someone to initiate some difficult conversations.
@Daniel
Thanks a lot, it is pretty much explanatory.