I wouldn't be lying.
And the reason for that is because... damn... just thinking back on all those retros I've been sitting though during the last 10-15 years. Lol!
So yeah. Well, let's just say that some retros are worse than others, right 🙂
This is part one of a mini course about agile scrum retrospective meetings (and agile meetings in general). So if you're into this stuff, please hang around so you don't miss the next parts. Coming up real soon!
Anyway, let's kick off this thing and talk about retrospectives and what they're good for.
Now that is a great goal... only there is a teeny-tiny problem...
Perfection can't be achieved. Big surprise there, right? But if you think about it, perfection is like trying to reach the speed of light. No matter how hard you try, you can't really get there. That's the bad news.....
The good news is that perfection is more like an ongoing process. It's the journey that counts, not the destination. A bit on the cheesy side, but still... true enough.
The same goes for improving stuff: you can’t just improve, and then be done with it. You gotta keep doing it, and never stop. That’s the path to perfection.
Hey dad, I just learned something! I think I'll stop now.
Nope, that's not how we do things.
The way to improve is getting feedback. Without feedback, you’re blind. Each time you get some feedback is also a chance to improve how you work. So you want to get feedback as early as possible, as often as possible.
The idea is to get some feedback and then using that feedback to improve how you work. Or, in this case, how your team works.
In other words: you look back at what happened and decide how to change (improve) based on that.
Alriiiiight... That's not actually the point of retros.
The scrum retrospective meeting is probably the most important part of any improvement process. In fact, if you're bold enough, you can even begin your process without any rules whatsoever... except one: run a retro each week.
The retrospective meeting is the most important part of any improvement process.
The retro meeting is also an opportunity for the team to set aside some time to reflect on their work.
So... you’re looking for things to improve. And what you end up with at the end of the meeting is, well, a list of improvements! (I'll call them actions from now on). Simple enough.
One important thing to keep in mind, is that all actions are owned by the team members. The team looks at what happened, finds the actions, and then the TEAM implement them. This is much more effective than forcing change down from above.
The idea with retros is to find problems and then turning them into valuable improvements. This essentially means that the team adapts how they work.
Now, it’s crucial that your team are allowed to do that (change how they work). I can’t stress that enough: The team MUST BE ALLOWED TO CHANGE.
I know from experience that many organisations allow its teams to ”play agile” and even encourage them to run retros. But when push comes to shove, teams aren’t really allowed to make any real changes...
It usually goes like this:
There is a certain blessed document (”The Development Process”) detailing how teams should work. Or maybe there is a process police patrolling running around, lecturing teams what’s best for them. (It's no joke! I've seen it!)
What happens next is that the organisation tells the team:
”We want you to be agile…”, while simultaneously holding them back, saying ”… as long as you follow our extremely detailed development process”.
This is a recipe for disaster. At best, it causes confusion and waste. At worst, it brings distrust, conflicts and apathy in the team. Don't go there. Instead, make absolutely sure your team is allowed to organize how they work.
You hold this meeting regularly. Usually at the end of each week, month or sprint. You can also hold it at the end of a project, or when you do a release, or when you need it.
Best is if you run them using fixed intervals. Say, every other Thursday. This creates a natural improvement pace and helps it becoming an integral part of the development cycle.
The Scrum guide (if you’re into that) says you should run retros at the end of each sprint. And I think that’s a great suggestion!
But then, again, remember, retrospectives are not just for Scrum or even for development teams: you can use retros in any organisation or setting.
Well, the entire team of course!
For a developer shop, that means all developers + the product manager and, of course, yourself, the facilitator.
You shouldn’t invite any observers (like your manager). Doing that will make the meeting a bit awkward. Having to think of what you say when your manager is hovering about will certainly hold back discussions…
It really depends on when you last ran it, but
It’s better to hold short meetings more often, rather than long meetings more rarely. The reason for that is -- you guessed it! -- getting feedback quickly! After a month or so, no one will even remember what they did four weeks ago.
RETROSPECTIVE MEETINGS -- TAKEAWAYS FROM PART 1
To get the most out this meeting, you need to know how to keep it on track, how to keep it energised and to make sure the team actually gets something out of it. Not to mention, you need to learn how to manage the group so everyone gets heard and much more.
You’ll get into all those details in the next part (and more!).
In the next part (part two) of this series, you'll learn a super effective retrospective recipe. This framework is a tried and tested method (in five steps) for running these meetings. I'll show you, step by step, all the way from kicking off the meeting and how to wrap it up properly. So don't miss this!
Learn the secrets to Agile Scrum Retrospectives!
I'm a developer, running my consulting business while raising two daughters. The little one is 9 months and the big one four years. Yikes, time flies! Wish I had more time to spend with them.