One of the issues any team leader can face is when people don’t arrive punctually at their meetings. While fortunately this is very rare at Globant, it has happened from time to time. Working as a Scrum Master in Agile development, I want to share my experience of how I have handled it. Early on in my career, I saw that a traditional “solution” was to place some sort of penalty for tardiness. However this usually only deterred the behavior for a couple of sprints and then this “punishment” was converted into a prize. Clearly in this case, the teams were not applying the penalty in the correct manner, but that is a matter for another article.
I want to focus on steps that a Scrum Master can take to ensure everyone is at the Daily Standup, participating, and that the meeting stays useful for everyone on the team. As we work together over time, sometimes these meetings can lose their initial spark and people stop discussing obstacles. I’ve seen meetings where there is a lot of repetition and they took way longer than they should. However, these meetings are a crucial part of Agile development, and as a Scrum Master, it’s our responsibility to ensure they are well run.
Along with the usual “let’s try to be on time” requests, which only have a short term effect, I have spent time investigating alternative ways to make sure teams stay motivated, and I came across gamification. It was then that I realized its power to keep teams on track.
For example, in one project I constructed a “Masters of Time” game. The rules were simple – you received points from simple things like being on time and participating in meetings. I wanted to make sure the game was fun for everyone. At the end the objective of the game from the Scrum Master ́s stand point was to get teams to participate, have fun, and collect measurements. From the participants side it was to receive recognition from project manager, technical lead, Scrum Master and peers.
So we started the experiment which had a planned duration of four 2-week sprints. There was an immediate positive response – we enjoyed excellent participation and punctuality. These results continued throughout the project.
So what came next? Together with the team we decided to conclude the experiment. Even though personally I would have liked to continue, I realized it was important to avoid making it “”obligatory”. It was a team decision to start the game, and a team decision to end it. And over time it was clear to see that positive habits had set in.
This turned out to be a fun way to get the team to adopt positive habits, and take responsibility for how we work together. It showed how such an approach, based on trust with all the team members, works much more effectively than other methods such as micromanagement and punishments.
In summary I attribute the success of the experiment to the following factors:
- It was a fun game, including recognition for “winners”.
- The duration of two months was long enough for the positive habits to set in, but not too long that people tired of the game.
- It’s more effective if it doesn’t appear as being obligatory.
- Experimenting and trying something new helps with team energy and enthusiasm.
If you are looking for an outside of the box thinking idea for getting your team to improve in some way and improve your Agile development practices, I highly recommend such approaches.
