We are just about to change how we organize our scrum teams. Currently we have component teams, strongly attached to particular technology skills (our focus being client-side mobile library development these are Android, iOS and Windows). However, now having reached (more or less) feature parity across the 3 platforms, and having experiences various drawbacks of this team setup (like unsatisfactory alignment across teams when working on the same feature, or embracing new technologies coming into our scope), we’d like to change to a combination of feature and core teams.
I’ve just read Mattias Skarin’s blog about this topic. It describes the following 4 categories of teams: dynamic feature team, fixed feature team, function team and component team. Even though this is quite a short blog post, it helped me a lot understanding the pros and cons of these various teams.
I see two main challenges with this change:
1. Flow of knowledge regarding technology areas and component code bases. I think a good way to solve this could be something similar to the matrix structure introduced by the engineering organization of Spotify having squads, chapters, guilds and tribes, described by this blog of Henrik Kniberg.
2. Risk of demotivating people in the core team. Most of developers prefer to work on exciting new features compared to bugfixes or relatively small enhancements. The solution may be just the naming of teams. Instead of calling them Core Team and Feature Team 1, Feature Team 2 and so on (in which scenario Core Team may be very easily interpreted as Maintenance Team), let’s give them some codenames, like Red Team, Blue Team, Green Team etc.
Let’s see how well this goes.