To Be Truly Great, Make Yourself Unnecessary

I feel like I’m pushing my team out of the nest, and I’m not sure if they’ll fly, or spiral to the ground.

On Monday my team will hold a sprint planning & a retro without their Scrum Master. Although I’m a little nervous (What if things don’t go well & our release plan is derailed? What if things go too well & they don’t need me anymore?), deep down I’m intrigued by this. If the team succeeds, it mean’s they’re developing and “growing their T’s”. If the team fails, we have more work to do.

The Old Model: How Can I Seem Important?

As an interning developer, one of my first thoughts at any new job was “I need to make myself necessary to this organization”. If the team relies on me, they can’t fire me, and I might get a bigger year-end bonus. Therefore I should get really good at one thing, and become the resident expert on it.

Although slightly embarrassing, this way of thinking is quite common, and was required in the old-school corporate model. It’s also contributed to innumerable project & organizational failures throughout history.

The Hit by a Bus Problem

If any member was hit by a bus, could the team fill the knowledge gaps?

Team Green-Pants has been working on a new Facebook-killer for the past three months, and their Product Owner is waiting impatiently for Monday’s first product release. In Friday-morning standup, Jill says she successfully integrated the last piece of code, and she’ll be tagging the repository for deployment today. They pass the ball to Jim, the dedicated deployment guy, who after giving his update mentions “By the way, I’ll be in Mexico for the next two weeks. So…”

Kara (the tech lead) asks the team in a worried tone “Can anyone else handle this deploy?”. She’s met with silence and slowly shaking heads. Kara turns to Jim.

Kara: “Can you get me up to speed on how to deploy by end of day?”
Jim: “Nah, I don’t have time for that.”
Kara: “Well can you at least show me where to ‘push the button’ or whatever it is you do?”
Jim: (snorts) “Push the button? What the heck does that mean? There’s no *magical button*, trust me. It’s a whole process.”
Kara: “So I guess we can’t deploy Monday?”
Jim: “(shrugs) I guess so.”

Now instead of celebrating their accomplishment, the team makes a long, defeated trudge towards the Product Owner’s cubicle to break the news.

Team Green-Pants designated Jim as the “Head Deployment Guy”, and for Jim, embodying this role made sense. If people need him for specific capabilities, he practically can’t be fired (no matter how late he brings up his far-flung vacations). For the team, this acute specialization means a delayed release and an upset Product Owner. They’ve discovered a less morbid version of the “hit by a bus” problem, where if one team member’s unavailable, the team’s left with a massive knowledge gap.

Silos. Silos Everywhere.

A good Scrum Master will not only see the obvious red flags, but the underlying mindset that causes those red flags to exist. Team Green-Pants’ real problem isn’t a designated head of deployment, it’s the underlying silo mentality that caused them to designate a head-of-deployment. Each team member has their role, and feels subconsciously threatened when someone else does “their duties”.

The Terrific T-Shaped People

The members of Team Green-Pants look less like T’s, and more like I’s.

I-shaped people know a lot about their specific field, but not much beyond it. These people fit perfectly into their silos (developers are developers, testers are testers, project managers are project managers), and spare nary a thought about rounding out their skillsets. This causes two problems:

  1. No Flexibility — In a perfectly predictable project, the team will always have the right balance of developers, testers, operations specialists, business analysts, and DBAs. Developers perfectly estimate their effort, testers never find any issues, operations can read minds, and Sparkles the unicorn just pushed some backend changes to master (you can always count on Sparkles). 
    Surprisingly enough, real projects aren’t perfect or predictable. If the team’s comprised of I-shaped people, every day at least one silo will be swamped with work, while another group’s practicing for the thumb-twiddling world championships. The team can’t perform optimally since their average utilization is well under 100%, and constant bottlenecks turn the value delivery flow into molasses.
  2. Big Walls & Muffled Phones—While throwing context-less tasks to other far-flung departments, I’m often reminded of the game Telephone (instructions here). As proved by that classic icebreaker, every handoff of information introduces error & uncertainty. Everyone knows the difficulty of cross-department handoffs. What’s less obvious is how difficult even inter-team handoffs are, when members lack cross-role context.
To Product Owners, Developers speak Greek. To Developers, Product Owners speak Latin. To Operations Specialists, everyone else speaks Furbish.

When you spend 40+ hours a week in the same role, your language and understanding of the topic become second-nature fast. Which is why when you reach outside of your bubble, you’re flabbergasted by how dumb other people must be to not understand you.

Meanwhile to them your request doesn’t make sense, is written in gibberish, and doesn’t seem important. One person’s speaking Greek, the other Latin, and there’s not a babel fish in sight.

Once you’ve dipped your toes in another field, you’ve passed Klingon 101. Your knowledge isn’t deep, but you know enough to communicate across job roles, and get to the heart of what’s needed. You‘re becoming a “T” shaped person.

Scrum doesn’t care about job titles or certifications. It’s only concern is whether a group of talented individuals can deliver genuine value to customers every few weeks. If a developer needs to test some features to clear a bottleneck, they’ll do it, learning from QA specialists as they go. Not only will the team deliver faster, but each member will develop the tools and language needed to effectively collaborate with each other, no matter their role difference.

You may have to reverse some cultural norms to help your team tear down silos. An environment with high layoff rates or large individual performance incentives will breed a silo mentality. Work with management to stabilize the team, and work with HR to emphasize team performance over individual performance.

Team Green-Pants & the Mexico Mishap: Revisited

What if Team Green-Pants’ members were more T-shaped, and less siloed?

Jim: “By the way, I’ll be on vacation in Mexico for the next two weeks. So…”
Kara: “Hm, Can anyone else handle the deploy?”
Kevin: “I can give it a shot. Hey Jim, remember when I sat in on that deploy a few months ago? Mind if we sync so I can brush up on the process?”
Jim: “Ohh yeah… but what if something goes wrong? I’m not sure if I trust you to handle a prod meltdown solo.”
Kevin: “What about the infrastructure specialist Sara that we worked with last time?. I can see if she’s on-call Monday.”
Jim: “Oh awesome, yeah we can totally sit together today. See if Sara can join as well, it would be good to have her in the room for that.”
Kara: “Sweet, sounds like a plan!”

Spoiler alert: Monday’s deploy goes swimmingly, and the Product Owner is so delighted he brings in Tuesday donuts. Everyone’s carb’ed up and happy.

Back to Reality — Add Scrum Practices to the T

As a Scrum Master, you’ve done your job when the team doesn’t need you, but can’t imagine you leaving.

Although the Scrum Master’s duties are paramount to a team’s success, there’s no secret rituals or blood pacts that only a certified Scrum Master can perform. In fact, great Scrum Masters will aim to make themselves unnecessary to the team. They’ll coach the team until they can run their own Scrum practices, communicate directly with the Product Owner, and remove or elevate blockers without much hassle. So if the Scrum Master gets hit by a bus (or on a lighter note goes to Mexico), the team can uphold their Scrum practices and continue delivering maximum-value quickly.