In the last 2 years, I have been diving deep into the practice of agile methodologies, their frameworks and processes. Hindsight being what it is, I often find myself looking back and thinking, “Man, if only I knew then what I know today!” And not only for software delivery, but for my time working as a WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. organizer as well.

There is a lot that event organizers can learn from lean and agile beyond the now ubiquitous kanban board, and today I want to share some thoughts and techniques for my favorite of all the agile practices: the sprint retrospective.

At the end of each of the three WCEU organizing years that I participated in (2016-2018), the team, or teams, would hold a “post-mortem” to reflect on all of our successes, learnings and fumbles. Those learnings didn’t often translate into anything actionable, because:

1. We didn’t have a clear and consistent process
2. The team had a high turnover rate
3. Folks switched roles from year to year
4. At the end of the year we were all exhausted and just ready to move on

Why run a sprint retrospective?

Retros are most effective when they are done at regular intervals while the work is ongoing. They serve as checkpoints to create space for teams to stop, inspect, learn, and adapt. In scrum jargon we call this a sprint retrospective, where a sprint is a predefined and regular interval of time into which project delivery is broken down and delivered. The sprint retro then serves to only look back on that period of time. Typically this is 2 weeks, but 3 and 4-week intervals are also common. (Yes, I do realize that I’m writing this largely to a group of software developers, but I won’t assume everyone reading is familiar with these concepts 🙂)

Am I saying that because we didn’t run regular retros that we never learned on the job and course-corrected when needed? No, of course not! On the contrary, for a huge team of volunteers self-organizing across a dozen countries, we were constantly learning and adapting our work accordingly. We just didn’t have a clear process to do so, which meant that a lot did slip through the cracks, knowledge did get lost, and a lot of things went unsaid. And worst of all, not everyone felt comfortable or safe raising difficult topics and in a timely manner.

Retrospectives serve to:

• Create a safe, dedicated space to have open, candid conversations
• Build trust
• Hold ourselves and one another accountable
• Celebrate everything we’re doing right
• Share our learnings
• Identify things that don’t make sense to us
• Take an honest look at what’s not going well
• Come up with creative, tangible solutions toward improvement
• Define controlled experiments
• Follow up on action items, experiments and their outcomes in the next iteration

How to run a remote retro

These types of conversations are best had in person, with a big bare wall, a punch of Post-it notes and some Sharpies. But there are lots of great tools and tips for running remote retrospectives as well. Let’s dive in.

Participants

The participants should only include the immediate delivery team. That is, the individuals who are directly collaborating on a daily (or regular) basis. No stakeholders or outside team members should be present, without the express permission of every coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team member. Why? Again, this needs to be a safe place to talk about potentially difficult topics. Folks need to be able to express themselves without fear of judgement or repercussions.

However, sometimes it does make sense to bring in someone to facilitate the meeting, that way all team members can participate. This person should of course be someone that all team members are comfortable with, and someone capable of remaining neutral (more on facilitating below).

Duration

A retro shouldn’t last longer than an hour, although for larger teams, and for end-of-project retros it might make sense to extend this an extra 30m to ensure enough time for discussion.

The acknowledgment

Before kicking off I always mention the following (and include it in written form on the tool being used):

We are having this discussion with the goal in mind of continuous improvement. Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what was known at the time, their skills and abilities, the resources available, and the situation at-hand.

Hat tip to my colleague Jen Laker for that one. She says that she will refer back to this if the conversation ever starts turning into a blame game – retros aren’t about blaming people or passing the buck. They are about being accountable and learning from our inevitable errors.

I’ve also come to add the following:

If you find yourself struggling to find the right words to say something, that probably means that it’s really important. I encourage you to not worry about getting the phrasing just right. Get it out there first, then we will work through it together as a team.

This came after repeatedly watching people start to type and then erase their words…finding just the right words is not always possible, and not wanting to offend anyone is a real fear. Make it easy for people to voice the hard stuff.

The brainstorm

Now it’s time to get all the ideas out. There are different tools that you can use for this:

• Google docs (my preferred method)
• TrelloTrello Project management system using the concepts of boards and cards to organize tasks in a sane way. This is what the make.wordpress.com/marketing team uses for example: https://trello.com/b/8UGHVBu8/wp-marketing.
• Confluence (has a built-in template)
• Miro

Really, any online tool that lets multiple people collaborate simultaneously can serve this purpose. With Trello and Confluence, the prompts are divided into columns. On a Google doc you can create sections with bullet lists.

I find that 7-8 minutes is the right amount of time for this phase.

• Encourage everyone to contribute at least one item to each column
• Invite them to mute themselves and to work in silence
• If you see the activity waning early, you of course don’t need to use the whole allotted time, stop early
• Give folks a 1 minute warning before the time is up, asking them to wrap it up
• At the end, ask if anyone needs more time – it should absolutely be ok to spend another minute or two to make sure all of the important stuff gets out there

The formula

There are lots of different ways to frame a retro, the most common, and the one I use most frequently with teams is:

1. What went well?
2. What went less well?
3. What still puzzles me?

And sometimes I add a fourth:

4. What did I learn?

An alternative to this is:

1. Start doing
2. Stop doing
3. Keep doing

Though I find this lacks the emotional connection that helps foster team building.

For long term projects I like to shake it up from time to time. Two I’ve experimented with, with great results, are The Wish, and The Sailboat.

The vote

This is an optional step. Ideally, when the time intervals aren’t too lengthy or the team too big, the group can get through all of the items in the allotted time. However, if it’s clear that there are too many to get through, then you can take 4-5 minutes and have members upvote the topics that they feel would be the most valuable use of time to discuss.

Grant each person 3-4 votes. They can be added as emojis, and tools like Trello have “like” features that can serve this purpose well. People can place one or more of their votes on individual items, as long as they don’t use more than the defined quantity each. Count the votes and sort topics in each question/column by those with the most votes.

The discussion

I often like to start with what went well as a bit of an ice-breaker. It’s great to look at everything the team is doing well, and this column/section often has the largest quantity of items.

That said, when there are a lot of items in the “went less well” and “puzzles me” columns, then I’ll save the “went wells” until the end. The facilitator should read the room and decide what the best approach is on that particular day.

The facilitator

Right, so yes, someone should facilitate this meeting, and ideally that should be someone who is not also participating. This may not always be possible. The important things for effective facilitation of this meeting:

• The facilitator is neutral, they are not there to push an agenda
• They actively create a safe space and ensure that everyone has a voice
• Respect the timeboxes, and move the conversation along if the group gets stuck on a topic (see below)

Notes, decisions & action items

The facilitator should also capture the output of the discussion. This generally falls into 3 categories:

1. Notes: general impressions that add value beyond what was captured in the brainstorm items. The development of those topics that add clarity, meaning and different perspectives.
2. Decisions: has the group agreed to make any process changes? Document these under Decisions, and keep a log to refer back to. Process is specific to each group and it is natural for it to evolve.
3. Action items: these are clear tasks to be completed and should be immediately assigned to one or more individuals. p2’s have built in checklists that can be used to track the completion of actionables, or trello could be a good place to track them as well. Make sure and check off items as they’re completed, and review previous Decisions and Action items in the next meeting.

Decisions and action items don’t often manifest on their own. It is also the role of the facilitator to move the discussion toward the learning, change, action or experiment. Give the discussion ample space to breathe, then move toward the idea of improvement.

Some closing thoughts

I had the honor and privilege of accompanying the WordCamp Asia organizing team over the last 10 months as one of their mentors. I brought up this idea of running retros, and eventually facilitated one for one of the teams. A big thanks to @hlashbrooke for prompting me to share these thoughts and techniques with you all, following that experience 😄

Some final thoughts in no particular order:

• You might try leaving the sprint retro doc open for folks to add to it as they go, rather than wait until the meeting itself. This can be particularly useful if the sprint is longer than 2 weeks, but also helps for teams that are multitasking a lot (as WordCamp organizers do!).
• I recommend making it clear that people don’t need to wait for a retro to raise a topic. Some topics are timely and should be addressed accordingly.
• On the flip side, not all topics need to be addressed right away. The sprint also serves to let the team focus. I often suggest, “hey, that’s a great topic, how about we address it in the next retro?” That way folks don’t get unnecessarily distracted by things that aren’t urgent. Also, you don’t want to introduce change or an experiment mid-sprint (unless something is really broken and it’s absolutely vital). Most things can wait, ride it out then introduce change in the next iteration.
• While conflicts and misunderstandings absolutely can get resolved through this process, a retro is not a replacement for conflict resolution, or to be used punctually as such. This is essentially what ended up happening for WordCamp Asia. It’s not a bad thing, but again, retros are most effective when done regularly.
• Along those same lines, everyone on a delivery team should participate. For flagship events, this would mean that if one team is running retros, all teams should be running retros. They can each add their own nuance to the way they’re run, but ideally all teams have the same framework to operate in.
• Community Mentors could potentially be well placed to serve as facilitators, especially for local WordCamps.
• For flagship events, I’ve always thought of the global lead role as being that of a scrum master, more so than that of a product owner. That is, a servant leader, someone who is their to educate, mentor and coach the team. I see the individual team leads as the product owners, each with the vision and autonomy to set objectives for their teams.
• A flagship event might then run a scrum of scrums, where individual teams run team retros, then team leads also gather to run them at a global level.
• It would be interesting to explore how other scrum practices could benefit event organizing teams, but that will have to be another post for another time 😍

Thank you for reading to the end! I hope you have found this interesting and valuable. If there is any area that I may have missed or that you’d like me to develop on further, please let me know. 🙂