How to Deal With Team Best Practices or Processes Gamification
Hey, guys! I’m Pavel, Scrum Master and Development Lead at Wrike. This story is part of my “Experiments in the Team” series in which I share my experiences with coaching the team and improving our culture.
The problem
Last time we discussed improving your retrospectives. An improved retrospective is expected to give the team a number of action items related to improving their processes or agreements (something like “ best practices”) of dealing with different situations.
Let’s take a look at these best practices. For example, after a year of experiments and mistakes we’ve gathered the following:
- Development flow : Code review shouldn’t be later than within the next working day; start the frontend and backend integration from the very beginning of the sprint to set up the contract as soon as possible.
- Processes: Split each task into several parts so that their estimations don’t exceed three days; do minor bug fixes in the separate branches so you don’t lock the main feature branch; and add the buffer to an estimation when you’re not working in your own scope.
- Product elaboration: Determine where product requirements are expected to be described in the tasks hierarchy.
I once tried to collect all of them in a single place and counted 64 different practices that we have to follow. Guess what?
You’re right — we didn’t know our practices. We couldn’t remember all of them, because there were too many — and that was exactly one of the complaints from our last retrospective. So, we had to make the list useful.
The hypothesis
I hypothesized that if we had explicit triggers for most of those cases, we could remember and follow most of them.
One more thing to know about our team is that we’re in love with board games, especially ones with complex mechanics. So my first idea was simple : Let’s create a set of cards with triggers and actions that can be played at any time like in the Munchkin game.
Creating a deck
The worst thing I could do was ask my team to use the set of cards that I prepared. It would look crazy to bring such complex mechanics for a big number of cases, and it was likely that nobody would even try to participate.
So, at the next retrospective we split into three groups. Each group got their own set of agreements and tried to gamificate those. It was really entertaining — my team brainstormed a lot of funny ideas based on our inside jokes and memes.
The rule is simple : Have fun!
Let your team use every jokes their want
Enjoy the brainstorm and enjoy everyday usage of those cards
We ended up creating about 40 cards, which I printed and randomly dealt from the deck at the beginning of the next sprint.
We didn’t set any rules. If you had a card for the case that was happening, just play it. How do you play it? Put it on the whiteboard, mention it at the daily standup meeting, or go to your victim’s desk and give them a curse card. Nothing formal.
How did the deck work?
It didn’t! It was fun, but only a few cards were played.
We think the main reason was that we learned all those practices well enough during the brainstorm and started to follow them as well. To prove it, we have to repeat the experiment again in a few weeks.
One more idea was that we dealt the deck randomly. Some cards were more useful for QA and should’ve been given to them first. Probably, we should try to define different classes (“Frontend”, “Backend”, “QA”) and cards “Just for QA”.
Another reason could be that we still had a lot of triggers for a long, two-week interval and got distracted. How can we deal with it?
Focusing on a particular case
Next I wanted to focus on a small set of practices to make them work. I selected our next sprint planning meeting for this experiment and prepared a list of nine related practices.
It isn’t simple to track a lot of agreements if you lead the meeting, so I asked my team for help.
Right before the planning, I asked everybody to choose a random number from one to nine and give them a certain practice. This way everybody had to focus on just one or two practices. For example, one person owned splitting big tasks into small ones, another got limiting a number of researches for one person per sprint, and a third checked if requirements were properly described for each task.
The result was better. Every “practice owner” raised their hand during the planning if something was wrong so we could notice and fix it in advance. It was simple and interesting for the team, helpful for me, and good for our planning meeting.
The person interested in the agreement can introduce it better
One more conclusion that we made was that most of these practices work fine eventually. We don’t need to set up a special process for tracking them. But if something is a real problem, it’s a problem for a specific person. And the best way to fix a problem is to ask somebody to keep an eye on it during the sprint and continuously provide instant feedback for the team about following the practice.
The idea was to take two to three of the most relevant practices to each sprint. For example, last sprint we were working on the following improvements:
- We split bugs by severity to fix low-priority bugs separately and deliver the feature in an acceptable quality as soon as possible. We concluded that it already works for our team.
- We made a“5 Whys Survey” to investigate the root cause of specific problems and discuss at the next retrospective. We did it once and it worked.
- We started testing (at least smoke) the day after passing a task to QA to have more time for bug fixes. And this sprint we avoided any bottlenecks or delays.
So the main lesson here for me is that having a huge amount of “best practices” is useless. Nobody can remember all that stuff.
If the team wants to make it work, they should focus on groups of practices applicable to certain events (like sprint planning and retrospective review), sprint phase (like the last days of the sprint when nothing new should be started), or process (like Dev-QA flow). Another option is to focus on the most relevant issues for each sprint.
Don’t hesitate to involve your team and ask for their help. And don’t forget to have fun!
Follow me for other cases and challenges I solved with my team. Check out the full video in Russian (~70 minutes) about experiments available at the Wrike Tech Club channel.
Leave your feedback and share your experiences in the comments!
