Agile Software Development Retrospectives: Why the Invitee List Matters
Originally published on www.RetroRabbit.io
In the past, I’ve written about how retrospectives are like vegetables for your agile software development team. Oftentimes they are not peoples favorite food, but you need to do them so that your team continues to learn, grow, and get better.
Having the same format, with the same group of people can get repetitive. Discussion points can get stale, like that pain in the butt ongoing dependency that just keeps coming up. Or maybe everything is working smoothly (so it seems) and there just aren’t many real points of discussion (never a good sign by the way).
In reality, there is always something to improve on. Improvement within an agile team is just like a complex problem; sometimes you need to look at it from a different perspective to determine how to keep moving or overcome the problem.
Getting a fresh perspective for your retrospectives can be game changing, and this can come in many forms.
One of the most effective ways I’ve seen at changing things up for a retrospective is the invite list.
But Ben, what do you mean? The only people that are allowed to go to retrospectives are members of the squad!
Nope, not true!
Bringing esteemed guests in from outside of your retrospective core team can make an astounding difference to the quality of your retros. The possibilities are endless. Here are a few potential guests you could bring in and how they might be able to help:
An Experienced Facilitator
Most self directed engineering squads will facilitate their own retrospectives. For self organizing development teams well versed in agile methodology, this is the best possible consistent way to host retrospectives.
However a lot can go wrong in retros if you are not careful. Arguments can happen. The group can get easily derailed on unimportant discussion points that become too detailed. Action items get lost.
All of this can be solved with an experienced non biased third party, regardless of whether your team is brand new to retrospectives, or experienced agile practitioners. This person can bring an outsiders perspective and be the one to ask the “stupid questions” in order to understand why things are being done the way they are. This facilitator may also see examples of what has worked for other technology teams like new retro formats that could be beneficial for your group.
Members from another tech squad your team has been working closely with
Engineering teams interact with many other groups, depending on their scope or level of service. No matter what your team works on, unless you are working at a tiny startup, your team is going to have to work pretty closely with other tech teams. Using retrospectives as a forcing mechanism to share feedback is a no brainer.
At many larger companies for example, squads may work together on a project by project basis. Meeting after a project is done and capturing what worked well and what could be improved will pay dividends for the next time your teams need to work together.
Schedules and willingness to participate can be varied here, so a good point to keep in mind is that this doesn’t have to be an entire squad, it could be the lead on a project, or a key player in decision making. Regardless, sharing feedback across groups both on what went well and what could be improved for next time will be incredibly beneficial.
A Key Stakeholder
Engineering teams often work closely with other teams, but they also frequently have key stakeholders that are in a great position to provide some incredibly valuable feedback. Ideally, the stakeholders you’d be inviting to your teams retrospectives are one with whom you were recently supporting via feature delivery.
Most projects or functional areas have some sort of executive sponsor. While it is in the Product Manager’s job description to ensure the product that the engineering team develops is delivering value, value delivery is also intrinsically the responsibility of every member of the engineering team. Having that external perspective can really provide insight to the engineers in terms of what is top of mind for key stakeholders in the organization, and how they are perceived.
And don’t forget, guests can be silent participants too. Not only can guests provide great context to stakeholders, but the retro team can provide the same level of context to that guest. Who else, besides the retro team can better speak to hurdles of implementation, or speak to what didn’t go as planned as the team worked to build a feature?
All in all, retrospectives can for sure get stale over time. Guest participants are one of the most effective ways to spruce things up and provide a new prospective. Be sure to ask yourself and your team the following questions in order to continue improving on your retrospectives:
Can you think of someone who might add value to your next team retrospective?
When is the last time your team has included someone from outside of the immediate team in your meetings?
About the author:
Ben Staples has over 7 years of Product Management and product marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com I do Product Management consulting!
Interested in finding out more? Want to get notified when my next Product article comes out? Interested in getting into Product Management but don't know how? Want book recommendations?! Contact me!