Does your Scrum team spark joy?

The term “spark joy” entered popular language somewhere in the beginning of 2019. The source of this was the hype around Marie Kondo’s konmari method. In a nutshell, konmari involves households assessing all their possessions by the amount of “joy they spark”, getting rid of the meaningless, refreshing their interior and lives in the process. Now, the hype is gone, but I still find the question of “how much joy does something spark?” a powerful one. It’s applicable in all areas of life. The amount of joy in something really gets to the core of things. Scrum teams are no exception. So, what makes for a joyful team? Let’s get a proper joy-inspection going!

Illustration courtesy of abstrakt.design

The Joyless Team

We’ve probably all encountered a joyless team at some point in our professional lives. I believe most of us know instinctively when we do. In the first hours of joining one, you just feel it. It’s the low energy, the facial expressions, the subtly uneasy interactions, the tone of it all. Whatever this team is doing, it feels like they’re not enjoying it. At best, they’re just going through the motions. When the team gets together, it feels like most team members would very much prefer to just be left alone. Whenever a conversation, a decision, or teamwork is needed, team members silently stare around like it’s a Mexican stand-off. Whoever caves under the pressure first will have to do the work.

Do you feel lucky?

Though there’s hardly a stereotypical “joyless team”, I’ve noticed some recurring patterns in the ways many of them approach their work:

• Each team member is working on their own “island of specialty” instead of collaborative efforts. New joiners are immediately assigned to their personal island. Pairing is considered wasteful, or just plain stupid.
• The team dives into technical solutions without thoroughly considering the problem, context, end-users, and desired outcomes. The team cuts those technical solutions into tiny technical tasks to fit each of the individual specialties.
• Sprints or time-boxes are seen as buckets of work that need to be filled to the brim with the aforementioned tasks. “We do 50 story points every sprint, so let’s fill ‘er up!”.
• Doing too much work in parallel. Starting a lot of efforts, with not much finishing. Optimizing for busyness. Everything is always “almost done”. A sprint later, everything is again “almost done”.
• Commitment to goals or outcomes is avoided at all costs. The team just builds what someone asked for. “Just give us specs and we’ll build it”. If the result is what end-users actually need, that’s not our problem.

Hard conversations about any of this are avoided and pushed forward, building tensions inside and towards the team.

The cycle of joylessness

Often, the sum of these patterns and behaviors kicks off a vicious cycle. They cause the work to not be ‘up to standards’:

• The work doesn’t integrate;
• The work can’t be delivered on time;
• The work doesn’t deliver the value and outcomes expected;
• Trust between the team and stakeholders is damaged.

As a reaction to this, the teams start cutting up the work in even smaller tasks. The work delivered has no value, but they did deliver what was promised. Often, the team will also resort to cutting corners to please stakeholders for the short term. In the long run, this causes delivery to become even slower while the product becomes increasingly unstable. The technical debt causes the team to have to work around the work-arounds. The team is stuck in quicksand; the harder they try to move, the faster they go down.

If this team was a person, you would wonder who hurt them. Something or somebody probably did indeed hurt them, causing these patterns to emerge. It’s not always their fault, but it has become their problem. Whatever may have caused it, it’s sure that this team does not spark joy.

The Joyful Team

Upon joining the joyful team, you immediately sense the good vibes. There’s no escaping them. People are smiling, enthusiastic, and full of energy. It’s almost contagious. People laugh and joke around, but also get down to business. Everyone feels ownership of the team, its work, the way the work gets done, and what it means to the business and end-user. They jump on the opportunity to figure something out or help a fellow team member. It feels more like a party than a team. A group of adventurers on an exciting quest.

Behaviors you may spot in a joyful team are:

• Forming as a group around the outcomes, goals, and larger context of the work they are doing. They pair, swarm, and truly collaborate to reach these goals
• Deeply thinking about the problem, before thinking about the solution. They see technology as a tool to get somewhere, not the solution by itself.
• Creative “good and safe enough” approaches are preferred over “ultimate solutions”.
• Psychological safety and trust. Everybody does their best but it’s safe to fail. Tough conversations take place at the earliest possible time. Courage is rewarded.
• A good sense of when to be strict and when to be flexible. What is non-negotiable, and where can the team be flexible?
• Achievements are celebrated, big and small.

This team acknowledges not everything is certain and that the work they do is complex. But, they are confident they know enough to start somewhere, addressing uncertainties and discoveries while doing the work. The team knows openness is key to delivering value. Seeing their work being successful and making a difference, brings them happiness. This team sparks joy.

Joylessness as a smell

Of course, I’m sketching and generalizing when I describe these two hypothetical teams. No two teams are the same. Many can have elements of both, and in real life, there will be countless other factors at play. Still, at some point the scale tips towards a “mostly joyless” team. As said, I’m very sure we can all feel when that’s the case. It is a distinctive smell, one you notice rather quickly.

In programming, we sometimes talk about “code smell”. It’s when you as a programmer do a quick read through some unfamiliar code and see things happening that make you doubt the quality of the work. The code has a “bad smell”. You can’t fully point out everything that’s rotten or why it has gone bad, but you know just “by the smell of it”, that something is off.

“Joy” is a fundamental team and company smell to me. I struggle to find a more encompassing north star. Something fundamental like ‘trust’ comes to mind, but at the end that too affects joy. An environment with little to no trust does not spark joy.

When it comes down to it, there are two essential reasons I find joy to be both so telling and important:

1. I have never seen joyful teams deliver bad work.
2. I have never seen joyless teams deliver great work.

Sure, there are always a few exceptions to be found. But that’s exactly what they are, exceptions. Joyful teams are nearly always in a good place overall. They like the work they do, and are acknowledged for their contributions. I’d dare to say we need to declare ‘joy’ or ‘fun’ a missing Scrum value:

A work in progress, but you get the point. I’ll refine it a bit before submitting to Scrum.org ; )

The 2017 Scrum Guide states that Scrum teams are made up of “motivated individuals”. That always stood out to me, motivated individuals being a prerequisite. That’s honestly not always easy. The 2020 edition instead describes the Scrum team as a “cohesive unit of professionals”. Considering the both of them, let’s not underestimate the ‘cohesive’ and ‘motivating’ qualities a bit of joy and fun can have.

Moreover, Scrum borrows a lot from sports analogies and game theory. Cross-functional teamwork, outcome over output, quick time-outs to realign the game plan; the list is big. Any decent sports team, however, is also having fun. Any sports fan knows when they’re watching their favorite team play a frustrated, joyless match. Something just isn’t working for the team. There’s no soul in what they are doing. Chances are good they’ll get crushed by their opponent that day. Great teams are serious, engaged and committed, but also enjoy the hell out of the game they are playing.

Creating some sparks

In general, people tend to forget about joy and fun in professional settings. It doesn’t come naturally. Many of us have internalized in some way or another that “work isn’t the place for fun”. Joy and work live in separate worlds, because if work is too much fun, work might cease to be work. Think of the consequences!

So, we really need to get that conversation going. And that’s exactly what my first advice would be. When confronted with a joyless situation, simply ask “what would make this more enjoyable?”. What could make this fun? Over coffee at a later point might even be better. Coffee is more joyful than meetings anyway.

Apart from calling it out on the spot, running a sprint retrospective around this topic can really help.

“OK everyone, great you’re here. We need to have a serious talk… about fun.”

Here are a few formats I found good for talking about the levels of joy in a team:

• Using Autonomy (being in control), Mastery (being able to master your craft), and Purpose (making a difference and being recognized for your efforts) as categories for discussing improvements for the team. These are borrowed from Daniel Pink’s “Drive”. He describes them as the three areas being key to motivation and happiness work.
• Using the Scrum Values as categories for discussing improvements for the team. Even though joy is missing as an explicit value, it is a good starting point. Teams that experience a lack of focus, commitment, courage, openness or respect, likely aren’t enjoying themselves.
• Simply go with “What, about our team and way of working, sparks joy?”, with of course a “What doesn’t spark joy?” next to it. Pretty direct and it gets the job done. If you have a flair for the dramatic, or if things feel really bad, a “Why are we not enjoying ourselves?” will also work.
• The TRIZ exercise from Liberating Structures. In this three-step exercise, you first ask “How can we make this team the worst team ever?”. Anything goes: terrible behaviors, dreadful rules, the worst tooling, releasing velociraptors, anything goes. The crazier the better. From there you move on to “What are we doing right now that resembles topics from step one?”. Maybe you don’t have velociraptors skulking about the office, but there is a manager with pretty similar traits. The final step is brainstorming actions for improving the pain points from step two.

For more practical ideas about joyful team collaboration, I’d like to refer you to “The Scrum Masters Playbook” by Evelien Acun-Roos and Sjoerd Nijland. A core thought behind this book is that no matter how much you read about Scrum, it is first and foremost “meant to be played”. I couldn’t agree more; playfulness sparks joy.

Closing thoughts

To some of you, it might sound like I’m just using different words to describe zombie Scrum or perhaps a feature factory. There’s a definite overlap there, but it’s not 100%. I have observed teams have great fun and deliver good products using only “mechanical” Scrum. Causes for joylessness can be as small as “bad office coffee”, or as big as “this company has no moral compass.”

Whatever the cause, anyone responsible for a team should strive to make it more joyful. Not just because joyful teams deliver better outcomes, but because most of us are doing this 8, 9, 10 hours a day, 4 or 5 days a week. If something is going to soak up nearly a third of our lives, we better make sure we enjoy the hell out of it.

Join us! Do you want to write for Serious Scrum or discuss Scrum?