(Photo by Andre Mouton)

are meetings found in — but not limited to — the Scrum development framework where members of a product team reflect on past work and discuss ways to improve in the future. I’ve seen occasionally write retrospectives off as not being particularly relevant or interesting to them — sometimes to the point where they don’t even attend, but I’d argue that if you’re not very engaged (or not having them at all) you’re probably making a mistake.

A good retrospective allows a team to:

  • Discuss and address things that aren’t working as well as they could be
  • Discuss and improve things that are working well to see how they can be better
  • See the broader picture instead of getting stuck in an overly reactive or narrow mindset
  • Have happier, more empowered team members with a greater sense of control over their work and process

Getting all these things to actually happen isn’t always straightforward though. Retrospectives are cut or consolidated surprisingly often when the value doesn’t quite manifest. In fact, if you close your eyes you can probably imagine that one engineer complaining about yet another meeting interrupting precious working time. The way to overcome this resistance is to show the value of retrospectives by running them effectively. A retrospective done well can be transformative, and designers are uniquely positioned to contribute. All it takes is understanding what’s needed to make a retrospective great:

A retrospective is not a postmortem!

If you only schedule retrospectives after a project ends or when something goes terribly wrong you’re sort of missing the point. Agile is about continuous improvement along the way. Put another way, there’s a reason we get annual physicals instead of only waiting for our own autopsies.

Make sure people actually feel comfortable contributing.

This is where experience with design thinking practices can really make a difference. You want to create an atmosphere where it is OK to share ideas and where all team members feel like their input is heard. Sound familiar? It should. A retrospective is just another collaborative design session, only this time the thing you’re designing is the way your team works. Typical strategies for ideation or critique sessions can be applied. For example, common mantras from design thinking are that all that all participants should be encouraged to contribute, and judgement about those contributions should be deferred. Even wild ideas or potentially “bad” ideas are accepted as a way to get conversation going. Engaging and building on the contributions of others should be encouraged as well and you’ll especially want to be conscious of cultural or personality differences that may make some people less comfortable speaking up.

You can also create better energy the same way you would for a design session by getting people to stand up and move around or by using sticky notes or a whiteboard (or a technology equivalent) as an anchor for the conversation. Being visual helps and you want to have everyone in-person as much as possible. Also, it never hurts to bring some kind of snacks!

Pictured: snacks. (Photo by Anna Sullivan )

Discuss a variety of subjects.

A retrospective should have a good balance between discussions centered around people, process, and product.

People: Do you have the right skill-sets embedded within the team? Is everyone working well together? Is anyone struggling? Is everyone learning and having fun?

Process: Is releasing code easy and painless or difficult and slow? Are stakeholders and managers helping or impeding the team’s autonomy? Are there any bottlenecks that can be addressed? Should developers be more involved in discovery work? How can retrospectives or other ceremonies be more ?

Product: Did the last shipped feature actually create value for users? Where is your product a shining example of good practices and where does it need work?

You should also balance the conversation in other ways as well. Balance the negative with the positive (calling out kudos is vital), the tactical with the big picture, and divergent thought (coming up with lots of suggestions) with convergent though (being critical of those suggestions).

Retrospectives are for you, too.

A retrospective needs to include participation from all members of a product team, from product owners to developers to scrum masters/agile coaches, and yes, designers and researchers too. Typically designers embedded into product teams are going to be outnumbered by developers. Developers are going to want to talk a lot about things that aren’t your domain, like technology choices, technical debt, and how to make improvements to their pipeline. In my experience developers really like talking about their pipelines. You can and should learn a lot from these types of discussions, but don’t let your priorities be pushed out of the conversation. A good retrospective should also include discussion about people, processes, and product as applicable to the domain of design.

Consider using a structured format, and mix it up if things start to feel stale.

If you find you get a lot of blank stares you might need some additional structure. The good news is there are plenty of retrospective formats and games to fall back on. You can find tons of examples of those through a quick google search so I won’t go too deep into them here. Just keep in mind that a good format should encourage conversation and prompt discussion on a variety of topics. You want to avoid anything that is too limiting. A good retrospective feels like a conversation, not a court proceeding or party game. One of the simplest formats to start with is to go around the room and ask everyone to make a suggestion for something the team should continue doing, try doing, and stop doing while pausing to discuss as needed. As time goes on you may discover different formats work better or worse for your team, but you’ll never know if you do the exact same thing every time!

Prepare before, and follow through after.

Generally a specific person should be on point for facilitating each retrospective. If that’s you (and if you can’t tell yet — I’m suggesting it can be!) then consider collecting your thoughts before the retrospective begins and encouraging others to do the same. A small amount of prep and planning can go a long way. In true UX fashion you may even want to do some research as a starting point. How many times has code been pushed to production so far this month? How many times have daily stand-ups run beyond 15 minutes? What issues do team members bring up when you interview them individually? During the session you may want to designate a note-taker so that there’s a record to refer back to or to share with others. It’s especially common to write down tangible items to act on after the session, but “next steps” aren’t necessarily the outcome you need. Just having a conversation that helps team members learn and align perspectives is valuable in itself.

Be flexible about what a “retrospective” even is.

You might find that you sometimes need to coordinate retrospectives across multiple teams (check out the Spotify health check), meet with a subset of the full group, or even have one for a group unrelated to an actual product team. You might set up additional time for discussion that isn’t explicitly called a “retrospective” and it’s even OK to continue to discuss without any formal meeting at all! A retrospective isn’t a confining container for all reflection; It’s a stepping stone towards a culture where continuous learning and improvement happen all the time. By applying a design mindset to your reflection, you can make sure you’re making progress down that path.



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here