You don’t need a Retrospective to Inspect and Adapt your Effectiveness
Most teams that I have worked with run retrospectives. Usually, they are held at the end of their iteration. After doing the same for some time, we wondered if there is a more continuous way of inspecting and adapting.
In this post, I’ll share how we moved from retrospectives every few weeks to reflecting daily. I’ll elaborate on how we got there and the challenges we face(d). Lastly, I’ll bring in my view on whether retrospectives are still needed for our team.
Exploring the Theory
First of all, continuous reflection on the ways of working is not a Scrum thing. In the Agile Manifesto, one of the twelve principles reads as follows:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
As many teams use Scrum, they are most likely familiar with the term “Retrospective”. The Scrum Framework implements the “regular reflection” by making it an event within a Sprint:
The Sprint Retrospective concludes the Sprint.
[…]The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. — Scrum Guide 2020
Whether we use Scrum, SAFe, or any other framework, or invented our own way, it makes sense to reflect on a regular base on how we work as a team and how we can increase our effectiveness.
If you don’t reflect on a regular base, you’re missing an opportunity to improve. You miss a chance to create experiments to find better ways to achieve your goals.
Or as the popular saying goes:
The definition of insanity is doing the same thing over and over again and expecting a different result.
From Cadence to Continuous
Like many other teams, we were running retros on a cadence. But over time we felt that there might be other ways to reflect on our effectiveness that would fit our team and context better.
Retrospective on a Cadence
In our team, we are not using Scrum as outlined in the Scrum Guide. The team did decide on a cadence of four weeks for our retrospective. Those retrospectives are usually engaging and we manage to come up with actionable items that most often are addressed until the next retrospective.
On the other hand, four weeks is a long time. And while the team was happy with it, there was this feeling that we miss out on some valuable discussions. Everyone was encouraged to raise impediments or potential improvements at all times, but we did not get so many of them “in-between” retrospectives.
Root Cause Analysis on Customer Problems
Retrospectives were however not the only way where we reflected on our ways of working. For every problem reported by a customer, we ran a root cause analysis (RCA).
Regrettably, we faced a significant backlog of technical debt and quality issues with the product we were handling, which had accumulated over time. But that meant that we also had lots of opportunities to learn, reflect and improve.
Doing an RCA for every complaint helped to increase the quality a lot. Finding patterns in the root causes of the problems helped us address the biggest issues.
It took a while, but over time we did see a significant improvement and fewer and fewer complaints. But that also meant we were reflecting not as often anymore.
Reflect on Learnings for Every Product Backlog Item
As we saw the positive effect on our RCA for customer problems, we thought that it would make sense to do this more frequently and apply it more broadly to our process.
Adjust Workflow
We introduced the capturing of learnings into our definition of workflow. The name was purposefully chosen over “Root Cause Analysis” as we did not want to limit ourselves. We can learn from bugs as well as new features. We can learn from things that did not go so well as well from those items that were going very well.
In the end, it means that for every item the team is working on, we want to capture what we learned and how we can improve as a team.
In practice, this means that, for every item in the Capture Learnings column we have a discussion about what we learned. Everyone is invited to contribute to this. Often we specifically ask the people that were driving the specific item to share their learnings. This does happen async via the Discussion feature on the item on Azure DevOps. If the need arises, an ad-hoc call is held to dive deeper.
There are various possible outcomes of such a discussion:
No actionable learning
The item gets closed. It’s important to note that it’s not a must to generate something for every item.
Actionable Learning that can be done right away
Do it and then close the item once it’s done. This could be something tangible like code/wiki changes or less tangible like discussions with the team or having a knowledge-sharing session.
Learning that requires more effort
Create a follow-up item, link it to the one that spawned the discussion, and close it. Important to note here is that we aim to work on the follow-up item soon (in the coming weeks). Items that are “cool things to do in 6 months” are not what we look for.
Learning that requires more discussion
Find a way to discuss in more detail (e.g. in a Retro) or with a broader audience (with the full team or people outside of the team). Close the item after the discussion and follow up with other action items if needed.
Topics Covered by our Learnings
Our learnings cover many different topics. Some are more obvious and related to the work of the developers, like issues in certain parts of the code or technical debt that should be reduced.
Other learnings are triggered by our metrics. For example, we look at the work item age of the specific item and if it’s above what we’re aiming for. We are trying to figure out why that was the case and how we can improve that. Was the item too big and we should aim to have smaller chunks? Or was it blocked somewhere and we accepted that instead of actively trying to unblock it?
In general, we try to look for things that we would do differently if we could start over with this item. This can also lead to changes in our process that have an immediate effect on the way we work. It allows the team to challenge and improve our process immediately. For example, we realized that we were not aligned on the goal of a specific PBI, which lead to changes in how we refine our work and who is involved in the refinement.
Consequences
After the capturing of learnings became part of our workflow, we did notice an increase in cycle time. It took some time until the team was used to capturing the learnings for every item (instead of starting something new). We tried to counter this by limiting work in progress over multiple columns — only when we finish items we do start new ones.
While it still needs some “nudging” every once in a while, the learnings that are uncovered are invaluable. The fact that this is done closer to the work on the item helps a lot, as the context is more present to everyone involved.
What did we Learn?
After having introduced the change about three months ago, it’s a good time to reflect on how this worked for us.
In general, we’re happy that we reflect more often. It is hard to tell if all those things would have been raised in a retrospective as well. I guess that for sure some of them would have been forgotten by the time the retro happened. And even if not, we might not have had the time to dive deeper into all the items.
We’re still struggling that sometimes items are not reflected on. One assumption is that it could still be seen by developers that they need to “justify” themselves. Sometimes the content goes in this direction. Instead of “this is what we can/should change” it’s more of “this is why it happened”. While this might be a good start, but does not help to improve. We’d like every developer to be active in shaping how we work and would hope to get a concrete proposal of what we should change.
To improve this, we would like to discuss and clarify the purpose with the team. Also, we want to make clear that we look for anything that helps us improve our effectiveness. Then we plan to run a workshop to share some specific techniques to “extract” meaningful learnings.
Overall, we’re content with our approach. We can reflect on specific items relatively quickly. For the developers, it is nice as we don’t have to wait for the next retrospective but we can raise and potentially address impediments right away.
Obsolete Retrospective?
So does this now mean that the retrospective is obsolete? If we reflect right away during the work on the specific items, is there any need to still have a retrospective on a cadence?
For us, those practices are not mutually exclusive but complement each other nicely.
Retrospectives Then
Previously a retrospective might have been used to dive deeper to figure out why some items were taking a long time. Patterns might have been identified and some actions would have been put in place to improve this. Most likely we would have checked on the impacts of those actions in the next retro.
This is not a bad approach. However, nowadays we’ll discuss this right away, as soon as we have the first item that ages too much. We don’t need to wait for a pattern to emerge to take action.
Retrospectives Now
As some topics are “cleared” via the learnings already, it gives us more space to dive deeper into other areas during retrospective.
We can take the time to explore “wild ideas” to improve effectiveness and don’t need to discuss about code that needs a refactoring and how we should deal with that.
For example, this can be related to the different Sprint Events, like how we engage and collaborate with stakeholders during Sprint Reviews or how we could improve our Dailies.
It can also be that we want to dive deeper into some topic that emerged from a learning. If it can wait till the next retrospective and it’s something we want discuss with the full team, the retrospective is a good place to bring this up to not take away the focus from the team during a Sprint.
Conclusion
Openness about the things that can be improved is needed to bring more transparency to how we work. Displaying the courage to tackle those issues is key that we not only inspect but also adapt our ways of working continuously. Without those two traits lived in your team, any kind of inspection and adaption will be hard to achieve.
In Scrum, retrospectives are held at the end of each Sprint. While this is a good practice, it might make sense to reflect more frequently on our effectiveness. Combining a retrospective on a cadence together with reflections for every work item we worked on helped us improve as a team.
However, you should be aware that this might have an impact on your Cycle Time (if you make it part of your definition of workflow) and that the team needs to understand the purpose of this — it’s about finding better ways of working.
