What I learned running remote agile teams at Babylon in 2020

In April 2020, just a month into the pandemic, I moved from Accenture to Babylon Health as an Agile Delivery Manager. The change from consulting to healthcare startup was substantial, and brought many new challenges — not least an entirely remote delivery role. I still haven’t met in person many of my teammates!

Reflecting back on this year, there are some key lessons I have learned running my three teams (or squads as they are known at Babylon). All squads worked already within either the Scrum or Kanban frameworks, and these lessons were developed from our efforts to optimise our delivery.

Experimentation key to good change

Whilst in previous teams the agile processes were left very much to the Scrum Master to decide, my teams at Babylon were much more sceptical about accepting more processes and wanted to know the problems it was addressing. This was a good thing — the teams pushed me to clearly articulate why we would change something, and what the benefit is likely to be. The answer to introducing the new processes effectively was experimentation.

We settled into a new routine of running a fortnightly or monthly experiment of each new agile practice when it was raised as a potential way to solve the team’s current problems. This included:

• Story pointing and tracking velocity to solve the problem of not managing capacity effectively.
• Monthly and quarterly planning to solve the problem of engineers feeling overwhelmed with different priorities.
• Review sprint goals again after bringing work into the sprint to make sure goals set were not too ambitious

We agreed the rules of the experiment at the start, and what would be classed as success. At the end of the period, we decided whether to keep the practice or not. This took the pressure off the team to make a decision on whether to adopt a practice or not, and helped us to be guided by data rather than theory.

It helps the team to understand why each practice is in place (related to a problem being solved), and ensures everyone collectively agrees it is the best way of working. It also develops a constant experimentation mindset to continue to improve.

Design for deep work within the team

When remote work became the norm this year, the teams were being involved in lots of meetings throughout the day related to upcoming work, work in the sprint, and internal meetings. This is partly due to the value we put on communication within the team. We decide to dial back these interruptions to encourage deep work in two ways.

First, we set some clearer expectations around Slack and email. There were differences within the team about the speed in which people expected a response. We agreed everyone should have their Slack notifications turned off. Aligning these expectations gave people the freedom to work with fewer interruptions.

Secondly, we tried a surprisingly successful experiment of a ‘no meetings wednesday’. On the middle day of the sprint, a meeting is booked for working hours for the entire team. The team retain the daily stand up, but does not book any other meetings. This ensures at least one day a week the team have unbroken time to go deep on a problem. The team love having this in their calendar as guaranteed deep work time, and it even helps the Product Manager think through upcoming work. We’ve doubled the frequency of this from every other week to every week.

‘Russian doll’ goal setting to align the team

One of the big challenges of working in an environment with a high degree of change is setting effective and meaningful goals that rally the team to achieve them without becoming out of date quickly. We’ve experimented with goal setting lots in the last nine months, and have settled into a ‘russian doll’ of goal setting.

Set goals for the:

• Sprint
• Mont
• Quarter
• Product Vision

Once all of these are set, bringing them together regularly by storing them in one place is critical, currently the Confluence page. This means that you can check they all align, important for maintaining consistency and ensuring the engineers are clear on direction.

Blind feedback and voting for Retrospectives

When starting at Babylon, I was introduced to a tool by a colleague called Parabol. Whilst the tool itself is a great retrospective tool, and continues to be used by my teams today, it was actually the process behind it that revolutionised the way that we run retrospectives.

The Parabol tool follows a set format for retrospectives that involves completing much more of the process blind than other retrospectives.

1. All retro participants add their feedback blind for a set time.
2. All feedback revealed. Participants read feedback silently and group if similar.
3. Clarification questions asked on any points not clear
4. Participants vote blindly on their most important feedback points
5. Discussed in priority order and actions taken

Whilst many of these steps are common to other retrospectives, the blind feedback and voting have led to much improved retrospectives and conversation. The whole above process takes 15–20 minutes, leaving 40 minutes for discussion.

The last nine months have forced us all to adapt, and learn new ways of working in the time of a global pandemic. But many of the above improvements I will keep as tools, regardless of whether the team is remote. Please let me know your lessons from this year, and what you have added to your agile toolkit in 2020.