I Love It When a Team Comes Together
I’m pretty sure that someone’s already written a post about the A-Team, tying them back to Scrum, but I’ma be honest. I love the A-Team, and I couldn’t help myself. Hands down, it was my favorite TV show back in the day, and I even saw the 2010 movie on opening night. I’m still a big fan. If you’re unsure about my love affair with the A-Team, check out my Scrum Master toolbox.
When I think about why I still love the A-Team so much, it probably has something to do with how teams are part of the Scrum Master dance. It’s our job to be the team’s hype men/women, and coach people how to leverage the power of Scrum for good. I love metaphors, and for me, the A-Team epitomizes what Scrum Teams should look like. Unfortunately, the term “A team” has become synonymous for groups comprised of nothing but all-stars; the go-to players, or superstars. Sure, that worked for the ‘92 Dream Team, but it’s no secret that stacking the deck doesn’t guarantee superstar results, may create a team that doesn’t play well together, or gasp, hurt performance.
What makes a great team? It’s more than throwing a buncha skilled people together, each doing their own thing, or randomly forming teams because Jeff, and Ken said that's what you’re s’pose to do. Teams should be a cohesive unit coming together to reach a common goal. It’s about... well… teamwork. That’s why the A-Team is the perfect model. John “Hannibal” Smith, Templeton “Face” Peck, Bosco Albert “B.A/Bad Attitude” Baracus, and H.M. “Howling Mad” Murdock. Throw in Amy Amanda “Triple A” Allen, and you’ve got the complete Scrum Team.
“Scrum Teams are self-organizing, and cross-functional. They choose how best to accomplish work, rather than being directed by others outside of the team. They have all the competencies needed to accomplish the work without depending on others. The team is designed to optimize flexibility, creativity, and productivity.” — The Scrum Guide
Let’s break down what the guide said, and how it relates the A-Team.
Scrum Teams are self-organizing…
Allowing a group of developers to organize by themselves sends chills down managerial spines. Upon reading that bit, fear swells behind their eyes, and they question what their role will be in this new world, envisioning that their jobs are now obsolete. But it was never about asking teams to take up managerial decisions, advise on career advancement, or fulfill similar duties. That’d be self-management. Self-organization is about shifting the authority of decision-making around what they already know: software development. The A-Team decided which tools to use, and how to rescue a reporter kidnapped by a drug cartel. And when Amy started getting “on the jazz” like Hannibal, they brought her on as a new member. Those are the kinda decisions that shouldn’t be dictated, but put in the hands of the team.
Every time cross-functional is mentioned, someone inevitably throws out the term, “T-shaped people.” But let’s be honest. How many of those kinda folks exist in the wild? Folks should pitch in when necessary, but the simplest translation is that teams should have everyone aboard who can help to finish the job. Murdock can’t rebuild a transmission, but he can drive the getaway car when needed. B.A. can’t fly a plane, but he can help secure the aircraft before takeoff — though he’s deathly afraid of flying.
Everyone has different skill sets, and performs them at different levels of proficiency. That’s why Hannibal is the planner, Face is the smooth talker, B.A. operates heavy machinery, and Murdock is the pilot. The A-Team is the epitome of cross-functional.
They choose how to accomplish their work…
Think about Sprint Planning. During this event, developers aren’t handed a to-do list, and assigned work from a manager (though sadly, I’ve seen this in the past). They negotiate what they can realistically complete, and pull in tasks when they’re ready. In similar fashion, the A-Team chooses who hires them. People typically come to the team with a problem — like two college girls hoping to hire the A-Team to rescue their professor who’s been kidnapped by the mob. In true pull system fashion, the team then decides whether, or not to help.
Not only do they choose the work, but also how to do it. Teams are the ones closest to the work, so why not lean on their expertise, and let them figure out how to best tackle it? Jumping in, and out of random disguises probably won’t work for your team, but it most definitely worked for Hannibal.
They have all the competencies needed to accomplish the work…
At my gig, we roll with the Scaled Agile Framework (SAFe). If you’ve never been to Program Increment (PI) Planning (a.k.a. Big Room Planning), it can be overwhelming. It’s here where team are s’posed to call out dependencies. I often butt heads with the framework, especially when it comes to the concept of dependency management. In my mind, there are two different schools of thought with dependencies: manage them, or obliterate them. Guess which way the A-Team prefers.
When they got captured, did they rely on someone else, or wait for external forces to bust them out? Hell no! They built a slew of awesome armored vehicles, and smashed their way outta danger. The A-Team is self-contained, comprised of everyone needed to accomplish the mission, and resolve impediments. Scrum Teams should too.
…designed to optimize flexibility, creativity and productivity
This bit only calls out three things, but for me, it encompasses the intangibles of a team. Building a flexible, creative, and productive team environment requires a lot of ingredients: innovation, collaboration, trust, constant improvement, a culture of learning, experimentation, acceptance of failure, encouragement, and having each other’s backs. This is by no means an extensive list, but my point is that it takes more than three simple things.
It’s like that time when the A-Team infiltrated a prison fight club. They pulled out every trick in the book, including when Murdock used trash bags, and hair dryers to build a hot air balloon, escaping by flying over the prison wall.
Maybe the Scrum Guide had the A-Team in mind all along when they envisioned how teams should function? Probably not, but that’s what I’m going with. So, don’t model your Scrum team like an “A team,” but after the A-Team. You’ll love it when the team comes together.