Sunday, 24 July 2016

7 Reasons We Don't Need the 5 Scrum Values

In the latest update to the Scrum Guide, Ken Schwaber and Jeff Sutherland have added 5 Scrum Values, which are:
  • Courage
  • Focus
  • Commitment
  • Respect
  • Openness
You can read the official press release here.   Let's start with the positives: It's good that the Scrum Guide is updated when necessary, and it's good that Schwaber and Sutherland take into account user feedback about what should be changed (it wouldn't be very agile to do otherwise, one might think).  It's also good that the 222 people who voted for the "Add the 5 values in" suggestion got what they wanted, as they are presumably highly engaged with Scrum and are therefore important ambassadors and evangelists for this framework that we know and love.

Gunther Verheyen has a good piece on his blog about the 5 values and why he thinks they're a good idea.  A key section reads:

"[The 5 values] relate to the ethics of Scrum, thereby - from a social point of view - turning Scrum into a value system. Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions."

Gunther goes on to provide some detailed notes about each of the 5 values and how they guide actions and behaviours.  It's well worth reading and I'd encourage you to do so, especially as he seems to have enunciated a general feeling amongst proponents of the 5 values about what the values are intended to do, and how they are expected to drive the behaviours of the team.


I'm struggling to see the value of these 5 values, despite the admirable analysis from Gunther and many others (I'm using Gunther's article as a representative of this type of analysis because I think he's provided something of an exemplar, not because I want to pick holes in his work specifically). 

There are 7 main reasons why I think these values overstep the remit of the Scrum Guide.  The most obvious one is:
  1. They're lame.  The obvious complaint, but worth spelling out.  When you have a team of people who's primary skill set is technical, making them live by a set of values called things like "Courage" and "Respect" is not going to be well received.  I can count on the fingers of one hand the developers I've met who thought "values" were important, and all of them wanted to be promoted to management.  Management used buzzwords like "values", so values were important to these developers. They weren't important to any other developer.  These are cringe-worthy for many people, especially people who work in dev teams.  We're not the kind of people who generally talk about "values".  We talk about code, sci-fi and coffee.  I'm sorry if that sounds like a cliche, but it's a cliche because it's true.  If you think that talking about values is important and useful, then good on you and I would never try to stop that.  But for a lot of people a discussion about "values" is in the complete opposite direction of anything useful or enjoyable.  Like creating software.
  2. They're not Scrum. Scrum is an adaptable framework, not a value system, ethical system, or social system, and adding these values moves Scrum away from being a framework towards being one of these systems instead.  Values are not adaptable or flexible.  Systems are not adaptable or flexible.  Frameworks are adaptable and flexible, especially ones with a core mantra of "Inspect and adapt".  By their very nature, values normally end up codified, ossified and rigid, and it will not be long before the righteous start claiming that if you don't show these values then "you're not doing it right". 
  3. They're patronising. If you expect me to be courageous, focused, committed, respectful and open, I've got good news for you: I already am, because I'm a professional.  I'm also honest, hard-working, enthusiastic and thoughtful, again, because I'm a professional. Things I'm not: Lazy, stupid, cowardly, in need of being patronised.  Because I'm a professional.  If you work with people who don't already display these values, adding them to the Scrum Guide won't change their behaviours in the slightest other than potentially making them resentful and grumpy. People who are professional don't need to be told to be these things, people who aren't professional won't pay any attention to them.
  4. They're insidious.  Following on from people who don't already display these values, there is more than a whiff of the thought police about these values. If you can't see how someone in a position of power could use vague values like these to reward their favourites unfairly and punish their trouble-makers equally unfairly then you need to get better glasses.  "Why didn't I get my bonus?" "Sorry Kevin, you just didn't seem committed enough."  This is why people want quantitative achievements on their objective lists, not qualitative behaviours and competencies. These values add a legitimacy to the notion of measuring behaviours that just can't be measured.  The opportunities for abuse with this sort of behavioural standard are legion, and they will be taken by more than a few incompetent/unscrupulous people.  The ones who will suffer will be the people on the scrum team.
  5. They're random. Why these 5 things?  Why not say people should display "trust", or "honesty" or any one of a thousand positive behavioural nouns that would benefit a member of a scrum team?  Why not just say "I will work hard to achieve our goals without being a complete arse to the people around me."?  That would actually be a more accurate requirement, and less patronising.
  6. They're aimed at the wrong people. I've talked before about how the power of scrum doesn't lie in the scrum team, and these values are a precise demonstration of this.  It doesn't matter what values the scrum team try to embody, because they aren't the ones who will make a scrum implementation succeed or fail.  Scrum requires a cultural change of the whole company, not just the people who design/write/test/document the code, and by pushing these values onto the team all that will happen is that they will become just another stick with which to beat that team if something goes wrong, even it what went wrong did so because of an agile failure outside the scrum team.
  7. They're additional overhead. Scrum is not as lightweight as some people would suggest.  It is a complete cultural change that requires your company to do some serious shifting around of authority and responsibility if you're going to do it properly.  I'm totally onboard with that, but let's not pretend Scrum is no burden to bear.  Adding these values only increases the amount of cultural change and behaviour modification that moving to Scrum, or getting good at Scrum, requires.  Given that the success rate of Scrum projects is only 62% (according to the 2015 State of Scrum report), this is an overhead that's not needed.

So it's far to say that I'm not a fan. 

These values will be great for anyone who makes a living out of training or consulting in scrum, because they're vague enough to be endlessly analysed and written about without necessarily adding anything - ironically - of value.  This makes them an ideal subject for another day's expensive training, as well as extra consultancy fees for analysing your company's culture and explaining how the Scrum values could really, really help.  Would anyone be really surprised if training/consultancy companies started offering Scrum Values courses at a large amount of money per attendee?  No, me neither.  I'm sure that Schwaber and Sutherland genuinely believe that these values are an important addition to Scrum, and in their rarefied atmosphere they might well be right, but on the ground I can't see this being useful or beneficial at all to most teams. 

If you want to change the attitudes and behaviours of your team members, you don't have to be a psychologist to predict that "values" are not going to have this effect.  Try coaching, mentoring and, yes, managing your staff to help them get where they need to be.  Don't rely on an arbitrary set of values in a development framework to do that hard work for you.