Aspect Rating

Measuring the different aspects of a team

Posted by Devon Burriss on March 21, 2017
Agile

I recently ran a retrospective with a team of 11 (including myself). With that many people getting focused feedback is important or meetings can drag out. I found this exercise quite useful and the rest of the team seemed to as well. See this post for the Check-in/Check-out I ran before and after.

The first step is measure

The idea is simple.

  1. Put some aspects of team interaction along the top of the board or wall. I used the following and I suggest this order (see Analysis for why):
    • Direction
    • Progress
    • Process
    • Team work
    • Learning
    • Enthusiasm
  2. Draw an arrow up, labelling the bottom 1 and the top 5 (see image below)
  3. Ask the team to put their name on 6 post-its
  4. Explain that they need to put 1 post-it under each aspect rating that aspect of the team
  5. Discuss
Aspect Rating Example

Aspect Rating board: Note the order is different to my recommendations

What you want to focus on next is up to you. Be sure to celebrate the good but depending on the state of the team you may not want to spend too much time on it. We had 1 hour and we needed 5 to 10 minutes for the Check-in/Check-out. We then spent some time celebrating the good by allowing people to explain why they voted for those items.

My suggestion at this point is to focus on the lowest one from here and work your way up, time permitting. Unless something is systemically wrong with the team there should be quick wins to raise things that are a 1.

If things degenerate into technical discussions interject and ask to take it offline.

Aspects

Let's walk through what each aspect is in case this isn't clear from the label.

Direction

This is the direction of the team. Do they know what they are building? Do they know why they are building it? Do they know how they are going to build it?

Progress

How does the team rate its progress in building what it should be building? This comes after direction because if you don't know what you are building you are unlikely to feel like you are progressing toward it. This project in particular had a rocky start due to a dependence on an external party, so direction was low. Feelings of progress varied based on whether a team member was focusing on infrastructure or feature implementation.

Process

Here you are trying to find out the team's buy in to a process or feelings that the process is lacking. Again, the direction contributed but with a new team I was introducing processes as the team requested them. This is usually not a good idea unless you have an experienced agile team who are capable of raising issues proactively and self-organsing. Although a newly formed team it is comprised of experienced members so this was low risk.

Team work

How well does the team feel it is collaborating? Are they pair-programming? Are they stepping on each others toes? Are they aware of what each team member is doing? It was mentioned to me by a very astute team member that teamwork is very difficult, if not impossible, to get right if the team does not have clear direction. See my post on big agile teams for some ideas of facilitating team communication.

Learning

Is the team challenged? Are they learning new things? This is important for cultivating an autonomous, self organising team as well as for enthusiasm.

Enthusiasm

Are team members excited to come to work? Excited to work on the project/product? Happy to work together? This forms a symbiotic relationship with all the others and will go down if any of the others stay down and when it does go down, all the others will drop even faster from the feedback effect. It is the canary, so watch it well.

Analysis

This was from the team's first retrospective and as mentioned the direction was shaky from the start, so this was actually better than expected from a young team (with experienced members). If anything surprises you be sure to spend a large amount of time drilling into what is going on there. From this retrospective we implemented a few more process items that showed immediate benefit. I cannot stress the significance of this enough.

The team identified a problem, and an agile process (think demo, refinement, etc.) was introduced because the pain was felt and a balm was applied. How many things do you do and care about in your life that have no benefit to you or anyone you care about? Why should development be any different? Only solve problems that exist. Before Agile was a label, agile was a characteristic of a team.

Aspect Rating Chart

Aspect Rating analysis

Pros

  • Great snapshot of the team's perception of itself
  • Identify things to celebrate
  • Identify problem areas and provide a forum to start discussing
  • Seemed to eliminate personal rants and every team member repeating the same thing that often seems to happen with some other formats

The bottom line is that it really focuses the discussion into narrow, helpful, actionable bands.

Cons

  • It really focuses the discussion into narrow, helpful, actionable bands. Sometimes you want to generate more free form discussion or drill into technical details or inter-personal conflicts within the team. I can't say for sure but this does not seem suited.
  • The team really needs to get involved in discussing the aspects or this is going to be a very short meeting

Conclusion

I think I will be using this regularly to document the teams progression on these aspects. I won't use it every retrospective but maybe every 2nd or 3rd. As this is something new I am experimenting with so please note that this is early stage beta so take it with a pinch of salt. I will try report back with more data once I have more. Did you find this useful? Do you have your own methods that you use regularly for retrospectives that gives you measurable insight? Let me know in the comments below.



blog comments powered by Disqus