Today, another experience with some of my teams, in this case I will address “Feedback” inside the team: one way to get feedback and improve your team. A few months ago I was feeling like a “feedback” collector on behalf of teams. I was tired of doing that; comments were not very constructive and sometimes it was hard to explain them to the team.
I took one risky decision: I would deploy one of the core protocols at the end of each review. After a few discussions with the teams, they were not really convinced, but they let me try it. We deployed the “Perfection Game” feedback. It means that at the end of each review meeting (every 2 weeks), stakeholders will evaluate the meeting itself and they will use the ‘perfection game’ protocol.
For those who don’t know it, here it is at the core protocol:
The “Perfection Game” protocol will support you in your desire to aggregate the best ideas. Use this protocol whenever you desire to improve something you’ve created.
Steps
- The ‘Perfectee’ performs an act or presents an object of perfection, optionally saying “Begin” and “End” to notify the ‘Perfector’ of the start and end of the performance.
- The ‘Perfector’ rates the value of the performance or object on a scale of 1 to 10 based on how much value the ‘Perfector’ believes he or she can add.
- The ‘Perfector’ says “What I liked about the performance or object was X,” and proceeds to list the qualities of the object the ‘Perfector’ thought were of high quality or should be amplified.
- The ‘Perfector’ offers the required improvements to the performance or object in order for it to be rated a 10 by saying “To make it a ten, you would have to do X.”
Commitments
- Accept perfecting without argument.
- Give only positive comments: what you like and what it would take to “give it a 10.”
- Abstain from mentioning what you don’t like or being negative in other ways.
- Withhold points only if you can’t think of improvements.
- Use ratings that reflect a scale of improvement rather than a scale of how much you liked the object.
- If you cannot say something you liked about the object or specifically say how to make the object better, you must give it a 10.
Notes
- A rating of 10 means you are unable to add value, and a rating of 5 means you will specifically describe how to make the object at least twice as good.
- The important information to communicate is that the ‘Perfection Game’ protocol improves the performance or object. For example, “The ideal sound of a finger snap for me is one that is crisp, has sufficient volume, and startles me somewhat. To get a 10, you would have to increase your crispness.”
- As a ‘Perfectee’, you may only ask questions to clarify or gather more information for improvement. If you disagree with the ideas given to you, simply don’t include them.
As you can see, it is very simple; however it comes with a few risks. Here are a few that came to mind when I decided to deploy it:
- Stakeholders, sometimes, don’t realize the power of their words. We have as stakeholders VPs, Directors and the CEO from time to time.
- People are not always ready to give a 10. With this in mind, they look for every small detail. They force their mind to find something.
- Feedback could put down the team in only a matter of minutes. (if the team is not ready to get it)
- Sometimes, the team is not ready for any feedback. They are human and they have the right to be like this.
I have to recognize that when I decided to use this protocol, I thought of the risks, but I never thought that I would get all of these situations happen to me after only 2 or 3 review meetings. Yes, you read that correctly, all of these things happened to me after only 2 or 3 meetings:
- The team was down due to the feedback they got.
- Product Owner was on fire with the result of the exercise.
- Stakeholders were proud of their job. They were asked to give feedback, and they certainly did!!!
- Scrum Master (me) was having a panic attack. I could not believe that all those risks transformed into realities. Luckily I did my homework, and I detected my panic mode early enough to start to work on the solution.
Here are the actions I took to mitigate the risk at each level:
Team:
- The team was aware of the risk of this exercise. I used it to let the team know that it was part of our risks.
- As a team we have the right to discard the feedback: Yes, when you get feedback, you can take it and do something or you can take it and not do anything. In the end it is only feedback. (sometime a perception)
- First task for the team: what feedback they will take as an opportunity and change something.
- Prioritized the actions related to the feedback.
- Clarify their intentions.
- Allow the Scrum Master (me) to take this event to talk with everyone about the feedback, the value and importance of it.
- With the team, we defined very well the next few steps, exit points, and time frame. (3 more meetings with the perfection game protocol)
Stakeholder:
- Clarify the intentions of the feedback they are able to give to the team.
- Avoid “political” games, in the moment, to give the feedback: Yes, I tried to clarify the idea of the perfection game (very simple idea: improve as team). Sometimes, our mind plays against us and mixes feedback with political/internal games. People should not use feedback to fix things outside of the team context. I discussed with stakeholders about this “political” game and the impact inside the team. Since the impact related that the game was against their intentions; stakeholders understood the problem and they changed their behavior right away.
Product Owner (for me the PO is part of the team, but sometimes, I take extra time with him to explain the ideas. It helps me in the elaboration and exposure of everything to the full team):
- I only asked him to allow more time, and to believe in my tools and intentions: I could be wrong, but I needed to try one more thing before killing the perfection game and walking away with the lesson learned. I explained what I had in mind to do with the team, and stakeholders. I also shared with him why I think that this situation was a very good opportunity to learn as an organization to give feedback to the teams.
- He is always part of the team, so he participated in the actions I took with the team also.
The Result
After 3 months of applying the ‘Perfection Game’ protocol, I am able to say that it was a good idea to do it. Why? Check these comments:
- Happy to see the improvements related to our feedback a few weeks ago. (stakeholder)
- Nice to have one place to say to the team what I think of their work. (stakeholder)
- Finally, we are beginning to have good opportunities to improve, thanks to this small game. (team)
- Stakeholders understand better the idea of this game. (team)
- X is good feedback, we respect it, but we don’t want to change our dynamic to address it. We should let the stakeholder know that it is not our priority right now. (team)
- The scrum master does not feel like a feedback collector any more. 🙂 (me)
I don’t have any doubt about the result. I am very happy, and I am ready to do it again with some minor tweaks. In the end I got exactly what I intended to get:
- Team learn to accept feedback.
- People learn how to give “productive” feedback.
What about you? Do you have another way to do it? If yes, don’t be shy, share it with us. I will be more than happy to listen to more options.
Feel free to ask questions or give your feedback here.
Thanks,
Omar
[Reference]
Perfection Game protocol by Jim and Michele McCarthy