What agile retrospectives won’t improve, and what you can do about it

I hope you’re doing retrospectives in your project teams. Retrospectives are one of those essential rituals of agile practice. They’re fast, they’re easy, and a great way for a team to focus on how to improve what they’re doing.

But the thing with retrospectives is that they sometimes become all about the practice of your team, rather than the intent of your team. They become all about the team’s shoulda woulda coulda, rather than the team’s purpose. At worst, they become just about firefighting rather than fireproofing, they slide into wastes of time like Tom Mitchell’s meeting, and people come to loathe them.

Limited language gives limited results

Don’t get me wrong, it’s necessary and useful to have conversations about improving project efficiency and so on. But often retrospectives end up dealing only in project language: sprints, tasks and actions, technicals. Over time, as a team you might find that you’re not talking about the team anymore: team dynamics, team morale, and so on. And before you know it, the forest of improvement gets lost in the trees of the minutiae.

And let’s face it: it’s much easier to talk about project mechanics, rather than the soft squishy language of human interactions. But there are some issues that go on in teams that have nothing to do with sprint burndowns, and everything to do with these human interactions. And the longer you leave those sorts of issues untreated, the greater their impacts are on the team and the work at hand.

Here’s an example. One of the oft-touted benefits of working in an agile fashion is shared responsibility: everyone in the team can take the initiative, grab work off a backlog, proactively help each other out, and so on. But we’re human, and things don’t always work out that way: work is late, people aren’t always forthcoming when they need help, or some team members might just go for their preferred type of work over more important urgent work.

Now, in the language of projects, you can talk about who is assigned what tasks, when they’re due, who should do what, why work is getting delayed, and so on. I’m sure you’ve had plenty of those discussions. But often the real conversation to be had is not in project language, but in people language: what are peoples’ assumptions and expectations? Where are the misunderstandings? How do people feel about their work? Why are the same improvement actions coming up again and again?

People language is hard. They don’t teach people language in Comp Science degrees. But we have to have those “people language” conversations if we’re to make teams perform at their best.

You’re the doctor, your team is the patient

One way that has really helped us at Atlassian is to take on a doctor/patient mindset, where everyone in a team sees themselves as the doctor, and the team as the patient. And like any patient, teams present themselves with vital signs.

We’re big on creating an environment where people can feel that they’re doing their life’s best work, and it’s crucial to us that teams have this confidence, mutual understanding, and mutual respect. So a few of us asked ourselves: instead of vital signs like blood pressure and heart rate, what are the vital signs for teams and team health?

We went throughout the company, and collected all the vital signs that people used, to discern how their teams were going. For us, this boiled down to these eight health areas, or vital signs:

1. The project has a full-time owner. There is one lead who is accountable for the result of this project. This needs to be someone whose time is at least 80% dedicated to it, and who can champion the mission inside and outside of the team.
2. The project team is balanced. Roles and responsibilities are clear and agreed upon. The project has people with the right blend of skill sets (though it’s important to acknowledge that team members can change from stage to stage).
3. The team has a shared understanding. The team has a common understanding of why they’re here, the problem/need, they’re convinced about the idea, they’re confident they have what they need, and they trust each other.
4. The project’s value and metrics are clear. The team knows what success means from the business’ and user’s perspective, and there’s a unique value proposition in place. Success is defined as a goal, and everyone understands how it will be measured.
5. The project has an end-to-end demo. Some sort of demonstration has been created and tested that gives everyone clarity, shows why this problem needs to be solved, and proves its value.
6. The project has a “readme.” The project is summarized in a one-pager that is shared and available to anyone who wants to understand the purpose of the project and its value.
7. The project’s dependencies are clear. The team understands the project’s level of complexity, the infrastructure involved, risks, resources needed, effort required, and timeline. Everyone knows who they depend on, and who depends on them.
8. The project has velocity. The project is making incremental progress at the right pace, and iterations are being delivered to stakeholders (and even better, to customers). The project team is learning along the way, and making course-corrections where needed, resulting in greater success.

Together, these became a list that any team could assess themselves against. When teams talked about these vital signs, it forced them to get into “people language.” And this became the Health Monitor.

The Health Monitor: getting and keeping teams healthy

The Health Monitor is a session that a team runs to assess how the team as a whole is going, above and beyond the regular minutiae and mechanics of the work itself. Each session goes like this:

0. Set up

Someone (usually the project manager, but anyone can do this) grabs a room, the project team, some pens and paper (or a whiteboard), plus enough snacks and caffeine to keep the collective energy up. Put up a large sheet of paper with the eight area names in rows (or write them on a whiteboard), then set the tone for the session: no right or wrong answers, everyone’s opinion is equal, and there’s no hierarchy since the full team is required for a project to run smoothly.

1. Rate the vital signs

Each team member rates their team against each of the eight health areas, as either green (all good), amber (OK but needs work), or red (not good). This gives everyone the opportunity to have a say.

2. Bring the ratings together

All team members then bring their individual ratings together next to each health area row, and each person talks about their ratings. The group can then have a discussion about each area: did everyone rate it the same color? Or different colors? Why was that?

3. Make the prognosis

Give a pen/whiteboard marker to the project’s full-time owner. If you didn’t have one when you walked in the room, you’ve probably identified one by this point (wink). Lead by the full-time owner, and as a team, everyone decides what one color to rate each area. This gently forces the team to work together to achieve a common outcome. Any differences that aren’t resolved should become actions to follow up, not just left hanging unresolved.

4. Prescribe the treatment

Again as a team, discuss: how would the team get any non-green areas to green? What specific actions could we take? If all of this is a bit overwhelming, just pick the two top areas and focus on those.

Each health monitor session goes for about 30 minutes (more the first time), and teams do them as often as practical — especially if someone has that feeling that something is going wobbly — but never too often that it feels like a chore.

There is real magic that happens in the discussions about varying color ratings, and how to get to green. There are usually great “a-HA” moments, where people realize that they haven’t had a shared understanding of the project’s goals after all, or they’ve been carrying some assumptions that have been blocking someone else from working at their best. It might be hard at times, but there’s no hiding behind tasks on a board or schedules and deadlines; team members get to air their concerns and expectations with each other, and have richer conversations where it really matters.

It’s important to note that these sessions aren’t about gaming the board, and keeping everything green. That wouldn’t be useful for anyone.

They’re also not about getting really technical. We’ve had a lot of questions from others outside of Atlassian about why we use three colors, and not a score out of 10, or five levels, and so on. The truth is: it’s not about the colors, it’s about the conversations that picking colors provokes.

The Health Monitor is also a living asset, and is recorded as a poster on a common wall and/or in the team’s wiki space. Anyone can see how the team health progresses over time, session after session. Program managers love them too: each Health Monitor also becomes a valuable reporting tool when grouped with other teams’ health monitors.

Health Monitor as insurance policy

If you can imagine the sorts of rich conversations you could have in your team about team dynamics and health, you’ll realize that you can talk about more than just what happened in the previous sprint. You can start having more useful conversations about how to keep your team “green” in the future. What changes are coming up? What things would you do with your team members and your processes and tools to deal with those changes? In this way the Health Monitor becomes a nice insurance policy. And the cost is only 30 minutes every two weeks or so.

Give it a try in your team

So go ahead and keep doing retrospectives. But if anyone in your team is feeling the feels that something isn’t quite right, and talking about tickets and stories isn’t going to pinpoint the issue, give the Health Monitor a go. We find it gives people a better language to articulate what’s going on in a team, and how to get it healthy again. Because healthier teams deliver healthier projects. And that’s awesome.

This was originally posted on the Atlassian design team blog. Check it out and see what they’ve been up to.