How do I regain managerial control of my "self-organizing" team?

Question

I'm a manager of a development team. They have historically followed a very waterfall methodology and have been resistant to change. I'm a huge proponent of agile, so I hired a scrum master and said that we would be following scrum. I've stressed to the team the benefits of self-organizing teams and team empowerment.

After their first retrospective (which I was not a part of), the scrum master came into my office. He said that the team has collectively agreed to "fire" me as their manager. He explained that the team decided they didn't want or need me anymore, especially because they were now going to be self organizing. I told the scrum master that I'd like to talk to the team about this, but he was firm that they felt "intimidated" when I was in the room, and didn't want to discuss it with me.

If I could transfer to a different team in the company, I would, but it's not going to happen with the state of the company. My boss (and his boss) are both on leave for a few months, so I can't talk to my management about this (short of going directly to the CIO, which I'm certainly not going to do).

Other than resigning from my job, I'm at a loss as to how to approach this issue. How can I defuse this situation and re-establish my authority as their manager, while staying true to self-organizing and team empowerment principles of agile?

Answer 1

While I've worked with a number of teams who have followed this same course of action, it does not sound like this was handled with the care it warrants. I'd like to share what I've seen to see if it helps give you an avenue forward.

First, Scrum does encourage self-organizing teams. What the Scrum Guide specifically says about self organizing teams is this:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

That, along with a good deal else about being cross-functional and broad accountability, is meant to encourage team members to ask themselves hard questions about how well they are set up to field whatever requests are coming to them. It is definitely worth the time to give the Scrum Guide a read - it is short.

As for a manager, if you've found that your work in the past has been assigning tasks and tracking work items, Scrum does ask you to take a step back from this. Frankly, if the Scrum Master didn't talk to you about this long before the first retrospective, that may have been a bit of a miss on his part. A harsh reality though, is that many teams who are used to a manager arranging their tasks for them are not well-prepared to just jump into this approach. If you feel like your team is in this situation, I'd recommend talking to the Scrum Master about it. There are many techniques for making this transition easier. In particular, I'd look at David Marquet's Ladder of Leadership and maybe even his book Turn the Ship Around. You'll find that in both, no manager is fired.

Finally, let's look at why you'd want to make this transition if you've had success managing people in the past. The short version is that you'll have even more success helping them learn to manage themselves. There's so much research and data on this, it's hard to even know where to start - but I'll say it's a pretty well-demonstrated fact that all people are potentially capable of self-organization and in a team of, say, ten, eleven brains (yours included) will always solve problems more effectively than one and having another ten on the side waiting to put the blame on you if the solution is wrong.

I've seen a lot of successful managers in Scrum environments. I would always caution a team against outright "firing" one. Even if you are intimidating like your question says and you manage every task in front of them, I've worked with plenty of managers like that who are still amazing assets to the team. In these self-organizing teams, you shift from spending all of your time directing the team's actions to making sure the path for them to succeed is clear and it always comes out better across the board with teams delivering more and managers having a reputation for creating rockstars.

Good luck, I hope this gives you some angles to work with.

Answer 2

You give the scrummaster a weird look, and you say “bye Felicia,” and the next day you call a meeting of the whole team and ask them what the hell that nonsense was all about.

If this actually happened, then I’d fire the idiot scrummaster in a New York minute. This scrummaster is dangerous, unprofessional, and wildly unfit for his job. The way to actually “fire your manager” is to quit: he’s basically just tendered resignations for the whole team.

Answer 3

I don't understand why you're worried. They're all under you in the hierarchy, and don't have the power to fire you.

More importantly, you need to work out what the hell is going on. The scrum master himself might need to be terminated depending on the situation.

Do it before it's too late, before your boss (or CIO) says the same thing to you.

Answer 4

• In the context of scrum: What does the product owner say? It is not the function of the scrum master to ask for more (or less) resources. This is something the Product owner needs to align with the stakeholders

• In the context of scrum: A retrospective is about the process and the team and the project (not about "how do i feel about my boss"). If you were part of the team, you should have been invited. If you were not part of the team, the retrospective should have only dealt with your role in the project.

• scrum masters telling line managers what to do are at least as absurd as line-manager getting involved into scrum directly

So the scrum master clearly overstepped his bounds. It was his function to keep the retrospective focused to identifying specific problems which need to be addressed.

How to proceed:

• You talk to the team in one-to-one sessions and ask them whats going on. You explain clearly that the scrum master is not a line function and that he does not assemble the teams. Also ask where they feel that you should have stayed out of the daily business

• make it clear to the team to whom problems should be addressed

• You go to the next in line (if that is the CIO, it's the CIO - it is not acceptable that you don't have a manager for months), stating that the situation needs to be resolved immediately (by firing the scrum master or the CIO having a word with him that he will get fired on the current course), otherwise it endangers the project - to me it sounds like the scrum master doesn't understand his duties and limits. A professional answer to the team trying to "fire" their manager as part of a retrospective would have been "It is not my business to settle the relationship between you and your boss, and it's definitely not what the project pays us for".

Answer 5

I've stressed to the team the benefits of self-organizing teams and team empowerment.

Well, they certainly took that part to heart.

It seems clear that you're in very emotional situation right now. Apparently, your team has some major issues with the current relationship between you and them. It was probably a good thing you weren't at the retrospective, because that's usually the reason people are suddenly willing to speak out about what's really bothering them. If they're willing to do it around a Scrum Master that they've only been working with for a few weeks then either they already trust the guy or they're so annoyed that they don't really care about the consequences.

Either way; this isn't a new problem that suddenly appeared when you switched to Scrum or hired a new person. This is a problem that has been festering unseen for a long time. It's often stated that working Agile doesn't so much create new problems, as make the already existing ones extremely obvious. This is likely a case of that.

That said; your Scrum Master dropped the ball, hard. It's his job to help the team grow towards being self-organizing, sure. But this isn't the right way. For one, he can't actually fire you, and just telling you "this is what the team wants" is completely nonconstructive. I'm not sure what he thinks is going to be result of this, but it can't very well be what the team thinks it is.

Also, removing people is the hardest choice that a team (or Scrum-Master) can make and should never be taken lightly and without talking (repeatedly) with those involved. You can't just go out and remove someone who has no idea that anyone is having an issue with them. If nothing else, it's going to leave everyone scared as hell that if they miss a retrospective, they might suddenly return to work to find they've been booted from the team. It's going to create an atmosphere of fear, not trust. An atmosphere of trust and openness is what you want when working Agile.

So with your Scrum Master failing to work on an open atmosphere (at least outside the team; he seems to have gotten people to open up quite a bit internally) and not looking for a constructive solution, it seems to fall upon you to do it.

At this point, I don't think anything authority-based is going to be helpful. Scrum and Agile are about empowering people to do their own thing, and asserting your authority at this point is probably going to end up with the entire team being fired. The team has already stated that they're at the point where they want people gone, so while they might have gotten the person wrong, going head-to-head with them will probably end with at least a few people leaving. (And remember the most important rule about leaving: the most valuable people will be the first to go.)

So if you really want to do Scrum with this team, this is where you have to accept their ability to decide how they want to work and have an open discussion about how they want to organize their team. They can't fire you, but they made it abundantly clear that what you're doing now isn't working for them. You need to have a talk about what your role is going to be in the future, what they need from you, what you need from you, and how that's all going to be arranged. Keep in mind that they get to decide how they work, but ultimately there is still a product that needs to be delivered; they will be judged on the quality of what they deliver. And if there are organizational things that you need from them, they'll have to do those things as well. (That said; work with them on the form of those things, and make sure they're really required before enforcing them).

Make sure that in that meeting, you don't approach things from your authority; the whole idea is to get everyone on the same level. You are colleagues and individuals who all have a job to do, all want to do a good job, and all have to work together on a day-to-day basis. Being an authoritarian usually just makes people antagonistic towards one another, which isn't productive. So try to be vulnerable here, and be willing to admit the things you did wrong. You need to figure out how to go from here as human beings.

It sounds like your team hit the Storming Phase of their development as a team, and they hit it hard. Now it's up to the team (and I'm including you in it, at least for now) to figure out how to go from there. Be warned; not all teams get out of this phase and I can't promise that this approach is going to fix the problem. I can guarantee that it won't be worse than quitting or firing everyone, though.

And make sure to have a talk with the Scrum Master separately. I'm not sure what caused him to open with such an nonconstructive first message, but he needs to work on his communication and problem solving skills.

Good luck with your situation. You certainly live in interesting times; make the best of them and learn what you can from this.

(I'm also assuming here that the Scrum Master won't get the whole team to revolt against you without some serious underlying issues. If he can and he's angling for your job, he's a master-manipulator. As soon as you reach the point where you think that's what's going on, you need get rid of the guy asap. That's probably the one case where I'd consider just using your authority as the person who hired him and fire the guy.)

Answer 6

Whether or not they have actual power to fire you as their manager, you brought this situation upon yourself by mandating a change to scrum simply because you prefer it. You did not discuss it with them. You might have been within your rights as the manager, but it was nonetheless a dumb thing to do, and of course they now question whether they want to work for you anymore.

Do you not see the sarcasm in their claiming self-empowerment and self-organization as their basis for taking such an action?

You need to call a meeting tomorrow at 9:15am and apologize for making such an important decision without taking their input into consideration. You can then ask for their feedback about how they thought their first sprint went, and what could have been done differently.

If you want to introduce a new workflow into this team’s process, you might try it on a smaller scale, with specific tasks as a pilot program, with a select few members of the team who are open-minded enough to give it a fair evaluation.

With empowered employees, it is better to persuade, include and encourage than to mandate.

Answer 7

A different perspective: did it occur to you they are simply making fun of the Scrum process and its "self-organizing" aspect? Frankly, I can't imagine they were serious at all and had a good laugh while reading your post. Software developers (I am one) tend to be pretty cynical people with dry sense of humor that not everybody likes or even recognizes. I am sure they were simply telling you they don't like Scrum.

Perhaps the best course of action would be to try talking to some of them informally about Scrum and the reasons they don't like it.

Answer 8

As @Sascha correctly observed, this doesn't look like Scrum at all:

• A Scrum team doesn't have a manager, they answer to a Product Owner instead. The Product Owner represents the interests of shareholders with regard to the team, arranges deliverables for the sprint at the start of it, accepts results at the end, and clarifies things on team's requests in the meantime. He's essentially a proxy between the team and the company.
• If you were a part of the Scrum team, you would attend a retrospective meeting. If you're not a part of the Scrum team, the meeting should have been limited to your role with regard to the team within the Scrum model.

So, the question is: Where do you stand in this picture? What is your role within the Scrum model? Since it were you whose idea to try out Scrum was in the first place, you definitely have researched Scrum and thought about this before suggesting it, no?

And if you didn't, it's time to do this now. Arguably, the most seamless transition for a manager if they're not considered a part of the team when moving to Scrum is the Product Owner. You'll continue to do the same thing -- but now the team answers to you collectively rather than each member individually, and you stop micromanaging them unless they specifically ask for it (the latter one is arguably a good thing for both parties).

Seeing that you have apparently made a critical research failure when suggesting Scrum, I reckon you didn't arrange for a dedicated Product Owner -- so you're exactly in the position to take up this role now.

---

This doesn't negate the fact that the Scrum Master either has no idea what they're doing, or is after your job -- which other answers covered adequately how to go about.

Answer 9

How can I defuse this situation and re-establish my authority as their manager, while staying true to self-organizing and team empowerment principles of agile?

Since when are you the manager of this team? I don't think a team will rebel against the direct manager for a desagreement over only 1 topic. The issue might be more severe than just the agile method.

This is something critical for a manager and you need to adress it, it should be your number one priority for the next weeks.

Your n+1, n+2 are on leave for several month? maybe it influenced your team to rebel. What is the financial status of your company ? ( if it is bad, employees might think you are doing a bad job and can do better without you).

what to do : - organise a meeting with all the team : "scrum master told me you want to fire me, what is going on?". (it is very important you adress the topic to everybody since they all know it and if affects the daily work). -identify the real issue (only this agile method or you have some issue with the team before?). -once you know the real issue, you need to investigate : who is right? you or your employees? -identify who is the leader of this rebellion ( there is always an employee that is defying the autorities more than the others). If you think he is out of line you need to take disciplinary action.

Answer 10

"The code is more what you'd call "guidelines" than actual rules." - Captain Barabossa

It sounds to me like you've got quite the predicament, and you are trying to hold to some unreasonable ideals.

I've stressed to the team the benefits of self-organizing teams and team empowerment.

Explain to your children that self organizing and empowerment does not mean they get to do anything they want. If your team decided to go steal some automatic weapons and rob a bank, you aren't obliged to follow through with them just because they are empowered.

They cannot "fire" you. That is the role of your manager. Firing always comes from up the chain, not from below. Sure, they can jump rungs in the hierarchy and work with your boss to remove you, but since apparently your boss and your bosses boss are both on leave without having put anyone in place in their absence, there's not much of a hierarchy to go to. You've got a few months.

I told the scrum master that I'd like to talk to the team about this, but he was firm that they felt "intimidated" when I was in the room, and didn't want to discuss it with me.

Well that's just too bad for them. Talk to them anyway. Self empowerment may give you the ability to make your own decisions, but it doesn't free you from the responsibility to live up to those decisions. If I had a team like that, talking to them would be the kindest level of response I'd consider.

One might say "Oh, but the SCRUM master is supposed to resolve impediments like this. Everything should go through him." Well tough. He screwed that up when he went to you to tell you you were fired and failed to do so in a sufficiently courteous way that you accepted it. A SCRUM master is expected to have better people skills than that.

So what do you say?

First, you want to find out if they actually decided to "fire" you. You have one person's word on that, and I do believe this is the kind of situation where the team should be able to directly say their piece.

Second, consider what "firing" means. You claim to be a hands off manager, but they want you gone. Understand why. They aren't writing the paychecks, so the decision to fire you isn't a "oh they're not pulling their weight" kind of decision. That's a "this person is actively getting in the way" kind of decision. Something really isn't adding up here. You need it to add up for you before you make any meaningful decisions. Being an anonymous person on the internet, I can't say if its you or them or the SCRUM master, but something is really really really wrong in this scenario, and you better know what it is by the time you're done talking with them.

Work with them. Be a manager. Find a way to solve the problem. Find a way for you to be able to do your job, while they do theirs. Make it happen.

Now, if their answers provide you with sufficient closure to honor their self empowerment, now you have to show the team what happens when you "fire" leadership like that. Say "Fine. I'll stop acting as your manager. You can't actually fire me, because that's not your position, but if you want to play this game, we can play. I was your manager, helping insulate you from corporate politics and the stress of reporting to upper management. Now, I am your upper management, and you no longer have that insulation. Now since I can't actually remove myself from this position, I will instead simply begin relaying tasking from on high." Explain that just because the team voted, that doesn't mean you don't have obligations to upper management that you have to fulfill, and will continue to do so.

Then, get help.

A mutiny is not a small thing. Your entire team just voted you off the island. Don't underestimate it. Get ahold of someone above you to help. Maybe you call your boss on leave. Maybe you talk to your CIO. Someone needs to know that there is a major people problem in your company, and that you are solving it. The second half is clearly important. Never go to leadership with problems, go to them with solutions.

The solution I would recommend is to craft your image as the "manager bearing requirements" by choosing things to require which leadership (i.e. CIO) would want, which is crafted to build some self-realization to go with this self-empowerment. They may think they're free to do what they want, but you are still obliged to make them a successful team. If you have to do it from afar, do it from afar. Find out what about your hands-off approach was so intimidating, and make sure you don't ever do that.

The end goal is to get them to realize you are on their side. If they are truly self empowered, then they need to come to the realization that you are a beneficial part of the team. They will only come to that realization if they are successful. If they get deluged with impossible deadlines and hopeless red tape, they'll never see it.

Just make sure that it all adds up. 2+2=4. A "hands off" manager is "fired" by the new SCRUM master for being too intimidating while two layers of management are on leave? Something doesn't add up from here. You're closer to the situation. Figure out what doesn't add up, and fix it.

Answer 11

Either: a) They are right and you have failed to justify your existence. (They still can't fire you) or b) The scrum master wants your job.

I think the best thing for you to do is go do a 2 day scrum master course and get rid of your scrum master. You can then probably get a bonus at the end of the year for doing two jobs.

Answer 12

I'm not sure what a 'manager' means in your company, but in general i think it means somebody who helps the teams needs and increases their performance. Now:

I'm a huge proponent of agile, so I hired a scrum master and said that we would be following scrum.

Sounds more like 'i have a great idea' i want you guys to do it. Instead of consolidating the team first about your idea. I think every team has the right to criticize your idea and shoot holes in your idea. if your idea doesn't hold you should be fine to drop it.

It it is unsure if the idea holds can tell the team you want a tryout period and/or slowlly migrate to the new project structure.

This way you might still encounter resistance but probably not as much as you have now.

I think to summarize: You are their manager, not their boss. those are two very distinctive jobs!

Answer 13

Lao Tzu said

The wicked leader is s/he who the people despise,

The good leader is s/he who the people revere,

When a great leader leads, people say “we did it ourselves”.

A leader is best when people barely know he exists,

when his work is done, his aim fulfilled,

they will say: we did it ourselves.

and I've been following this maxim basically since day 1 of leading dev teams. If everybody knows what to do, then I'm not necessary and my work is best served this way - enjoying life out of office.

You follow the metrics, audit their code, you do slight course corrections, you encourage & enable whatever needs encouraging and enabling - communication, cooperation, writing tests etc, you shield them from the upper management & clients - and ideally you never act.

But when you do, you do and you kick noses when necessary, you are the guy that's responsible for their work, after all - people do get fired on your recommendation and fire you should, and on time.

I'm not sure why any developer would fire someone who is not in their way and is basically there to fix things for them and protect them from clients and occasionally even higher-ups, takes care of availability of equipment, documentation, nudges ever-so-slightly to be better programmers and better people and enables them to focus on code.

You are still their higher-up - you can still fire them if you need to, you have not been fired from this position. You were just deemed useless or detrimental to the development effort and they prefer to play without you.

Either this or there's some serious pathology going on with the team culture.

I'd say it's an amazing opportunity for some great reflection and growth.

Answer 14

I can see two viewpoints here:

• You were the line manager of a development team in a matrix organization, and you are still the line manager. Your job might have changed a little, but it is fundamentally the same -- you provide developer man-days to the PO in accordance with the company budgeting/HR processes, you look after hiring (and if need be, firing), you schedule leaves in cooperation with the team, and so on.
  In agile development, your role might be a bit less nuts-and-bolts than it used to be, but especially if there are multiple scrum teams your role will now include things like encouraging "communities of practice" or "guilds." Like everything, scrum can be harmful if taken to extremes, and somebody should take care e.g. that technology stacks stay compatible unless there is a very good reason to make an exception. That's the job of line management in such an organization.
• You were a member of the development team and you had direct input into technology decisions, architecture, and so on. In that case I'd suggest that you screwed up by not getting involved enough in this first sprint, because they don't see how you will contribute your skills to the team. In the next sprint, work with the team.

Answer 15

There is no manager role in a scrum team. The real question is why you thought you were a team member in the first place. If you aren't participating in feature delivery, you have no place in that team - so what the team did was correct.

If they consider you an impediment, find out why - the likely scenario is that you were interfering, and the solution is for you to butt out and let them do their jobs.

What do you think your role is in the team? Come up with a useful answer that is aligned with the goals of scrum, then emphasise to the team that you intend to do that job, and not interfere with theirs.

Answer 16

So I don't see why you cannot see this as something positive? My understanding is that the goal of a self managing team is to not need a manager.

What you need to do is to look at the opportunities this presents. You basically have a super team that can manage itself and now you're able to do the following:

• You're able to hold the team accountable to company commitments easier. If they cannot fulfill the company objectives, then they simply cannot be self managing
• You're able to grow the skills in the team. So now you can focus more on the people aspect of the team. Career growth, enablement and that kind of thing.
• Realize that the team + scrum master are still accountable to you in company hierarchy, budgets and the performance appraisal process. So it's not like they can go over your head.

So think of this as a success for now. Think more of the opportunities of how you can strengthen the team. Also realize that you need to be there for the scenario where this self managing approach fails.

Answer 17

I'm a manager of a development team.

I'm a huge proponent of agile

Good! If by "agile" you mean "Scrum" (why would you have hired a Scrum Master, otherwise...), then all is well.

They have historically followed a very waterfall methodology and have been resistant to change.

the team has collectively agreed to "fire" me as their manager

Good! They have changed their ways; they have dropped their resistance (you did not tell us what they resisted to, before...). They have learned the roles surrounding a Scrum Team.

As you are surely aware, a manager has only very remote responsibility in the context of a Scrum Team; you are neither the Scrum Master, nor the Product Owner, nor one of the Stakeholders, nor part of the Scrum Team itself. I remember when I got my Scrum Master certificate in a 3-day seminar; the role of "manager" was not even on the chart.

If your company uses the typical matrix structure of vertical line management vs. horizontal project-related (or product-related) management (i.e. line manager <> project/product managers), then everything seems to be going according to plan. You will still have managerial responsibilities, that is, managing everything that is outside of your team's day-to-day productive work.

Let me repeat your key sentence:

I'm a huge proponent of agile

Now is a good time to embrace that, and learn what it means to manage a Scrum Team. Your responsibilities have shifted now, as well. You do the usual stuff (onboarding new members, handling salary, helping your team to be able to work (getting them their hardware/softwar/etc. and a good working environment), maybe collaborating with other Scrum managers). The fact that your company seems to recognize organizational units has not changed. Your team members will still need to talk with you; just not about their work.

Depending on what you did before as your daily work (doling out work packages to individual devs), you might want to look at other things you can do. For example, you could have a say in which projects your(!) team works for, or if a Product Owner gets nasty in some way it could be your job to calm him down. You could be responsible for managing customer contracts (sales, etc.). You will be a partner and a shield for your team in case of escalations. You are managing. Managing is not the same as developing software; and assigning tasks to individual people is just a small part of it.

Frankly, I would say you are very lucky. Ride the wave. Let them do their thing. Avoid managing their new Scrum away; Scrum was made exactly to make the team self-sufficient and able to perform without constant micromanagement from outside. Many parts of Scrum are made to shield a team from unwanted management.

Your job could be very easy now. If everything works as planned, they will handle a lot of stuff you had to do before. Everybody may be very happy from now on, especially if they didn't like your micromanagement before.

the team has collectively agreed to "fire" me as their manager

Obviously, I am assuming that since you quoted the word "fire", they did not literally send a mail to HR to exclude you from the payroll, but they told you that they want to live Scrum to its full extent (and intent). Obviously, I am assuming that they don't actually want to cut the lines on the organizational chart of your company. Even a pure Scrum Team still needs to be rooted somewhere in the company, i.e., be part of line management, and that is you. You just are not involved in the day-to-day work anymore.