Emo: Creating Happier Teams (with Scrum)

Abstract:

Emo (short for Emotions) builds on top of the Scrum framework as a means to further improve the efficiency and productivity of Scrum teams by increasing their happiness levels.

Problem Statement

While agile & Scrum consistently deliver business value and significantly increase team efficiency it is also a well-known fact in psychological research that personal and team happiness can impact a team’s output. This paper discusses two simple methods that Scrum teams can adopt to increase their team’s overall happiness and productivity.

Background

So far Agile has proved to be a very efficient model for building software. From its inception via the Agile Manifesto in 2001 [1] until now, agile frameworks have been adopted in hundreds of thousands of companies worldwide and users of agile have recorded great benefits. Increasingly, agile has been applied to all sorts of new areas from marketing to sales, from education to wedding planning.

So what exactly is Agile? This question has gotten difficult to answer with time as more and more agile frameworks, practices and approaches emerge. But quite simply, at its heart, agile is about being nimble and swift. It’s about being able to react quickly to market changes, customer requests or sudden unexpected events. Agile helps companies stay relevant even as they serve customers whose needs are changing frequently.

Within Agile, Scrum has emerged as a proven way of working nimbly. There are other frameworks out there too like eXtreme programming (XP), lean software development, test-driven development (TDD) and others. And a lot of companies have found success in blending multiple frameworks.

The simplicity of Scrum makes it alluring for businesses because from startups to small businesses anyone can adopt Scrum quickly and easily. Let’s be clear that it can take a while to become efficient at practicing Scrum, but it’s still relatively easy to get started. The guiding rules that Scrum offers helps teams work efficiently in small groups (between three-nine) and deliver a working product every few weeks (typically two to four weeks, most commonly two weeks).

The idea of releasing a working product, or an iteration of a working product, every couple of weeks is one of Scrum’s top attractions for companies. In today’s fast-paced world companies know that if they can’t keep up with customer’s changing needs they won’t be in business very long. Gone are the days when you could plan for a software for six months, build it for six years and release it to the public in the seventh year. If you do that today, by the time you release your product, almost certainly your product will be obsolete. Think of how many iterations the iPhone has gone through in the last six years — from the 3GS to the latest iPhone X. Now imagine that you started work on the design of the first version of a smart phone seven years ago, worked on it for a year, froze on the design six years ago and then finished all the other manufacturing, administrative and marketing steps to release it today. What do you think would happen? The design and functionalities would look really dated right?

A clear advantage of adopting Scrum is that it requires you to produce releasable chunks of work every two weeks or so. This helps to frequently tap into real time feedback about our product and fine tune it accordingly. Even more important, we get closer to building something that our users/customers want.

In fact, iteratively built software that incorporated real-time user feedback increased project success industry-wide from 16.2% in 1994 to 35% in 2006 which in turn increased the industry-wide return on dollar invested in software from 25 cents in 1998 to 59 cents in 2006 for a compound annual growth rate of 24% [2]

Most of you might already be familiar with Scrum. For the benefit of those who aren’t, let’s summarize the salient features. Scrum recommends small team sizes of three to nine people, short sprints of work like two to four weeks, and a focus on deriving the most business value at a sustainable yet productive pace. In Scrum you break up the work that needs to be done into small chunks and organize it in order of priority, tackling the most important items first. One person takes on the task of prioritizing the items to work on. This person is called the Product Owner. The Product Owner focuses on the important items, meaning the items that provide the most business value. The development team which is meant to comprise of folks with all the skills needed to get the work done start off a sprint with a Sprint Planning meeting and then do daily check-ins called the Daily Scrum. At the end of their sprint they do a Sprint Review to demo what they developed. After that they discuss what worked and what didn’t at what’s called a Sprint Retrospective. Every sprint the teams must complete a piece of work and demo it or better yet release it to the public/their customers, so that they can gather feedback and improve. Once a Sprint is over, the team starts work on the next Sprint. In this way the team gets into a cadence of working at a sustainable pace to deliver something concrete every two weeks.[3]

The Emo Framework

While Scrum encourages an action bias of getting a demo-able product readied every two weeks, underlying team dynamics and their happiness levels can impact performance. Consider this, what if team members don’t get along with one another? What if they’re unhappy with the work they’re doing or dislike a particular quality in a fellow team member? Or maybe they are depressed and lonely. These things can not only impact individual performance but also dramatically affect team performance. For the last eight years I’ve had the honor of listening to people’s most pressing and private worries in my practice as a Psychotherapist and among other things, work-place stress has always been a prominent topic. I have also been on the other side of the fence, in extremely stressful corporate environments and seen first-hand how stress, anxiety and unhappiness can affect performance. So, an important question in the successful practice of Scrum is how do we measure where the team stands emotionally and how they are feeling? And how do we help them feel better, happier?

Daniel Goleman, author of “Emotional Intelligence” says, “happiness fosters an increase in available energy and quietens negative feelings that generate worrisome thought.” He continues, “this configuration offers the body a general rest, as well as readiness and enthusiasm for whatever task is at hand and for striving toward a great variety of goals.” [4]

Emotions like anger, fear, anxiety, depression and hopelessness can considerably drain team members of vital energy and resourcefulness. It can color their perspective and reduce their productivity and worse, negative feelings are contagious, they can spread through the entire team and reduce morale.

To understand the important role emotions play in our lives consider the evolution of brain structure. The most primitive part of our brain which we share with all species is the brainstem. It sits on top of the spinal cord and controls basic life functions like our breathing, heart beat etc. It’s largely autonomous, it doesn’t think or learn. Beyond the brainstem emerged the emotional centers. For millions of years brain structure remained that way. Only very recently did the thinking brain or the neocortex evolve from our emotional centers. The fact that our emotional brain existed long before our rational brain came along, shows the continued power and importance of emotions in our day to day life. While the neocortex has allowed us to make enormous progress as humans by enabling us to comprehend abstract ideas and complex feelings, still in “crucial matters of the heart and in emotional emergencies” our neocortex still defers to our limbic system — the emotional centers.[5]

Some might argue that the Scrum values (commitment, focus, respect, openness, courage) can push the team to be forthcoming and open with each other, and if they’re unhappy, to talk about it. And in Coaching Agile Teams, Lyssa Atkins talks about how teams can become high performing by practicing the Scrum values. [6] But typically team discussions are limited to work impediments and personal or interpersonal issues stay under the rug.

In his book Fifth Discipline, Peter Senge says “structures of which we are unaware hold us prisoner.” [7] This insight can be applied to teams as well where toxic team dynamics however subtle can eat into the team’s overall productivity and happiness. In “Managing at the Speed of Change” Daryl Conner talks about the dysfunctional behavior that sets in when people can no longer successfully deal with the changes in their lives. He provides examples of what dysfunctional team behaviors look like. Even in teams with low levels of dysfunction he says the following behaviors are expected: poor decision making, inappropriate outbursts at the office, increased conflict, decreased directness and defensive behavior. For teams with extreme dysfunction it is common to see sabotage, chronic depression, actively promoting a negative attitude in others and psychological breakdowns. Sometimes the team is so overwhelmed with all the change going on that they are like saturated sponges unable to assimilate anymore change.[8]

Emo is about specifically capturing individual and team happiness levels. To do this team members anonymously:

1) Rate their general level of happiness on a scale of zero to 10

2) Rate their happiness working in the team on a scale of zero to 10

They write these numbers on two post-it notes marked General and Team and drop it into a jar.

These numbers are then added to arrive at a composite score for the team and put up on a chart for the team to see. The team can track these numbers over several sprints and discuss ways in which they can help each other.

The rationale for asking team members how happy they are is that it helps to understand their specific situation. Maybe they are unhappy in their personal life. Asking them how happy they are working with their team helps to understand how well they’re getting along with the team and identify any under the radar team conflicts. Let’s say a team member’s general level of happiness is 7 out of 10 but their level of happiness in working with their team is a 4 then clearly they are having problems in working with their team. Or maybe they are terribly unhappy at home (a 2 out of 10) but happy working with their team (an 8 out of 10).

Next, in order for team members to be able to talk about the things that bother them and affect their performance, they have to develop a degree of openness. This can take time and for some teams it may never happen. Yet without there being this openness, it is hard to build rapport and unlock team potential. To address this, the Emo recommends developing a routine of writing pieces of appreciation for each other and at least one piece of feedback for each team member once a week.

For example, a piece of appreciation might say

“Sonia helped me learn an especially difficult piece of work this week. Thank you!”

Or

“Thanks David for a good laugh.”

Or

“Lisa thanks for walking me through the hard parts.”

Being appreciated by the team will help the team stay motivated and enable them to review feedback without getting defensive.

As we all know, receiving feedback, especially ones where someone highlights our drawback or points out a fault, is difficult. Anytime someone is even gently critical of us, we feel rejected and Psychology is reef with how painful it is for humans to deal with rejection. Yet, constructive feedback is also hugely helpful in taking us to the next level in our work or personal life. So how do we ensure that the feedback we’re sharing with our team invigorates and helps them instead of hurting?

A large problem with feedback is the way it is delivered. Those who use harsh words, talk sarcastically or come from a command and control style when delivering feedback are bound to elicit defensive responses in the other person. Unfortunately, most people giving feedback end up voicing it as a personal attack rather than a specific issue that can be worked on. This defeats the entire purpose of giving feedback this means we need to offer feedback in a way that the other person can lovingly embrace it and that can only come from our personal commitment to help the other person. In the Emo approach Scrum teams make this commitment as a group and incorporate it into their working agreement as a team. It could read something like this:

“As a team we commit to helping each other grow and promise to offer constructive feedback with the sole intention of helping the other person improve.”

Once such a working agreement is in place, the team can then have two feedback bowls — one for appreciation and one for feedback and keep it in the team room. Team members write out their feedback and appreciation and drop it into the jars. Team members can type it should they choose to keep the feedback anonymous.

Typically, a specific feedback question such as ““What can this team member improve on?” is a good guide post as team members write their feedback. The benefit of a direct question like the one above is that it helps team members to frame their feedback in the context of that specific question and keeps it relevant. To ensure that the feedback is even more relevant, request team members to keep it short. Preferably 2–3 words. Maximum 10 words. As an example, a team member may write: “Temper/Anger Management” and leave it at that. Notice, no other details are needed. There is really no need to expand it into a long note about the time Sonia flew into a rage.

Teams can choose whether they wish to openly discuss the feedback received or if they’d like to privately read it. Discussing it openly is helpful and a group discussion around areas for improvement can be cathartic and greatly help team members to develop deeper respect for others and form deeper interpersonal relationships with each other. If the team wishes to read their feedback in private, they can do so as well.

The 5 Minute Test

Emo is purposefully brief and simple to use. Scrum teams are already super busy and new ways or working, bulky questionnaires that take hours to fill and other cumbersome exercises can end up being counter-productive. Adopting Emo only takes 3–5 minutes.

Summary

Let’s summarize what Emo looks like in practice:

Happiness Index:

In two boxes/jars marked General & Team, the team:

1) Writes out their general level of happiness on a scale of 0–10 where 0 means most unhappy and 10 means very happy.

2) Writes out their individual level of happiness in working in the team again on a scale of 0–10 where 0 means most unhappy and 10 means very happy.

The scores are then added and displayed as a composite team score. Over time the team gets to see where they are as a team on the happiness scale and meaningful conversations can take place about how they can help each other feel happier and more productive.

Appreciation & Growth:

The Team also maintains two jars — the appreciation jar and the feedback jar. Each sprint they put:

1) Notes of appreciation for each other in the team jar

2) Area for improvement in the feedback jar

If they have nothing to write that’s ok. Although it is important to be careful in this regard. Given a choice, the entire team might slip into the mode of putting nothing in the feedback jars even when they are aware of improvements their team members could work on because giving feedback is always fraught with the tension of how the receiver of the feedback will react.

One way to help teams share areas of improvement for each other is to encourage them to envision that they have been entrusted with the work of making their team members the best that they can be, so it is both in their and their team member’s interest to discuss areas of improvement.

If you’re currently using Scrum and tried out Emo I’d love to hear from you. What worked? What didn’t? Where did you face problems?

References:

1) M. Fowler and J. Highsmith, “The Agile Manifesto,” Dr. Dobbs, July 13 2001.

2) Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, and Jeff Sutherland, “Scrum: A Pattern Language for Hyperproductive Software Development”

3) Jeff Sutherland & J.J Sutherland, “The Art of Doing Twice the Work in Half the Time,” New York, 2014

4) Daniel Goleman, “Emotional Intelligence,” Bantam Books, 1995

5) Goleman, p. 10

6) Lyssa Atkins, “Coaching Agile Teams,” 2010

7) Peter M. Senge, “The Fifth Discipline” DoubleDay Books, 2006

8) Daryl Conner, “Managing at the Speed of Change” Villard Books, New York 1992