Hi guys, this post will be about Scrum Retrospective Tips. I have been running Agile Retrospectives workshops for several years now and many people always ask me the same question: "How can I make my Agile Retrospectives effective?".
As you can imagine the answer to this question is not simple but I decided to leave four scrum retrospective tips that will help you to make your Agile Retrospectives more effective
I believe we should define more often: “Success Criteria for Retrospective Topics”.
I’m guessing that now you are thinking: “Oh my god, this guy is crazy, a list of success criteria for an Agile Retrospective improvement topic…!?” Let me explain my idea before you criticise: In life, there are some tasks we tend to perform without thinking about how, exactly, we will deem them successful. We cannot answer the question of “How do I know if what I did was successful or not…?” because we lack a clear set of criteria.
Let me explain my idea before you criticise: In life, there are some tasks we tend to perform without thinking about how, exactly, we will deem them successful. We cannot answer the question of “How do I know if what I did was successful or not…?” because we lack a clear set of criteria.
A few weeks ago, a Scrum Master I had coached asked me for an opinion regarding something that a team had decided. I answered by asking him:
How will you know if what you decided will help the team or not?
How do you know if what you decided is making things better?
He stayed silent, and I assume he did not have any clue. This is just one example; however, I believe this is what happens in 90% of all cases, we act without thinking about what the conditions for success actually are.
For example, in many industries, a PDCA cycle (Plan, Do, Check, Act) is not uncommon. Basically, we plan what we want to do with a success criteria, we do what we planned, we check the success against the success criteria, and if the implementation was successful, we choose something else to improve.
If it was not, we try something else that will solve the problem (this was a very simplistic explanation, meant just to provide you with a basic idea).
So, my idea is why not start using something like this in our Agile Retrospectives? I do not want to create anything formal or any strict process out of this, but rather I want to force us to think about our actions in order to see if what we do actually helps or harms us.
During my tenure as a Scrum Master and Agile Coach, I experienced the reality that many teams tend to collect a long list of items (that need to be changed) during an Agile Retrospective. This is a common mistake spread not only in the software industry, but also throughout our society.
How many of you have (or have had) a long list of “improvements” on the wall or in some excel sheet? The intention behind such lists is good, but are these really useful?
Mike Rother explains in his book, “Toyota Kata”, that “Whenever we alter any one thing in a process, we create, in effect, a new process with possibly new and different characteristics. This means that once we have implemented one or two items from an action-item list.
Then the rest of the items on that predefined list may no longer suit the new situation and new priorities in the process.” Taking this into consideration, is it really useful to have a long list of improvements?
There are ways to change several topics at the same time within a system (for example, by applying Design of Experiments [DoE], where multiple variables are changed at once), but few people are able to apply this technique.
We want to create organisations where everyone is involved with continuous improvement. Applying DoE means that only a few people within an organisation will be able to participate in continuous improvement efforts, and this is not what we want.
Based on the previous observations, I believe the right thing to do is simply to take one topic out of our Agile Retrospectives at a time.
Select a topic, but make a proper analysis of that topic. Thoroughly understand what the root cause of the problem at hand is (you can use techniques such as the “5 Whys”).
After understanding what the root cause of the problem is, you have the necessary information to fix the problem during the next sprint as I will explain on the next point.
During the last Agile Retrospective, I was a part of, one of my teams came up with nine topics to improve. Most of the topics were very general, for example: “improve communication”, “be more responsible”, “take more ownership”, etc.
Having a long list of improvements is actually a quite common “smell” in an Agile Retrospective. So, what should you do in order to avoid this problem, and what can you do to leave the Agile Retrospective with a good understanding of the problem?
In my opinion, you should choose one simple topic to improve. If you have several topics on the list, ask your team to do a vote session. Ask them to choose what the most drastic problem is—this is the one they should fix.
After having selected the biggest problem, we should spend some time understanding what the root cause of the problem is. I think this is one of the most important parts of an Agile Retrospective, where a team will truly come to understand what is going on within a system.
Without understanding this, your team will not be able to fix the problem.
All the aforementioned topics, like “improve communication”, “be more responsible”, “take more ownership”—they are simple symptoms, they are not the root causes. People need to stop and understand what affects communication, why people are not responsible, or why they do not take ownership of their tasks.
So please, if you are a coach, Scrum Master, or anyone else responsible for facilitating an Agile Retrospective, make sure that the teams involved choose one single topic and that they go deeply to understand it.
I just want to make sure that you guys are aware of this common pitfall; I made this mistake myself over the last few weeks, and I am sure there are a lot of people who do the same.
In my opinion, Agile Retrospectives are the most important part of Agile software development. This is the time when teams analyse their ways of working and suggest new methods to improve their current processes.
I believe everyone agrees that this is a mandatory artefact and cannot be avoided. However, not everyone agrees that Agile Retrospectives should be conducted within the sprint— thus I would like to explain why I think it´s important to do these within the sprint.
First of all, I see Agile Retrospectives as the closing part of a sprint; when the team does an Agile Retrospective, the sprint is over, and everything related to it is gone. This allows the team to start a new fresh sprint without any pending issues from the previous sprint.
Secondly, during Agile Retrospectives teams come up with several action points and topics to be tackled during the next sprint. If we allow an Agile Retrospective to be dragged on for two or three days inside of the next sprint, how can we take all of the items that will pop up within the Agile Retrospective?
And put them into the planning process for that sprint? This is why I think it´s extremely important to confine Agile Retrospectives within sprints.
My friend Marc Loeffler some time ago wrote another interesting blog: "The 5 Most Asked Questions In Retrospectives". I think this is a really good source as well, go there and take a look.
Hope you enjoyed. Leave a comment below with your thoughts.
[shortcake_call2action title="ORGANISATIONAL MASTERY SCORECARD" description="We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery." button_text="Take The Test" button_link="https://www.organisationalmastery.com/scorecard?utm_source=web&utm_medium=Blog - From Luis Goncalves&utm_campaign=Scrum Retrospective Tips" /]
If you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.