Agile Teams: Don’t use happiness metrics, measure Team Morale

Recently, there’s been a lot of discussion in the Agile world on measuring happiness in Agile Teams. Jeff Sutherland, one of Scrum’s creators, is a strong proponent of such an approach, as evidenced by his posts on the subject (see this and this post, for example). In this blog, I will explore the use of a happiness metric in Scrum and explain why — although it’s a good start — it provides only a very limited understanding of a team’s perception of it’s well-being. I will also present an alternative measure that borrows heavily from research done by occupational- and military psychologists (including myself). This post is meant as a discussion-piece, not a how-to. Although I will address a simple practical application, more details will follow in future posts.

A disclaimer is perhaps useful to understand where I’m coming from. I have a background in organizational psychology and have been working on and off on a PhD on team morale (with a colleague and friend, Maj. Frank van Boxmeer). Although this research project is primary focused on military teams, our work uses generic scientific models and approaches developed by organizational psychologists. I have experience as a consultant for a company that professionally measured job satisfaction and organizational/team well-being.

Happiness metrics: a primer

As a framework for software development, Agile emphasizes teamwork in software development and recognizes it’s human aspect. Delivering innovative, high quality software at a steady pace requires motivated, involved and happy teams. The happiness metric was developed to measure happiness as an indicator of team well-being. The assumption is that happiness is strongly correlated with team well-being. So, a team that’s happy, will also be more efficient, more cohesive, more ready for the tasks at hand and will deliver higher quality software. If people are unhappy, something needs to be done. After all, team well-being is what we are really interested in.

Although there is no formalized approach for measuring happiness in Agile Teams, the most common method is to ask team members to periodically rate their current happiness on a scale from 1 to 5. This can be done as part of the Daily Scrum, during Sprint Retrospectives or even every few hours. Most implementations include some qualitative questions to allow interpretations and facilitate discussion within the team:

• How happy are you with your company? (1–5)
• What feels best right now? (open question)
• What feels worst right now? (open question)
• What would increase your happiness? (open question)

A few implementations, like the one at Crisp, even allow historical plotting and measure related concepts, such as stress. There are several things to like about these metrics:

• They emphasize the human aspect of software development: How can you not like an approach that actively asks teams whether or not they are happy with how things are going? Asking if employees are happy is always a good thing;
• They provide input for retrospectives: The results from the metric can provide useful input for retrospectives. If team happiness is low, there is certainly something that needs to be done. Especially metrics with open-ended questions allow teams to discover sources of unhappiness and hopefully eliminate them;
• They can extend beyond just Scrum Teams: Happiness metrics are useful, no matter what work people perform. Especially in teams. Companies that use happiness metrics should use them throughout their organization;
• They allow individual retrospection: Happiness metrics give individuals an opportunity to reflect on their own state of mind. Being happy should be important, but being generally unhappy can indicate that someone is ready for a new challenge or another job altogether;
• They allow scientific analyses: Happiness metrics allow measurement of team well-being. This is useful as it allows scientific research into what makes teams ‘run well’ (or not). It also allows us to better understand what makes ‘well running’ teams different.

However, the usefulness of any measure depends on how well it captures actual team well-being and provides realistic venues for improvement. Although it’s certainly an excellent start, I believe that the happiness metric is sub-optimal at best. Let me explain why.

One of my biggest gripes with happiness metrics is that they are too subjective to be meaningful. At first glance, a question like ‘How happy are you right now with … ‘ might seem sensible. But take a moment to reflect on what ‘happy’ means, exactly. How would you interpret this question? I’m sure many people will have wildly different interpretations of ‘happy’. Does happy mean that you’re smiling all day? That you jump out of bed in the morning, happy for another day of work? That you are just ‘ok’ most of the time? People will have different interpretations because ‘happy’ is a very subjective state-of-mind. Different interpretations will lead to a different meaning of the responses to these kinds of questions. It’s like comparing apples and oranges.

The metric shown above includes the organization as the source of happiness. But what exactly is ‘the organization’? Is it the team? The whole company? The business unit? The room? If you are like me, you’ll wonder what the scope of the organization is in the context of this question. It’s perfectly possible that a team member is happy with the team, but not with the organization or vica versa. Because the question is too subjective, it allows multiple interpretations which gives different meanings to the responses. More apples and oranges.

Is this really a problem? Well, that depends. If you only use the happiness metric as input for retrospectives, there is room for members to clarify their individual responses. In that case, the metric is just used as a start for discussions. But if you calculate team averages, create and/or show management information, perform further analyses, show aggregated scores to the team, plot historical happiness, you’ll need a metric that measures one thing well. The current metrics potentially measure different things, depending on the interpretations of the individual. You’ll quickly run into problems.

2. The Happiness metric is not task-oriented

When you only ask if someone is (un)happy, you don’t know what they’re (un)happy about. Suppose that someone is in a bad mood, has a pessimistic disposition in general, or is unhappy because of something unrelated to work. In that case, the team can’t really do anything about it. And they shouldn’t. Scrum Teams are not therapy clubs or self-help meetings. Therefore, it’s more useful to ask members if they are happy with their work and the tasks they are performing. A person can be generally unhappy, but he can still be happy with the task he is performing. If they are unhappy with the task, the team can do something about it. So, if you are going to ask any questions about well-being at all, make sure they are at least task- or work-oriented.

3. The Happiness metric is not team-oriented

It’s possible to have a completely happy team that is not performing at all. You can have a happy team that produce sloppy, buggy code and does not complete sprints on time. In fact, the most happy team members are probably those hanging out in the XBox Game Room. Asking if someone is happy does not give you _any _meaningful insights into the team’s well-being. Happiness, after all, is a very individual state of mind. But the happiness metric does suggest that it gives an indication of team well-being and meaningful input for retrospectives. Although an employee’s happiness can certainly affect well-being of the team (and vica versa), I think it’s more useful to measure concepts that are not as focussed on the individual, but rather on the team as a whole.

4. The Happiness metric does no justice to the reality of the work environment

I’m not sure about you, but i’m rarely 100% happy throughout the day. And this is ok. I understand that my job involves tasks that I don’t like. They don’t make me happy, but I accept them because I need to do them. In any team, people will have to do things they don’t like to do, but will do for the team. Swallow the bitter pill. Take one for the team. The happiness metric assumes that being happy is a goal or even a right. Although I strongly believe that being happy in life and work is important and that a company is partially responsible for this, I don’t think that we should give people the false impression that being 100% happy at work is what matters. And the happiness metric does just that. Not on purpose, of course! But if you score low (and are considered unhappy), this obviously is a problem according to the metric. This might make teams feel pressured to deal with it, even though unhappiness is part of the job.

5. Happiness metrics are (statistically) bad metrics

Because happiness metrics are so subjective, they are bad metrics in a scientific and statistical sense. In addition, the metric usually includes only one question about happiness. A single item is usually not a good idea. If you are serious about measuring team well-being, take a measure that is statistically (and preferably scientifically) sound. Occupational psychologists have been working on good measures for team well-being from the get-go. The happiness metrics reflect nothing of what we’ve learning so far. In fact, the happiness metric makes many of the mistakes that occupational psychologists have learned to avoid, like measuring highly subjective ‘states-of-mind’, using only one or two questions, asking questions about the individual when it concerns the team and making questions too multi-interpretable.

6. So, the Happiness metric is measuring the wrong thing

I already implied this between the lines, but I don’t like the happiness metric because it is measuring the wrong thing (and also in the wrong way). Although happiness is certainly important, I believe that a Scrum Team can benefit more from a task- and team-oriented measure that does do justice to the nature of the work environment. What is it that we really want to know as a Scrum Team?

• Are members enthusiatic and energetic about their team and their work?
• Are members willing to take one for the team?
• Are members proud of their team and their work?
• Are members happy to be part of the team?
• Are members feeling valuable to the team?
• Are members happy with their tasks?

I strongly believe that in a cohesive, well-running team, people are willing to go the extra mile even if it makes them (a bit) unhappy for the duration of the task. They will accept this for the greater good. Thankfully, there is a concept that captures these aspects of a well-running team.

An alternative: Team Morale

As a Scrum Master I’m more interested in the morale of my team for the following reasons:

• Morale is more task-oriented: Morale reflects a team’s appraisal of it’s own abilities to deal with the tasks at hand;
• Morale is more team-oriented: Morale is more oriented towards the team rather than the individual. It’s an indication of how cohesive and ‘well-running’ a team is;
• Morale includes happiness, but more subtle: Teams with high morale are generally teams with happy individuals. Teams with many unhappy members will probably also have low morale. But not always. So rather than throwing happiness away as a metric, we’re capturing parts of it through a more high-level concept;
• Morale is less susceptible to mood: While happiness is very susceptible to the current mood of the member, team morale is a more stable perception of how the team is doing. Team Morale can be high, even if an individual has a bad day;
• Morale is not as biased: The happiness metric is, by of it’s definition, biasing people to believe that you should always be happy. ‘Morale’ as a concept is less biased;

So, how do we define team moraleexactly? Thankfully, there is quite a bit of scientific literature on the subject. In fact, we can borrow from occupational and military psychologists that have done this work for us:

‘(Team) Morale is the enthusiasm and persistence with which a member of a team engages in the prescribed activities of that group’ (Manning, 1991).

Manning’s definition is closely related to team cohesion and ‘esprit the corps’ (team spirit). There are alternative definitions in literature, often geared towards specific occupations, like Hart’s educational definition: ‘the energy, enthusiasm, team spirit, and pride that teachers experience in their school’ (Hart, 1994). A similar but less military-sounding concept is ‘work engagement’ (Schaufeli & Bakker, 2004). Manning’s definition is based on research done by military psychologists into high-performing, cross-skilled, self-sufficient military teams that work under high pressure. Scrum Teams can actually learn a lot from how military teams operate. In fact, many modern teams also use iterative approaches to achieve their goals. But that’s for a future blog.

Teams with High Morale usually have the following traits:

• Members are willing to help each other out, no matter the nature of the task;
• Members are proud of their team (and usually tell the outside world) and the work they do;
• Members will go the extra mile individually or for the team, even if it means staying late to finish the sprint;
• Members will persist (not give up), even in the face of high work-pressure, difficult technical problems, nasty bugs or a difficult sprint;
• Members are generally happy in the team and enjoy working there, on a whole;

Teams with Low Morale usually have the following traits:

• Members withdraw from team activities or don’t participate at all;
• Members are not proud of what their team does or are even ashamed;
• Members will stick to a 9–5 (or less) mentality, even though a bit of overwork might turn the tide;
• Members become focussed on doing only their part, and nothing more (‘this is not what I was hired for’);
• Members will easily give up in the face of trouble;
• Members are generally unhappy in the team and don’t enjoy working there, on a whole;

I’m sure you’ll agree that the above more accurately describes a well-running Scrum Team than a happiness metric does. After all, a Scrum Team can be perfectly happy even though they slack off, deliver low-quality code, take it (too) slow or play XBox all day long. Measuring team morale puts a focus on the task at hand, and how the team feels about it’s capabilities to deal with it.

So, how do we measure team morale in a team?

As part of a running PhD research project, I have worked with a colleague (Maj. Frank van Boxmeer) on a set of items that reliably measure Team Morale in a valid, scientifically and statistically sound manner (Van Boxmeer, Verwijs, De Bruin, Duel & Euwema, 2007). I adapted the questions slightly for use in a Scrum Team:

1. I am enthusiastic about the work that I do for my team
2. I find the work that I do for my team of meaning and purpose
3. I am proud of the work that I do for my team
4. To me, the work that I do for my team is challenging
5. In my team, I feel bursting with energy
6. In my team, I feel fit and strong
7. In my team, I quickly recover from setbacks
8. In my team, I can keep going for a long time

You can clearly see that these items are specific. They still measure fairly intangible concepts, like ‘proud’, ‘bursting with energy’, ‘enthusiastic’, but they are more specific than simply happiness. Individual questions are rated on a 1 to 7 or a 1 to 5 scale (I prefer 1 to 7 as it allows more nuance). To calculate the morale of an individual member, we average the score on the eight questions. Team Morale is the average of the individual averages. For those interested, the alpha coefficient (an indicator of reliability) for this scale is very high (0.90, N=2471).

This set of questions is useful in a scientific context. A more practical, shorter version of the measure is shown below:

1. In my team, I feel fit and strong;
2. I am proud of the work that I do for my team;
3. I am enthusiastic about the work that I do for my team;
4. I find the work that I do for my team of meaning and purpose;

You could probably narrow down the set of questions even further. For pragmatic purposes, you could also ask a team what their morale is instead of their happiness, though that will cause some of the problems mentioned above. The four questions above have been selected based on their factor loading on the shared construct of Team Morale and their weight on the scale’s alpha coefficient.

When is this measure useful?

1. When you want a more objective measure of a team’s well-being (perhaps for management reporting or a team monitor);
2. When you want to have a more fine-grained measure, that is more focussed on the task and the team processes;
3. When the team says it’s going ok, but you feel that it’s not, and the team needs a wake-up call;
4. When you want to do further analyses on the results, perhaps even with historical measures;
5. When your HR-department wants to measure well-being regularly (which happens a lot in The Netherlands) and use it for research;

A simple practical application

Although I did not intend this blog as a how-to, but more of a discussion-piece, I will present a simple practical application for those interested:

1. Do the measure before the retrospective, preferably halfway during the sprint and not at the end
2. Ask members to answer the questions on a scale from 1 to 7 on a piece of paper or digitally, individually. Depending on the team’s preference, you can do this anonymously or not;
3. Collect the responses;
4. To calculate individual morale: average the scores per individual (per individual, sum the scores and divide by the number of questions);
5. To calculate team morale: average the individual average’s (sum the individual averages and divide by number of members that entered the questions);
6. On a whiteboard, write down the results or put them in a chart (see below);
7. Discuss the results with the Scrum Team and identify causes of low and high scores. Specifically address how Team Morale can be improved. You can use the questions to pinpoint where the pain is. Try to identify 1 or 2 interventions to improve team morale, but don’t overdo it. A Scrum Team can’t work on 10 changes at the same time;
8. For historical comparison, you can keep track of team- and individual morale to plot out changes over time to see if interventions;

In this blog, I have investigated the happiness metrics that are going around the internet. Although they are certainly a good start, and put focus on the human element of software development, they are far from perfect. Happiness is too subjective, will fluctuate quite a bit and is not task- and team-oriented enough. Happiness, although important, does not seem to be the most useful metric for a team. As an alternative, I presented Team Morale as an alternative. Team Morale is focussed on the team and the tasks at hand, and tells us if a team is working smoothly and feeling well. I also presented a set of questions that can be asked to team members to gain a reliable and valid understanding of a team’s Morale. The responses can be used as input for retrospectives or general team discussions.

The measure of Team Morale presented in this post has since been succesfully used in a number of studies (Euwema et. al., 2009, Boxmeer, Verwijs, Euwema & Dalenberg, 2010, Van Boxmeer, Verwijs & Euwema, 2011) to investigate important causes and consequences of low and high Team Morale. Military psychologists have also investigated outcomes of low and high morale, e.g. cynicism and burnout (Boxmeer, Verwijs, Euwema & Dalenberg, 2010), depression (Britt & Dickinson, 2007), perceived group performance ( Boxmeer, Verwijs, Euwema & Dalenberg, 2010) and organizational citizenship (Britt & Dickinson, 2006). These studies are mostly correlational and have focussed on military teams. It would be amazing if the same measure can be used in Scrum Teams to scientifically underpin the usefulness of Scrum and relate it to subjective and objective measures of quality (bugs, customer satisfaction) and investigate potential causes of low morale (high work pressure, bad management, low team cohesion).

If we have a good, statistically sound measure of Team Morale, we can use it to advance our understanding of the processes at work in Scrum Teams:

• Investigate if Scrum Teams have a higher Team Morale than other teams: Is Team Morale higher in Scrum Teams than in other teams? You would think so. But the measure allows us to empirically verify this. This is useful for scientific research, but can also convince management and skeptics that Scrum is really beneficial to improve the human aspect of work;
• Investigate sources of low and high team morale: We have to investigate what differentiates a well-running team from a team that is not working well at all in terms of their environment and process. In military teams, we’ve already learned that team cohesiveness, task- and social-leadership and task autonomy are very important. Social support from colleagues is also important. By identifying the most important sources, we can determine where interventions are most beneficial;
• Investigate consequences of low and high Team Morale: It would be interesting to know what differentiates teams with low and high Team Morale in terms of their outcomes. Do teams with High Morale indeed deliver more high quality code, as you would think they should? Are the product owners and customers more satisified? Is there less turnover or absenteism? This can help convince management and skeptics that Scrum is really useful;

In my free time I decided to write a small web application called TeamMetrics that can help with the measurement of team morale: https://teammetrics.theliberators.com.

You can already support us with $1/month. Find out more on patreon.com/liberators

References

Boxmeer, L.E.L.M. van, Verwijs, C., Bruin, R. de, Duel, J., & Euwema, M.C. (2007), A direct measure of Morale in the Netherlands Armed Forces Morale Survey: ‘theoretical puzzle, empirical testing and validation’. Presented at Internation Military Testing Association Symposium (IMTA), November 2007 (direct link);

Boxmeer L.E.L.M. van, Verwijs C. & Euwema, M., Dalenberg, S. (2010), Assessing Morale and Psychological Distress during Modern Military operations, Presented at International Military Testing Association Symposium (IMTA), November 2010 (direct link);

Boxmeer L.E.L.M. van, Verwijs C. & Euwema, M. (2011)_, Assessing Soldier’s Morale in a Challenging Environmen_t. Presented at International Military Testing Association Symposium (IMTA), November 2011 (direct link);

Britt, T. W., & Dickinson, J. M. (2006). Morale during Military Operations: A Positive Psychology Approach. In T. W. Britt. C. A. Castro, & A. B. Adler (Eds.), Military life: The psychology of serving in peace and combat: Vol. 1. Military performance (pp. 157–184). Westport, CT: Praeger Security International.

Britt, T. W., Dickinson, J. M., Moore, D., Castro, C. A., & Adler, A. B. (2007). Correlates and Consequences of Morale Versus Depression Under Stressful Conditions. Journal of Occupational Health Psychology 12(1), 34–47.

Euwema, M., van Boxmeer, F., Broesder, W., OpdenBuijs, T., Verwijs, C. & Vogelaar, A. (2009), _The Morale of the Peacekeeping Warrior, _Presented at International Military Testing Association Symposium (IMTA), November 2009 (direct link);

Hackman, J. & G. Oldham (1980), _Work Redesign, _Reading (MA): Addison-Wesley;

Hart, P. M. (1994). Teacher quality of work life: Integrating work experiences, psychological distress, and morale. Journal of Occupational and Organizational Psychology, 67, 109–132;

Manning, F. J. (1991). Morale, Cohesion, and Esprit de Corps. In Gal, R. & Mangelsdorff, A. D. (Eds.), Handbook of Military Psychology (pp. 453–470). Chichester: John Wiley & Sons Ltd;