My induction into my informal position of Scrum Master was rather quick, a member of staff was leaving and the team needed someone to help run the meetings. Learning fast and jumping straight in at the deep end is my typical (if not favourite) way of learning so I rolled up my sleeves, read a few books and did my best.
So what have I learned? What dubious advise could I pass onto any developer who finds themself stepping into the same role?
Know your Ceremonies
The Scrum Master’s week is punctuated by meetings such as Daily Standups, Planning Sessions, Sprint Review and Retrospectives. You’ll encounter resistance to these because devs like writing code, they don’t enjoy spending hours each week sat in the meeting room. You’ll need to justify these sessions, if you can’t explain why you want to meet then it’s best not to!
Daily Standup
This is the most common session you’ll be expected to run. It’s also the most famous, many businesses claim to be agile simply because they have a daily standup! Getting it right is key to your team’s success.
First the obvious question, do you actually need to stand up? No! People who have never attended a standup will challenge this methodology, there are advantages for and against standing up for the meeting and you need to understand both sides if you want to discuss the reasons. On the one hand physically standing encourages participants to keep their part short and on topic, I also like to guide speakers around the circle so everyone knows when they will be expected to talk and no one is left stammering. On the other hand standing up can be very difficult for distributed teams, meeting over Skype with headsets reduces lot of background noise but brings with it the inevitable technical problems and opens the unending source of distractions which is a dev’s PC. There’s no right answer, but different teams will prefer one style or another.
Keeping on topic is a huge challenge and one I’m still struggling with. Your standup should consist of three bullet points
- What did you do yesterday?
- What are you aiming to do today?
- Are you blocked in any way and are you on track to burn down?
In my experience there are two main reasons for a scrum wandering off topic, these are Story Telling (going into too much detail about what they did yesterday) and Problem Solving (using everyone’s time to try and become unstuck). Devs love to talk about challenges they overcame and solve other people’s problems. The key is to spot when this occurs and suggest that these conversations can be had later.
The sixteenth minute is an interesting idea, as I mentioned above one of the main reasons for scrums dragging on is people trying to utilise the entire team to solve their impediments. One approach is to formalise an optional follow up chat for the required parties so they can continue to discuss issues without hindering the rest of the team. Keep an eye on how many of these follow up conversations are needed, too many and they rapidly take over the team’s morning.
Sprint Planning
I’ve found the key to Sprint Planning is preparation, this can often be an issue when the meeting is scheduled for first thing on a Monday morning! Before you walk into the planning session you should have:
- The backlog prioritised
- Details of the capacity of your team (or team members if you plan individually)
- Details of how much work has been carried over from the previous sprint
If you don’t have this information to hand you’ll need to acquire it in the meeting, this is all information you should have access to through your planning software. Asking for it in the meeting wastes everyone’s time and leads to boredom and the feeling of wasted time, not how you want to start your sprint!
Armed with this data your planning meeting is simply a matter of dishing out the highest priority tasks to the team members who want to pick them up. Simple!
Sprint Review
The purpose of the Sprint Review is to demonstrate what you’ve built to the stakeholders and other interested parties, this can often be your Product Owner, Support Team or other devs. These people then have the opportunity to provide feedback which can be considered, prioritised and included in the project.
The problem I often find is that there are so many ideas, so many discussion points and so many questions that your one hour slot is barely enough to get through the first demo. So how can we address this?
- Nominate a single person to make note of the suggestions, by making sure everything is written down no idea is wasted and they can be prioritised and scheduled with your Product Owner
- Consider recording videos instead of live demos, the live demo is a bane of any presenter. By asking your devs to record videos in advance the demos are foolproof, there are no unexpected technical problems and you know exactly how long each video will last!
- Save questions and feedback until the end of each presenter. We are geeks, not public speakers, give your developers a chance by letting them get to the end before bombarding them with suggestions on how to improve the task they’ve been slaving over all week!
Sprint Retrospective
A fundamental part of the Agile Manifesto is that teams should look at what went well, what they’re struggling with and adapt their processes to improve. Often this is done in a retrospective meeting.
When I first started doing retrospectives we followed a well known pattern
- What went well?
- What didn’t go well?
- What should we start?
- What should we stop?
We worked our way around the table and everyone was expected to come up with a suggestion for each list. I found these meetings rather unfulfilling, I often felt they descended into a rant about process, other teams, technology or whatever else was irking the group at the time. While I’ve no doubt that it was good therapy I didn’t feel like the hour achieved much.
Instead I’d suggest planning each meeting with a specific topic
- How can we ensure that high priority support requests are picked up mid sprint?
- Should we use Web API or WCF for our new API?
- How can we get clear acceptance criteria for our upcoming bespoke development?
By stating what you hope to achieve from the retrospective in advance you stand a much higher chance of success! Ask your team for items they want to discuss, email around your proposed meeting topic with plenty of notice and ask your devs to bring their own ideas to the meeting.
Hopefully I’ve given a few helpful suggestions for you to consider. I don’t claim to be an Agile expert and I’m still struggling to follow lots of my own advice but every sprint we learn a little more… Isn’t that the point after all!?
dotdotdev.com 