This article is an excerpt from our new book. For the full guide to building a collaborative software team, pick up your free copy!
You’ve done it. The milestone ended. Code that solved a specific problem was tested and shipped. One of your programmers grew a beard. No one expected mutton chops from Martha, but your team is being very supportive of her choices.
All in all, it was a successful sprint.
Now it’s time to take stock, analyze your work, and fine-tune your process so that your next sprint is even more successful.
“Teams that don’t have retrospectives never close the feedback loop,” says Wes Garrison, a Rails consultant and Ruby conference organizer. “They say they want to improve their processes, but they don’t have a system to actually put those changes into place.”
Let’s discuss what that system might look like for your team.
If your team is centralized in GitHub and ZenHub – and therefore already highly collaborative – they are probably familiar with what’s been accomplished during the Milestone. Regardless, demos can be a helpful practice to stay connected with your end user.
Try doing a bi-weekly or monthly demo from the user’s perspective. Similar to how we emphasize a user story format in an issue’s title, you should place an emphasis on how you’re continually solving new problems for your customers.
This is the perfect time to bring in other people, like designers, executives, marketers, salespeople, and the customers themselves. Not only does it feel awesome to show off what you’ve been working on, but it's also helpful to put your complex day-to-day work into terms that everyone can understand.
Tweaking your process with sprint retrospectives
After a Milestone is complete, you need to make time to reflect on it – especially if you’re new to this workflow.
Working constantly might feel good, but without reflection it’s akin to being too busy mopping to turn off the faucet.
At ZenHub, we schedule 30-45 minute check-in meetings every two weeks. To keep the conversation focused, the product owner or project manager will prompt us to come prepared with any points of discussion, which are collaboratively added to a GitHub issue.
The most important aspect of a retrospective
The core of any successful retrospective is honesty.
Unless you are transparent about where problems originate, you’ll only be treating their symptoms.
If your team is anything like ours, nobody wants to point fingers. To address this problem of politeness, encourage a non-judgemental environment focused on improvement and information-gathering. Shaming or punishment have no place here. Set the tone by establishing a safe space; for example, open the meeting by giving out +1s for recent wins.
Scott argues that radical candor – the practice of giving, receiving, and encouraging frank guidance – is actually your moral obligation as a teammate. She says:
Radical candor is humble, it’s helpful, it’s immediate, it’s in-person — in private if it’s criticism and in public if it’s praise — and it doesn’t personalize.
In contrast to radical candor, most of us fall into a dangerous space Scott calls ruinous empathy – which is to say that we’re so intent on being “nice” that we end up ignoring problems and sabotaging our team in the process.
While feedback should be immediate and impromptu, regular retrospectives are an invaluable tool to building a healthy and radically candid team.
Here are a few ways you can improve your retrospective.
Retrospectives: Start, stop, or continue
During the meeting, ask each team member to name things they should start, stop, and continue doing. “Continue” items are the things that are helpful but aren’t yet habits. Mark these in your GitHub issue.
To stay accountable, open each retrospective with a 5-minute review of the previous sprint’s issue. Ask the team: did you stop, start, and continue the things you said you would?
Retrospectives: Keep it focused and actionable.
It’s always better to have a couple of high-value actionables than a bunch of vague ones.
Identify a few things your team will do differently in the next sprint, mark them in GitHub, and remember to follow up next time to evaluate how it went.
We close our retrospectives by verbally repeating what our actionables are, and state who the keeper is. A lot can come up during a retrospective, so this final step helps cut through the clutter and ensures everyone understands who is responsible for what.
Retrospectives: Keep asking “Why”.
Of course, the value in reflection isn’t just about identifying what you did well, it’s openly discussing problems and areas of improvement.
Root cause analysis is a fancy term that means “tracing a problem to its source.” It can help you figure out what happened, why it happened, and what steps you can take to prevent it from happening again.
The first step of root cause analysis is to identify the problem: what areas of concern arose during the sprint? How and why did you recognize it as a problem?
Next, you’ll want to collect data: how long has the problem existed? What was its impact?
After that, try to identify the causal factors: What events led to the problem? What other problems sprung up because of it?
By figuring out the causal factors, you can move toward nailing down the root causes of the problem. We need to go as deep as possible to uncover these root problems. Try asking “why” a few times.
- Why did x happen? (Because of y.) Why did y happen?
- Why is x a problem?
- Why did we not see x happening until now?
- Why did no one report on x?
It feels weird, but you’d be surprised how repeatedly asking “why” digs up root causes that nobody would have thought of.
Finally, figure out the actionables you’ll take to prevent the problem from happening again.
Retrospectives: Dealing with leftover work
Your team may not close every issue attached to your Milestone – that’s just life.
Are they open because your team didn’t have enough time, or are they open because they’re no longer relevant?
Whatever the answer, don’t just leave your leftover work in your sprint backlog. You’d be surprised how often those issues just don’t matter anymore because circumstances have changed.
If work is still relevant, look at the issue title (user story) and details (like acceptance requirements). Does the issue need to be re-written or clarified? If you’re confident everyone still understands the goal, save yourself the time and leave it as-is.
Most importantly, make sure you understand why the work wasn’t done. Did you over-estimate your velocity? Is there disagreement with the original time estimate attached to the issue? Unless it’s really unclear, it’s probably fine to leave this task to the product owner.
Pat yourself on the back
You did it! Not only did you properly prepare for your sprint, you successfully saw it through to the end, and you took the time to reflect and make sure future sprints go even further.
Now get ready to do it all again.