The Perfection Game

Written by pubudud | Published 2018/01/01
Tech Story Tags: agile | scrum | startup | productivity | tech

TLDRvia the TL;DR App

Software companies from red hot startups to industry giants like Google & Facebook have all identified that Software Process Management plays a critical role when achieving success. The terms “Agile” and “Scrum” have become so common in the field that experience in “Scrum” has become a fixed entry in almost all job postings in LinkedIn, StackOverflow and what not.

I won’t spend time on explaining what Scrum is, or what the Scrum ceremonies are. But I’ll just state that Scrum is not all about conducting the “Scrum Ceremonies.” As the Atlassian team says,

Some people think agile ceremonies magically make a team agile. They’re wrong!!

They also state that,

A team’s agility is built on solid engineering practices, a tactical and strategic approach to change, and great team collaboration. Agile ceremonies simply facilitate communication across the team.

Thus my team discovered several other practices which help(ed) us to get better at Agile, everyday. In fact, these practices help(ed) us to get the maximum out of the standard Scrum practices. The Perfection Game is one of many such mini ceremonies that my team adopted.

How to Play the Perfection Game

It makes sense to play the game during the Sprint Retrospective. The scrum master for the sprint will ask the fellow members to rate the sprint from a scale of 1 to 10. Each person, after providing the rating, will reason for the given score.

Shown below is an example conversation which demonstrates the above procedure.

Scrum Master: Now we are moving on to the Perfection Game. We’ll give the first chance to Alex.

Alex: I will give 8 points out of 10 for the last sprint. What I really like about the last sprint is that, all scrum ceremonies were conducted right on time as planned. However, I think we could have done two things to make the sprint perfect.

Scrum Master: Can you describe those two things please?

Alex: First, I think we could have saved time during the BackLog Grooming session, if we had gone through the Jira tickets considering priority in descending order.

Second, I think we could have distributed the UI design tasks among all developers so that we could have leveraged everyone’s creativity in designing the UIs

How NOT to play the Perfection Game!

Something to note in the above example is that “Alex” is not complaining about anything while reducing 2 points. For example, a member should not be saying things like,

“I reduce 3 points since we failed to send the production release as planned”

The idea here is that, we should not reduce the score for the mistakes we did, but rather, only if there were things that could have avoided the mistakes. As in the above example, if the production release failed due to an infrastructure issue, the statement can be modified as follows,

“Regarding the production release issue, I think we could have requested the infrastructure needs at the very start of the sprint, so that they would have been ready by the planned release date”

Similarly, we should not increase the score for the unplanned good things that the team did.

For instance, even if the team did something which saved a possible security breach, score should not be increased saying that “the issue came up in the middle of the sprint, and that the team put a huge effort for that”. Such things are out of the scope of the Perfection Game. Why? That’s because,

The intended outcome of the Perfection Game is not to insult, blame or praise team members, but to identify what the team can do in future to avoid mistakes and perform better.

Final Thoughts

I just described how the Perfection Game is adopted by my team to make the sprints better. However, the same principles can be applied for evaluating any other event like a Production Release, a Feature delivery or even to individual bug fix tasks.

Nevertheless, there are no strict rules about playing the Perfection Game. You can modify the ceremony to suit your context. Just like all other Scrum tools, this should be used in a way that it improves the team performance, not as an overhead which hinders performance instead.

End of the day, it’s all about the capacity of the team and the expected team velocity. You don’t need to spend hours and hours talking about how you plan to improve things and negligible time on doing actual work.

Okay folks, now it’s time for you to make things perfect!!Don’t forget to support me by giving some claps to this story.


Published by HackerNoon on 2018/01/01