Agile Retrospectives

Retrospectives 101 for Non-Software Developers

Luis Ortiz

— 8 min read

The software development industry has brought much wisdom to other sectors. Many good practices meant to reduce as much waste as possible while amplifying value for the customer and the organization are currently used in marketing, HR, sales, and business intelligence, just to name a few examples.

One concrete example is how the Kanban board has become a critical tool for managing projects. Even though systems such as Jira, monday, or Trello offer more sophisticated versions, the spirit is the same: Visualizing workflows in a simple, engaging, and inclusive way.

Another excellent teaching from the software industry is the habit of running Retrospective sessions. Performed to understand how processes can be improved, these ceremonies are a central component of the Scrum framework and can benefit any kind of team. So get ready to learn the basics and power up your project management skills!

Topics to check

  1. What is an Agile Retrospective?
    a. Sprint Review vs. Retrospective
    b. How to run a Retro session
    c. Retrospectives in Kanban
  2. Analyzing your workflows
    a. Task efficiency score
    b. Task cycle time
    c. Task throughput
  3. Preventing waste
    a. The 7 types of work waste
  4. Visualizing your workflows
    a. Getting started with Trello
    b. Agile Retrospectives Trello Power-up

1. What is an Agile Retrospective?

One of the main ways you can help your team become more Agile is by fostering conversations around their synergies. A Retrospective is an intimate session where the core team gathers to review the past work cycle in terms of:

  • What was okay?
  • What was not great?
  • What could be improved?

Getting everybody's feedback is essential for a transparent and honest perspective that can provide a foundation for concrete improvement. In terms of Scrum.org, "The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint." These are usually called Action Items and are the most convenient way to follow up concretely.

Before setting up your Retrospectives, you must consider the Prime Directive, which is meant to prevent the sessions from turning into blaming games, so make sure the team believes that everyone did the best they could. As you can see, this is a person-centered conversation that's different from a Sprint Review.

a. Sprint Review vs. Retrospective

There seems to exist some confusion with the terms Sprint Review and Retrospective. These are not synonyms, as the latter focuses on the team. Instead, the Sprint Review is intended to assess the increment of value delivered as a product of the tasks performed during the last work cycle.

In a software development situation, that could mean analyzing any feature, fix, or sub-product released. Depending on the context, it may refer to a campaign launched by the marketing department, a deal closed by the business development unit, or any other accomplishment. It's crucial to focus on the product delivered, not the process.

That's where retrospectives come into the scene. The goal of these sessions is to discuss how team dynamics went during the past work cycle. The review and Retrospective may be parallels, but remember that Retros are a conversation about improving people relationships, enabling teams to be more autonomous and accountable, ultimately leading to high performance.

b. How to run a Retro session

When it comes to hosting effective retrospectives, it's essential to keep them as simple yet engaging as possible. You can easily frame your meetings within this structure:

Set the stage - Greet everybody, throw in some ice-breaker questions, make some small talk, and make sure everyone understands that the session's goal is to review the past work cycle or Sprint.

Gather data - Ask for everyone's opinion. You can use the three basic questions: What was okay? / What was not great? / What could be improved?

Generate insights - Discuss the inputted ideas, but prevent any blaming between peers. Group similar ideas into topics and collectively define which are the most important to address.

Decide what to do - Based on the team's topics, consider the most relevant and formulate action items to fix the flagged issues. These will be incorporated into the next work cycle.

Close the Retrospective - Action items should be assigned to specific persons who must ensure those get implemented. After making that clear, it's time to end the meeting, not without asking any doubt or last comments.

c. Retrospectives in Kanban####

Retrospectives are inherently linked to Scrum, which might be the most popular Agile framework. But they can also work if you use a Kanban approach. Wrike suggests some methods for incorporating them into your workflows. We recommend adopting any of the following:

Scheduled Retrospectives - The whole team agrees on these sessions' cadence. For example, you could run them on Fridays to check on the week's work.

Pull system Retrospectives - Kanban is a pull system: Items are only made when needed and move across workflows after meeting specific criteria.

Based on that idea, you can manage a separate board where people put issue cards that require discussion with the whole team. After a certain number of cards is reached, a retrospective is held.

There's a third method suggested on Wrike's blog, the Stop & solve one, which we don't encourage using, as it can be hard to establish criteria for making them efficient. The idea of this Retro is to call for the whole team when someone gets stuck, which isn't viable most of the time.

Regardless of which type of Retrospective you choose, you must make sure to bring some data to your sessions. Let's dig into it.

2. Analyzing your workflows

Continuous improvement sounds nice, but how do you understand if you're actually achieving it? Keeping an objective view of delivered work is pretty helpful. When it comes to Kanban, we consider three essential metrics for this end, taken straight from Raviv Turner's wisdom:

a. Task efficiency score

The ratio between the time a task waits in a queue and the time it is being worked on.

b. Task cycle time

The time a task takes to be delivered from one workflow to another.

c. Task throughput

This is the balance between the efficiency score and the cycle time. It represents the number of tasks completed within a fixed amount of time.

With these metrics, you can have a concrete idea of your workflows. You can even do some task delivery forecasting to manage your team better. However, it's also important to consider if the tasks performed bring value or if they're a waste of resources.

3. Preventing waste

The effort is important. But more so is knowing which battles to pick. We mean that your team must be mindful of the tasks they will perform. Any work requires a clear goal that aligns with your business priorities. Doing stuff for its sake isn't Agile, nor effective at all.

We're not stating that you shouldn't allow for experiments. Testing ideas is okay when:

  • Your minimum required tasks are covered, and no one puts on extra pressure.

  • The experiment has a clear hypothesis to prove (or refute) and a detailed description of the employed resources.

Other than that, tasks that don't drive real business benefits should be examined and, if needed, dropped or replaced. Not assessing their relevance puts you at risk of investing your budget into generating waste.

a. The 7 types of work waste

Experts Mary and Tom Poppendieck grouped software development waste into seven categories based on what's considered waste in lean manufacturing theory. These can be applied to any team working on products/services.

Partially Done Work - A work item that has not yet reached the Definition of Done* and cannot be sent to the following workflow or shipped.

*The Definition of Done is "the minimum work generally required to get a product increment to the 'done' state."

Extra Features - Developing more than what is needed. It's always a good idea to back up your assumptions with data, so no one does more than what's required to cause some effect.

Relearning - Ignoring the knowledge available to the team members. Always check the documentation written by other folks or ask them about their expertise areas.

Handoffs - Waiting for others' work to be able to progress. If you follow our advice to analyze your workflows, bottlenecks should be evident. Loosen them up.

Delays - Taking more time than committed to delivering value. Stating deadlines is always tricky, and some tasks may delay for some days every now and then. But losing control over this can affect the performance of the whole team.

Task Switching - Moving to another task without completing the previous one. Sticking to the Definition of Done should prevent this from happening, but someone could get blocked due to interdependencies -or anything else. Ensure all blockers get raised during your stand-up meetings and clean the road.

Defects - Plain errors in delivered tasks. This one is pretty obvious. Consider that some flaws might be more severe than others.

Keeping a record of the most common issues during your work cycles is critical for continuous improvement. It can also enrich your Retrospectives with concrete examples of things that could be improved for the subsequent work cycles.

4. Visualizing your workflows

Whichever your approach, visual support of how tasks move through the workflows. Especially with the rise of remote and hybrid models, many comrades no longer share the same physical space.

There are some options out in the market that can fulfill your needs. One of them -and a great one, we must add- is Trello, which has a free version, aside from packing a bunch of benefits.

a. Getting started with Trello

This platform will let you easily create boards with the needed number of columns to represent all your workflows. Work items get registered in cards containing all their related information, including checklists, due dates, attachments, conversations, etc.

Head here to open your account.

Remember, if you go full Kanban and deploy a pull system, it's a good practice to add some buffering columns in-between the ones representing the workflows.

For example: In the case of a recruitment team, there might be a column for candidates that will be cold-reached. After being approached and accepted to start the process, its related work item could be put in a column under the label 'Interested', where it sits until somebody in the 'First interview' workflow picks it up.

b. Agile Retrospectives Trello Power-up####

After setting your board, adding the Agile Retrospectives Power-up would be wise. It will let you run Retros inside your Trello project, making it easier for your team to attend and follow any action items.

You can add it from here and start fostering a continuous improvement culture with little effort, thanks to its main features:

Customize your session to suit your needs - You can choose a template or use your own technique. Check some ideas to start off. After setting it up, you can begin the Retro and go through its simple yet engaging three steps:

Think - Everybody adds their ideas for each category.

Vote - The team votes for the topics they consider the most relevant.

Discuss - Talk about the top-voted topics and plan action items to address them.

You can turn those Action Items into Trello cards to ensure they get assigned and prioritized during the next work cycle.

In conclusion…####

Running Retrospectives is not only about scheduling meetings but the germ to fostering an autonomous spirit of continuous improvement. The best way to keep a high-performing team is by ensuring their internal dynamics flow and flagging any anti-pattern or issue that could mine the peers' confidence in each other.

This post is from our Agile vault. Articles previously published on the SoftwareDevTools Blog that we're re-publishing. In that blog we discussed everything from Agile adoption, distributed work, and the Atlassian ecosystem.

Trying to improve your #Agile practices? OR are you getting started with Agile? Are you in a remote team? Check out our products for Agile teams at CatapultLabs. We focus on making agile ceremonies more effective and easier to adopt for remote teams.

Check out our Atlassian tools:

Follow us on our networks:
Facebook: /CatapultLabsTeam
YouTube:CatapultLabs
LinkedIn: @CatapultLabsTeam
Email: hello@catapultlabs.com
And Subscribe to our blog below!

Read more