Once upon a time, I worked at a company where everyone was proud to work there.  Everyone knew that the work they did was excellent.  There was much back-slapping and congratulating amongst the staff, and a slightly superior pitying of everyone who didn’t get to work there.

I hated it.  But I’ll come back to why in a moment.

I was recently reminded of this when the NewVoiceMedia Scrum Masters discussed an experiment.  Inspired by this article they talked about doing a variation to the Spotify Health Checks for teams.  Now I’m big fan of the Spotify way of working, and it’s fair to say that if one of their engineers were to drop by for a visit, they would feel quite at home here! 😉  I also wrote a bit about the new-team-agility heuristic here, so it would seem I ought to think it a great idea.

The proposal was to just benchmark our agile teams on some core practices, and then track improvements.  The initial thoughts were to expand it out into a workshop or a retrospective.  Then, each team could assess themselves & their own practices, choosing what they thought was valuable and they’d like to measure.  (Again, I covered similar here, about reviewing your practices as a team and looking at ways you can improve them.)think

Reflecting on yourself as an individual or as a team is a sensible and healthy thing to do.

This expansion of the idea concerned me though.  I found I worried that teams would compare their traffic-lit practices with those of other teams and could be swayed unconsciously to game the system. They might rank themselves higher than was appropriate, subconsciously or otherwise.  I also worried that our natural human tendency to judge other teams (and ourselves) harshly might increase too.  This would almost certainly lower morale.

I expressed these concerns to the other Scrum Masters and suggested instead that we use it as an exercise among the Scrum Masters only. I reasoned that the Scrum Masters would naturally share with each other which teams were strong in which practices.  If Team A were having difficulties with story breakdowns, their Scrum Master could suggest looking at how Team B did story breakdowns.  Plus it would likely be a more objective assessment of the teams’ skills too.

And then I remembered the situation at the company I mentioned above, and saw my mistake.

I was doing exactly what that company had done.

How easy it was to fall into that trap!  (I have now found a small sliver of sympathy for that company as a result of this realisation!)

I was about to extol the virtues of introspection and team centric appraisal ONLY.  I’d like to be sure that this was purely for the reasons I gave above, however, I wondered if it might have been more than that.  Perhaps, I was also subconsciously trying to avoid the difficult conversations, caveats and high-maintenance nature of delivering the proposal.    I was (briefly) disappointed in myself 🙁

More importantly though, I have re-learned something, and that is awesome!

You see, for the company I mentioned, although they were all proud to work there, almost all of the staff had been there for over a decade.  Well over half the staff had been there for multiple decades.  When I say that everyone knew the work they did was excellent, this was true.  Unfortunately the company had made this judgement without reference to external peers at all.  They almost certainly were excellent 25 years ago.  But they hadn’t kept up with the times,

They hadn’t looked to see if their bench-mark for excellence was still relevant.

Race2They had no idea what anyone else was doing, and were self-referencing.  This gave them neither a fair measure of ‘here-and-now’ nor any hope to find what they needed to do to improve themselves.

So, this idea to try a Spotify-style health-check for our teams might be at risk of over-confidence from some teams.  We might also risk being judged by other teams, and that, in turn, might make teams feel vulnerable too.

But, these are risks a Scrum Master needs to be meeting head-on with our teams.

matesWe should be shining lights into dark corners.

We need to be walking alongside them as our teams reflect on their strengths and weaknesses.

We must protect our teams from both lenient and harsh judgements of both themselves and others.

This is not something we should be avoiding because it might be difficult.  How else will we know where the bar is for awesome agile practices at NewVoiceMedia?  And for that matter, for any other company?

Ultimately it doesn’t matter whether you are setting the bar, or measuring yourself against someone else’s, as long as you are consciously doing so.

Remember the only thing that truly matters is that we are better today than we were yesterday, and tomorrow we find ways to be better than we were today.

Helen Lisowski.