Best Practices
This section holds learnings regarding communication and behavior best practices in the day-to-day business of a scrum master.
Ideas on how to improve yourself and your team:
- Take care about the “work in progress”
- “Developers should not always work only in their main area of expertise. They should take a task of work outside their comfort zone from time to time” à again.. pair programming
- “Clean Coder Initiatives”, like Workshop on coding guidelines – will improve the team spirit, consistency and commitment
- Coding dojos – “In a coding dojo, the whole team sits together in a conference room. Two developers do pair programming at a single computer connected to a projector so that all others can see what they do. The pair is rotated every 15 minutes. In this setup, the team solves exercises to train their engineering skills (unit testing, design code, write code, use tools, …).”
- Set personal sprint goals for team members – everyone chooses a personal sprint goal at the end of the retro – SMALL goals!
Scrum of Scrums
If you run more than one Scrum team and these scrum teams have interdependencies, than introducing a Scrum of Scrum Meeting is a good way to improve cross team communication. It should take place at least twice a week. Invited are all SMs from the different teams (or they send a deputy).
Daily Scrum
A good Daily Scrum/Standup should fulfill these criteria:
- for each team, a daily scrum of 5 to max. 15 minutes each
- take place at a fixed time, there is no excuse for skipping it, even when some colleagues are missing (track the missing ones and remind them that the meeting is obligatory)
- questions every team member should answer:
- 1. what was your daily goal for yesterday?
- did you manage to reach it?
- if not, what was the problem?
- if there was a problem, how did you solve it?
- if you solved it, did you document it for the others?
- if you didn’t manage to solve it, who can/could help you?
- did you manage to reach it?
- 2. what is your goal for today?
- estimation: how long will it take until it will be done?
- 3. what are my current impediments?
- 1. what was your daily goal for yesterday?
User Story Kickoff
When starting with a story: story kick off meeting with the requirements engineer is a great tool to share the goal of the US with the developer. It won’t take longer than 10-15 minutes usually. It can help to clarify some last questions and make sure that everyone really 100% understood what’s expected.
Retrospective
At the end of every sprint, a retro takes place. For this, everyone gathers answers to the two questions:
- What was good in the previous sprint, what should we keep doing?
- What was bad in the previous sprint, we should stop doing it or solve the problems?
How to do a good retrospective
- reserve at least 1h for a retrospective but not longer than 2h because it usually tends to become unproductive after this time
- preparations
- create a flipchart with two columns: positive and negative topics
- i tend to draw smileys for each column, but be creative, you can always try different variants
- send out the appointment for the retro at least one day in advance but you should stick to a regular schedule which means one retro after one sprint!
- the retrospective is obligatory for the whole team, excuses are not allowed (as it is not a serious illness or private problem)
- doing
- one needs to be the moderator of the retrospective (usually the Scrum Master of the team)
- responsibilities for the moderator
- let everyone speak up and remind those who tend to be silent
- guide discussions in a result oriented direction: at the end of each discussion there needs to be an outcome or action that should be taken (including a responsible person doing it)
- keep time in focus
- collect the pros and cons as post its on the flipchart
- clustering: group similar postits
- note concrete actions and solutions for each discussed negative impediment
- let the team do a prioritisation of the top most important topics that should be solved within the next sprint
- post processing
- as scrum master create a summary of the retrospective
- collect the top most important items and the defined solutions/actions in an email
- send the email to each in the team
- everyone in the team needs to take a look at the discussed topics during the next sprint, remind them
- as scrum master create a summary of the retrospective
Handling of impediments
Collect impediments in a Scrum Master Impediment Backlog (e.g. your issue tracker should provide you with such a feature, or Google Spreadsheets can also be your tool of choice). It’s crucial to have problems get documented: create an tickets for impediments, so that every one knows what’s currently blocking the team or slowing it down. Additionally everyone sees if there is progress made on resolving these impediments.