In part 1 of this series of articles we looked at the pros and cons of platform based teams. Then in part 2, we looked at how project based teams worked out for us. In this article we’re going to look at how we moved to feature based product development teams; each team looking after a subset of features.
Getting straight to the point
A feature based development team is aligned and responsible for developing all the required functionality for a specific feature/set of features. This is a customer-centric team with all the required skills to deliver ideas into working software.
For us, feature based teams were a vast improvement over project based teams, but they were still not perfect. Each of the teams were given a specific set of features to look after.
Here’s a diagram on roughly how we were set up:
Each of the teams consisted of:
- iOS developer(s)
- Android developer(s)
- Backend developer(s)
- Frontend web developer(s)
- QA specialist(s)
- Scrum Master
- Product Owner
Any new enhancements, user feedback, bugs or anything else related was directed to the team that owned the feature.
If we needed to add a new field to the account registration form, that went straight to the My Account Team; as would any other features, such as creating a consistent account experience across all of our platforms.
If a request was made to enhance the users podcast experience, e.g. adding the ability to cast to a Chromecast device for example, that would go straight to the Podcasts Team instead.
- This set up promotes long-term ownership of features, which means that individuals are more likely to make “quality” code changes and decisions. People are less likely to take shortcuts, because they are likely to have to revisit that part of the product again someday.
- It’s easy to understand who is working on what. If you have a problem with a particular part of the system, you know who to speak to.
- It builds long term relationships with areas of the business aligned to the team that owns the feature. e.g. a podcast editorial team can be aligned to the podcast feature based team
- It promotes long-lived teams. The holy grail! We’re not switching projects anymore, so we can keep the team as one and learn how to work with each other.
- It’s quite easy to scale this approach. If you want to deliver more features, more quickly, add more feature based teams (note – you’ll need other teams to help support lots of teams if you get too big – this will be discussed in a later article)
- This approach promotes teamwork, as we are all developing an end-to-end product increment as a team
- A Product Owner only has to explain feature requests to a team once; not once per platform
- For my situation, the demands for each feature set were uneven. Sometimes there were orders of magnitude more requests for updates to our podcasts section, and very little changes required to a very well established My Account section. You could resolve this by aligning multiple teams to a single feature set, but we didn’t have enough people to achieve this.
- We didn’t have enough teams to cover each feature independently; this means that one team will need to own many features; which leads to context switching and conflicts.
- We had high priority work waiting to be started, whilst some teams lay nearly idle. Here’s an example to explain what I mean. The top two things we should be working on happened to be looked after by only one of our teams, and they would be tackled sequentially. This means that the other feature teams are no longer working on the top business priorities. We had a combination of near-idle teams with low demand, coupled with teams with demand well beyond their capacity.
- Some demands span feature sets e.g. iOS updates, platform library updates etc… Who owns these changes? It needs to be decided in advance.
- You need good people. It’s a lot of pressure on the single Android developer (or any other role) to get things done.
- You need to cover absence. If you only have one specialist on the team, what do you do when that person is on holiday, or off sick? You need cover.
I hope you enjoyed reading how we moved to feature based product development teams from project based teams.
Using feature based product development teams comes with some great benefits. It really felt like a positive change for us, like we were moving out of the old world and into the new. But we didn’t stop there. In my next article, I’ll describe how we started to adapt to OKRs (Objectives and Key Results); and how we structured the teams to help deliver the most important things for the business every single quarter.
Till next time.