The start of the year, ahhh, the perfect time to have a fresh start and forget all the pain of the year that went before. Or as I see it, the ideal time to run a retrospective to take the learnings from the past and use this to create goals for the year ahead.
I like to start by addressing any actions from the previous year (for example from previous retros) to identify what needs to be done to resolve them, and ensure the assignee hasn’t simply forgotten about it.
Then I move on to look at metrics for the year, followed by reviewing the team’s health - ideally you’ve run at least 2 checks throughout the previous year to identify not only the problematic areas that need to be addressed, but also the areas where you’ve improved. Reflect, as a team, what has changed - what steps did you take to improve things? How are we going to maintain this level going forward?
Aha, that old chestnut! If you can, prepare an overview of what was worked on in the past year (if you’re using an electronic tool like JIRA this should be a piece of cake!). You should at least have an idea of the percentage of time dedicated to particular epics throughout the past year. Take into account public holidays and vacation time (for example summer) - you may have seen increases in the amount of time stories stayed on the board for particular periods of the year.
I inspected the metrics for 2017 with one team in particular, opening up an interesting discussion: at the beginning of 2017 their stories were large monoliths that would take weeks. By the end of the year they had got into the practice of splitting their stories into much smaller tasks, with a clearer scope. In doing so, their cycle time decreased and the number of stories associated with one epic grew. The team were able to see this from their yearly metrics report, so be sure to bear such things in mind to add context to your charts.
Which direction are we heading in?
Being the beginning of a new year, try to think strategically - focus on the big picture more than you would in an ordinary retrospective. Looking at specific areas, such as whether or not the team feel they contribute value to the business or how they feel in their interactions with other teams and departments, helps to identify issues that may not be otherwise visible. It’s not about whether or not the team actually provide value, but rather understanding how individual team members feel about their overall contribution to the organisation’s product or service.
Although there are several models for visualising how a team is doing, one of the most popular models being the Spotify Labs’ Squad Health Check which is the one I am focussing on in this blog post. This is a high-trust model as it relies on the teams to do a self-assessment, and thus is based on the subjective opinions of the people within the team(s). The model focusses on specific areas such as ‘teamwork’ and ‘release process’, which you can see in the photo above. Next to each area is either a happy, neutral, or sad face and a comparison to the previous quarter. At the end of the flipchart is a direction with a green up arrow if the team have improved since the last check; red down if more of the team feel negative about that area; and a rectangle for where they’ve maintained the status quo. From the photo you can see that the ‘delivering value’ area shows a red arrow in terms of direction, inferring that something has happened since the last quarter to make the team they’re not delivering as much value as before, and hence discussions should focus on areas which have been negatively impacted.
N.B. No change in a particular area isn’t necessarily a bad thing - if the majority of team members feel positive about that, and the percentage of the team who feel that way hasn’t changed, that’s great!
Through open discussion as a team, they should start to identify changes to make to particular areas to improve. For example, with a team who feels that they are not delivering value to the wider business, an action might be for the Product Owner to provide more regular feedback from the stakeholders and end customers with the team so that the developers know their features are being used, and know how they are helping real users.
It is important to reflect on improvements that have been made and to show the team how far they have come over the course of a longer period of time (in this case, a quarter). This allows you to start the year on a high note, and to identify any trends that should be corrected that aren’t visible in a shorter period of time.
Personally, I was pleasantly surprised to see how many of the health check areas that had improved. The team had worked incredibly hard to achieve this, and I am very proud of them. I’m also impressed with their ability to inspect and adapt without prompting - they continuously identify improvements and have become a stronger team in a relatively short period of time. I’m excited to see what the next health check for them looks like, and am confident they will manage to improve those areas of concern by the time we run the next health check.