Why we switched from Feature Teams to Component Teams

Making the best of a suboptimal situation by preventing Feature Teams from slowing you down

You might be thinking: why on earth would anyone switch back from Feature Teams to Component Teams? That’s like switching from the superior graphite tennis racket back to the outdated wooden version.

Image by Farer

Hold on to that thought. I wrote this article to show how using Component Teams may be a sensible decision in some situations.

For those who don’t read my articles regularly, I’m a big proponent of Feature Teams. I’ve written multiple articles on Feature Teams to help convince people of their benefits and assist them in making the switch.

Regardless of my preference for Feature Teams, I’m a pragmatic person and do my best to not be blinded by idealism. Even if I have a predilection for working with Feature Teams, I try to keep an open mind. It is essential to entertain the possibility that your Feature Team set-up may actually be working against you.

Recently I found myself in a situation where it actually made sense to switch from Feature Teams to Component Teams.

We were tasked with rebuilding our whole e-commerce platform, a daunting endeavor. We would be using the same SaaS platform but start over from scratch. I will not explain why, but let’s assume we made the right call for the purpose of this article, and it needed to happen.

When creating the different teams, we had a big problem we needed to workaround. We had way more back-end developers than front-end developers, at a ratio of 6:1 (7 developers in total). Since rebuilding the platform consists of both front-end and back-end work, we had a massive bottleneck that would limit the pace at which we could deliver the new platform.

We asked ourselves the following question: how could we best organize our work to be impacted as little as possible by this limiting front-end factor?

Considering different approaches to deal with the bottleneck

Imagine we would have gone for Feature Teams. This would have meant that we would have two teams: one team with a front-end developer and one team without. Even if we shared the front-end developer between both teams, we would only be able to complete work at the pace of the bottleneck: the front-end developer. As features are only done when all parts come together.

You might be thinking now, why not make just one big Feature Team? There would be two disadvantages to this approach:

1. We’d be breaking the Scrum limit of the recommended size. Breaking an arbitrary limit isn’t a dealbreaker for me. However, as the team size increases, communication becomes more complicated and less effective. Based on my personal experience, I have a preference for smaller teams of around 5 people.

2. One Scrum Team means having one Sprint with a single Sprint Goal. This wouldn’t be possible with the big team. The front-ender and back-enders would effectively be working towards different goals within the same team. As a result of this internal misalignment, all Scrum events would become pointless and hollow.

Instead of making a single big team, we opted for a different approach. We divided the teams into front-end and back-end to ensure they could each work on their own components. The back-end team worked on integrating the vanilla SaaS platform (inc. default non-customized front-end) with our systems. The front-end team (with UX) would work on building the new front-end components together with the improved UX.

The back-end developers were able to work full speed on making sure the platform was connected with all the existing back-end systems. The front-end developer, together with UX, would pick up the front-end components at their own pace. If any adjustments were necessary on the back-end due to work on the front-end, we’d prioritize the work instantly.

The approach was a big success, even though it was initially met with skepticism and frustration. Depending on other teams to finish things by design is something we often try to circumvent. We actually chose an approach where it was the norm.

Once the teams learned to be as flexible as possible towards each other, we were delivering features swiftly. The skepticism and frustration disappeared as well. In fact, when we started talking about moving back to Feature Teams, many people actually now wanted to stay in the Component Team set-up as they thought it was working extremely well.

Work with your bottleneck instead of against it

Any speed improvement not at the bottleneck is an illusion. With this understanding in mind, flexibility between the two teams was given the highest priority. The front-end changes were prioritized at the expense of finishing things in the back-end. We wanted to move fast, not appear to be moving fast.

After many months when the e-commerce platform was close to completion, and additional front-end developers were hired, we switched back to Feature Teams. Would it have been better if we had sufficient front-end developers from the start? Absolutely! But sometimes you got to make it work and be creative.

I thought it would be good to share, as someone else might be experiencing similar problems. Now they might have a potential solution to address their problem(s).

Be aware that by working this way, you will often be revisiting things that were already built. When the back-end is done, the front-end might not yet be done, and vice versa. Code that was written a while back is more cumbersome to modify, as it is no longer fresh in the back of the mind anymore. Still, despite these setbacks, I firmly believe the chosen structure was the optimal approach deal with our bottleneck.

There is no best solution. You can only discover what works best in your specific context. Keep an open mind, experiment, and learn!