If you’ve followed me at all, you know that I worked at a company called iContact from 2009 – 2012. It was one of the best agile experiences of my life, both professionally and personally.
You see we tried to influence the entire organization at iContact to leverage agile principles and practices as we grew, evolved, and delivered value to our customers. It was an exciting time, as the agile energy creeped out of the technical and product teams and started to influence the behavior of everyone in the company. It was quite a unique experience.
As I reflect back on the successes we had at iContact, I also think about the central practices that influenced the broader agile transformation. If there was one practice that stands out, it was our use of retrospectives beyond the team level. Let me share what we did.
First the Release Train
We followed a 4+1, 2-week release train tempo at the time. We then reserved a 2-week sprint between trains for next train planning, taking a bit of a break, allowing time for a hackathon, and conducting our release retrospective.
Our company-wide release retrospectives became a cornerstone not only for improving our releases and teams, but they also changed the company culture. Let me share some of the things we discovered for creating truly transformative retrospectives at-scale.
Here are some of the crucial lessons we learned about preparing for and conducting our retrospectives:
- Include everyone! The scope of our release retrospective timeline was from the first day to the 5 days post the release. We emphasized that we were looking for feedback from the entire period and not simply the last few weeks. And we wanted to hear from all roles within the company, so we invited everyone to the retrospective. Did everyone show up? No. But out of a company size of ~450, we would have ~100+ folks in the room. So, the engagement level was very high, as everyone wanted to have their say.
- Find a really good facilitator. I can’t begin to explain the value and impact of a good facilitator if you do choose to have larger-scale retrospectives. I found a great one to run ours. And he did it for a long time, so not only did he facilitate well, but he was continuously refining our approaches and experimenting to get better and better results. Another key from my perspective, was the ability to M/C the event. You see the facilitator needs to be personable, a great communicator, well-liked and respected, thick-skinned and not easily flustered.
- Don’t forget about the last one. One of the things we took particular pride in was taking action on our retrospective results. Or, if we failed to correct something, acknowledging that as well. The first 10-15 minutes of our retrospective was always focused on “setting the stage” from our last one. What had we done better? What had we fixed? And a special focus on progress-made, as there was a bit of celebration of everyone’s hard work. The other important point is that over the course of many retrospectives, everyone got a sense for our company improvement trending. Which to be honest, generated some pride for everybody.
- Is it better to collect feedback in advance? One of the challenges we had, as the release retrospectives became more popular, was collecting feedback. Early on, we did it via Post-It Notes in the room. And yes, there were a lot of notes. But later, this became more challenging, so we put up a wiki-page (survey) about a week before the retrospective, to collect feedback before the meeting. Then we used this AND cards collected during, to populate our feedback board. The key point is we supplemented our feedback, which also increased the contributors. But we never wanted to totally remove the dynamics that real-time feedback had on the retrospective.
- Every voice counts! Even though our releases were technology focused, we wanted to hear from every corporate function. For example, DevOps always had interesting feedback, as did the Customer Support team. We wanted to hear from Sales, as to whether they could “sell it” and also what was their level of excitement? Or lack thereof? It was the cross-organizational feedback that fostered a broader agile transformation. No voice was left out nor marginalized in our listening or in our actions.
- Dot-Voting or Collaborative Decision-making. We made great use of collaborative, dot-voting on the items we collected. I know, at-scale it’s a big challenge. And you’re right. But we felt that the value of getting the entire room to interact “at the wall” was worth the logistical challenges. Again, it goes back to the effectiveness of your pre-prep and your facilitator as to how this can work. One of the things we truly believed in was the wisdom of the crowd when it came to identifying improvement opportunities. So, there was always healthy debate around the voting as well.
- Be totally transparent. The more “reality” you can put on the walls as information radiators, the better off you are. As you’ll see in the story I’ll share later, one of the hallmarks of our retrospectives was the amount of transparency we showed. We hid nothing and shied away from no conversations. We accepted all feedback, digested and considered it, and took appropriate action based on impact and priority. I have a funny story to share:
Our facilitator was named Mark and he did a great job. But apparently, he had aggravated someone in our company. Because every release retrospective a card would show up on the wall that read – “Fire Mark, he’s doing a poor job”. And we wouldn’t hide or remove it. It was feedback that was handled with all the rest. Even though it was rude and inappropriate. To Mark’s credit, he handled it each and every release retrospective, with grace and transparency.
- Receive the feedback well. We found out early-on that we (the technology team) were a relatively defensive group. That we didn’t take constructive feedback that well. And we also learned that getting defensive in front of 100+ of your colleagues really wasn’t a good strategy. Therefore, we quickly learned to how take the feedback (embrace it) as the gift it really is. And this ability served as a role model to everyone in the company. Point being, we all got better at accepting hard feedback and acting appropriately to it.
- End with a BANG! Don’t just end your retrospective, end it with a bang. Make the meeting a big deal, because it is. Celebrate the feedback you received. Celebrate the cross-organizational interaction. Heck, celebrate your release! You also want to be appreciative of all of the attendees and their engagement. I often like to inject an “appreciations point” to most retrospectives. It’s hard to do in this large of a meeting/forum, but I would encourage you to try to do something. Point being, we always took some time to appreciate each other.
- Share your go-forward plans. Everything leading up to this point is for naught if you don’t do something with the feedback. About a week or two after the retrospective, we would share with everyone the change plans from everyone who took something away from the retrospective. This was the commitment from individuals, teams, or groups to effect specific changes to improve or resolve a challenge. Or things (experiments) they would be trying for ongoing improvement. This became our commitments and we took them very seriously because we knew our progress (or lack thereof) would be exposed in the next retrospective.
Of course, there’s more to our story then the above. But I thought long and hard, and I believe these were the primary keys to our success.
The best way I can describe the transformational aspects of our retrospectives is by sharing this story.
After one of our early release retrospectives, Kevin Fitzgerald, our VP of Sales, pulled me aside to give me some private feedback. He said:
Bob, I’ve never seen anything like it. You guys (our technical and product organizations) are totally open to our feedback. You take it like grown-ups and you do something even more important. You take action on it. You do something with it and then are transparent with the results.
You are accountable, transparent, and driven as a team. And the results it’s creating within our products is palpable. I want my Sales Team to exhibit the same behaviors I see in your teams. Can we “do Scrum” in Sales? Can we achieve the same level of transparency? Can we focus in on continuous improvement and not worry about our egos or perceptions?
I said, of course you can. I’d be happy to help you in these efforts. And perhaps we can do Sales team-wide retrospectives as you start down your own journey?
He said – I’d love that. Let’s get going…
This was an incredibly welcome, but unexpected, outcome from our retrospectives. We found that the principles exhibited in the retrospectives, seeped out into the landscape of our company as an example. It helped us transform our culture towards agile values and principles more than any other thing we did.
@ Velocity – Remote Team Engagement
One of the areas that challenge this approach is if you have remote or distributed teams. Or, as in the case of Velocity Partners, you are partnered with any nearshore or offshore firms. Clearly, depending on the time zones, getting these folks involved in a release retrospective can be a challenge.
But at the same time, you want to be as inclusive as possible. Both before, during, and after the retrospective.
This is one of the areas where tools can really help you. For a release retrospective, allow the remote individuals to enter their feedback before the larger event. And then allow them to vote on things remotely during the retrospectives.
Towards the end of our experience with these retrospectives, we had some nearshore teams in Argentina. We leveraged Trello for them as a means of sharing feedback and gaining their engagement during the process. Even though it was a challenge, we felt it important to get EVERYONE’s feedback independent of whether they worked for the company or where they physically worked.
What I’ve observed as a coach, is that many folks marginalize their nearshore partners because the feedback can be logistically hard.
We found that it was worth the effort to figure out ways to integrate those teams. Not only from a feedback perspective, but to improve their morale and feelings of inclusivity. After all, if they contribute to a release, then they should be a part of the retrospective.
The article was inspired by a Spotify article that shared their own experiences with larger-scale retrospectives. In fact, the photo associated with this article is from Spotify as well. Thank you, Spotify!
I hope this article encouraged you to think about and try more broad retrospectives. Many of the scaling frameworks have a larger-scale retrospective aspect to their recommendations. Therefore, you can look at LeSS, SAFe, and Nexus as additional places for advice.
Stay agile my friends,