Owen Gotimer
Hello everyone. My name is Owen Gotimer. I’m the community manager at TechWell. I’m joined today by Tom Stiehm the CTO at Coveros. Tom, thanks for joining me today.
Tom Stiehm
Thanks for having me.
Owen Gotimer
So the anti-pattern we’re going to talk about is no retros.
Tom Stiehm
So what happens a lot with teams is that they get stuck in this retro pattern where they don’t feel they’re getting anything out of it, so they stop having them. Now with agile processes and with DevOps, really the time for the team to reflect on the work they’ve done and tune their process is the retrospective. So when you stop having retrospectives, you stop evolving your process, you stop making it more fit for purpose, and it kind of gets stuck where it’s at now. And that can last for a little while, but just like anything that human beings do, your projects and your software are constantly evolving, whether you want them to or not. And so by not giving yourself time to reflect and tweak your process, your process isn’t evolving along with the business and the product that you’re building.
So one of the things I like to recommend is that you change your retrospective format. There are literally dozens or hundreds of retrospective formats, and you can change those so that you’re not going through the same motions all the time. One of the other things I like to do is every fourth or fifth retrospective, rather than doing a retrospective, do some kind of team building, whether that’s in your office, going out and doing something with with the team, or some other means, just spend that time getting the team to get to know each other outside of just their work context. That can help people work together more effectively.
One of the other areas that we see people give up on retrospectives is when nothing changes. So one of the things I’ve seen at some of my clients is the teams identify things that are outside of their control, and they escalate those to their management and the people that they feel should be able to do something about it, and then nothing happens. So just like anyone else, if you ask five times to change something, and the answer is always we’ll look at it, but then nothing happens, you become disillusioned with that. So one of the best things that the people supporting teams can do is actually listen to the problems that they’re having and address those problems so that the things that are preventing the team from getting their work done are moved out of the way. The whole goal, whether it’s a Scrum master or an agile coach or a manager, is to enable their teams to work better, and they do that by listening to the team, hearing what impediments they have that’s preventing the team from getting their work done, and remediating those impediments for them.
Owen Gotimer
I love this idea of making sure that that there’s someone that’s responsible for following up on some of these impediments. You talked about having dozens or hundreds of different retro formats, because I know that some things that teams definitely get into this repetitive pattern, and they feel like it’s boring. Do you have a specific retro format that maybe is different than what other people have seen before that you like to use?
Tom Stiehm
Some of the different ones that I’ve seen, there’s one called six hats, where the hats are irrelevant, it’s the idea that each hat represents a focus. So the focus might be what went wrong in the last sprint, and then another focus might be on what did I feel about the sprint result? So you just have different focuses and that gives you time to think about from that perspective. You know what happened? Your traditional Scrum retrospective is “What went right? What didn’t go right? what should we change? What should we stop doing? What should we start doing?” That kind of thing.
Another one that I like a lot is called the sailboat, where literally on a piece of paper you draw a sailboat: you’ve got an anchor that slows down, you’ve got wind that speeds you up, and you’ve got rocks ahead that you need to avoid, and the rocks represent risks. Then people just start writing down the things that they see that relate to what what causes drag, what helps us move forward, and what things are we trying to avoid? So it’s just a different way to capture that same information, but it gives people a different way to think about it and look at it. Then some retrospective formats focus on other things, some focus just on team dynamics, some focus on the technology that we use, some focus on outside of the team, so it’s just an idea of change it up, look for different aspects, do things that give you different perspectives.
