Scrum Masters and Agile Coaches play a key part in the development and supporting of Agile practice within Scrum teams. Both hold key responsibilities to support and educate teams in the ways of the Scrum force. However, sometimes more than talking needs to be done to help squads. Occasionally, bad habits creep into practice that need to be addressed. At times, teams need stronger support to learn Scrum principles and ceremonies.
No matter how many times you try, it is my experience that you cannot force them to read The Scrum Guide. Not everyone can be an uber Agile enthusiast such as myself. For those who simply want to use Agile techniques to focus on their primary love of coding and building cool things. Irrespective of the number of pages, or the incentives you put forward to encourage them, they will only read it when they want to. If ever.
When it comes to learning the important lessons, there’s no reason we can’t have some fun. Recently I have been having fun, yes fun, transforming Management 3.0 Delegation Poker to help teach our squads Agile best practice. Here, I provide insights into how this game can be used to educate teams, and the successes and lessons learned from our first pilot poker game.
Applying an adaptation of Delegation Poker to this Scrum delegation seemed like a good opportunity to clarify some elements of Agile practice and encourage collective learning of Scrum best practices. In advance, you’ll need a set of delegation cards for each player. The set includes the key Scrum roles, as defined in The Scrum Guide, along with a few other common IT roles. Feel free to print off the below template, or add additional roles to ensure all members of the Scrum superhero squad that is playing are represented!
In preparation for the session, the dealer running the session should select a series of scenarios to present to the team. Six to eight is a reasonable number to cover without making the session too long.
These can be selected from The Scrum Guide. In my case I used this resource for part of my inspiration. There were particular red flags present in this Scrum team that I also hand picked events to include in the game. For example, following a comment from one team member that they felt they had to commit to all items shortlisted by the Product Owner, it seemed appropriate to ask which group is responsible for committing but not shortlisting work.
To ensure the team also reflected on prior experiences I also added situations the team have encountered where perhaps they had struggled with key principles such as autonomy or collective ownership. Given each team member commonly selects a story to work on individually rather than together, questioning the responsibility for unfinished elements seemed appropriate. Especially since it is the responsibility of everyone in the team to complete the work. Presenting situations where they can present one or multiple cards forces the players to consider if all parties are key to addressing a particular set of circumstances.
You will need approximately one hour to play. The rules of the game are simple. For each identified scenario:
- Present the team with a given scenario.
- They are able to ask questions to clarify the situation.
- Place down one or more cards to represent the individuals who are responsible for addressing the event in question. Encourage participants to place them face down until everyone has voted.
- All players should reveal their hand at the same time.
- Spend a few moments asking players to explain the reasons for their selection. Encourage all viewpoints to be discussed.
- Reveal the true answer, clarifying the reasoning for those individuals being responsible to remediate the issues within this situation.
Not so difficult to follow, right?
That Was a Crazy Game of Poker
We held our first Delegation Poker session in July 2020. Overall, I was very happy with the level of engagement. As a facilitator of any session, having a number of attendees contact you post-event commenting on how helpful and well-run the meeting was always leaves a warm, fuzzy feeling.
The above format can always be included as part of a larger session. I included a role identification step where each participant voted on who held each of the key rules using video conferencing annotation tools. The initial goal of this stage was to highlight the confusion of who held the Scrum Master role. It meant that when they were later voting on scenarios, they were able to learn the key responsibilities of this role, and later discuss who of the shortlist should be carrying out the role. After all, there should only be one Scrum Master!
There were several situations that highlighted the team have a good understanding of some other roles. The Product Owner and his need to shortlist work items was very clear. The team had a good understanding of some collective responsibilities. And most players gave thoughtful justifications for their answers. We also managed to clear up some misconceptions on the team committing to shortlisted work, which facilitated some interesting questions.
Playing the game with a remote team is slightly more challenging, as we found out in this case. Being able to play the cards would definitely have been more fun. Bandwidth issues meant players used annotation tools to place a mark next to their card(s) of choice. If you have all participants in areas of reliable broadband, I would strongly advise playing poker by holding up your cards to the camera.
The Winner Takes It All
The success of this session gives me hope that the game can be used again in other situations. We have a couple of other squads that currently hold onto certain misconceptions, or need similar support. It is clear that with a similar, or slightly modified set of scenarios, the game can be reused to help them recognise pitfalls in their own practice that require remediation.
This isn’t the only Scrum game out there. After running this session I happened to come across The Scrum Card Game. I am definitely tempted to try this game out too. Although some colleagues may require convincing on the benefit, especially if they consider themselves to be an established team.
Gamification of learning Agile theory may seem to some to be rather juvenile. They call it work for a reason after all. Nevertheless, learning and work should be enjoyable. If they are not, question how you can make it so. Be sure to play your hand at Scrum Delegation Poker, and learn how the key roles can help you adapt to past and future software development challenges.
Thanks so much for reading! Claps and comments are always appreciated. Do get in touch to let me know your experiences of playing Scrum Delegation Poker!