Game mechanics for a scrum team that loves desktops
Once we realized that we had accumulated a lot of full cones and agreements on what to do in a given situation. And they also understood that we are constantly talking about them, but when it comes to the point, we do not always remember and do not apply.
Under the cut, I’ll talk about how we came up with Munchkin-style game mechanics in order to make team agreements work.
Hello! My name is Pavel, I do frontend and scrum in Wrike team. We work on Scrum, now we have about 30 teams, in one of which I am a scrum master. I became one more than a year ago and want to share my experience of how we tried to gamify our processes.
What team best practices mean to us
Over the past year, our team has been able to try its hand in super-powerful releases, and in quiet neighborhoods with receptions. Over this year, we have accumulated team agreements that we have come to through our own experience and mistakes. For example:
- about flow development: do a review code no later than in a day, from the very beginning of the sprint, integrate the front and back at least on the plugs to agree on a contract;
- about processes: when decomposing, do not leave tasks with an estimate of more than 3 days, cut minor bug fixes into separate branches, when evaluating, lay a buffer for changes in the scope of another team.
We discussed our mistakes in retrospect and agreed on how to prevent them the next time. Surely many teams have such stories, because each one has accumulated its own baggage of experience. And surely, many teams have scrum masters who really want the agreements to be respected.
The team, when I ask her to remember the arrangements with the retro
Naturally, it is impossible to remember and use each arrangement (especially if there are a lot of them). And then we decided to try to make explicit triggers for intra-team agreements, as in the desktops.
Map Set and Rules
We had several groups of situations: flow development, product development, general processes, etc. We split into 3 groups and after the brainstorm we got this:
Play this card on a sick person. Send him home immediately.
Curse: Feed the QA
Give it to someone who hasn’t run AutoTests on their branch before submitting for testing.
and one more thing about the same:
Play this card on the one who passed the QA branch without running auto-tests. Unhappy himself parses fallen autotests.
like in Munchkin itself:
The Ugly Couple
Give this QA card if you want your branch to be tested in advance along with the review.
Play this card on a player whose branch has fallen into a sprint review. The selected player conducts the next sprint review out of turn.
Chip and Dale Rescue
Play this card when you see that the task has grown greatly. Selected players must rally.
Give it to the one who translated the task into testing before the end of the review. The player must fulfill the secret desire QA.
Curse: An incredibly dirty curse
Play during any rally. He who sticks into a laptop closes it and puts it on his desk.
Play this card after the Daily. The whole team gets up and goes for lunch.
Items: Crossbow of Defeat of False Thermal Goals
Use when someone changes the sprint plan. The crossbow player must update the sprint goals.
Bronik: The Invisible Hood
You can upload technical iterations to the wizard in a hidden form if they are not available to users.
Throw the Glove
Call the scrum master and lead immediately if you feel that you are doing someone else’s work (for example, another team) .
Cough up questions
Play when a critical blocker occurs.Selected players must deal with the problem within 24 hours.
The selected player must give layouts for new features to the review of stakeholders.
Play if the PO gave the dev team an unprepared story. A black hole sucks the team, and the story returns to PO or UX.
Play for a stretched task, if no one has previously highlighted this on the Daily. A delinquent player spends the next day.
Play FE and BE pair so that they begin to integrate (you can safely - on the stubs).
You Can't Talk About Sprint Review Fails.
Play when an unfinished task hits the sprint. Replace it with another task of the same type from the backlog.
Curse: Fulfill the wish of an architectural team
Play against someone who didn’t fix a technical one at the time the task was worked out.
- The whole team participates (at least 1 experimental sprint).
- A card can be played at any time, what is written on it is mandatory.
- To play a card, you need to publicly put it on the table during the rally, announce it during the day, or give it to another player.
- Cards are dealt randomly.
We agreed to try this idea for one sprint and then decide whether to continue. On the morning after the retro, I printed and cut a deck. Everyone who came to the office drew 7 cards - the game began.
The first thing we noticed was that it began rather sluggishly. The most interesting maps were related to the active phase of the sprint, when tasks are stretched, transferred from developers to QA or deployed. On the first day, the guys only created branches and delved into the requirements. No triggers have happened yet, so only technical cards were played: for example, “Gong”, so that everyone could go to dinner together.
Cards were played during the day: when it came to someone's turn, they were laid out on a common table. During the sprint, triggers began to fly in.
We played Despicable Couple when it came to reviewing one of the tasks. The logic turned out to be quite complicated, it made sense to check it in advance in parallel with the review, especially since QA had free time. Some people forgot to run autotests before giving the task for testing - I had to feed QA lunch. Toward the end of the sprint, I played "Following" myself and drove home so as not to sit and cough in the common room.
However, most of the cards could not be played. The first problem was that we distributed them randomly. It seems that by analogy with "Munchkin" it was worth adding classes - "Frontender", "Backender", "QA". If “Only for QA” were written on the “Cesspool”, he would have got to the guys who are interested in him. In addition, all cases with non-running autotests will definitely go through them, and developers with such a card in their hands might not even know about them.
Second point: we do not have many triggers for these rules. After we went through the whole list of our agreements at the brainstorm, we began to better abide by them, and the original problem became not so acute.
What is the conclusion we made
At least it's fun! It was interesting for everyone to come up with mechanics together, especially in such a banter style. And it turned out to be interesting to try how it works.
During the brainstorm, we once again remembered all our agreements and began to better abide by them, so there were not so many triggers for our cards. Now we only monitor compliance with the hottest topics: if someone from the team feels a problem on themselves, then he is ready to see that the team follows all the agreements. For example, if QA has to spend a lot of time parsing autotests, then we can agree that developers always do this themselves before submitting for testing. Then QA will sprint to make sure that they already come to the dismantled runs, and remind developers about it. There are 2-3 problems in each sprint, the solution of which the guys want to drive, and we work on this during the sprint as a whole team.
The team came up with the idea of gamification, but it needs to be tuned. It is worth abandoning the random distribution of cards, introduce classes and class restrictions for cards (“Only for QA”), think about the exchange mechanism and update the list of triggers (so that only current problems remain there).
Which card would you play now? What would your team add ?.