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.

However......

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.

The Basics - How to Document a Script

An occasional series looking at best practice for common documentation tasks and situations.

You work on a project that involves making database changes using SQL scripts.  Your customers' DBAs need to know what the scripts will do before they run them.  This article covers what you typically need to include in your script documentation.

Before documenting any scripts, make sure you include a warning to your customers to back up their database before running any scripts.  Ideally, customers should test the scripts on a test version before applying them to live.


1 - What Database type and version is the script designed for?

Does the script update MSSQL? Oracle? MongoDB? Something else?  What versions can the script be run on? Are there scripts that do the same thing for different database types and versions?

For example:

This script is designed for Oracle 10g and later.  You can find the equivalent Mongo script here [where "here" is a hyperlink to the Mongo script location].


2 - Do you need any particular permission level or security settings to run the script?

Do you have to have a specific system or object privilege?  What user roles should run this script?  Is the script likely to impact high-security areas such as users, passwords, personal details, company accounts, and so on?

For example:

This script requires the SELECT ANY TABLE privilege.  We recommend that a SYSBDA review the script before running as it will add a constraint to the main USER table.


3 - Which database or schema does it need to be run against?

If your application(s) provide more than one database (separate finance and personnel databases, for example), make it clear which database the script needs to be run against. Provide a warning about running the script against any but the intended database.

For example:

This script applies to the Finance database/schema only.  Do not run it against any other databases as there may be unintended consequences up to and including data loss.


4 - What does the script do at high level?

Explain how the script amends the structure or the content of the database.  The primary types of change are:

• Add/delete/amend table(es)
• Add/delete/amend column(s)
• Add/delete/amend index(es)
• Add/delete/amend constraint(s)
• Add/delete/amend data

For example:

This script will insert 3 new columns to the User table and populate the existing rows with default data.


5 - What does the script do in detail?

Provide all available information about the detail of the script.  This will depend on the type of script, but for adding or amending tables or columns include the following:

• Friendly name
• SQL name
• Primary keys
• Foreign keys
• Nullable
• Data types
• Data lengths

Explain why something is being added/amended/deleted, and ideally link to the release notes for the code change that the database change is required for.  If data is being deleted explain why it isn't needed any more; flag up data deletion strongly so that customers can make an informed decision about running the script with full knowledge of what will happen when they do.

There are so many possible combinations that examples would be impractical here. Focus on putting the data into a readable format such as a table.  This will also help you make sure that the information provided is consistent.


6 - How will this affect reporting and/or database diagrams?

Provide an updated entity relationship diagram and/or data dictionary.  Explain that cusomters will need to amend any database reports - e.g. SRS, Oracle, Crystal, etc - and explain what they'll need to change.  This is especially important for columns changes; new tables won't affect existing reports and index/constraint changes will rarely have any impact either. If a table or column has been deleted and replaced with something else, explain the mapping of the data between the old and new structure.

For example:

The new data dictionary can be found on our website here [provide link].  If you have reports that reference the deleted column, please amend them to refer to [new tablename.columnname] instead. 


These should cover all of the generic bases for script documentation.  Create templates for the types of scripts you need to document, including any bespoke requirements that aren't covered here, and you're good to go!  If you think there's something missing from the list, drop me a comment below and I'll add it in.

UK Tech Comm Awards - Nominate Yourself!

For my UK readers: The UK branch of the ISTC is looking for nominations for the 2016 UK Technical Communications Awards.

There's more information at the link above, but these 2 paragraphs should give you the gist:

"The UK Technical Communication Awards are open to any individual or team, whether employed, self-employed, contracting, volunteering, permanent, temporary, full-time or part-time.  You do NOT have to be a member of the ISTC to nominate someone, and the nominee doesn’t have to be to a member of the ISTC either.  You can nominate yourself if you wish; the judges’ decisions will be made solely on the merits of the entries, not on who nominated the entries.

We encourage entries of product/process documentation and technical innovation – the “traditional” entries – as well as entries such as blog posts, books, training material, e-learning and anything that displays, encourages or helps the production of high-quality technical communication.

There are some rules to follow, so take a quick look at them before you start nominating.  Check out the 9 categories that will be awarded and to nominate someone, or to nominate yourself, go here.  Go on, you and your team deserve it!"

I'll echo the last 2 lines - technical communicators don't always get the credit they deserve, and these awards are a great way of showing off your achievements.  I know it's not the British way, but it is genuinely OK to nominate yourself!  No-one cares as much about your documentation as you do, and if anyone deserves an award it's the unsung heroes like you who do so much to make life easier for your users.

If you've got any questions you can fill in the form here and the ISTC Awards team will get back to you very quickly.

Nominations close on July 15th 2016 - 5 days from the date of this post - so don't delay, nominate today!