Journey to Full stack delivery Teams. Episode 1: Where we were and where we wanted to get to
Episode 1: Where we were and where we wanted to get to
Where we started:
Back end teams building Microservices in Node.js using AWS, Front end teams building Micro-frontends in React for Web and TV apps.
1 x BE team & 3 x FE teams, of the FE teams we have a mix of 1 x TV development, 1 x Web Development and one of the newer teams that are developing features for TV & Web at the same time.
We had already started to move the FE to be cross-functional for both Web and TV.
An important point is that TV shares the same tech stack with web — which means that frontend developers can work on both.
The original reasons for this were that the teams had to rebuild some existing services and web frontends while matching existing API contracts. Because of this, it made sense for them to be separate so they could work at their own pace and delivery when ready.
Where we wanted to be:
Making autonomous and independent teams able to own features from BE through to the TV and Web.
Ideally, each engineer would be Full stack rather than just a team made up of a mix to create a full-stack team as that adds on extra complications and risks, but this is a much longer-term goal and depends on the engineer as not everyone wants to be full-stack.
Able to plan a feature that could be handled by the team on both backend and front end to delivery it as a single entity.
Caveat: This still doesn’t solve the issue where multiple teams are needed to deliver on a feature, but it does help it out a lot.
What problem were we trying to fix?
There were a few items here, some not current problems but more future-proofing the teams and delivery, most of the engineers wanting to be full-stack, the ability to own features across the board, more straightforward planning and prioritisation of features.
We realise that we won’t solve all problems with this approach and it will likely add other problems, but we believe it is going to be the best approach to deliver content to our customers quicker.
What was the plan?
We wanted to be clear that it will be a reforming teams rather than people being merged into existing teams.
We wanted to end up with two groups of ten, and within those two groups, we would likely have two teams of five. The groups represent the areas of the product those teams look after and then the teams within those groups can own features but share the services or possibly have teams within the groups own services, but we hadn’t decided at this stage.
Another benefit of this is that we wanted to make it easier for engineers to move teams, the most straight forward form of this being people could easily swap teams without a team being hit by losing a specific skill set, read another post by me on how this helps to reduce employees leaving and keeps them happier here:
How we went about it
In the past, I have run self-selection days which I do prefer, but we were not able to get everyone together at the right time to run one of these, so we did it in parts:
- Informed all the teams about it happening as a group with some detail and a time to ask us questions
- Let them go away and then have a think and ask their current line managers questions they thought about over the weekend/next few days
- 1:1s with the current manager where needed, this was more ad hoc for people who wanted a bit more of a chat
- We let everyone know that this wasn’t that they would be merged into another team but that it would be new teams, and we would redo DoD, ways of working and so on including new team names so it’s clear to everyone they would be brand new teams, this was important to make sure people knew they would have an input on how things would be in the new group.
- Gave each of the current teams get an understanding of the roadmaps of where they would be working
- Asked them individually if they had a preference for an area or didn’t mind.
- Ran some get to know you sessions as not everyone knew each other
Next episode: Why this plan failed….
or in other words why it wasn’t the best approach and what we decided to do instead
Episode 2 is now up: https://medium.com/@tommurton/journey-to-full-stack-delivery-teams-2ce55b4675bb
