Is My Boss On The Scrum Team?

The impressive thing about self deception is the way it covers its own tracks. That is, we deceive ourselves about how much we deceive ourselves. If I have amazing powers of observation, I might catch a fleeting glimpse out of the corner of my eye. Did you know only two percent of college students think they are below average in leadership ability?

One of our favorite self deceptions is denying how concerned we are with looking good.

There’s a fun science experiment involving a cup of water, a sprinkle of pepper, and a bar of soap. You can try this at home, or at your local pub (if you normally bring soap to pubs…). Sprinkle pepper on the surface of the water, spreading it evenly. Then touch the soap to the surface, and watch the pepper zip out to the outer edge of the cup. The pepper’s organization changes radically because of something barely visible, but quite influential — the soap altering the surface tension of the water.

Improvisational theater guru Keith Johnstone and animal behaviorists have observed there are no status free transactions. (There are also no gender-free transactions.) Status is always there, often just below the threshold of awareness.

What does this have to do with self organizing teams?

A high performing Scrum team organizes itself around the Sprint Goals. Status and leadership flow between individuals from situation to situation according to the wisdom of the team. The experienced software architect may have major influence when the team is deciding what persistence framework to use, the brilliant intern is suddenly important to the team when they’re setting up the new tools, the old timer leads when questions about institutional knowledge arise, the person with the most QA experience might have greater influence when the team is figuring out how to build for testability, then a personality conflict may occur and the less technical person with the better soft skills emerges as the leader.

Everything not driven by Sprint Goals is muda.

What happens if one of our “team members” controls which one of us will get a promotion, which one of us will be downsized in the event of a layoff, which one of us will be have a warning in our personnel file if we frequently disagree about how to accomplish goals. Now we’re at least slightly concerned with looking good for the boss, which is a different driver than accomplishing the Sprint Goals.

This invisible force, essentially a parent/child rather than adult/adult dynamic, distorts our self organization and colors our interactions with each other. 10% of this will be obvious to you, but I’m more concerned about the 90% that is not. We’ll still get our work done and probably mildly exceed expectations, but fall far short of what our team could do.

Perhaps you’re one of the vast majority of people who have an above average relationship with your boss. I won’t blindly prescribe that your boss not be on your team. I do suspect the cost is greater than you think.

I remember stepping in as Scrum Master for a team whose previous Scrum Master was also its Product Owner. And he also happened to be the boss. He was a really nice guy and an inspiring leader who later led the whole company through an Agile transformation. But when he walked into the development team room to, um, help out, the conversation shifted, subtly, invisibly. All the pepper moved to the outside edge of the cup. Just as we rarely detect our own scent, bosses sometimes forget that invisible gun is always with them.

–mj

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Tagged with: , ,
Posted in Agile
5 comments on “Is My Boss On The Scrum Team?
  1. Jimi says:

    Michael’s point is well taken. At one company where I introduced Scrum I was both the ScrumMaster AND the functional manager. I was certain because of my knowledge of the rules and principles of Scrum and because of my general belief in “servant leadership” that this would not be a problem. After all I had a great and open (and I was convinced safe) relationship with the people reporting to me.

    Imagine my surprised when I discovered (through one of my reports who happened to also be a personal friend) that the team was “very intimidated” by me and “afraid to report impediments”. At first I tried to reinforce that my office was a safe haven for anyone on the team, but I don’t think they really believed it. Mostly because my friend said, “They don’t believe, dude. They’re still afraid of you.”

    I decided the only sensible thing was to get out of the way. I hired someone to serve as ScrumMaster full-time and stopped trying to do it myself. The transformation in the team was dramatic and nearly immediate. Suddenly, a host of organizational impediments of which I was completely unaware came to light which I was capable of resolving and in so doing improve the productivity of the team by probably an order of magnitude. They went from being merely a good team to being a great team.

    I was completely blind to my influence on the team dynamic by trying to be functional manager and ScrumMaster. I was the soap in the glass of pepper & water and I didn’t even know it until I got out of the way.

  2. Dan Rawsthorne says:

    MJ asks: Is the Boss on the Scrum Team? and then proceeds to answer the question with a resounding No! It’s not that simple.

    His main argument centers around the rhetorical question: “What happens if one of our ‘team members’ controls which one of us will get a promotion, which one of us will be downsized in the event of a layoff, which one of us will have a warning in our personnel file if we frequently disagree about how to accomplish goals?” and then notes that having a person like this inhibits self-organization.

    Ok, I have a few things to say here:

    * power dynamics inside a scrum team cause issues that must be managed;
    * there are always power dynamics on a scrum team; and
    * scrum has already addressed this issue.

    Let me discuss these statements. First, why do power dynamics always exist? Well, every team has a Product Owner, who is a team member that is accountable to management for the team’s success. Since the PO is accountable, the PO has power over the team, as it wouldn’t be fair to the PO to put himself at the mercy of the team. This power is inherent to the position of PO, as it is a Leadership position; that is, since the PO provides direction and goals (and is held accountable by stakeholders for their execution), the PO has the right to “boss people around” (but an obligation not to). In other words, the PO is the Scrum Team’s “boss” – but it would be nice if the PO was not any individual team member’s boss… but we can’t guarantee that, either. (Note: people in Leadership Positions are not necessarily leaders, but it would be nice if they were)

    So, there is at least one power dynamic that must be managed. This is well-known in scrum, and managing this is one of the responsibilities of the Scrum Master. The Scrum Master must have courage, and work to keep the PO “in line”. If there are other power dynamics on the team that must be managed (such as a manager/managee relationship, or the Dev Lead being on the team, etc), the Scrum Master is responsible for managing that, too. Maybe in a particular case it can’t be managed well, and people must be separated, but scrum has recognized the problem and builds in a solution…

    Now, there is a big problem in two cases:

    * when the Scrum Master has power over other Team Members (as in Jimi’s case above), and
    * when the Scrum Master has a lack of courage, or is incapable of managing the situation

    Ken Schwaber has said that the first case must be avoided, as it makes scrum “too hard”, and has also said that this is the only case that is virtually guaranteed to fail. I agree, as it is too big an impediment to self-organization and self-management – the Scrum Master must be a servant leader, not a boss. Don’t do this! In particular, don’t let your Product Owner or Functional Manager, or any other person with power over Team Members, be the Scrum Master.

    In the second case you have a defective Scrum Master. The team may have to get another one and try again. This is also already discussed in the Scrum literature.

    So, bottom line, don’t invent problems that don’t necessarily exist. Get an appropriate Scrum Master and let scrum be scrum. Let the Scrum Master help the team self-organize to solve the problems they have, including these “power dynamics” ones.

    Dan 😉

    Dan Rawsthorne, PhD, CST
    Transformation Coach
    http://www.danube.com

  3. Michael James says:

    Regarding “proceeds to answer the question with a resounding No“:

    To be clear, my answer is that I think the cost is greater than you think. This is due to factors you won’t be able to observe unless you’ve seen the same team go through forming/storming/norming without the boss/worker dynamic.

    Regarding “don’t invent problems that don’t necessarily exist.

    Which brings us back to self deception….

    –mj

  4. Dan Rawsthorne says:

    Ok, I’ll agree that having a team with a worker/boss dynamic on it might be expensive to manage. So what? That doesn’t mean you don’t do it.

    As a coach, I wouldn’t preclude anything unless it caused scrum to fail, which means either that it won’t be effective, or the team’s can’t self organize. I might warn against it, I might even warn that it will be expensive and hard to manage, but I wouldn’t forbid it.

    In the case you mention, self-organization may be expensive, but I see no impediment to effectiveness – only impediments to efficiency. Therefore, it is merely a problem to be managed, not forbidden.

    So, if you want to say, “it would be better (all other things being equal) if my boss wasn’t on the team with me”, I’d agree with you. And, now that I reread what is in your blog, I can see that you did say that — oops! So, I guess we agree on this, actually…

    Maybe the title of this blog should “Should my Boss by on the Scrum Team? — Dan 🙂

    In the case you mention, I presume that things aren’t equal, and there are legitimate reasons my boss needs to be on the team with me. So we’ll just have to deal with it… and suffer the consequences.

    Just sayin’ Dan 😉

    Dan Rawsthorne, PhD, CST
    Transformation Coach
    http://www.danube.com

  5. Michael James says:

    Regarding “I see no impediment to effectiveness – only impediments to efficiency

    This is true the same way an airplane without wings is only less efficient. We’ll still get places faster than when we were walking and it will “work for us.” It will certainly seem safer, more familiar, and initially easier to sell. And we’ll call it “flying” … until we’ve actually experienced flying.

    –mj

2 Pings/Trackbacks for "Is My Boss On The Scrum Team?"
  1. […] “right thing to do.” Often referred to as the “invisible gun effect” (see Is My Boss On The Scrum Team? or do a web search for “scrum invisible gun”), just the presence of someone in a power […]

  2. […] who can’t voice their concerns at the retro because the person running the thing also carries a giant invisible gun. …well, it’s invisible to the manager. To the team, its about the only thing they CAN […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*