Command and control manager

Off the top of my head, it seems to boil down to a basic level of trust.   Why doesn't this manager trust the teams developing the product for him?

Maybe an experiment is in order.   See if the manager is receptive to a hands-off approach for 1-2 sprints to see the results.   At worst, the team will still produce something to move closer to the manager's product vision.   At best, the team will exceed the manager's expectations, and it could be a turning point for that manager's Agile maturity.

"See if the manager is receptive to a hands-off approach" - can you please elaborate a bit on what do you mean by that? 

I believe the main reason is not to feel lose of control. I understand that it is hard for someone that uses the command and control approach for 15 years to change his approach in one day. On the other hand, as internal agile coach, I need to "protect" the agile team from abuse. 

Given that the team exhibited a high level of self-organization and agile maturity beforehand, why are they allowing command-and-control now? No-one can force it on them and presumably they must know that.

Is there still really a team at all, or do these new arrivals effectively constitute a sub-team with their own non-agile management arrangements?

The mature agile team resists to a command-and-control approach, and I trust them to stay on guard on that aspect. However, the 4 new Scrum team members are highly affected by command-and-control, since he is their line manager. Those 4 people are his entire team. 

Now we get to the question what the role is for a line-manager in the agile world. I believe there is a lot of room for a manager in the agile world, in the form of servant leadership - be an "help desk" to your team, look for their development grows, help them resolve none-Scrum dilemmas (personal, etc), coach them to be a better version of themselves, communicate organizational news to them. 

What do you think? 

"See if the manager is receptive to a hands-off approach" - can you please elaborate a bit on what do you mean by that? 

You've observed a command & control issue with this manager, wanting to not only direct the team in what to do, but also in how to do it.   You tried unsuccessfully to educate the manager on the importance of team self-management.

I would be curious to hear his response when asked why he doesn't trust the team, or why he feels everything needs to be funneled through him.   Does he realize that his insistence on controlling the team actually creates a vulnerability and doesn't make the process healthier?   What is his recourse for the team/product if he were unavailable for any reason (illness, vacation, capacity, etc)?

Along these lines, I would see if he were receptive to focusing only on the "what" (i.e. - Product Owner refinement with the team), and to give the team freedom to figure out the "how".   That is what I meant by a "hands-off" approach.

Certainly, he must be aware that the team members are highly-compensated and highly-skilled.   Why would he want to reduce them to mere order-takers?   Why would he not want to seek ways to leverage their abilities?

I believe there is a lot of room for a manager in the agile world, in the form of servant leadership

Every manager ought to be a servant-leader. However each agile team must recognize and address its own problems, and it sounds as though a sub-team has been allowed to form which looks for external management instruction. That's something which the team has to get a grip on, as it will have an impact on the ability to make team-based commitments, to self-manage the flow of work, and many other practices. This issue should be tackled openly and decisively no later than the next Sprint Retrospective.

This issue should be tackled openly and decisively no later than the next Sprint Retrospective.

The extra 4 team members didn't have the chance to join yet (they would next week). It was raised in the retrospective we had today by the reduced team - they are ready to tackle that from their side. I will back them up when they need me. 

Why would he want to reduce them to mere order-takers?   Why would he not want to seek ways to leverage their abilities?

The team is in ramp up phase on a new product and new technology (the entire team - the current team and the 4 new ones). When I ask him why he needs to be in the meetings, he told me he must know everything now and that he has valuable knowledge and therefore he is a key person. He also has an upcoming visit of his boss on site in 2 weeks and I think he wants to be part of every discussion in order to acquire sufficient knowledge to answer his boss's questions. He also looks for reports on progress and maybe think the team is not moving forward fast enough.  

I suggested that if he has valuable knowledge, we can do a session where he transfer the knowledge to the team. I also mentioned that if he needs to know the high level of the architecture/modules (for having enough information in other architecture/roadmap/boss discussions) we can arrange a session where the team presents that to him and any other stack-holders. He wasn't pleased with that so far. I guess this is a transition he needs to go through. Maybe once he will start getting push back from the team itself (rather then me), he will change his approach. 

Why can't you have him participate in refinements? You would just need to make sure he gives information, but not makes decision individually. And as a stakeholder, obviously, in Sprint Reviews.

I have defined him as a stakeholder and the Scrum Product Owner works with him closely on the backlog. Still, he wants to get involved. I guess you can't really change a mindset in one day, no matter how much talking you invest into it. 

I wanted to update you on the progress of this case. We got to the point where the Scrum team pushed back the manager's command and control approach and things started to hit up (the team pushed back, and the manager tried to force command and control).

My approach is 'people first' and therefore I stopped it - the manager and I set down together for a conversation. There were 2 options on the table:

1. Split the team. The manager's people will be a separated "Scrum" team. 

2. Continue together, but in agile spirit. 

I recommend to the manager to take #1, since I don't want to force Agile on anyone and since I think that he would feel better with continuing with command and control approach. The communication on the engineering level would continue (as communication between 2 Scrum teams). The manager won't approach the original Scrum team, but only through the PO. 

After a week, an amazing thing happened. The manager started to read about agile and requested option #2. My conclusion from this incident is that you can't (and shouldn't) force Agile on a manager. The manager should want it and make the first step toward agile. Once the manager did the first step, a great journey can begin. 

Now my job is navigate through this journey. Thanks for your comments and reaplies. Cheers! 

One of my favorite sayings working as an Agile change agent is "you can lead a horse to water, but you can't make him drink".   You can try educating, instructing, and guiding others, but so often people will only respond in their own time.   

I've put many "suggestions" on the shelf until a specific pain point occurs that is a result of current practices, and only then were they willing to listen.   I once had a product owner that apparently communicated with others in the organization and then approached the team with an idea that I suggested 6 months ago.   Sometimes it just takes time, and one of the key attributes I've learned in being a Scrum Master is patience.

Thank you for the update Erez, and good luck to you.

Thank you Erez for sharing the follow-up!

I was searching for Command and Control behaviors and I got this page, nice to know about your experience Erez. Thank you for sharing!