“If it ain’t broke, don’t fix it”; It’s a phrase that I’ve heard as long as I can remember. This was always a peculiar saying to me, because every time I heard it, I couldn’t help but ask myself the question, “but how can we make it better?”
Yes, it’s true that sometimes as long as something is working moderately well, we should just let it do its thing. However, when it comes to Agile, there’s always room for improvement to work towards becoming a well-formed team (WFT). Sometimes you may find yourself comfortable with saying that you’re working on a WFT, but should that mean that team processes stay constant if they “ain’t broke”? I propose that teams should always be looking to shake things up a bit, and continuously experiment with tools and processes, even if existing tools and processes appear to be working well for the team. This experimentation is important because changing context and environment can help expose things that may have ended up in the collective team’s blindspot. There’s a lot of different areas that a team can experiment with, but for the scope of this blog post, I’m going to focus on one key aspect of Agile - the retrospective.
A Moving Target
To provide some context, I recently have started working on a new project in which I stepped into the role of Scrum Master for the first time in my career. With everything about this project being new, from project domain to team members, figuring out how we operate as a team was like an artist staring at a blank canvas alongside paint in every color imaginable. We found ourselves frequently asking the question, “how do we decide what’s best for our team?”
Eventually, we learned that what’s best for our team will always be a moving target, as time passes and tools, processes, and even ourselves evolve. So in order to keep us on our toes, in a truly Agile manner, we decided to embrace continuous experimentation. The forum for brain-storming and reviewing this experimentation would be our retrospectives, naturally. And since this is such an important ceremony for inspecting, adapting, and improving, the retrospective activities needed to be carefully thought out.
In my experience, the kind of retrospectives that always made for the best team discussions included a fresh, new retrospective activity that framed how we thought about things to discuss; the more creative the activity was, the better. The most common of all retrospective activities that I’ve participated in was the good ol’ fashioned “Start, Stop, Continue”.
I’m sure everyone who’s reading this that works on an Agile team knows this activity. It’s mostly self-explanatory; think of things that occurred this past sprint that the team should stop doing, things the team should start doing, and things the team should continue doing. It’s a great activity, mainly because it cuts straight to the chase. However, I found myself tending to go into autopilot if we continued to do it sprint after sprint. I reflected on what I thought were my favorite retrospective activities, and those that came to mind were activities that introduced a new concept for discussion. They really helped our team have a bit of a reset in terms of how we approach team discussions.
The Retrospective Rolodex
One principle I have kept dearly during my time as a Scrum Master was to try and have a different retrospective activity than the activity we had the last sprint. I would do research into finding all the different kinds of retrospective activities and started keeping them in a rolodex to use with my own team.
What we quickly found was that when we framed the discussion differently via the retrospective activity, we started discussing aspects of the team and the project in a different light. Some retrospective activities, like the sailboat activity, framed the discussion around the scope of the entire project rather than what should we change from a team perspective. There were also activities that aimed at gauging the emotional wellness of the team that helped expose how we can improve our team relations.
One important takeaway about switching up retrospective activities is to take note of what kind of discussions develop from that activity. For example, if the general theme of a sprint was that our processes hindered some of our progress, maybe a process-centric retro would be best. Or, if there seems to be team members who aren’t working too well together, an emotional-wellness activity might be able to help get to the root of what the issue may be. Keeping all these activities in your team’s toolbox and knowing when to use which kind of activity to help frame team discussion is the next step in working towards becoming a better well-formed team.
The main take-away of this post is this; constant context of discussion may lead to blindspots for areas in which the team can improve, and one way to avoid that is to try and keep that context fresh, but also pragmatic. There’s a ton of retrospective activities out there, and knowing which one will be a good fit for a certain retrospective will take time, as well as trial and error. Even if a certain retrospective activity may not be the best match for that sprint, at least the team is venturing out into new discussion territory and avoiding those “autopilot” forums. Repeating activities can lead to “cruise-control” discussions, but venturing out of the team’s comfortable domain and tapping into a more creative framework of discussion can help the team approach more nuanced problems in efforts of working towards reaching its full potential.
Are you on a Scrum team that is in a retrospective rut? How do you generate fresh ideas from your team? Join in the conversation below or contact us to learn how we can help improve the efficiency of your team.