Hi guys this blog will be short and simple. :)
In this blog post, I will introduce something new that 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 a 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.
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 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.
Did you like this post? Get a sample of the book by subscribing to my newsletter below and follow me on twitter: .
In some of my retrospectives, I used something like a personal success criteria. An example of this is a retrospective that I did with a team which had way too many actions coming out of retrospectives and wasn’t making progress with the actions: their backlog of actions became bigger and bigger. I did a retrospective where my personal goal was to bring the action list down and have them focus.
I started this retrospective by asking them on the progress of their actions, where I wanted them to be explicit on what has changed. They had been so busy with the sprint that they didn’t spend time on the actions. Admitting and discussion this, they became aware of the problems they had: Too many actions, actions were too general, and insufficient insight in the benefits they would get from the actions.
We discussed some of the actions that they considered most important, and then redefined them to have two doable actions for the next sprint. In the next print they managed to complete one action, which was celebrated in the retrospective.
Ok, initially it was a personal success criteria to bring the number of actions down. But it cam a team goal when they agreed that not making progress with actions was their biggest problem. So the success criteria of that retrospective was to come out with fewer but better actions!
Hi Luis, what you are proposing is simple but powerful. Check this out: I’m in the middle of the planning for the next sprint retrospective with one of the teams that I’m working with, and I’m experiencing the same situation by asking myself the question: is this the right subject to discuss with the team? is that subject which would bring them to the next level ? How do I know that what I planned was successfully implemented?. Well I totally agree with you, about having a kind of simple but solid process to help you and the team validate, that the retrospective was a success or not.
I believe that you need that feedback as an inspection mechanism to hep you adapt to what the team requires. Good post series, about retrospectives. PD: Just to let you know Luis, that your post has been helping our community of practices to hold important discussions about this crucial matter, so thank for that.
I do not have words to tell you how much I was happy when I read this… Thank you so so much for your kind words… They made my day :)
Cool Luis !!!!
Luis,
The retrospective is nothing but a mini Kaizen event. During the retrospective the team should improve the process. PDCA or DMAIC are the right approach, and it should be the standard approach for every retrospective.
A process improvement should have a clear and measurable goal, so you know whether the change is good or bad. The success criteria should simple whether you achieved the measurable goal or not, or to what extent.
I agree with you Jerry. I do not say that we need to have a process or a formal way to measure it :) We just need to force ourselves to know if what we did gave results :) Only that. I am not fan of process :) :)
In projects where they claim to do retrospectives I usually ask: “Do you also do retrospectives on the retrospectives?” As you said: mostly they don’t.
In the projects I coach, we retrospect every week, immediately followed by a prespect. This is a part of the planning process. We learn from what we thought we should do and what we actually did, and use the learning as immediate input of what we think we should do, what we actually should do, and what we should not do: as half of what people do, later turns out to be unnecessary, prespecting this saves a lot of time. It’s strange that the word ‘retrospective’ exists in English, but the more important word ‘prespective’ not (yet). By not setting the retro- and pre- spection apart, but doing it as part of the planning process, we automatically plan any appropriate action and automatically check the results of any action.
PDCA is the powerful mechanism. We start using it every week, but soon it becomes a way of everyday (work)life. Because in the Act phase of PDCA we introduce a ‘mutation’ in what we do or how we do it or how we organize things (product-project-process), we call this the evolutionary approach. Every cycle we should change something, because as Einstein (and Benjamin Franklin earlier) said: “Insanity is doing the same thing over and over again and expecting a different outcome” (let alone a better outcome). If we change a lot at once, if the sum seems positive, we wouldn’t know what contributed positively and what negatively. If we do PDCA ‘continuously’ we can still learn very quickly.
Because evolutionary is such a long word we call it Evo. Evo is the oldest and most agile (pre-)Agile approach. Why is Evo less known than e.g. Scrum? Only if an approach doesn’t work well, people have to tell others to find out why it doesn’t work. Because Evo is based on continuous PDCA, based on RoI and producing the highest value first, we see not much reason to spend time telling others. We just use it. Why is it the best approach there is (as far as we know)? Because, as soon as we see a better promising approach, we plan it, then do it, the check it, and if it works better than what we did before, we keep it, shelving what we did before, as that may be better at some other time. I think that’s what you can call agile. We don’t call it Agile, because that would limit our agility.