I’ve worked with teams of all sizes over the years. The similarity with all these teams? They were always one team all focussed on the same priority. So, when I moved companies and got assigned to one of the larger teams in their Technology division, I didn’t think anything of it. This was no different to my previous teams, right?
I was wrong…
When I joined the team, it was clear there wasn’t just one priority and they had about a gazillion things to do at once. OK fine, they were largely handling it well, or so I thought, but then I started to notice some issues.
The team were huge but they were split into 2, a front-end ‘Apps’ team and a back-end ‘Services’ team. This way of working left me stumped on how knowledge was being shared across the teams and more importantly – how value was being delivered to the customer when they’re setup as component based teams?
We continued working in this vein for some time and changes were introduced to help increase the knowledge sharing – (improved sprint reviews, whole team planning, a whole team stand up), but something was glaringly obvious. These were 2 very separate teams, working from 2 different backlogs, delivering components that weren’t very joined up and not getting value out to the customer quickly. The handoffs between the 2 teams were also causing delays.
This all came to the fore when an urgent piece of work landed on the plates of the whole team. The Services team got straight to it. They brainstormed, they planned, they got everything together and built everything in the backend ready for the apps team. The klaxon was then sounded: “Apps team we’re ready for integration!”.
How painful was that integration…?
The amount of rework required and the amount of time spent with Services developers working with Apps developers to get it all working was huge. Now I’m not big on finances but if I had to make a guess – I’m sure this would have been quite expensive. It begged the question – why weren’t both teams working together from the start?!
Other problems were starting to bubble up too. Stand up, from an outsider’s view, must have looked like a crowd at a concert and planning was becoming more difficult. People were disengaged having to sit through the other team’s story planning knowing they weren’t going to be working on any of it over the next sprint.
Now I would be doing the team a massive disservice if I didn’t point out that a lot of them knew this was wrong. They knew this way of working was not productive and change was needed. We wanted to be feature teams, we wanted to be cross functional, we wanted to deliver end-to-end features, but where did we even start?
LeSS is more…
Now for various reasons, I’d been pointed in the direction of LeSS or Large Scale Scrum. I looked into it and thought this isn’t miles away from what we want. It can’t hurt to give it a go. I also received a lot of advice from my boss on how we could tackle this team size problem.
I presented my ideas to the team, alongside an argument to move to 1 backlog (this is a battle I didn’t win and a discussion for another day) and it was largely met with a ‘let’s try it’ attitude.
Steps needed to be taken before we could dive right in. For one, the 2 backlogs were very different. One was chalk and one was cheese and if the team had to pick one to eat, I’m pretty sure I know which one they’d choose. Secondly the team names, ‘Apps’ and ‘Services’ meant work would still be coming in to those teams with those themes. Finally, the teams needed reshuffling. All the backend knowledge was on one team and all the front-end app developers were on the other.
Rebalance, Reshuffle…
I worked with the Product Owners for weeks trying to rebalance the backlogs and make the ‘chalky’ one a bit more palatable for the team. After one final sit down, we did something I was initially trying to avoid. We gave one team the iOS app and one team the Android app. Updating these 2 apps were one of the highest priorities for the team, so it just made sense. Now the reason why I say I wanted to avoid this, is because I didn’t want an iOS team and an Android team. We wanted feature teams, not teams formed around technologies, but everyone agreed this was a good first step and we should then inspect & iterate to aim to get to the ideal further down the road.
Allocating people into the 2 teams was fairly straightforward. We wanted the team to have input on this, so we ran a Market of Skills session and asked the developers what technologies used across the project they were strong in and which ones they wanted to learn. The Engineering managers then sat down, looked at this info and allocated people making sure to have a good mixture of FE and BE developers in each team.
Once the teams had been chosen and people allocated, they spoke with the developers individually about which team they had initially placed them in with an emphasis put on the fact that these weren’t permanent placements and that team rotations would happen regularly. This may seem a little ‘top-down’, but we wanted to ensure an initial fair balance of skills across both teams. However, if anyone was unhappy this would be looked at. Surprisingly, no one had an issue. Happy Days!
Defining our events was the next step.
- Stand up and Planning would be per team.
- Sprint Reviews would be for the whole team.
- Refinement would be a joined-up meeting with a smaller subset of the team.
- Retrospectives would alternate week to week from per team to whole team.
- A Scrum of Scrums 2 days a week was added to aid knowledge sharing across teams.
New arbitrary and meaningless team names were spun up and we were finally ready. A start date was agreed, the developers were aware which team they would be joining, the white boards were ready and everyone (I think) seemed excited to give it a go.
So far, so good…
The team have now been split for 2 months and so far things seem to be going well. Don’t get me wrong we’ve had issues and there still are some, but nothing majorly to do with the split. People have switched teams, but that was always planned.
Both teams have a good mix of frontend and backend knowledge allowing them to work on end-to-end features that touch all layers in our stack. These can largely then be shipped as soon as they’re ready instead of waiting for other components to be completed by other people. There’s a long way to go, but the feeling I’m getting is that the team certainly feel positive about the change.
What I didn’t mention at the start, is that at every retro we take a happiness measure. Since we split the team into 2 cross-functional teams, the happiness metric has been consistently high and stable. The guys are able to focus more, knowing what they’re going to be working on, rather than listening in on planning for a story that they know they’re never going to touch. They’re also working on technologies that they’ve expressed an interest in…well most of the time, we’re not perfect!
We’ve also met some big release milestones. The updated iOS app was released in good time, with App Store ratings going up, and since then has had a major new feature added which is a UK first and even made the press! I think it’s safe to say that having a team working on end-to-end features made this a lot smoother. The Android app is not that far behind either and a release to the Play Store is imminent. The team have also gone live with an integration to a 3rd party application.
Not bad seeing as the team only split 8 weeks ago.
What next?
Other problems have started to surface now to do with how we balanced the backlogs. We’re seeing some diverging of the two mobile apps and so organically the team are already asking for more of a feature split, rather than a technology split. As I write this, this week’s happiness metric was significantly lower and it was clear it was due to how the work is currently split across the 2 teams. We’ve not really planned well for after the great iOS release and issues and noise have started emerging from our older systems that are proving difficult to juggle across the 2 teams in our current split. It needs addressing. It’s in the works, so watch this space.
Ramblings of a Mistry Man 
Leave a comment