Scrum master problem

Has the situation been acknowledged yet, such as in a Retrospective? If so, is it recognized by the team as a problem which ought to be solved?

I have the same problem here. The team has a problem with a member of it, but they don't have the balls to say that in the retrospective meeting. only by 1 to 1 if they speak with me and I will stay neutral and will not open this topic at the retro by my self like: other peoples said that you....

I've been dealing with a very similar issue, and I'll just share a version of my story and see if maybe we can help each other?



I'm an individual contributor (Developer) acting as SCRUM master (I know - not good, don't get me started, I had to advocate and petition leadership for 4 months to get someone to act as Product Owner!)



One of our team members has the following attributes:

- He rarely keeps his tasks up to date, most things he works on are not on our JIRA SCRUM board

- He does unplanned work EVERY SPRINT, and somehow this work ends up being "critical" to our entire infrastructure, or one client or another.

- He NEVER completes stories and tasks on time, ever.

- He has 100% control over the whole architecture.

- He has never delivered a single architecture-related artifact for the purpose of communicating to the team UNTIL/unless specifically requested

- When artifacts are delivered the artifact is generally useless to the team.

- He is known for flip-flopping on architecture decisions, and blaming other team members for implementing the flipped solution and for failing to implement the new flop decision when he does so.

- He has lost the trust of the team (because above has happened to everyone on some level).

- He has not demonstrated empathy for the team, and demonstrates restrained defensiveness with the team,

- He is not open to criticism or critique, nor will he allow facts and research to change his mind once he's made a decision, nor will he discuss the conditions for when his mind has changed in a flip-flop scenario - because he won't admit to the flip-flop.

- He has the role of "Senior Architect"

- He is also the CIO, and a founding member of the company.



So, about 6-8 months ago I went into the CEO's office and had a deep discussion about these woes. He seemed receptive, and I heard nothing for some time. Then, about 3-5 weeks after that, I had a follow up meeting. He explained to me that "changes were coming", and within 30 days the COO/CTO stepped in to lead development (while CIO remained on SCRUM team).  I thought we had achieved a measure of success, as this new leaders style was pragmatic, open, honest, and direct.



Now here we're on another 2-4ish months since the change, and old habits are starting to creep back in.  The new Development manager (COO/CTO) has "backed away" from architecture decisions (due to lack of knowledge), and the old oppressive and blocking habits are recurring.



So now, after listening to several books on motivation & habits, I have come to several conclusions:



1) As long as this team member continues to hold a grip over the flow of work (through the secrecy surrounding the architecture design, and exerting power of position), work will not get done in a timely manner.

2) Team morale is in the toilet, and if this team member were to leave every member would simultaneously rejoice, and experience fear and consternation about the knowledge gap.

3) He has become the strongest uniting force (common enemy) on our team that I have experienced during my tenure.

 Any suggestions?

Sometimes you have to let go your best talented people for the longer term goals of the team

What is the team's opinion on the matter? Have they openly expressed their concerns?