All meetings in scrum are important, but one weighs more than all: Scrum Retrospective (notice that I even used Caps Lock to write the name – it is that important). You can live without it, of course, but you will certainly not improve, nor identify possible mistakes.
In other words: you will find yourself doing “Homers’ D’OH!” at least once in your future. Especially when you will discover that you did the same mistake twice.
Audience: Scrum Team members or anyone interested in keeping the meetings short & productive | Estimated reading time: 20 mins
1.Is Scrum as simple as making soup?
For those who aren’t familiar with the purpose of retrospective meetings we will explain in one moment. But first let’s remind ourselves what is SCRUM.
Scrum is an empiric process control model.
When do we use empirical model process control?
If we look up the definition (for instance the one on Wikipedia) we see that empirical process control models are used when you want to control imperfectly defined processes.
The simplest example of empirical model process control i can think of is making soup.
How do we make sure this control approach works?
The answer is pretty intuitive (if you think of it) : we need to make sure we have three things:
Sprint Retrospective covers points 2&3 from above.
Shortly : by keeping regular and productive retrospective meetings we assure 66.7% of SCRUM success.
The sentence above seems pretty easy BUT there is one word that is difficult to achieve : and that is “productive” meetings. For the rest is simple: We just establish regular meetings, we invite the DEV team and we hold the meeting. But how to hold the meeting so that it is “productive“?
I’ve ask myself : “How do I measure if a meeting is productive or not? How are the meetings now? What is the baseline?”
***For those who want to learn more about measuring abstract things I strongly suggest reading “How to Measure Anything: Finding the Value of Intangibles in Business” by Douglas W. Hubbard – a good book with great examples.
I choose to guide myself after the most intuitive “radar”: people morale. Please notice I don’t refer here to happiness, but to morale.
So I went ahead and said to myself that the meeting was “good|productive|successful” if:
- the people were engaged during the meeting:
- they were paying attention
- they were asking questions
- they talked even if it was in contradictory – it is a good thing to argue (not fight); from disagreements new ideas can emerge.
- the people were saying “that was a good meeting” after the meeting
2. Good meetings are like skiing
There is a long way between knowing the theory and making it happen. For me it took around 3 months until I could say i had a “productive” meeting. I hope you will do it quicker 🙂
The great thing is that when you and your team have your first productive meeting something switches in everyone’s’ mind. The team will definitely know it. It’ s like learning to ski: you try for a long time to keep your body in the correct position so that you don’t go against gravity, but use it in your advantage. You try and you try and you try …and all of a sudden comes a moment when you know you did it : your knees and ankles no longer hurt, your legs are parallel and your skies slide perfectly with no big effort from your side. That is the moment when you know you had the perfect position. It was a great moment, you enjoyed that moment and you definitely want to feel it again. The same happens when you have a productive meeting: everyone is engage, they all are having the same goal and they own the moment. After seeing how good it feels to work productively in the team they will definitely want to repeat it. So after the first productive meeting you will definitely have a second, a third ..and so on. Like a good cupcake : everyone will want one more.
3. What I’ve learned through experience
About Retrospective meetings
Retrospective meetings are scheduled after the Sprint has ended. It is the meeting where team members openly discuss issues, ideas, think of what and how to improve. Product Owner should not participate as she/he might get bored of the technical discussions. On the other hand the Product Owner must not be kept in the dark. I think it is in the Scrum Master responsibilities to keep the Product Owner informed on the topics & actions coming out from Retrospective meetings that might impact him/her.
When to define Retrospective Meetings?
Retrospective meetings should be scheduled as close as possible after the end of the Sprint (maximum 2-days after Sprint Review & Planning meetings). Otherwise the team members will start focusing on the new sprint and will forget what happened in the old one. We are humans: we don’t have the memory of an elephant.
Also it is important to keep it time boxed.
What about the format?
There is no success recipe for having good retrospective meetings. It is encourage to change from time to time the format of the Retrospective Meeting so that the team members don’t get bored, try more things until you find the format best suited to your team.
Who brings input?
I’ve also learned that in time, after the team & project reaches maturity, the input of the Scrum Master counts more and more.
4. How we use to keep the Retrospectives:
We started at the beginning of the project with a simple format :
- Good – what we liked in the Sprint
- Bad – what we thought it went wrong in the Sprint
- Ideas of improvement (with responsible).
Our Retrospective meeting took around 1 hour (for a 2-weeks Sprint & team of 6): 10 minutes for everyone to write on a piece of paper in silence and peace their input. The rest of 50 meetings (or less) were dedicated for open discussions.
After a while I read on forums about ‘Retrospectives with a theme’ and we tried couple of things out. We tried out the “Fly High!” Retrospective theme (or “Flying a kite”) inspired by Madhavi Ledallas’ article from scrumalliance.org combined with Mikes’ Cohn START-STOP-CONTINUE format (from his blog). I found Mikes’ idea very productive as it makes us focusing on actions instead of emotions; on “what we can do?” instead of “how is that made me feel?”
The idea of this format is that everyone identifies impediments, and also thinks at actions that can be done by themselves. In the end you should sit and map what actions eliminate impediments. You can even use suggestive post-it colours :
- blue post-its for “actions” ;
- red post-its for “impediments”;
- orange post-its for “what the team should stop doing”;
- green post-its for “what the team should star doing”;
- and so on..
We went with almost all of them blue – economy purposes 🙂
Positive aspects for using theme retrospectives: There is a big chance at the end of the Retrospective to see that most of the impediments can be eliminated by the proposed actions. This has a very positive impact to the team members as they see that it is in their power to solve issues. The remaining impediments that don’t have a pair-action should fall in the responsibility of the Scrum Master – to at least announce the Project Owner and tackle them.
Negative: 1-hour is not enough for a “theme retrospective”. If you let everyone state all the five points (good, bad, impediments, start, stop & continue) it takes at least 1.5 up to 2 hours.
Conclusions: I think it is a great approach for the first couple of months of the project, when the team is still in the accommodation phase (i am talking of 2-3 months). But after everyone gets the drill it might be perceived as childish 🙂
5. How we currently keep the Retrospectives
Our current approach is faster and based on the input brought by the Scrum Master. The timebox is 1 hour, and it is split is as follows:
- 10 mins – Scrum Report presented by the Scrum Master. The report contains parameters that you consider relevant for the team or Product Owner. They might differ from team to team, but the must have should be : burn down chart, number of bugs, stories that were not estimated correctly, stories that were rejects.
- 10 mins- everyone writes down start-stop-continue actions plus the “thanks you”. “Thanks to..” it’s an idea brought up by one of my colleagues in the last Retrospective and it had a great such a positive impact on everyone that we decided to keep it. Basically you tell “Thank you!” and you nominate the person who helped you, or you recognise & give someone credit for doing something good. This has a great impact coming from your colleagues – and it is a sure boost of the team morale.
- 40 mins – Open discussions
Please share your thoughts in the comments below. What have you tried out so that you make meetings more “productive”?
- Wikipedia: Empirical process (process control model) – https://en.wikipedia.org/wiki/Empirical_process_(process_control_model)
- Techniques for Keeping Retrospectives Lively – https://www.scrumalliance.org/community/articles/2014/april/a-reflection-on-retrospectives
- Sprint Retrospective – https://www.mountaingoatsoftware.com/agile/scrum/sprint-retrospective
- Retrospective Wiki – http://retrospectivewiki.org/index.php?title=Common_ailments_%26_cures
- Re-Energize your Retrospective video: