Shutl

Feature teams 101

When I joined the company there was only an engineering team. As we started to grow we ended up splitting into three teams.

There was the mandatory platform team that doesn’t require further explanation. The other two teams had wittier names and focused on the different aspects of the business. One dealt with merchants, carriers and anything related like building new integrations, adding shipping services, and evolving the API. The other team focused on customers and had tasks like developing the main website, building mobile clients, expanding client acquisition and offering marketing tools.

Despite being different teams, everybody worked more or less on the same services. Moreover, the teams were fluid so people could switch from one team to the other.

This structure worked well for us.

After the eBay acquisition our priorities slowly changed but the teams didn’t. We kept the same teams but our product scope widened and we started working on the eBay stack as well. The variety of tasks increased and team members needed to switch context quite frequently. With many things on our plate, progress became less visible, the performance decreased and we started to feel less satisfied with delivered results.

As with many other e-commerce companies, we stop deploying to production for the Christmas period. This introduced a hard deadline into our roadmap. We had to deliver 2 key features fast. People naturally organised into small teams that would focus on just delivering those two features. Features were delivered and everybody had a lot of fun. And on the next retrospective all engineers agreed that we enjoyed this way of working and that we would like to keep the spirit of it. We came up with a new idea: feature teams.

What’s a feature team?

A feature team is a relatively short-lived team. It only exists to deliver an epic and it disappears once that is done.

The team is completely independent. It has its own backlog, its own sprint meetings and its members don’t have to care about anything but delivering the feature.

A feature team has a clear lifecycle. When it is born it has only one developer assigned. This person will be the driver of the project and will keep the role untill the end.

This early stage is all about analysing the problem, building knowledge, foreseeing potential issues, and starting the foundations of the project. The outcomes of this stage would be a walking skeleton or some kind of prototype.

Once the initial work is done and there is a good understanding of what’s required, the team moves to the second stage. More people join the team and new features are added quickly.

At some point the team will get to the point where most of the work is done. It is time for the team to shrink, people will leave it and join a different one.

Finally, once the feature is completed the team is completely disbanded.

Let’s try

We decided to give the idea a whirl and I was lucky to be a member of the first feature team. The feature we chose was something we had been working on for a while, but our knowledge was still fragmented and we struggled to make steady progress. The scope was clear and we had a good understanding of what was required but the lack of focus made it hard to advance.

The discovery phase didn’t take too long but it was very useful. We consolidated the knowledge we had into users stories that formed our new backlog. From there we mapped out new stories to create a path to feature completion. Then we started building.

And it worked! Not only we managed to maintain sustained progress, the team benefited in many different ways. With more focus we started to make better decisions, both business and technical. We were able to pay technical debt, improve the test coverage, and accelerate the development process.

Stand-ups were shorter, planning meetings were shorter, everything was more relevant. The team was confident and morale was high. The team committed to a deadline and fulfilled it on time.

We succeeded and then disbanded on a high.

The caveats

Feature teams are great because they allow the team to focus only on the final objective but there is an obvious caveat. Who is running the business? Who is doing maintenance, fixing bugs and improving the platform?

The answer for that is that there is another team, a team that is “focused” on taking care of most of these distractions. We call this team Mosh Pit. A mosh pit may be where all the cool kids are but our Mosh Pit team is doing the grunt work to contain distractions and keep the show running.

As such, Mosh Pit is fluid. Teams dissolve into Mosh Pit and appear from Mosh Pit, this way we make sure it is fair for everybody and people rotate. There they can help their colleagues staying focused while waiting for their next assignment. This is where I am right now.

A second aspect to take into account is how to spread the knowledge. It is usually a problem that is exacerbated in feature teams. The visibility is definitely reduced in all directions, hiding all the details from anyone who is not part of the feature team.

How do we mitigate it? We are doing several things. We have weekly demos on Fridays and an engineering kick-off on Mondays where the three teams give high-level updates so everyone can get an overview of what’s going on. These are some things that we were doing previously but now they are even more relevant.

Ironically, another way to help spreading the knowledge is via Mosh Pit. Though the feature team is disbanded, the feature is never complete. It may be an product improvement or a bug fix, but some work will eventually be required. When that happens a former member of the feature team will pair with someone who wasn’t part of it, transferring some knowledge in the process.

Finally, planning becomes even more important. You want to make sure that you have enough people in the feature teams to make progress. You need people in Mosh Pit to run the business. But you don’t want too many people in it, just the right amount so the rest can deliver fantastic features. What happens if too many feature teams are disbanded at the same time?

Very fluid teams don’t help. We use points to estimate our stories but we have never been very strict with it and actually each team uses different values. On top of that, teams don’t last long enough to provide useful metrics like velocity. We already have discussed some ideas to address that but we still have to put them into practice.

What’s next?

All in all, the experience has been good and feature teams are here to stay. Interestingly enough, it looks like three is our lucky number and right now there are three teams. But that’s where the similarity ends.

The teams perform very differently. Feature teams are more focused and driven. They are delivering new features more consistently. And to be honest, it’s not that bad to be in Mosh Pit either :).

Tags: , ,

Discussion

Leave a Reply

Your email address will not be published. Required fields are marked *