How to generate actionable items in retro
In our Scrum Team, we sometimes struggle to generate actionable items within our retrospective.
We usually have an icebreaker, followed by some general questions about what went well and what didn't.
After gathering this data, we group the findings and vote on the topics, to find out what the team wants to elaborate on.
Here we get stuck in detail and discuss multiple opinions on possible solutions without actually reaching a consensus.
We spend a lot of time on one or possibly two issues and have a hard time defining a concrete improvement or task to take into our next sprint because we either do not agree with each other or don't know how to tackle the problem.
Is this a common theme in retrospectives and does anyone have a solution on how we could improve on this, as it feels very unsatisfactory to the team, to leave the retro without any actionable items and having only discussed one or two topics?
We have come up with the following improvement to the retro ourselves:
- Instead of asking the team what went wrong, we want to ask for concrete improvement ideas. This way we could vote on them and put them into action straight away, instead of having a full-scale brainstorming and discussion on negative aspects of our collaboration.
Do you think this is a good idea? What else could we try?
thank you very much
- Friedrich
Don't obsess over how powerful an action item might be, also consider how likely you are to do it.
4 columns on a board:
- Action
- Motivation (how motivated are we to do it)
- Ease (how easy can we make it to do it)
- Reminder (how can we remind ourselves to do it).
It migh help or not, but check Liberatin Structures website developed by Keith McCandless and Henri Lipmanowicz https://www.liberatingstructures.com/
It has many interesting practical techniques about braking the ice and facilitating interactions within stagnating groups of people.
Not everything has to be a solution to a problem. An actionable item could be to continue doing something that everyone feels is beneficial.
Also, since you are working with Developers help them see it from their perspective. I'm sure that everyone of them has ideas of how the code base could change to make the product better or more manageable. Have them consider the team's ability to work together as a code base and every individual is one or more routines/APIs/services/functions/etc. How could that "team" code base be improved to be more efficient, more manageable, more robust? Help them to see this as a way to address "technical debt" in the process and interactions they have.
Also, don't try to reach a consensus on how to solve the problems. Reach a consensus on an experiment that everyone is willing to try. Teach them the concept of "support but disagree". I always tell people that there is no right answer, but there are a whole lot of good ideas that can lead to an answer right now. Empiricism enables you to evaluate a situation based upon the information you have available, make a decision on what to do, then inspect the results to identify new information. Repeat over and over and over ...
Generating actionable items in retrospectives is a vital but often challenging task. One effective approach is to focus on soliciting concrete improvement ideas rather than dwelling on past mistakes, promoting solution-oriented discussions. To enhance this process, prioritize the most critical issues, ensure specificity and measurability in action items, assign clear deadlines and owners, and regularly track progress.
For instance, the team can identify key areas for improvement, devise specific and measurable action items (e.g., scheduling weekly team meetings for better communication), assign responsibilities and deadlines, and review progress in subsequent retrospectives. These strategies facilitate ongoing team improvement.
An actionable item doesn't require a concrete solution to a problem. One person doing further investigations or getting in touch with another department regarding a problem is actionable. A solution is developed thereafter.
A retrospective is not a meeting to solve problems but to reflect and learn. One powerful sentence in the Scrum guide is, "Assumptions that led them astray are identified and their origins explored." An example can be developers having thought something was easy to implement, but it turned out to be a hard problem. Why did they have those wrong assumptions? And what does that mean for future implementations?