Retrospective guide

Swarmia is all about enabling data-driven continuous improvement cycle in software development teams. As the purpose of retrospectives is to facilitate continuous improvement in a team setting, using Swarmia in retrospectives can help you get there. Great retrospectives have three things in common, they are blameless, fact-based and actionable:

Blameless

One of the worst things to happen in retrospectives is that it becomes a blame game having an overall negative effect on team work. This is why it is important to keep a blameless mindset and focus on improving team dynamics in retrospectives. A long-running task is not someone's fault, but the result of the team organizing their work in a certain way.

Fact-based

Having a shared fact base when conducting retrospectives helps you identify objectively what went well and what we could still improve as a team. However, many teams are not used to full transparency of data. It can be useful to remind the team that looking at the data allows us to have a more directed conversation about things to improve. Looking at the data feels even less appealing if it seems to be incorrect. It's good to highlight the elements that contribute to the data quality: practices using the issue tracker, linking of Pull Requests to issues etc.

Actionable

The last piece to crack in great retrospectives is to make them actionable. We have experienced that teams often struggle to turn discussions in team retrospectives into concrete action. Having the right tools available can make the difference between action and inaction.

Swarmia is here to help you conduct great retrospectives whether it comes to preparing, conducting or turning them into concrete action:

Before retrospective

Explore your team's data on Swarmia to prepare for retrospectives by discovering insights and validating hypotheses on what seems to work and where you could improve based on data.

Check the Work Log view to identify if there are signs of working alone, siloed work, days without progress or too much reactive work. More information on how to diagnose patterns from Work Log here.

Use the Insights view to identify PRs, Tasks, Stories or Epics that took a long time to complete. When you click a dot in the Cycle Time graph, you can dig deeper to what actually happened with the feature each week.

During retrospective

After a good preparation you can focus on well-informed discussion which should result into concrete actions agreed together as a team. Swarmia has built-in Working Agreements that can be set up based on actions agreed upon during retrospective.

Pull Request flow is easier to fix than Tasks or Epics, and thus it can be a good starting point for the discussion. It's good to dig deeper into the outliers. Was the scope of this PR too large, and could we have split in other ways? Was it difficult to get a review? Was it clear what's supposed to be done here?

With tasks/issues, the change requires a bit more effort. Developers often like working on their own thing, as you don't have to coordinate much. Changing the behavior requires several things:

1) limiting Work In Progress

2) multiple people working on the same task

3) better planning of the sub-tasks

4) making sure that sub-tasks are small enough

After retrospective

If the team decides during retrospective to clean up old Pull Requests and set a Working Agreement for Pull Request age and review times, you can expect to see results in a week (or: just in time for your next retrospective). Having team and personal Slack notifications enabled makes use of Working Agreements even easier.

Deciding to strive for better planning will likely take a couple of iterations, as it is hard to get right at the first try. Thus, in future retrospectives it's useful to discuss individual tasks and how well they went.