Measuring Agile values

I'm really very proud of the team here, in that I think they've done a lot of work over the past 18 months to adopt the Agile principles and the 'characteristics of a high performing team'. One of the most useful exercises I've done recently is to actually get the team to rate themselves on these values and characteristics. This works, not only because they are able to see a reflection of their own performance, but also because I can share these metrics with our new departmental head, as an indication of how the team is doing.

The graph above represents the outcome of the team rating themselves last week. The task was to read through all of the values and then rate how true they are for the team on a scale of 1 to 5, with 5 being outstanding. Looking at the graph, I think the team thinks they're doing pretty well, and it also highlights areas that they believe they're particularly good at, such as:

• Openness
• Empowerment
• Consensus driven

Those values really ring true for our team, and when I showed them the graph, it felt authentic to them, as well.

If you want to do an exercise like this with your team, here are the Values and Characteristics.

Scrum Values
Commitment – Be willing to commit to a goal. Scrum provides people all the authority they need to meet their commitments.
Focus – Do your job. Focus all your efforts on doing the work you’ve committed to doing. Don’t worry about anything else.
Openness – Scrum keeps everything about a project visible to everyone.
Respect – Individuals are shaped by their background & experiences. It is important to respect the different people who comprise a team.
Courage – Have the courage to commit, to act, to be open, and to expect respect.

Characteristics of a High-Performing team
1. Self-organising rather than role- or title based.
2. Empowered to make decisions.
3. Believe that, as a team, they can do anything.
4. Committed to team success, rather than success at any cost
5. Team owns its decisions and commitments
6. Trust (rather than fear or anger) motivates them
7. Consensus driven, with full divergence followed by convergence
8. They live in a world of constructive disagreement

Please rate our team on a scale of 1 – 5, with 1 being lowest and 5 being highest.

Agile retrospective: How cross-functional are we as a team?

In this exercise, we listed out all of the technologies and skills that we think are used and needed by members of our team. We then took turns graphing our skill sets and arrived at a picture of how cross-functional the team is, highlighting areas where we are low on certain skills and discussing ways we can share knowledge to become more cross-functional.

Agile retrospective: The Happiness metric

I included the Happiness Metric exercise in our sprint retrospective yesterday, and I think it was fairly well received. To my great pleasure, the team seems to be, generally, a fairly happy bunch.

Here's what we did:

In this exercise, we answered a few questions about happiness, rating on a scale of 1 to 5 (5 being ecstatic), how happy each of us are with our team.

On a white board, write four questions:

1. How happy are you with your team right now?
2. What is working best for us as a team?
3. What is working worst for us as a team?
4. What we could do right now to make us happier?

Explain to the team that this information is to be kept private, for the use of the team only, and not to be reported elsewhere or to their management.

• Have the team write a sticky note, rating their answer to question 1.
• For each subsequent question, they can write as many notes as they want and place them next to the questions.
• Review the notes, group them together to find common themes, and agree on any actions to take away which might increase team happiness.

This exercise can be repeated periodically, and can be translated into a google docs spreadsheet which the team can keep constantly updated with their levels of happiness. The benefit of this exercise is to uncover easily fixed issues which make team members unhappy, as well as find issues which effect several members of the team, and nip problems in the bud early.

A way to encourage pairing

We are a team of software engineers, web developers and devs-in-test, and we have begun to realise that our velocity increases (and so does morale) when the whole team is pulling toward the same goal. This can be a particular challenge, when the goal of a sprint is heavily focused on a single discipline, say, a feature that's primarily work for software engineers, which leaves the web devs looking for other things to concentrate on.

In our quest to become a more cross-functional team, and to eventually get to the point where we are a group of well-rounded generalists who can pick anything from the backlog, we have been trying to think of ways to increase our learning across disciplines.

A good way to achieve this is through pair programming with members of the team that you don't normally pair with, and to encourage this rotation, we had a great idea from Rob Chatley.

The Pair Stairs

Track who has paired with who this sprint

The idea here is that each person ticks the box for the person they last paired with, making sure that they spend some time with everyone in the team at some point during the sprint. It doesn't have to be a whole day, just an hour or two will go a long way towards understanding what that person is up to.

Ideas to liven up your Agile retrospectives

For almost a year, I led my team in a standard method of sprint retrospective:

1. Draw happy and sad faces on the board
2. Draw arrows: up, down, equal (to represent "do more of, do less of, keep the same")
3. Everyone quietly reflects on the sprint and writes their thoughts on sticky notes
4. They then stick the notes by the icon that fits the most, happy, sad, keep the same, etc
5. We all then gather round and look at the notes, taking it in to find common themes
6. The notes are then grouped into rough themes
7. Actions are derived from the themes and (sometimes!) assigned an owner
8. We all wander back to our desks, somewhat satisfied that things will change in the next sprint
9. Outcomes are documented on the wiki with photos of the whiteboards

On one hand, I have to commend the team for sticking with the retrospective process, sprint after sprint, rather than abandoning it, which is what a lot of teams tend to do. Retros can be the first thing to go in Agile teams, as they can feel like a waste of time, especially if no actions come out of them.

On the other hand, we let the process get stale to the point where it seemed like a robotic action to go through every other week.

It was time to shake things up and do the retros a little differently. We decided to learn some tricks from another team, and try part of their retro method.

In this exercise, you go around the room and everyone states:

1. How they rated the sprint on a scale of 1-5 with 5 being best
2. List 3 words that describe the sprint for you

Everyone rates and describes the sprint

In this exercise, everyone takes a marker and makes a graph of their happiness throughout the sprint. It allows you to see where blockers had an impact on team morale or where one person is feeling particularly frustrated by something.

 

A visualisation of team happiness

We then finished the session with the exercise to understand common themes:

Uncovering common themes

The "How would you spend £1000" prioritisation exercise

We did a 3-hour session the other day to come up with requirements for a open tender procurement, with a large group of stakeholders from around the organisation. Each stakeholder was coming from a very different angle on the problem, and the challenge was how to arrive at a set of commonly agreed requirements in priority order, with some idea of how they would be scored in the tender process.

The exercise we ended up doing was actually pretty fun and a good way to lighten up a long session.

Here's what we did:

1. Before the session, collect some play money (either from a board game or create your own) in a number of denominations
2. Once all of the requirements are written on index cards, lay the cards on the table
3. Give each participant their "budget" (in this case, our budget was £1000, divided into £200, £100, £50 and £20 notes)
4. Get everyone to "spend" their money on the requirements, piling their money on top of the index cards
5. Send the group on a coffee break and tally up the piles of money on each card
6. Arrange cards in descending order of money spent on them.

By the end, we arrived at a linear priority list of requirements. Some were surprised by which requirements floated to the top, which generated useful discussion and thoughts on how we can expand the sub-criteria for those categories.

How do you do your priorisation exercises in a large group workshop?

Measuring team happiness

At this sprint's upcoming retrospective, I plan to try a new exercise, involving measuring the happiness of the team.

We've attempted this in the past, with everyone drawing a graph of their mood throughout the sprint. This proved fairly useful in identifying factors (often external to the team) which brought down morale during the sprint.

The massive drop in morale was when our application failed load test which blocked the live release.

We tried this method for 6-7 sprints, but eventually the graphs fell out of favour because nobody felt it was giving us that much value in terms of concrete actions to resolve issues and improve morale.

So, this time round, I want to try a slightly different tack, the Happiness Metric.

I'll ask the team 4 questions, and get them to write their responses on sticky notes:

1. How happy are you with your team?
2. What feels best right now?
3. What feels worst right now?
4. What would increase your happiness?

I'm actually considering making a little Survey Monkey mid-sprint to gauge the team's happiness, and have something to compare it with at the end of the sprint, but I'm not sure how valuable that will be.