Managers and Agile and Riding an Elephant

At some point in time, Tanner Wortham and I decided to guest post on each other’s blog.

Tanner was kind enough to let me go first – and the results are here on Spikes and Stories “Retro Technique: Building Team Empathy”

Then it was “Tanner’s turn.” He pinged me via LinkedIn to nail down a topic:

Let me scan through my list of topics that I’ve jotted down over the last month.

Hmmm … I have one topic in mind about the manager’s place in an agile shop, but that’s a rather controversial topic (especially with how I intend to write it).

I’ve also thought of writing a follow up to one of my most popular posts: Tips To Be a Successful Scrum Master:  It would be the top 10 (or 8 or 7) tools a scrum master/agile coach should have in his belt. My initial post was primarily about mindset. I envision this one to be about mechanics and be more tangible.

What do you think?

To which my reply was:

Are you shocked?

Every good leader should try to teach people all he knows... Click To Tweet

Let the Dialogue Controversy Begin

Andy: Ok, Tanner. I’ll take the bait. Tell me more…

Tanner: Here’s my hypothesis and my solution:

• Hypothesis:  The overlap between the role of the traditional manager and a self-organizing agile team creates unnecessary complexity, causes confusion, and creates dysfunction.  While there’s a place for leaders, there is no place for managers in an agile shop.
• Solution: Toss the title “manager” in the trash and rename them as mentors, leads, or something other.  These previous managers will be assigned to an agile team as a team member.  They’ll mentor others of the same discipline on other teams and assist with inter-team dependencies, as needed. Managers and agile don’t mix.

A Shared Vocabulary: Managers and Agile

Andy: Interesting, and you did warn me 🙂 …. Two questions pop into my mind:

1. What do you mean by “the traditional manager”?
2. What do you mean by “an agile shop”?

Tanner:  Let’s tackle that second question first.  What’s an agile shop?  It’s pretty straightforward really.  It’s a place that embraces everything we know and love about the Manifesto for Agile Software Development (a.k.a. the Agile Manifesto).  Have another read here and here if it’s been a while.  If this agile mindset has permeated throughout the entire organization, you’re an agile shop.  Unfortunately, I wish it were that simple.  Here are a few cases where you might not be as agile as you think:

• Did you follow the two links above and have a knee jerk reaction: “We’ve been agile for years. We rock in every way.”  If the answer is yes, you may not as agile as you think.  An agile shop is one who recognizes the journey for perfection is never achieved.  It’s a place where good enough never is.
• Does your company execute scrum by the book?  Have you standardized everything across the company to work at peak performance? Might you actually be following the rules but not understanding the game? Doing scrum isn’t the same as being agile.  That’s for certain, and I talk about more about it here: “Agile Mindset Over Scrum Mechanics.”
• Even if you and your teams live, breathe, and embrace the ways of agile, what about the rest of the company?  Do they?  You may be agile in all the right ways, but it’s important the company and all the “staff functions” have a similar mindset.

Here’s one more sanity check for you.  Go to Comparative Agility and ask your organization to complete their survey.  Ensure you sample the entire organization and not just those who agree with your points of view. The survey will compare you to other companies to see how you stack up.

Now, let’s talk about a traditional manager.  His name is Ed, and he’s an engineering manager. Several years ago, Ed was an engineer himself, but over time, he became a full-time manager and no longer practices his craft.  He hasn’t in some time because he wants to focus all his energy on his six direct reports, and they take up a lot of his time in a number of ways:

• As a resource manager.  He assigns people to work based on their skill sets and also manages dependencies between his resources.  After all, no one knows the capabilities of his resources better than he.

• As an arbiter of priorities and solutions.  When projects conflict, he decides which has priority.  He also dictates solutions, where necessary.

• As a compliance manager.  And by “compliance” I am referring to the responsibility of ensuring that he and his people comply with all organizational policies, that all are good citizens and playing by the rules of the organizational game. When one of his resources misbehaves, he gets involved.  When it’s time for a yearly review, he gives it.  He’s also working with upper management about his reports’ yearly salary increases.

• As a coach and mentor.  Ed doesn’t get to spend as much time as he’d like here.  Those first three buckets eat away at most of his day.  (Sometimes all of it on a chaotic day.)  And because he’s not practicing the craft himself or as involved in the code as he used to be, it’s sometimes challenging to give solid guidance.

But here’s what’s funny.  Would Ed ever exist in a new start up?  Doubtful.  When you’re small, everyone must contribute to the bottom line to survive.  Every person matters.  Person, not resource.  When you’re small, being lean matters.  Being nimble is necessary.  Waste is repelled.  Arguably, every start up starts out agile and along their journey … somewhere … somehow, something goes awry.

Wait, Don’t the Managers Actually Do Something Around Here?

Andy: Ok, I’m following you. My next questions is: if we 86 the managers at that level, what happens to that list of responsibilities?  And related: why stop at that “first layer” of management? What happens if we get rid of ‘em all?

Tanner: So it’s clear Ed doesn’t work in an agile shop. Agile teams are responsible for their own resource management and priority management.  The compliance piece gets more interesting.  For example, a solid agile team has an environment of trust and candor.  Team members give frequent feedback to others on the team. It’s specific, it’s relevant, and it’s helpful. These quick feedback cycles reinforce proper behaviors in ways that yearly reviews could only hope, and managers aren’t often present when something goes wrong.  They often have to deliver feedback second-hand never having observed what occurred.

All that Ed has left on his plate is coaching and mentoring, which is arguably his most important responsibility.  After all, every good leader should try to teach people all he knows, not so he can be replaced but so he can be promoted.  In order for Ed to be an effective coach, he must be able to relate to his people, and in order to mentor, he must practice his craft.  In short, Ed needs to become a team member.  I recognize that he can’t be a full-time member since he has collateral responsibilities, and that’s okay.  We need to grow our people, and by putting Ed’s reports on other teams, we gain cross-team communication for free, and this is worth the price of admission.

And let me speak personally for a moment.  I’m a scrum master; I’m a manager of scrum masters.  I will always ensure I serve a team no matter how many scrum masters report to me.  It gives me an opportunity to grow professionally and to set an example for those that report to me.

My inspiration for this model comes from Spotify and Henrik Kniberg, and it’s a very weak matrix model.  Squads are agile teams, and Ed would be a chapter lead for one of those chapters seen below.

That brings me to your second question:

“Let’s get rid of all managers!”

Absolutely not!  I’m only suggesting that those first-level managers become team members with mentoring responsibilities.  Not everyone should be a member of an agile team.  You can’t establish, guide, and executive strategic vision for a company if you’re knee-deep in tactical decision-making.  Spotify’s model suggests as much as well with the figure in the top left of each tribe.  His or her responsibility is to tribe as a whole with no team-level responsibilities.  Again, I only suggest first-level managers become team members.

Chhhh-changes

Andy: Ah, now I see what you’re saying. (We can come back to the question of all or some later…) So what’s the transformation path for Ed look like, from his old role of command and control to servant leader? What skills does he need to learn/unlearn? Who helps him on his journey? And equally important, when Ed stands back from his command and control role, how and where does the team need to step up? (Ok, that’s more than one question….)

Tanner: Are you familiar with the elephant and rider metaphor?  This video explains in well in two minutes.  It’s a great metaphor that describes how to affect behavioral changes, and Switch by Chip Heath explains it thoroughly.  It has three parts:

• The rider.  This is your logical side.  It’s the side that sees you’ve put on a few pounds and says, “I’d like to lose some weight.”
• The elephant.   This is your emotional side.  When you get hungry, this is the side of you that says, “I’ll just cheat this one time because I’m starving.  It’s no big deal.”
• The path.  This is the external environment.  If your pantry is full of fattening food, your path is littered with the temptation to lose that weight so the food has to go and be replaced with healthy alternatives.

All three parts must be addressed, and even when your logical side recognizes that change is necessary, it will have a hard time directing the very large elephant if he emotionally disagrees with the change.

That brings us back to Ed.  We’ve adjusted his environment by placing him on a team, but that’s certainly not enough.  As Chip Heath points out in Switch, “For anything to change, someone must start acting differently.”  We need to address the three parts we talked about above for the change to be successful.  So let’s talk about that.

First, let’s direct our rider by scripting a few critical moves.  We’ve discussed with Ed our new expectations as a coach and mentor, and we also talked with him about peeling off his other responsibilities as a resource manager and compliance manager.  Additionally, we’ll need to ensure he isn’t overwhelmed with direct reports so if he had six previously, we’ll adjust it to three.  Finally, by placing him on a team, we’ve adjusted his environment and changed his routine.

Second, we’ll talk to our emotional elephant.  I fear Ed will feel this is a demotion.  Ed’s contributions as an engineer and before he became a manager were instrumental in the company’s success.  We’ll stress this.  We’ll also stress that we want our senior engineers leading from the front, not the back.  And, Ed, didn’t you say some of your guys were looking for promotional opportunities?  We’re creating those opportunities, and we want you to help lead that charge.

Finally, let’s shape the path.  Instead of implementing a sweeping change across the entire organization all at once, Ed will lead our first pilot.  He’ll be our first manager turn leader.  With his help, we’ll uncover the pain points, the difficulties, and if all goes as planned, he’ll be our first success story, which he can share with others in the organization as we continue to adopt the change.  By calling it a pilot and by starting small, it gives us breathing room to learn from and recover from any small failures that happen along the way.  These failures are okay.  In fact, they’re expected.  Although the idea is simple–place Ed on a team–the impact is great, and the change of context is bound to affect many parts of the organization.

Everything is Hitched to Everything Else

Andy: I like it. And it reminds me of a quote by John Muir.

“When we try to pick out anything by itself, we find it hitched to everything else in the Universe.”

So when Ed begins to change, everything else needs to change too. Just about all of what Ed used to command and control now gets distributed to the team.

Let me see if I can elaborate in the format of a matrix:

Where to Go From Here?

Wow, thanks for sticking with us … this ended up being an epic post. Any thoughts on what to do about stuff like ISO Compliance when working with a agile shop?

And what happens if/when we scale this model to the larger organization?

Those, our friends, might just be the subjects of a few future posts!

Recommended Reading

• Storytelling change management processes to share positive experiences.

Turn The Ship Around!

Amazon

Corps Business: The 30 Management Principles of the U.S. Marines

Amazon

Humble Inquiry: The Gentle Art of Asking Instead of Telling

Amazon