I’ve heard complaints that the Scrum approach to software development creates a lot of additional stress. Really? That perception needs further analysis.
The team commits to a delivering a set of stories by a target date. That’s stressful. They have daily standup meetings to report progress and discuss impediments. More stress. They have to satisfy a definition of done for every story. Added stress. Finally, they have to sit through retrospective meetings and take criticism. I’m stressed out just thinking about it.
It’s important to understand where the stress comes from and how it can be mitigated. Scrum isn’t designed to be stressful. When done well, the Scrum approach should be a less stressful and a more enjoyable way to build software systems. Here’s the lowdown.
Starting at the beginning, the team is committing to the delivery of a set of stories by the end of the sprint, usually 2-4 weeks long. We all need to make and keep commitments. It’s part of being a professional. Problems arise when management expects the team to deliver exactly the same number of story points – or more – during every sprint.
That’s not realistic. Software developers are human. They have family obligations, get distracted, encounter problems, make mistakes, etc. The number of story points delivered per sprint will fluctuate. Measure the average number of story points delivered over several sprints. The average sets an expectation for what the team can achieve over time but it’s not a guarantee for any given sprint.
Much of the stress around the daily standups comes from managers who attend the meetings and interrupt with too many questions. They may unwittingly turn the standups into status reports. Everyone is pressured to report progress and commit to making more progress by tomorrow. Of course, poor managers don’t want to hear about impediments at all.
The daily standups are team meetings. They are not management meetings. Managers who want status reports should consult the Scrum Master after the standup. Let the team do it’s job.
The definition of done (DoD) should be a useful artifact. It should help team members verify that all the steps required to deliver a story to the business are complete. It really should be a simple, helpful checklist. Don’t include lots of administrivia in your DoD.
If the definition of done is too long and complex, it will frustrate the team members. Keep it simple. Also recognize that the team needs to work together. If someone has trouble satisfying the DoD for a story, that person should ask for help (or better yet, someone should step up and offer help). It’s a team effort!
As for retrospectives, they are a great tool for continuous improvement when used effectively. Beating up on people during retrospectives is not allowed. Neither should people be allowed to whine and complain. The focus is process improvement.
The topic of retrospectives is too broad for this short post but in essence, keep the retrospectives impersonal. Focus the outcome on one or two areas for improvement during the next sprint. Determine how the improvements will be measured and make sure they happen.
Scrum and other agile development approaches are not torture tests. They are designed to improve teamwork and minimize the need for management intervention. If you’re stressed out, don’t blame Scrum. Blame the people around you.