A few days ago I went to a meetup called “Agile games and gamification”. As a software developer I didn’t have too many expectations as it was intended mostly for scrum masters. Imagine my surprise as I did acquire some practical knowledge that may help me along the way. Besides, there was pizza and beer, so it could never be a failure. Therefore, I decided to share my experience and personal thoughts in this post.
The presenters were a company called Ajimeh which is an authority in agile training. It started by a short introduction to Scrum principals which gave a structure to the rest of the presentation. After that the audience was divided into several groups to simulate different Scrum teams for the following exercises.
The exercises were about different kind of games teams can play to improve their Scrum process. I actually enjoyed the games as it was entertaining and allowed me to meet some interesting people who had a variety of different roles.
We started with a game called “21”. The game objective is for the team to count to the number 21. The rules state that the members can’t say the numbers by the sitting order or signal each other about what to say. Every time two team members say the same number the counting restarts from one. The game develops the sensitivity of the team members to their colleagues’ behavioural queues and allows a better communication between the members. I have to admit that the game was not easy and it took a few tries until we eventually succeeded. I would recommend this game to any team which has a large amount of new members.
The next few games where about building estimation skills. Each team made a list of animals and then ordered that list by an uncountable characteristic of those animals. First we needed to order them by input from all team members until all agreed on some order. Next we ordered the list by finding the list edges on which all agreed and added the rest by comparing them to animals that were already in the list. This exercise emphasized that even if you cannot exactly quantify a task you can estimate its volume compared to another task.
Another entertaining game was for shortening the speaking times at the daily Scrum meeting. It was based on making the speaker nervous or uncomfortable and therefore speaking less. First it was by playing a tune while a person speaks and making it louder as time passes. The second was a more primitive way by giving the speaker some paper stacks so that the more time passes the heavier his burden becomes.
The conclusion I got from this meetup is that these games are not really for everyone. It depends on the place and more importantly on the team. During my career I worked at a few different companies and experienced the whole range from non agile “waterfall” processes, to a crazy passed agile development with a single week sprints.
I think that these games are great if you start a new team which you need to learn to work together in an agile methodology. It will also be useful to conduct such games when migrating teams to work in agile methodologies in big corporate companies. The reason for that is to add motivation for change in team members who are used to a completely different way of work.
However, I wouldn’t use gamification in a team that is already motivated and implements agile. It will only distract the team and waste time. One thing stated by the presenters which I would recommend, is one weekly meeting that is not related to work. This can be great to elevate the constant pressure of the ongoing development.