DeveloperBlogs

Team Mechanics Part 2: Collaboration and Improvement

Welcome back to the Team Mechanics series. In this second instalment, we continue to explore how our SRE team develops and refines its ways of working. This time, we are building on how the Mikado Method shapes our planning (as explored in Part One of this series) and how it connects directly to the day-to-day practices we use to break down work more effectively. 

Mob and Split 

One of the practices that’s helping us put this into action is our Mob and Split approach. By coming together to focus on a single task, then dividing into smaller groups when needed, we’re able to collaborate more effectively, stay aligned, and complete each Mikado inspired slice with purpose and clarity. 

To do this, we start a task off in a mob where we determine what needs to be done. This is done in Slack via a huddle. If it’s particularly complicated we may stay together during the complicated parts and pool our knowledge, but often we will find parts of the task that can be split into small manageable chunks and someone (either a pair or an individual, depending on the task) will split off to complete it and come back to feed back the information.  

An example of such a task would be if you were creating a new endpoint, you could have someone split off to create a stub of the API endpoint while another begins to implement the underlying mechanism.  

This not only helps to complete tasks quicker, but it also helps by pooling the knowledge of the team and enabling the entire team to have visibility and awareness over each task/component of the work. This means that the task is not dependent on the knowledge of any single person in the team, and people being absent later won't block progress.  

When we split off, we usually split into pairs, with a driver and a navigator. The driver is the one writing the code and the navigator has the responsibility of seeing the bigger picture, while trying to make the driver able to continue unhindered. This means finding answers to questions that may end up blocking the driver so they don’t have to do it themselves and can just continue writing the code.  

We have several Slack channels that function as general working rooms for our team, allowing people who are splitting off to form a huddle in one of those channels. While split working on separate parts of the work, the split groups are encouraged to regroup in a huddle together, if at any time there something that needs to be discussed.  

The key to this is to regroup frequently. This can be hard for tasks that are challenging to split down to tiny pieces, so sometimes it’s best to plan specific times to come back together to share knowledge on progress and to get thoughts on anything. We’ve found that on tasks where we’re splitting a lot, it is beneficial to come back together at least twice a day.   

However, this shouldn’t be restricted to those planned check-ins. If there is an unknown or new information that changes the approach, then it is useful to get back together to discuss the situation and get the input of the entire team.  

How we improve  

When we first started as a team, we would have scheduled weekly hour-long retrospectives where issues were raised, with specific sections for different types of discussion. These mainly focused on our workflow and day-to-day discoveries we wanted to refine. As we grew as a team, we began reflecting throughout the day, identifying what to improve upon and raising it as soon as it is not disruptive to do so.   

This allows us to adapt and trial new approaches and to get feedback quickly without having to wait until the next retrospective. Sometimes the things raised can be anything, from a passing comment that allows us to change something then and there, to a larger 5-minute discussion that identifies a way to move more effectively or quicker.  

The planned retrospectives can then be shorter and focused on more high-level topics instead of focusing on the detail, including ideas for new approaches.  

It was through such retrospectives that we trialled lots of new approaches that have been adopted to make us more effective as developers, including both the Mikado method and the Mob and Split approach.  
 

As our Team Mechanics continue to evolve, these practices represent where we are today, not a fixed way of working. We’ll keep experimenting, reflecting and adapting as we grow, always looking for better ways to communicate, share understanding, and stay aligned as a team. By building approaches that make knowledge collective rather than individual, we’re removing friction, strengthening collaboration, and creating a workflow that can keep improving alongside us.  

Authored by Blaise Duggins & Ethan Hawkins | Senior Software Engineers | SRE Team

Codeweavers

Read more by Codeweavers