Scrum can be a drag when executed poorly. Done right, scrum is a non intrusive framework that provides a great flow for software development teams. In this post I share my best tips on how to dial your scrum all the way to 11.
Scrum today
Most software development teams today use scrum to coordinate work within the team. Scrum was developed in the early 1990ies. The latest update of the Scrum Guide was 2020. The scrum guide focuses on process and terminology, not tools. While no one does standup in front of a physical board with post-its these days, scrum artifacts and scrum events are everywhere.
Yet how we do software development has changed immensely. 30 years ago we could only dream of releasing to production many times per day with anything more complex than a phone directory. Working with distributed teams required expensive travel arrangements. Seamless ad hoc video conferencing was science fiction. Provisioning a server took months.
What a small team of dedicated professionals can do today in a sprint would be a six month project in 1994 if at all possible.
Advances in tools and technology impact how we best execute scrum. In this post I share my best tips on how to use the tools available today to get the most out of scrum. But before jumping into the finer details, let’s make sure we got our basics right.
Scrum is never the purpose
Always when talking process frameworks and tools, we need a big fat reminder: Scrum is never the purpose. Scrum is a process framework, a tool that can help you. The purpose of your team is to deliver value to your customers and this trumps any other concern. Never let a tool, framework or technology get in your way of delivering great software.
Scrum is never the purpose.
Now let’s take a look at how you can boost your execution of the three most important scrum events.
Non intrusive daily stand ups
The purpose of the daily standup is to coordinate the daily work and catch if someone needs help. This can be achieved in a non intrusive way using chat and occasional video calls:
When you go online at the start of your workday, write in the team chat: “Today I will work on (problem/task/story). I need help with (getting access to…/setting up…/figuring out…).” When you log off for the day, write in the team chat the results you have achieved today, including new issues discovered. When a pull request is ready for anyone to review, announce it in the chat immediately.
Supplement with occasional video calls to socialise and to catch if someone needs help without realising it themselves. A virtual coffee break with no stated agenda. For a mature team, once or twice per week is enough.
When needed, team members set up video calls to collaborate. Backlog grooming, knowledge sharing, code reviews, informal demos, test sessions, shared troubleshooting. For new team members and junior developers, senior team members should check in at least daily and schedule a series of onboarding sessions.
This way you get a great flow of information within the team where your engineers can focus on what they do best.
Self organising sprint demos
The sprint review is where the team look at the product together. This is the most important event in scrum. The sprint review is not for counting story points, updating Jira issues or talking about all the stuff we didn’t finish. We look at what we have built. What is working right now. Get ideas for what to improve next.
The best way to do sprint reviews is for each engineer to demo the completed features they have worked on. Show how it looks and how it works. The advice show don’t tell has never been more appropriate. Watching someone use software simply eliminates any number of mental question marks and very effectively communicates exactly what is there, what it does, and how to use it.
The advice 'show don’t tell' has never been more appropriate.
You can include insights into the code and the configuration, but keep this brief. Schedule separate sessions on opt in basis to dig into details.
You can demo supporting assets like build tools and technical documentation, but take these at the end so that product owners and less technically interested stakeholders have a chance to leave.
A smooth way to organise the agenda for the sprint review is to start a thread in your team’s chat channel a day or two before the scheduled time (you can configure a bot in Slack to do this quite easy). Engineers who have completed stories or features to demo replies with a short message stating the topic. At the demo, simply demo in the order listed in the thread.
Product owners and other stakeholders can listen in and decide for themselves if they want to join. Or reach out directly to the engineer with questions and input.
Shake up the retrospectives
Sprint retrospectives are where the team inspects the process and identified improvements. Process awareness is essential for self improving teams. However, it is also the part of scrum I see most teams struggle with. They easily turn into a boring drag.
[Retrospectives] easily turn into a boring drag.
Either everyone talks about everything. Or people disengage and self censor themselves until only one or two speaks at every event. You get a list of well intended improvement initiatives that are either impossible for the team to carry out or addresses one off issues that are unlikely to occur ever again. Most teams need coaching to benefit from retrospectives.
Short of calling in an external facilitator, here are a few ideas you can try out:
- Rotating facilitator. One idea we tried out in a team was to rotate the facilitator for the team retrospectives. This helped fix missing engagement even if not everyone liked being put in on the spot.
- Feedback in advance. Another idea is to break up the format of the retrospectives. Sometimes, collect feedback in a survey 1-2 days before the retrospective and have someone analyse and present the responses at the retrospective. It takes more effort from one person but helps surface views of less outspoken team members. The most outspoken view may not be the most important issue to address.
- Take the long view. Once in a while, run longer sessions where the team looks back three or six months. This helps the team see how far they have moved over time. Like, remember back in April where we were battling endless build breaks? Or chasing memory issues in that shaky component? Isn’t it great that we have fixed that?
Conclusion
I hope I inspired you with specific and actionable ideas for how to dial your scrum to 11. Context matters and what works for your team only you know. I’d be happy to get in, get to know your team and provide feedback specific for your situation.
I’m a software professional with more than 20 years experience in delivering great software. I work hands on within teams writing code, test, and documentation. I coach teams in tools, technologies, and best practices. I committed my first line of code for production in 1999. Since then I have explored software development from ideation to sunsetting. I have designed software, deployed software, procured software and supported software.
I’m looking for a full time role in the Greater Stockholm area working hands on within a team writing C# .NET code. Get in touch if you think I’m a match for your team/organisation.