How to deal with power mad dev team Line managers who are part of developer scrum teams controlling everyone
On a recent project I was running three scrum teams at once, I coached them on agile & Jira, coached stakeholders as well & we saw great improvements in velocity, transparency, value delivery & trust. These teams had three levels of line management in it before I started but things still went well.
An external dev team that was experiencing issues then joined one of the teams I was running. This external team included two line managers who were very disruptive, they were not even using story points, they didn’t know how to play planing poker, even though I asked them not to the managers continued to control the flow of work and assigned tasks to people.
I tried talking to them privately explaining why we needed to but they went over my head and continued the disruption.
Eventually another external project crashed and released internal scrum masters & i as a contractor had to train one fo do my role.
anyone else had similar experiences?
Advice?
I sympathize with your situation. I have some experience of something similar.
My first advice would be to be humble and separate the genuine concerns and professional opinions of the line managers from the behaviour which you have observed.
I say this because I don't agree with some of your assertions, and that's because even though I think they're based on some good intentions and principles, they're subjective, and not necessarily supported by empirical evidence, or the members of your teams or organization: The need to use story points, for example.
I think you will waste a lot of time and energy if you try to fight such battles when there appears to be a much more critical issue: why is anyone assigning tasks to the team members? It might be well intentioned, but it flies in the face of a self-organizing team.
On that point, I'm also interested to know what you mean when you say you were running the teams?
anyone else had similar experiences?
All the time. My advice is to focus on transparency first, and to make problems visible along with their effects on value delivery. The appetite for organizational change can then be gauged.
To further emphasize Simon's point, as a Scrum Master I have never run a Scrum Team in my life.
I'm a bit unorthodox on this one. Yeah, I've been in the same situation more times than I care to think. Command-control management is not something foreign to anyone that has tried to help an organization transition to agile methods. My unorthodox approach is ... let them control and make it transparent who was "in charge" when ever any pain is felt. I'm not advocating "I told you so". I'm saying that when problems arise, make sure that they are discussed, root cause analysis undertaken, and credit given where it is due. Then help the team determine how to make it better. When you get the team of developers coming together to push back on the manager, it can have some real impact. Coach everyone on how making decisions in the moment can be beneficial. Coach everyone on how letting individuals be accountable for their own work is a good thing.
Pain is a pretty powerful motivator and when things are failing there is pain. @Ian Mitchell's advice is good and much more eloquently said.
This external team included two line managers who were very disruptive, they were not even using story points, they didn’t know how to play planing poker, even though I asked them not to the managers continued to control the flow of work and assigned tasks to people.
I will say that the above paragraph really left me unsettled. Your assumption that story points and planning poker is part of a successful team is flawed. I have worked with teams that did not use story points. A couple used t-shirt sizes and others didn't use any kind of point system at all. Estimates do not have to be done by story points and in truth story points can be a problem for a lot of teams/organizations as they try to use them formulatic and as indicators of succcess/failure. The only problem I see in your statement is that they assign tasks.
Since you say that this is an "external team" I find it interesting that you seem to think you can control how they work, especially since you are a Scrum Master and there is no control in the equation. Based on your statements I see you as being as much a problem as they are since you are trying to dictate how they organize and work. Is there a contractual agreement with the external company that they will do everything exactly as they are told or are they contracted to deliver product? And if they are contractually obligated to work as told how is that agile in anyway?
As @Ian Mitchell and @Simon Mayer stated, I have never run an agile team regardless of how they chose to organize. I have never known a Scrum Master to run a team. I have never known any servant-leader to run teams. I have run teams as a command-control manager. I have known a lot of people that have run teams as command-control managers. But in those cases we never claimed to be agile.