In several previous posts,

I’ve explored agile metrics as a set of 4 KPI areas that are typically monitored in agile instances. In this particular post, I want to drill into team health or “happiness” as a viable and important agile metric area. In fact, I might argue that it’s your core metric.

Let’s look at a couple of approaches.

Crisp – Team Barometer

In this blog post:

http://blog.crisp.se/2014/01/30/jimmyjanlen/team-barometer-self-evaluation-tool

Jimmy Janlen of Crisp describes a sort of reflection or retrospective technique for teams.

They start by establishing a list of “powers” or characteristics of agile teams. Then for each of them, there is defined a Green and a “Red” variant. I’ll use one of their examples:

Characteristic: Power

Green = we go out of our way to unblock ourselves when we run into impediments or dependencies.

Red = when we run into problems or dependencies, we alert managers, ask for their help, and then wait.

You can see the opposite nature of the question. In his example post, he recommends 16 difference characteristics. You could use all or some of them or even come up with your own.

I like the variant of picking from his list and perhaps creating a few of your own that are specific to your context. I also think 16 options may a bit too many for more in-depth conversations. And Jimmy suggests this might be the case as well.

Consider the team barometer session to be similar to a retrospective. In fact, I could see you replacing a traditional retrospective with a barometer check every few sprints.

I often say that the most important thing in an agile team is their behaviors, that is, are they walking their talk. And this is a great way to explore behavior from the overall teams perspective.

At Spotify

Crisp coaches seem to be engaged quite a lot with Spotify, so they’ve had some influence in introducing this method there.

There are two blog posts that discuss it. One is directly from Spotify. The other is by Barry Overeem and details his experience with it. Both posts have graphics and/or photos that significantly help us understand how to assess teams. I particularly like some of the photo’s in Barry’s post.

Spotify seems to use the tool for team (squad) self-assessments across a tribe. So the results are useful at a squad and tribe level. They also do it for the folks within a squad and for squad supporting teams – so that you get a broad-brush view of the health of the tribe-level ecosystem.

While focused on team health, it is again, largely a retrospective technique.

UX Health Check

Anders Ramsay shared a post where he explored some of the “healthier” aspects of UX to developer and agile team interaction. It’s not graphical, but it does present a view that could be quantified with the Crisp technique.

You can read about it here: http://www.andersramsay.com/2012/12/04/agile-ux-health-check/

Quality / Testing Happiness Check

This is an oldie, but goodie in this genre of data radiators. In 2008, Jeff Patton shared a post in StickyMinds:

http://www.stickyminds.com/article/simple-strategies-keep-quality-visible

presenting a simple strategy to keep quality visible. In it, he illustrated how a test team could make a table represent component or functional areas of an app they were testing.

Then, on a daily basis, the testers would assign a Happy, Sad, or Neutral face to each functional area they were testing / tracking.

It was a great way to “radiate” the feelings of the test team (happiness) over application stability and maturity. And this would generate discussion involving the whole team as to what need to be done to turn those frowns upside down ;-)

Crisp – Organizational “Happiness”

To round out this post, I thought I’d bump things up a level and look at these metrics at the organizational level. Again, Crisp is a thought-leader in this space. In a powerful blog post, Henrik Kniberg walks through an evolutionary process at Crisp.

First they articulated their company vision and mission across the entire organization (team). Crisp is fairly small, so this was easy for them. However, size is not an excuse for not establishing directional clarity.

Now based on their vision and goals, they constructed a monthly, open-ended, company-wide happiness spreadsheet that tracks overall company happiness. It’s in a Google spreadsheet, so open and visible to all.

As you see in the article, Henrik shares several examples where happiness feedback inspired adjustments on the part of the organization.

Below is a link to the original post and two others that are inspired by it.

And a contrary point can be found in this post:

http://blog.agilistic.nl/agile-teams-dont-use-happiness-metrics-measure-team-morale/

Where Christiaan Verwijs makes the case for moving from happiness to morale. I’m not sure I found it to totally change my mind on the value proposition of these sorts of metrics, but it is thought provoking.

The Key to it ALL

I just want to emphasize that the key to all of these techniques is something beyond the colors, faces, and emotions.

First, it’s the transparency and the conversation(s) that the health indicators inspire that are crucial. Whether the conversations occur in real-time or during a reflection, the fewer and deeper the conversations, the better the results.

And they have to focus towards improvement ideas and ownership over whining and complaining.

The second key is ACTION. In my classes I often talk about information radiators as one of the primary status indicators in agile teams. But radiating the information is the easy part.

The hard part for an information radiator is inspiring or driving action. It’s the whole point of them. If an information radiator doesn’t inspire action, then it’s a poor radiator – so replace it.

The third key is being able to effectively HANDLE the TRUTH. This really is at all levels of the organization. For example, one of the worst things you could do is capture these sorts of measures in a culture where leadership is micro-managing all issues and solving problems for the teams. In this setting, the teams (if they had any common sense at all) would game the feedback to protect themselves. And thus, the happiness feedback would be meaningless.

So to be crystal clear, the keys are:

  • Happiness-driven conversations and improvement;
  • A preference towards action over discussion;
  • And congruent handling of the happiness data up and down the organization.

Wrapping Up

In the spirit of this article, I’d like to check your happiness with my blogging / writing. In this case I’ll be using Net Promoter Score as the means of doing it.

Here’s a link to a short survey. Please fill it out.

https://docs.google.com/forms/d/1nToX5i1X31cYQYbfUXiWH31YElPf7rsRlTme0gMXkMw/prefill

What I promise to do is expose my readership’s Happiness Factor in a future post (or comment to this one).

I just hope everyone is relatively happy…

Stay agile my friends,

Bob.

Comment