Serious Scrum
Published in

Serious Scrum

The Ice Cream Truck Experience

Squads goals are better than solo accomplishments

Chasing down the ice cream truck with my friends as it rolled through our neighborhood each summer is one of my fondest childhood memories. While playing outside, we’d hear the distant telltale jingle-jangle of its bell, hop onto our bikes, and track down the wheeled, frozen-treat nirvana. Now that I think about it, outside of sports I played as a kid, ice cream truck hunting was one of my first true team experiences.

Everyone contributed financially, pooling our nickels, and dimes to maximize purchasing power. We rode with an unspoken strategy. One of us biked on the main road while others spread out, and pedaled down side streets, regrouping with a sitrep. When someone got closer to the sound of jingling bells, they’d holler, and the group converged on their position. We repeated the pattern until locating our quarry. Like a BMX-riding hunting party, we cornered our prey, and feasted on its sweet, frozen goodness.

It’s not like we formally planned out that strategy. But through trial, and error, we devised a tactic that proved successful every summer. We worked toward a common goal: sweet, sweet ice cream. Listening, patience, and communication proved to be our keys to success. That being said, how does a group of 8-year-old kids self-organize, and master the concept of teamwork while adults struggle with it? In my experience, organizations tend to implement teams as a group of individuals doing their own thing rather than a forming a singularly-focused unit.

“Individual commitment to a group effort — that is what makes a team work, a company work, a society work, a civilization work.” — Vince Lombardi

If you’ve been in the game awhile, the importance of teams shouldn’t come as a surprise. The Agile Manifesto only mentions the word team 3 times, but to put it in perspective, the principles are only 12 sentences. In the 19 pages of Scrum Guide (TSG), team is mentioned a 17 times. So, it must be an important concept to wrap your head around.

When it comes to Scrum, one of the hardest selling points is the idea of team mentality vs. an individual one. People are thrown together, and called a “team,” but not in the context of completing work items in a collaborative manner. If you live in the land of Jira, this is exacerbated by designating an assignee. Unintentional, or not, the “Assignee” field perpetuates the nonsense idea that work is s’pose to be the responsibility of a lone individual.

How hard will report-mongers resist removing this field in Jira altogether?

Long, long ago, when I used to be front end developer (way before paved roads), writing code used to be a solo endeavor. We’d stockpile Jolt Cola (gross), or Mountain Dew (also gross), and huddle in front of a computer screen. Coding sessions would easily go for 12–18 hours straight, losing ourselves in solitary code-writing bliss. Fast forward to today, as with everything, development practices have evolved. Take paired, or mob programming. With that old school mentality, tryna sell those practices are inevitably met with, “Pairing is going to slow me down,” or “I can get more done by myself.” As if on cue, the powers-that-be fire back with, “Why should multiple people work on the same thing at once? Five people working on five different things is more productive.”

When folks read the bit in the Scrum Guide about teams, they get tripped up on the word cross-functional. You can almost predict it. They have nightmare visions of QA engineers writing Java, or business analysts tryna deploy code to production. But it’s not about that. Cross functionality was always about skills, not people.

For a moment, let’s aside stories of folks running experiments with pairing, or what Woody Zuill is on about with mobbing. At its core, team is about building shared accountability. Some people scoff at the idea, claiming that shared accountability is nouveau mumbo-jumbo that never works. One such old school project manager insisted that it’s individuals that must be held accountable so that, as he put it, “…management knows whose neck to choke.”

If you’ve ever watched the 1989 movie Major League, there’s a scene where Jake Taylor (Tom Berenger) lambastes teammate Roger Dorn (Corbin Bursen) for making a half-assed effort during a play. As life imitates art, in 2010 St. Louis Cardinals pitcher Chris Carpenter chewed out Brendan Ryan for taking his sweet-ass time retrieving his glove between innings. If you’ve ever watched, or played sports, you’ve already witnessed shared accountability. Players hold their teammates accountable for wins, losses, or simply playing the game right. It’s not a foreign concept. Every team that’s won the World Series, or World Cup has subscribed to that idea.

“The strength of the team is each individual member. The strength of each member is the team.” — Phil Jackson

One of the signs that your team might need an intervention, and functions as a group of individuals rather than a cohesive unit, are statement like, “My velocity is 18 story points,” or “I’ve completed coding 20 story points, but QA didn’t finish their part.” These should be red flags. When there’s a slew of items sitting in the backlog already assigned to developers, that’s another indicator.

When I think about my fellow bike-riding ice cream hunters, we could’ve struck out on own, each of us chasing after the ice cream truck solo. But children have an intrinsic motivation to wanna belong to something. I’m reminded of an African proverb, “If you want to go fast, go alone. If you want to go far, go together.” When the critics start hollering, “Scrum doesn’t work,” think back to the mindset instilled within the team. Was it defined as a group of individuals, each assigned to doing their own thing, or a single, cohesive unit, working together toward a common goal?

“Wait… which way are we going again?”

You may think all of this makes little difference, but have you tried it? What would it look like if the individual members of your favorite sports team did their own thing rather than work together? In basketball, that’s what we call a ball hog. Even if they’re in fact a good player, they’re horrible a teammate, and everyone knows it.

Running with my ice cream crew back in the day accomplished a few things: it developed friendships, built trust, and a reliance upon one another. Isn’t that what teamwork is s’pose to be about? If you want great work, don’t build around work. When you do, there’s a real danger that you’ll create a group of individuals simply completing task after task after task. You won’t leverage the real power behind the team. By building around people, giving them the environment, trust, and support they need, great ideas will follow.

medium.com/serious-scrum

Wanna publish in Serious Scrum? Connect with us on Slack to make it happen!

serious-scrum.slack.com

We run a Serious Scrum channel on Slack, and you’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
John Clopton

John Clopton

Certified Sailor. Agile Coach. Public speaker. Author. Urban legend. I’m not a player I just Scrum a lot.