Middle Managers and Scrum

February 24, 2011

In a lot of organizations I work with, we need to do a better job of explaining Scrum to the middle managers.

Most of the people in the teams get Scrum and see benefits. Most of the senior guys see their metrics get better, and, if they focus on the right feedback, hear and see good things.

But often the middle managers feel left out. Yes, they see benefits here and there, but often not for themselves. They should actually see benefits for themselves, but no one shows them how to recognize and realize those benefits. We just assume they will naturally, without any explanation, understand and adapt to the change (to Scrum).

But, a common feeling among the middle managers is: “Who moved my cheese?” (If you know that book.) Meaning: “Before, I knew how to manage and be successful and show progress. Now, with Scrum, they moved all my levers. How do I function successfully?”

So, we need to take the time to explain it to them.  To be fair, some will figure it out without explanation, but not as many as we want.

Here is a first, too quick, pass at that explanation. It is too simplistic, and too specific in assuming a prior waterfall process, but a good start (I hope).

_______________________________________________

  1. Your job has gotten better (and no longer as stupid as it was). Instead of doing something that is not very effective (trying to manage individuals in a waterfall process), you now help teams get better in a more effective approach/framework (Scrum).
  2. Your job has gotten better (clearly useful). Instead of trying to show in waterfall that you did something truly useful (almost impossible to show, really), you now can see real progress in the success of the Scrum Team, and working product (software) is a far better measure of real progress, as is team Velocity. So, if you oversee three or four teams, you can show these team metrics and show real progress. It was not (and never was) all based on you, but you had a hand in it (see below).
  3. Your job is different (remove impediments). Instead of pushing the people to ‘work harder,’ you now are a servant leader to the teams. Your main job is to help the team remove impediments. Honestly, most of you removed impediments before. You just didn’t call them that, and there was no clear way to prioritize them. Now, you get help from the team and more recognition (up and down). (Or you should.) For some of you, you get to join a Scrum Team and lead the team in doing ‘real work,’ which in general is more satisfying for most people. But for those of you who like the frustrating work of removing impediments, we have a clear, prioritized, long list of them for you to help fix.
  4. Your job is different (no command-and-control). In almost all cases, we do not recommend the command-and-control style any more. OK, maybe at most 1-in-20 of the guys in our shop are really lazy or fundamentally without good motivation. Yes, you can help re-purpose (ultimately, fire) those very few people, and you can identify those people who also appear to be de-motivated, and help them get through the past de-motivators (here or at their prior firms), and connect to work they really want to do. But mostly we want you to take the coaching, servant leader style with the team. You will find that the coaching style is much more satisfying than the command-and-control style, and the people you work with will now mostly like you and appreciate your efforts to help them work better. Instead of ducking-and-diving to avoid you.
  5. More truth. With both the people below you and the people above you (well, we want to start moving away from the hierarchy metaphor, to a more flat organization, but for now…) for both sides, the good news is everyone is talking the truth more — this is much more satisfying. Although, to be honest, in the short-term, and until we get more people understanding it, it can be painful and take more courage, but in the long-term, it is better for everyone, including you, if we are all more honest. Our work of new product development is truly hard. We, of course, make lots of mistakes. (As all scientists who set out to discover a new thing do.) We are trying as hard as we can to learn as fast as possible from our mistakes — none of us is perfect. Each of us tends to have a typical, repetitive weakness (and, the good news: we now have a team that helps each of us avoid our own peculiar weakness(es)). There is nothing particularly new about this; it was true in waterfall really, but we are now going to admit it more, top to bottom (as we say).
  6. Career growth. Because we will be more successful as a firm with this approach (Scrum, or at least so we fully expect), we will be more profitable as a firm. And so, your prospects for long-term career growth are better assuming it is the style of ‘play’ that you are comfortable with. (To be honest, not every manager fits with the style of Scrum. Some are dyed-in-the-wool command and control managers and they should not be ‘forced’ to play Scrum, although maybe they should be ‘invited’ to play their style at another firm.)

__________________________________________

This is a start on what to explain to the middle managers. Even at the high level, we have left out a lot. The middle managers start to ask: “OK, what do I specifically do?” While some of the specifics will indeed be very specific to your organization, we can say more on that and will in a future post.

P.S. The excellent cartoon is by Mike Baldwin. Google him.

« « Dear Rob – 2 || Innovation’s most important question » »

Posted in: leadership, managing agile
Tagged: Tags: , , , ,

14 thoughts on “Middle Managers and Scrum”

  2. Simon Kiteley

    I think one of the biggest problems is not just explaining Agile techniques to middle management but also those that understand it will realise that 1) significantly less middle management may be required 2) With the development team being empowered it can really can highlight the difference in abilities of the once middle manager (now Product Owner) 3) Career progression stops in the way it used to… a successful middle manager won't get responsibility for more and more engineers as their careers progress. Career progression is purely a measurement of efficiency.

    ↓
  3. Joe Little

    Hi Martin,

    Umm. I think the ability to deal with people issues is quite important. As are technical skills. And of course, a lot of others as well.

    Hi Simon,
    Not sure if I follow you. (And hope what I will say will be clear.)

    1. Less. Well, often, but not always. And I think there can ALWAYS be reasons to have people in the middle. And these middle people can be very very good. Maybe they are not 'managers' per se, but they can contribute a lot.

    2. Differences between whom and whom?

    3. Yes, career progression can definitely start to be different. I would say success and progression should be based on delivering business value with speed (and of course quality).

    Thanks!
    Joe

    ↓
  4. Anonymous

    No offense, but I see your entire article as very naive. It seems to assume that all people have the same skills and desires. Let’s take it from the perspective of the manager. He likely got to his position because he was good a command and control. Even if he wasn’t a micro-manager he probably enjoyed being involved in the decision making process. He probably also thinks that he is better at making these kind of decision than those on the team. Now, we no longer value what you enjoy doing and are good but since it helps the organization you should enjoy it.

    Furthermore, probably the IT deparment decided they are going to do agile. The manager still feel that it is his team. The rest of the company probably also shares this view as not everything went agile. Now the manager is sitting in management meetings but cannot contribute in the way that any of his peer manager can contribute in terms of adjusting plans, making commitments, etc. But he is supposed to like it.

    You acknowledge that the career paths have probably changed but you don’t offer any real alternative to this manager on what it is likely to be. He likely doesn’t have a clue and over time he will get less and less credit for the successes of the team. His boss sees this too…he says I have 5 self managing teams, what exactly are all of these other managers doing? Seems like a lot of solitary. The boss get credit for making the organization more efficient the middle manager will not (because after the initial implementation he isn’t contributing much to that efficiency). The middle manager gets canned.

    So what is in it for him? Better titles – No, More Money – No, More Challenge (partially but only because he now is focused on stuff he isn’t good at and doesn’t like), Job Stability – Ha! Sure some prefer to coach and being a servant to the team but in my experience this is the dramatic minority.

    ↓
  5. Joe Little

    Hi Anon,

    Naive? Well, I don't think I am. But I can agree that the blog post does not cover the whole subject. It is, I think we can agree, barely a start.

    So, the first thing I will say is that your situations seem realistic to me.

    AND…they are not all the situations that I find in companies. There are many different situations.

    More specifically: On your first 2 paragraphs, I think what you describe –can be– exactly how a specific middle manager can feel.

    3rd Paragraph: Yes. We need more time/space to discuss the new career path in more detail. That blog post was not enough. And I agree that some middle managers can be fired (often wrongly) because more senior managers do not see how they will contribute. Again, a reason to talk about the new role of middle managers, rather than to be silent about it.

    4th Paragraph:
    Titles – Well, I never knew anyone I respected to care much about those.
    Money – Actually, since the Team(s) should be more successful, there should be more money as bonus to distribute. So, I think the middle manager, assuming he/she is making a contribution, should see this as a Plus.
    More challenge – Actually, I see this as a Plus. I think many middle managers are actually quite good at removing impediments. Scrum makes it easier and better. But not all middle managers are; you are correct there. If they only thing they are good at is command and control, and not interested in changing, then you are right, basically.
    Job Stability – Ummm. Well, often we must produce a good/better product faster than our competition. Scrum greatly improves your chances of doing that. So, a plus. But, if you were actually not contributing much or can't do it in a Scrum context…well, then you will be re-deployed to a different firm sooner. Maybe a good thing for you (the middle manager).

    Thanks,
    Joe

    ↓
  6. Andrew Kazarinoff

    In a Scrum transition I just coached, we bypassed middle managers ("project leads"), and successfully turned senior developers and architects into ScrumMasters. We gave the displaced middle managers new jobs that would benefit from their knowledge of the organization and domain: resource and workload balancing, risk analysis, recruiting, impediment removal, and supervision of lights-on work. We gave them enough training on Scrum to show where their new roles will fit. There was a period of adjustment and patient coaching (the techs formerly reported to the middle managers, who had to become chickens in all Scrum meetings). The middle managers are now contributing well.

    ↓
  7. Joe Little

    Hi Andrew,

    As a factual matter, what you said is similar to what I have seen. I would emphasize more removing impediments, is all.

    So, I liked your specific suggestions. Which is probably the most important thing.

    Now, I find that middle managers are (or were) some of our best people. Typically.

    I am a bit concerned that your words can be read this way (maybe exaggerating a bit): "Those jerks who are middle managers can't do much, but we got them re-assigned so that they actually are mostly positive around here." In other words, the words might be read as disrespectful. Now, having seen some bad middle managers in my day, maybe some disrespect is deserved. But on the whole, I like to start with respect.

    Again, not sure that is what you meant [disrespect] (I think in fact you did not), but I think some could read it that way. Which I think does not usually help.

    Thanks,
    Joe

    ↓
    1. Michael

      Hi Andrew,

      So you took people who are experts at object-orient programming and had them spend time doing something equally important that they were not so good at? As someone who has been both a developer and a Scrum Master I’ve not seen many cases where a person can maintain an expert level of competency while doing something part-time.

  9. Joe Little

    Hi Andrew,

    Makes sense. As I said, I did not think you meant disrespect.

    Still, I find too many people in Agile feel disrespectful of middle managers. My view is that some middle managers are 'worthy' of disrespect, but far far from all. And too many good middle managers think Scrum gives them no decent role. Now, part of this is 'talk' they hear and part is lack of discussion (of their new role). Because I think good servant leaders have plenty to do in Scrum.

    OK. Soap box off.

    Thanks,
    Joe

    ↓
  10. Anonymous

    Joe, three questions, in your experience / observations:

    1) Do you see more Agile/Scrum implementations closer to Anderw's approach (TL's and sr devs being moved to SM roles) or moving current project leads/project managers into SM roles?

    2) Which have you found more effective?

    3) How do you see the sourcing of the role of the Scrum Master evolving as the Agile/Scrum/SM role matures?

    Anonymous II

    ↓
  11. Anonymous

    Joe, Scrum seems to assign the teams are self organized. It will start well as self organized team, during the stressful times it breaks. 'Middle managers' in the scrum have influence and not control. They can fix in time, but immediate deliveries will suffer. In that phase, there will be a huge urge to go back to 'command and control'.

    ↓
  12. Joe Little

    Hi Anon.

    Thanks for your thoughtful comment.

    Yes, sometimes the self-org "breaks" as you say, or does not work. And a good manager does not just watch them fail. Depending on the situation, he or she might have to intervene some. Or a while.

    Remembering that people are free. And creative people (you do have those kind, right?), creative people especially must be free. To do good work. "People are remarkably good at doing what they want to do." And, deep down, they want to be free, to control their destiny.

    But the bigger problem is the middle-managers have been taught, trained and seduced into command-and-control. They have been lied to and told, in effect, "these people are you slaves." And there is only one thing to say about this: It is wrong! It is against the dignity of any human being.

    We can also say that in the long term it does not work. Human welfare progresses to the degree that people have, and use properly, more freedom.

    This is not to say that freedom is not scary to those 'given' it. (Well, given by God, we would say.) We try to escape our freedom all the time. But freedom is good economics, if done 'professionally'. (Explaining that last word is too much for today.)

    Thanks,
    Joe

    ↓
  13. Allen Jones

    Joe,
    I would suggest some changes on the first two items.

    On the first item, I would avoid the word “stupid.” Many of the middle managers who will resist the move to something like Scrum made a name for themselves by working in a waterfall environment. If you call what they have been doing for years “stupid,” you are not likely to get them to be open to change. I know that you did not call them “stupid,” but what you say and what someone hears can be two very different things, especially when they are already feeling threatened by a change. What I prefer to do is walk through some of the waterfall type approaches that they have used in the past (straight waterfall, V model version of waterfall, stage-gate, etc.) and talk about the problems that each approach encounters. If the middle managers have been using these approaches for any significant amount of time, they will readily recognize and agree that these are indeed problems. I then talk about how things are changing faster and faster. The Gantt chart was invented about the same time the Model T was being introduced. If you looked at 1917 Model T and a 1927 Model T, there is not that much difference. Back then, project schedules that were hard to change were not that big of a problem. But if you look at the average life of a company on the S&P 500 list today, you see a very different story. In the 1960’s the average lifespan of companies on the S&P 500 was 32 years. By 2027, it is expected to be 12 years. This is something that middle managers will recognize. They are constantly being pressured by upper management to move faster and faster. I then talk with them about the success rates for agile vs non-agile projects. At this point, hopefully most of them will at least be open to exploring the idea of using Scrum since they see that it could help with some of the challenges that THEY have faced.
    On the second item, I would not totally agree that it is almost impossible to show that you did something truly useful with a waterfall project. The real problem there is that you cannot show that you are doing something truly useful until the project if totally finished and the customer has been using it for a while. That can mean that you could go for years without being able to definitively show that what you are doing is useful. With Scrum, you can show that you are doing something truly useful in weeks to months. And if it turns out that what you (and everyone else) thought was going to be useful is, in fact, not useful, then you can change your course before you have wasted major amounts of time.

    ↓

Leave a Reply