Co-creating change through retrospectives
How to effectively introduce better ways of doing things as a group
Reducing process was a consistent goal for me and my colleagues while working as a developer over the past decade. All that meant to me was overhead and bureaucracy that got in the way of writing code.
In typical managerial fashion, I’ve come around on process. When introduced correctly, it is the most effective tool available to ensure your developers are supported and producing their best work. However, the way in which process is introduced to your team is key to its adoption and usefulness.
A developer’s workflow is their bread and butter. They work through this process on everything they contribute. Naturally they’ll be skeptical of suggested changes to that workflow. New process is a change to the way she operates and will be met with resistance when imposed without a good reason.
If a new process appears arbitrary, without solid reasoning or clear benefits to the team, you can count on one of two things happening: Begrudging hoop-jumping or low key mutiny.
This is why retrospectives are so critical to adopting a better workflow. Retrospectives are reserved time after a project, sprint, or incident for your team to discuss what went well and how we could have done better. On top of finding ways to improve your process, it also gives everyone on the team a chance to air their concerns and be heard by their teammates.
If you have a strong culture on your team of discussing how things went on any given project, sprint, or incident you have a way to identify where process is needed. Retrospectives the manager’s best tool to create a more productive team.
There are a few different types of retrospectives, each with their own strengths:
- Project retrospectives
- Incident retrospectives
- Sprint retrospectives
Project Retrospectives
After a project has shipped, it’s important to take the time to recognize and praise the great work of the team and talk about what could be better next time. The takeaways will vary from project to project, but no project is perfect and we can use the outcome to learn how we can work together better. You might get suggestions like:
- I felt like the scope changed a lot, it would be good if we spent more time on the spec early to nail down what we’re building
- We didn’t give ourselves enough time to test before launch, we should be better about our estimates on the next one
- The downstream team didn’t have their side ready when we were ready for testing, we should check in with them earlier
These are great adjustments that your team will discover as a result of pain being felt on a project. It’s not a top-down decision to make these changes, they actually want to make the changes to prevent these problems in the future.
Incident Retrospectives
Being involved with an incident can be stressful, but these are the retrospectives that see the most action items. Depending on the severity of the incident, you may uncover a laundry list of different tasks that had been overlooked leading to the problem. People are generally motivated to make these changes so they don’t have to go through another incident like it. You might get suggestions like:
- The PagerDuty rotation didn’t have the right setup and we had a hard time getting the right people involved
- We aren’t doing enough integration testing on these two disparate systems
- Our tooling didn’t catch this problem before it got to the point of being an incident
It is critical that these retrospectives are blameless and supportive. Obviously, somewhere along the line something got messed up. Placing blame on any individuals doesn’t accomplish anything here. If you’re able to assume everyone on the team is doing their best we can identify the underlying reasons why the individuals involved made the decisions they did. Maybe you’re not allocating enough time for testing, maybe you’re not prioritizing projects to mitigate risk in your systems. These are the sort of takeaways you want from an incident retrospective.
The most challenging part of an incident retrospective is allocating time afterward to complete the action items you built together. Incidents are inherently unplanned and will eat up time you had previously allocated to the project it interrupted. You need to prioritize the work to fix the issue or you’ll be having the same problems again soon. It’s a good idea to schedule a follow-up meeting to check the progress of these action items since they’re generally outside the planned workload and can easily be dropped.
Sprint Retrospectives
Sprint retrospectives are slightly different from the other two. The action items coming from your sprint retrospective are more for the manager than the contributors. In an environment where your team can raise struggles they had this week and discuss why things went well or poorly, this is the chance for the manager to get a read on where the team is feeling friction, then go and address it. You might get suggestions like:
- I had a hard time getting my code changes reviewed, I know everyone is busy, but one of them went a day or two without a look
- I keep getting pulled into meetings that don’t really apply to me, it’s starting to eat up a lot of my time
- Apparently the project we were depending on from our upstream team is delayed, I’m not sure what that means for our timeline
These are the signals you want to hear as a manager, so you can go find out how to mitigate their issues. If it’s something that can be addressed as a group, it’s great to discuss in the moment and decide on a change. For example, the group can agree to review each other’s code more diligently before moving on to their next task. If there are issues unrelated to the team’s workflow such as cross-team communication or roadmap planning, this is your chance to find the gaps in your coverage and make adjustments to how you’re managing the team.
Each of these meetings should be practiced regularly. They’re a great use of time for the team and can often be accomplished in only an hour of the team’s time. With each of these retrospectives, they should be largely driven by the contributors as they are most in-tune with the pain being felt. You can come with your own ideas of what you’d like to see happen, but it’s important you’re co-creating these changes and you present your ideas for feedback as possible adjustments, not dictated changes.
If you’re not currently doing any kind of retrospectives on your team, taking time to talk about this stuff can feel awkward or overbearing. You may get some resistance to introducing a new meeting, but this is the critical meeting you want to be spending your team’s time on.
These meetings give people space to learn from each other and adjust their workflow in a more organic and positive way. It can also make your life as a manager better with a happy, engaged team that is invested in team success along with you.
It doesn’t need to be overly formal to be effective. Just having space and time to talk about these things as a group can yield great results. It’s the starting point to getting better as a group.
