Health Radars are institutional waste!

There's a recent trend that organizations transitioning to agile ways of working get bombarded with so-called "health checks" - long questionnaires asking many questions, that need to be filled in by hundreds or maybe even thousands of people in short cycles. They deprive organizations of thousands of hours of productivity, for little return on this invest. 

Radar tools are considered useful by consultants with little understanding of actual agility. 
My take is that such tools are absolute overkill. What you can do - to save time and effort, and get better outcomes.

The problems of health radar tools

Health radars are deceptive and overcomplicate a rather simple matter. They also focus on the wrong goal.

A radar is only helpful when things are happening outside where you could otherwise see them.

If an organization wants to be agile, the goal should be to improve line of sight, not to institutionalize processes which make you comfortable with poor visibility.

The need for a radar reveals a disconnect between coaches/managers and the organizational reality.

Early transition radars

When an organization doesn't understand much about agile culture and engineering practice, you don't need a health radar to realize that this isn't where you want to be: time-to-market sucks, quality sucks, customer satisfaction sucks, morale sucks. No tool required.

Initial health radar surveys usually suffer from multiple issues:

• Culture: Many traditional enterprises are set up in a way that talking about problems isn't encouraged. The health radar results often look better than reality.
• Dunning-Kruger effect: people overestimate their current understanding and ability, as such, overrate it.
• Anchoring bias: the presented information is considered far more reliable for decision making than it is.

I don't think it needs much further explanation why taking a health radar under these conditions can actually be a threat, rather than a help.

Repeat surveys

The next problem with health radars is that they are usually taken in cyclical intervals, usually ranging from monthly to quarterly. Aside from people starting to get bored having to answer the same fifty questions every month (oddly enough, agile development would encourage automating or entirely eliminating recurrent activity!).

Frequently repeating the surveys thus suffers from:

1. Disconnect between change and data: Especially in slow-moving environments, the amount of systemic change that warrants re-examination of the state tends to be low, so the amount of difference over time that can actually be attributed to actual change in the system is low. 
2. Insignificant deltas: Most change actions are point-based optimizations. Re-collecting full sets of data will yield changes that are statistically insignificant in the big picture.
3. Fatalism: When people see that there are dozens of important topics to be changed, and that progress is really slow, they might lose hope and be less inclined to make changes.
4. Check-the-box errors: With increasing frequency of surveys, more and more people will just check some boxes to be done with it. The obtained data is statistically worthless. It might even require additional effort to filter out. Likewise, the consequently reduced sample size reduces the accuracy of the remaining data.

Those are the key points why I believe that constantly bombarding an entire organization with health radars can actually be counterproductive.

A much simpler alternative

With these four rather simple questions, you can get a clear and strong understanding about how well a team or organization is actually doing:

Sometimes, those questions don't even need to be asked. They can be observed, and you can enter the conversation by addressing the point right away.

The four questions

To the observant coach, the four questions touch four different domains. If all four of these domains are fine, this begs the question: "What do you even want to change - and why?" - and taking a Health Radar survey under these conditions would not yield much insight, either.

Usually, however, the four questions are not okay, and you can enter into a conversation right away.

1 - Product Evolution

The first question is focused on how fast the product evolves.

If the answer is "Quarterly" or slower - you are not agile. Period.

Even "daily" may be too slow, depending on the domain. If you see inadequate evolution rates, that's what you have to improve. 

And don't get misled - it may not be the tool or process: it may be the organizational structure that slows down evolution!

2 - User attitude

The second question is focused on users.

If the answer is, "We don't even know who they are" - you are not agile. Period.

Some teams invite selected users to Reviews, although even this can be deceptive - having an informal chat with a real user outside a meeting can be revealing indeed.

3 - Developer attitude

The third question is focused on members of the development organization.

If the answer is anywhere along the lines of "I'm looking for job offers" - you are not agile. Period.

Sustainable development can only be achieved when developers care about what they do, are happy about what they do and willing to take the feedback they receive.

4 - Continuous Improvement

The fourth question is focused on how improvement takes place.

If the answer is along the lines of "We can't do anything about it" - you are not agile. Period.

People need to see both the big picture and how they affect it. The system wouldn't be what it is without the people in it. The bigger people's drive to make a positive impact, the more likely the most important problems will get solved.

The core of the matter is what people do when nobody tells them what to do. Until people have an intrinsic drive to do the right thing, you're not going anywhere.

The conversation

Depending where you see the biggest problem, have a conversation about "Why": "Why are things the way they are?" - "Why are we content with our current situation?"- "Why aren't we doing better?" - "why do we even want to be agile if we're not doing our best to make progress here?"

People can have an infinite amount of reasons, so this is the perfect time to get NEAR the team and their stakeholders.

Following up

The followup set of questions after a prolonged period can be a series of "What" questions: "What's different now?" - "What have we learned?" - "What now?"

Summary

Drop the long questionnaires. They waste time, capacity and money. 

Learn to observe, start to ask questions. Reduce distance in the organization.

You don't need many questions to figure out what the biggest problem is - and most of all, you don't need to "carpet bomb" the organization with survey forms.  Keep it simple.

Often, people know very well what the problems are and why they have them. They just never took the time to get things sorted. All you need to do is help them in understanding where they are and discovering ways forward.