I attended a sprint review of a team a few weeks ago. The results were impressive, the team delivered more than their forecast: they established 133%, excellent result I thought. At one moment during the review, the Product Owner showed a slide and graded the team a 7 (out of a possible 1 to 10). Just one slide with one big seven. I was astonished… I didn’t know what to think about this…
To set the context a bit more. The team exists of seven senior professionals, they delivered more than expected, and moreover, they also took care of the incidents that were reported during that sprint. The product owner still ranked them just a simple 7.
I feel two things can happen after such an event:
- First scenario: the team feels insulted… they overperformed; they delivered everything they forecast the product and then they delivered even more. Is that not perhaps worth a 10? A perfect score? They must feel totally demotivated and they surely will start complaining about the Product Owner at the coffee machine. It is never good enough for that guy… why even bother to overperform?
- Second scenario: perhaps they shrug their shoulders. They laugh amongst themselves about the Product Owner and they just continue what they are doing. They are professionals, they don’t care about being graded by a Product Owner, they know what they did and what they stand for. If he wants to give them a 7… well, if that makes him happy, let him grade them.
I think that both things are not what the Product Owner would like to happen.After the sprint review I had a short talk with the Product Owner. I asked him why he ranked the team and why he ranked them this way. He could not directly answer the question. It was just common to do so within this particular organization, so he just complied. I asked him if the team ranked him as well or if he could grade himself based on his performance as a Product Owner in the last iteration. He started to smile, “I get your point Ralph”, he said. Later that week he told me he would tell the team about my question to grade himself, and how this was going to be difficult.
A few days later I attended another sprint review within the same organization. The setup of the sprint review was identical, and at one moment the slide with a grade appeared :). However, this Product Owner did not mention the grade. Instead, he told the team why they did a great job last sprint. They faced some challenges but handled them well as a team. He also was quite proud that his team was reliable and despite everything what happened kept delivering items. I liked it and gave my compliments to the Product Owner afterwards.To make sure I don’t get into a fight with the first Product Owner: he also complimented his team in their review, and also does so when applicable during a sprint.
Now the moral of this story: many managers, product owners, leads, etc. are looking for different ways to provide feedback to their teams. That is a good habit. As Kaizen teaches us, things can always be improved and getting feedback is a way of learning where things can be improved. It is important to provide feedback to a team and vice versa! However, in my opinion it is impossible or just too simplistic to rank a team in just one grade. A team is a complex system with many variables: individuals working together, interacting with the organization and the world around them, unexpected things happen, etc. How can you describe that in one grade? How does a single grade help a team determine where a Product Owner wants them to improve first? What does a mere body temperature of 37,2 degrees Celsius tell you about a patient in a hospital?
I think there are different ways to provide feedback to a team. You could use the feedback wrap (not the feedback hamburger please), you could implement Kudo cards. You could also consider to start working with Objectives and Key Results for example. If you would like to use metrics, take the following guidelines for metrics:
- Measure for a purpose: Why is the metric there? What is the bigger picture? What answer does the metric provide a question or problem? The metric should help you to get insight if you are getting closer to a goal.
- Shrink the unknown and use multiple metrics to take into account that there are always different perspectives and don’t jump to conclusions too fast. There are two sides to every story. Always.
- Seek to improve and use only those metrics that will help you improve. Set up metrics that can help you learn things. As Eric Ries writes in the book The Lean Startup: “The only way to win is to learn faster than anyone else.”
- Delight all stakeholders, a team, an organization is a complex system. Everything is related to each other. So make sure you have metrics focus on different goals and/or stakeholders.
- Distrust all numbers so be really careful with metrics. Trust me, if you are going to measure the number of story points a team delivers and you want the number to increase… the number will increase! People are smart and they will game the system if they believe there is a need for it.
- Set imprecise targets. I tend to be very black and white sometimes. That makes my life easy (sometimes…). But how frustrating can it be for a team when a metric is about doing 100 and they are doing 99… Sorry, not good enough… Make sure metrics are precise but targets should have a bandwidth.
- Own your metrics. In the case above, why not ask the team to rank themselves? Everyone should measure for themselves; don’t measure someone else.
- Don’t connect metrics to rewards. Really, do I need to explain this? Just a few random words regarding this… banks 2008 crisis?
- Promote values and transparency. For me, being Agile is about being transparent as much as possible and even a bit more. By making metrics as transparent as possible, you also minimize people rigging the system.
- Visualize and humanize. Make sure your metrics are visible and understandable by everyone (or at least people related to the organization) in a split second. A traffic light in a DevOps environment is very easy to understand.
- Measure early and often, make sure you measure just enough (ring a bell anyone?). You need to be able to see trends and to start the discussion based on the metrics. Measuring once a year what the velocity of a development team is… could perhaps not be enough, or too late.
- Try something else, experiment. Read blogs, go to conferences, read books, do Management 3,0 Workshop, get insights on how you can improve your metrics and also experiment with new metrics.
To conclude, there are many ways to provide feedback and feedback based on metrics is great, but promise me you won’t rank your team or employees with just a single number.