OK so I get it, the idea of a standard size squad being split over time zones in different continents with likely more than a single first language may at first seem like a non starter; an idea manifested from a dare or perhaps one too many at the bar. I remember when we first entertained the idea of such a thing. Being told from higher ups that our well established, smooth working team of developers, BAs and QAs who all sit in the same office together in little old England were going to be forming a “super team” with our colleagues in the USA and Mexico to align on business direction and road maps was a frightening concept, though interestingly exciting at the same time. The obvious questions were thrown out: How will this work? Why would we break what is working so well? What if it doesn’t work out? But we work on different time zones! Every one of these were valid questions and concerns. But this was not a choice, this was going to happen. And I for one am happy it did.
All the concerns I mentioned above had to each be addressed, of course. After all, this was not an idea that could happen one day and be implemented the next. And to add to the list “things we need to think about” was our tech stack. We both used similar but different stacks in each part of the business, but between the 2 teams we had a HUGE wealth of industry and working tech knowledge. Now, I won’t run on into boring details for each point, but here is a basic overview of the events and decisions that were made to at least get us started.
- Leaders from the team in the USA jumped on a plane to the UK and locked themselves in a room for a week with leaders from the UK team
- Agreements and disagreements ensued but ultimately decisions were reached
- Our tech stack would be a combination of what both teams were using; a .Net Core WebApi backend with a React front end — exciting for us full stack developers in the UK as we moved from the same backend but an Angular front end
- We would form a “Platoon” consisting of 3 squads
- Each squad would consist of 3 devs (1 full stack UK dev, 1 front end and 1 back end US or Mexico dev) 1 QA and 1 BA. The full stack UK dev would mentor the front and back end US devs to become full stack developers
- We would allow flexibility to work across UK and US time zones, with majority of necessary meetings falling between 2pm and 4pm UK time to capture the best of the “cross over” in our time zones
- Obviously a lot more was decided in that week such as road maps, training time, squad focus etc.
So there we had it, the basics of the geographically distributed Platoon plan. Sounds pretty straightforward. Now for the easy bit — implement it and make it work. Really work. After all, we needed the output to surpass the previous 2 separate teams to accelerate development of a brand new product and get it to market in a reasonable amount of time, to a decent size audience, and to start to recoup some of those cents and pennies we had sacrificed to make this happen.
And so onwards we went. Those that needed to trained up on tech that was new to them, new processes and tools, understanding an agile working methodology to those unfamiliar with it, we had trial “stories” to break down, point and deliver, meeting schedule blueprints in place, squad velocity plans etc. It was all hands on deck and everyone jumped in with both feet, there was a huge buzz around the offices and over Teams and best of all, we started to see how this could work quite quickly into the process. As we began to get to know our new far away colleagues through the power the internet, we quickly worked though sprint 0, and now we were ready for the “real” work to start. Before we knew it, sprint 1 was done, sprint 2 was flying, sprint 3, 4, 5 all came with a flash. Working relationships blossoming, growing pains were being medicated with ambition and hard work and we were evolving. We no longer had front and back and developers, everyone was full stack. Sprint ceremonies were a breeze, everyone was really understanding how to work in an agile way, we were in pointing stories in harmony! Of course there were new problems popping up, and occasionally we would see an old problem pop its ugly little head back up, but for the most part, we had done it! We had not only merged 2 largely walled in teams, but we had created 3 geographically distributed fully autonomously functioning squads.
Fast forward in time and we have just completed sprint 35. A few members have moved around squads, we added a 4th squad, knowledge is constantly being shared, we added a retro of retros to our scrum ceremonies, a dev forum, a weekly design review and many other useful improvements. We are still learning, adapting, improving and looking forward, things that will never stop. But with 35 sprints, each 2 weeks long, under our belt, we now have the ability to look back and reflect on what we have achieved and how we tackled those early questions we had, as well as truly understand the benefits of working as a globally distributed squad including some nice little unexpected bonuses. Let’s take a look at a couple of these:
Time zones — This actually ended up becoming one of the biggest benefits of our new structure. As we have around a 2 hour window for cross over between US and UK time zones, this has meant that all scrum ceremonies have become very efficient and to the point. Stories for workshops are created and shared within the squad days ahead of the meeting to ensure everyone has a chance to have a good look at what we will be workshopping and pointing, which allows us to ask questions in our own time, get clarification and make sure stories are clear before workshop. We start and end meetings on time, almost every time. When an ad hoc meeting is required outside out our regular reoccurring meetings, that meeting has a clear agenda created and sent ahead of time, and we really think about who needs to attend. The benefits when looking at meetings alone has been huge, but what this also means is that we have all our meetings compacted into the end of the day UK time and start of the day US time. The added benefit of this is that we have a solid block of around 5 hours a day of mostly uninterrupted time to focus on our work. A developer’s dream! This also means that our squads are working on our roadmaps for around 15 or so hours a day.
Diversity and Inclusion — This is a big one for us. We pride ourselves within our business on promoting diversity and inclusion and this platoon structure really accelerates this. My squad alone has developers in the UK, USA and India, QAs in USA, Mexico and UK and a BA in Mexico. The absolute wealth of different knowledge and experience this brings to our squad alone gives us so much benefit at every point in our agile workflow. Different questions are asked, stories are viewed from varying viewpoints and squad members are bringing new ideas and working practices to the squad based on these different experiences. We take the best of all of this and roll it all up into our way of working. We constantly learn from each other and everyone feels comfortable to contribute and have their say.
Acquiring Top Talent — Given our remote location in the UK, we have historically found it difficult to find the numbers of highly talented humans we have required to fill all functions in our team. We actually have quite a number of tech companies around us in an area filled with farmland and countryside, all competing to find hugely talented humans to come join us. This is no longer the case. Our “talent pool” is no longer a 20 mile radius of our remote office, it is now a global search. Now I know this has changed for many companies since adapting to remote working during the covid pandemic, but it is worth noting this change in our way of working started in 2019 — before the pandemic. Which brings me to another unexpected benefit:
Remote Working As Standard — We were very fortunate in our part of the business that thanks to this new platoon structure we adopted, we were already well practised in remote working daily with our colleagues. When the pandemic hit and word came down from above that our offices were closing, we pretty much continued on as normal, except we opened our laptops at home the next morning rather than in our office. Our daily working continued on as normal for us. This has continued through the whole pandemic, with no one being furloughed, no slow down of our road map progress and still hitting deadlines set pre-pandemic (in the usual tech way of hitting deadlines, of course).
Reflecting purely based on experiences and living this change over the last 2 years, I can safely say that in my opinion, Globally Distributed Cross Functional Squads Are A Good Thing and I would encourage any businesses with the ability to implement these changes to give it a go. With the huge uptake of remote working since the pandemic hit, there has probably never been a better time to make the transition. And for those looking to move into working in a more agile way and are not currently working with a squad based model, you have so many exciting possibilities ahead of you!