My Scrum Master playbook
I remember my first Scrum Master experience back in 2011.
Even after following several Agile courses I still have tons of questions.
After 10 years of practicing Scrum with several teams I decided to share some of my resources and experiences that worked well in those contexts over the years. I hope this blogpost inspires you to try them.
Define a clear but small team purpose aligned with company goals
I’ve been using the OKR Framework for some time now. It makes everyone in an organisation aware of what needs to be aligned. This critical thinking framework seeks to ensure everyone work together to achieve company goals.
Aligning the team with the purpose of the company brings motivation to the team to achieve great and challenging results. Having clear objectives / goals backed up by real data or measurable outcomes that are aligned with the purpose of the organisation helps setting priorities between the teams.
Define when the team is successful
Every engine has a monitor to analyse the performance for obtaining optimum results. Try to identify what performance metrics they would like to use in order to stay “healthy” as a team, together with the team.
I personally like the Software Delivery Performance Metrics from Accelerate: Delivery or cycle time, amount of production issues or deployments and recovery time.
Assess the team and their ambitions
You can learn a lot from your team by observing and assessing the group’s behaviour. I use the following tools to assess the team.
Tuckman’s group development model can be helpful to identify the current state of the team in order to discuss its potential. It can help you trigger the team to achieve another state.
Lencioni’s 5 dysfunctions of a team has a way to talk about the unspoken. Do we really trust each other to complete tasks? Are we disguising the real problems by adding artificial harmony? Are group decisions clear enough and can we live by them? Are we afraid to call out counterproductive behaviour? Do we work as a team or as a group of individuals with our own goals? Asking these questions triggers everyone to discover and discuss mismatches in team culture.
Belbin team roles helps you assesses how an individual behaves in a team environment. Depending on the goal of the team you can assess how effectively a team is likely to work together, including selecting the best candidate to fulfil each role, and identifying gaps and overlaps in the team role distribution which might affect a team’s success.
Time-box suggestions for every Scrum Ritual
Research shows that engagement in meetings starts to drop off quite rapidly after about 30 minutes. Attention levels drop quickly the longer the meeting lasts.
With that in mind I recommend the following timebox for Scrum Rituals.
- Daily Standup: Max 15 minutes
- Refinement / sprint planning: Max 45 minutes each. I would suggest having 1 refinement session every week. Combine and align that meeting with sprint planning. So you don’t have to create yet another meeting for sprint planning.
- Retrospective: Two separate meetings of 45 minutes. Preferable part 1 before lunch, and part 2 after lunch.
Having meetings with clear agendas explaining why we need to meet and what we are going discuss / decide will also help attain engagement.
You can skip Scrum Rituals. But don’t let it be the Retrospective
Scrum was designed to shorting feedback loops and stimulate improvement.
If you skip the retrospective, you will not be able to align on what is holding us back underneath all the dynamic experiences.
I would suggest to have the team retrospective focus on celebration and learnings. This will keep the team motivated to keep improving and growing.
Part 1 (max 45 minutes)
- Review last retro action points: Did we actually solve the previous problem?
- Collect feedback from the team about the team.
Personally I like the 4 quadrants retro format.
We collect feedback from the team about the following themes:
1. What are happy about?
2. Who should we give a flower (token of appreciation) to? Make sure to mention what he/she did to deserve the flower.
3. What are the things we are sad about?
4. What other ideas can we share? - Decide 1 or 2 problems to analyse next from area 3 and 4.
I would suggest dot-voting, but only after we discussed the risk of the problem(s). Once we have a common understanding of the problem and knowing the risk of not solving it, we can make better decisions.
Part 2 (max 45 minutes)
- Analyse the problem by using the 5 Whys, flush out symptoms and talk about the real problem
- Create action points to start improving / solving: Who will take action, what will we do differently and what do we expect to improve?
Also make sure that action points are planned in the next sprint.
Don’t use User Story Points to estimate, use Issue Counts instead
Create user stories so small it can be implemented in 1 day.
I’ve never seen user story points as estimations work well. It resulted in frustration, counterproductive dialogs and endless debating.
If you want to avoid having energy draining meetings, focus on what and how it needs to be done. Not how long it will take. Create a list of issues (to-do list) together and talk how we can break down this list even further.
Breaking down the problem into smaller pieces and start dealing with them one at a time, piece by piece. The smaller the piece, the easier it will be to evaluate it individually and come up with the solution.
If you are using Jira, you can easily configure your board to count issues.
In Jira: Use the Burn-up chart instead of Burn-down chart.
The Burn-up chart shows scope changes that can be discussed during standups. As far as I’m seeing in Jira, this is not possible in the Burn-down chart. The Burn-up chart will help the team (and other stakeholders) visualise problems in achieving the sprint goal. The team has to adapt and decide what to do next when the scope changes (red line).
Keep daily standup nice and short
Talking about what happened yesterday can be useful to keep everyone in the loop. But most of the times I witness the team completely zoning out during standups. Having the standard three standup questions being answered individually drains the energy out of the team because they are too much focused on personal succes, status and (even worse) ego. Most of the discussions already happened or are not interesting enough to discuss the single most important question of the standup: Are we going to “win” the sprint?
So my tip would be not letting the team members answers the standard three standup questions individually. Let the standup focus on achieving the goal by asking the team two questions:
- Are we on track?
- What is holding us back to “win” the sprint?
If you do want to discuss what happened yesterday (for whatever reason), make sure you discuss the board status from Done till To-Do.
I notice that you trigger something mentally in the team. You keep focus on what happened to achieve the goal. And it gives the team a motivation boost to talk about stories that are almost done and what needs to happen by whom.
Your thoughts?
I hope this blogpost triggered you to try out new ways of doing Scrum.
Feel free to leave a comment or share other ideas to keep the team hyped about achieving goals.
