Understanding Team Values

This article originally appeared on medium at https://medium.com/@defmyfunc/understanding-team-values-and-building-a-strategy-eee9f18be742

As a consultant we often have to go into a situation whereby we don’t understand peoples motiviation we only have the solution they are proposing. One to one, this can be fairly easily resolved, however, in teams, with team dynamics, this can be harder to get to the truth of and find agreement on.

In a simple world, everyone would have the same values in the same priority order and making decisions would be easy because everyone would be in agreement and understand why trade offs have been made, either this way or that.

I often run this meeting (or a variation on) to try and get common alignment on the qualities and values that we think a ‘good one’ of the thing we are doing are so that we can fairly and collaboratively evaluate any given solution against those values and qualities.

The Aim

The aim of this session is to generate a set of team values for a specific area of their work that is important to the team.

This will allow the team to judge solutions in this area according to these values.

Note

The rest of this description makes some assumptions about what values you are trying to get to (very software development heavy), but this process can be generalised to derive any set of values.

Some Pre — Reading

https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

“The model” from “5 Dysfunctions of a Team” by Patrick M. Lencioni.

Why run this session?

I run this session when I am in a “low-medium trust” environment and need to align the team around a common set of values. Specifically, being a developer, I tend to use it with Devs and QAs to try and get at the ‘technical values’ around what ‘qualities’ good ‘solutions’ have, agreeing a base set of rules with which we can judge our work in the future and guide our refactors.

I have also run it with wider teams in discussions around ‘ways of working’.

In theory it can work in any situation where you need a team to agree a list of values.

This session adds some tweaks to the usual interactions to make it more sympathetic to a ‘low-medium trust’ environment.

Process

For the purposes of this description I will assume this team is a software development team with a specific focus on the Technical aspects of producing software. However, it can be adapted to produce any set of values in any situation.

1. Generic: Talk about psychological safety and alignment and how important it is to teams.

2. Specific to your problem: I tend to talk about how values link to strategy. Something like… ‘Strategies’ are effective ways of making decisions. They provide the frameworks for how work can be judged. You only want to do work that fits with your strategy. A strategy should be high level and guidance. Not specifics… ie a good strategy statement would be ‘we value automation’… a bad strategy statement would be ‘use selenium to do automated GUI testing’. Strategies are based on explaining what we value. Strategies should also be prioritised. We can then judge solutions against the strategy without getting into flamewars about specific things. Instead we can judge things on their output and what value they enable.

3. Interactive: 10 minutes and everyone has to write down the 5 ‘values’ that influence their decision making when they do work. eg. I want to automate everything

These values are the things that you strive to do when you work and if you managed to meet all of them you would consider it a job well done. They are often things that you compromise

NB: Its ok to do more or less than 5… 5 is nice though

For example, a hypothetical list might be:

• All value is tested, anything not tested is deleted

• Simple over easy

• The ‘rule of 3’ applies to everything we do

• Understanding your live system is more important than understanding your test system

• Everything is versioned controlled

Once everyone has done it everyone gets up and puts them on the board under their name. If they feel they can, they should prioritise them.

In turn, everyone stands by their values and explains what those values mean to them.

The following is important…

NO INTERRUPTIONS AT ALL WHILST PEOPLE TALK.

Everyone else listens.

Each person get 5 minutes, tops.

For example, I might say:

All value is tested, anything not tested is deleted

This means I tend to like TDD because it gives me this value, but I am open to other ways of testing when necessary

Simple over easy

This means I tend to like simple solutions to problems and value these more highly than the ‘easy way’ which creates complexity.

The ‘rule of 3’ applies to everything we do

Automate it when you do it a 3rd time. For everything… tests, process, etc etc

Understanding your live system is more important than understanding your test system

Build. Measure. Learn. Get to live as quick as possible. Learn in live as soon as possible. Monitoring > Testing.

Everything is versioned controlled

VC is an enabler for all the good things. So if it can be versioned controlled it should be.

5. Once everyone has finished talking everyone dot votes. They get 5 votes, but they can only vote on 1 of their own values. The other 4 MUST go on other peoples.

6. Then take the top 5. You will probably end up with having to do some deduping, as you de-dupe add the dots given to the duplicate to the original.

7. These are your initial team values! Prioritised and everything!!!

Outcome

You will have a prioritised list of values based on what your team thinks.

This list of values can be used in technical discussions to constructively criticise ideas and also to ascribe value to certain solutions over other solutions.

This list of values can be played against the organisations list of values and see where there is alignment and also, discord. You can then as a team start those discussions around what to do to manage that tension.

This session should be run periodically, maybe 2 monthly (or as required!) at first, but then probably a lot less as a team matures, and maybe run it in different ways.

The views in this article are my own and are not necessarily endorsed by my employer.