How to significantly improve your agile retrospectives
When I facilitate a team’s retrospective I tend to use the 5-step approach from the book “Agile Retrospectives” by Esther Derby ad Diana Larsen. That could be a first step for you, if you aren’t using it yet. I like it because it starts with involving everyone who is attending the retrospective event. I also like it because it requires you to gather facts first and thus prevents you from getting lost in a meaningless and energy-draining discussion about assumptions which, in my experience, is still very common.\r\n\r\nBut there’s so much beyond a structured approach for executing a retrospective event. There’s also so much more beyond the many retrospective exercises and games you find in books and everywhere on the internet.\r\n\r\nYou may like to try the following suggestions to significantly improve your agile retrospectives:\r\n\r\n1. Keep track of significant events during an iteration\r\n\r\nMany data-gathering retrospective exercises involve remembering significant events from the past iteration. Wouldn’t it be awesome if you could magically present a stack of neatly described events which qualify for futher inspection?\r\n\r\nThe moment to inspect is the moment when something happens. Postpone it to later and you might find that the important details are blurry or even lost. Always have some paper and a pen handy to write down what seems important. Be prepared to experience important events at any moment in time.\r\n\r\nPersonally I always carry a notebook and a small pen to write down anything important that occurs. I cannot imagine a meaningful professional life without one!\r\n\r\nGreat teams make sure their team members all have notebooks. They also make sure that there is a way to gather and visualize collective learnings at their location. Whitewalls are sooo useful ;-)\r\n\r\n2. Keep track of impediments\r\n\r\nImpediments are my favourite “events” to track during an iteration. Impediments are often keys to organizational change. So inspect them the moment they occur and write down anything you can learn about them. Solving at least some of them might be the difference between doing solid business or experiencing a downward spiral.\r\n\r\nAre you able to solve a particular impediment during the iteration? Then still write down something about it. It’s never a waste of time in my experience. You can look it up later and feel joyful again. Or somebody else might learn something from it. Maybe it’ll help you write a book about success!\r\n\r\n3. Measure what you wish to improve (and only that)\r\n\r\nTaking notes about events is one thing. Measuring is another. Measuring means that you know upfront what you are looking for. You also have an idea what you wish to write down about it. And you want to do both the measuring and the writing part consistently so the gathered data will make sense.\r\n\r\nGood teams measure a lot. Great teams only measure what they wholeheartedly intend to improve. Focus is the keyword here.\r\n\r\nGather your data during the iteration and bring it to the retrospective event for further analysis. Or do the analysis even before that and present your conclusions at the retro. Then discuss how you can (and will) improve.\r\n\r\n4. Bring your notes, visuals and other data to your retrospective event\r\n\r\nSo you want to have a meaningful retrospective? Then make sure you bring your data to the retro!\r\n\r\nI witness many people showing up at a retrospective event at a meeting room far away from their work area…with nothing but their clothes on their bodies. Some don’t even bring blank paper to scratch down ideas, conclusions, decisions, or actions. Say what?\r\n\r\nAlways bring both blank paper and every single data source that seems even remotely significant. Or better: have the retrospective event close to your data sources which are often to be found at your work location.\r\n\r\nIf you still use the excuse that you cannot do a retro event at your work location because “it is not suitable” or “you will disturbe other people”, then perhaps you are not looking for impediments all too well. FIX IT creatively and make sure the data is at hand!\r\n\r\n5. Choose a single thing to improve and deep-dive into it\r\n\r\nEspecially when your retrospective approach is still a bit sloppy or you are not yet that good at problem solving, FOCUS will be your friend.\r\n\r\nRestrict your research to identifying one single impediment that is both important and difficult. Don’t go for the lame and easy stuff. Give yourself a challenge. It’s only one impediment for Amy’s sake!\r\n\r\nGo deep in analyzing, accepting, and solving it. Move to a next impediment if and only if you really have time and energy left after your team’s first pick.\r\n\r\n6. Improve during your retrospective event\r\n\r\nWhy postpone execution to after the retrospective event? Why leave the event with just a list of intentions without having them addressed properly?\r\n\r\nNo time? Really? Usually that means “no commitment” and more hidden impediments. Great teams don’t display excuses for improving. Ever!\r\n\r\nIt’s okay to leave your retrospective event with some intentions. As long as they are made actionable. You will use them in your next iteration planning, isn’t it? Just make sure your team at least tries to also solve stuff during the retrospective event. It will give the team an awesome feeling of progress and significance. Don’t settle for less too quickly.\r\n\r\n7. Don’t wait for the retrospective event to start improving\r\n\r\nHaving a retrospective event is an (often unconscious) excuse for teams to postpone inspect & adapt. Don’t fall into the trap there. The best thing you could say at the beginning of your formal retrospective event would be “hey, just look at all those improvements we made during the last iteration” while pointing at the evidence.\r\n\r\nNow seriously: how awesome would that be?\r\n\r\nThere’s nothing wrong with having a retrospective event, because it gives you a great opportunity to look back every once in a while and NOT also having to feel stressed out about your team’s productivity. Just don’t use the retro event as an excuse for delaying what’s important. Whenever you find something that looks like it needs some inspection, at least decide if you are going to dig into it right away or put it on the shelf until the end of the sprint.\r\n\r\n8. Ask for help\r\n\r\nFinally…maybe the most important one: asking for help. Not just asking your team mates, but asking anyone.\r\n\r\nSome teams are just unable to fix every problem they encounter. Then scrap “some” in that sentence and replace it with “all” for reality’s sake.\r\n\r\nDon’t waste too much time on chewing rocks. Involve other people. Most people are willing to help. Just make sure you quickly find some people that can really help you instead of creating a committee.\r\n\r\nThe ability to ask for help is one of the most powerful skills any team should be craving to master. Any team and any type of team. Yours included.\r\n\r\nParting thoughts\r\n\r\nMany teams I encounter have difficulties executing great retrospectives. Most of their retrospective events range from “good” down to “pretty darn useless and insanely boring”, causing them to shorten it timewise or even ditch it.\r\n\r\nUsually it starts getting better when you introduce a structured approach combined with answering the question “why are we here anyway?”, because a team must be willing to improve of course :-)\r\n\r\nFrom there, a team should learn to become more thoughtful about the science of inspection and adaptation. When that happens, the 8 suggestions above cease to be open doors and become life savers instead.