Imagine having an ART (Agile Release Team in SAFe) with people with following skill groups:
- backend developers,
- mobile developers,
- BI developers.
Having, as a product, a mobile app like Uber Eats, imagine that we want to deliver value to the users via new features like adding a screen with map showing a location of the food deliverer.
The question is: how to form the teams?
Either (a) strictly cross-functional, or (b) around skills?
With (a) we group people with different skills in one team, so we can deliver full feature (from backend, through mobile app screen, till the analytics & reports). On the other hand, it might be possible some skills would be underutilized (e.g. too less work for single BI developer).
As opposed, with (b) we rather group people around skills and move coordination from team-level, to ART-level. However, is then possible to have a feature that brings value, but does not span across different teams in the ART? I guess SAFe expects to have rather one team “doing” a feature, not sharing whole feature with different teams.
This comes up a lot and the “answer” often depends on who you ask. There are competing views within the agile and SAFe communities on this. From what I’ve seen in the wild:
For the people in question, consider assigning them to the team they will spend the majority of their time with. Then, let the other team “borrow” them for an appropriate percentage. Sharing this way IS suboptimal but usually more palatable than “we need to hire another dev so Bob can spend 8 hours/week on ___.”
Observe and adjust as needed. Many orgs new to SAFe spend too much time trying to get org details like this “right” the first time (unironically). Consider, “we’re going to give this a try and see how it goes” as walking the agile talk.
There are no great answers to the “team member rounding” problem in practice, only least bad ones. And the ones that work for you and your org. Good luck!
There’s no one right way to organize your teams. Even within an organization, you may have several types of teams. Consider Team Topologies and the unFIX model. Depending on your product and organizational context, you can consider several ways of organizing the team.
The ART – Agile Release Train – is a group of teams that have some level of dependencies between them that need to be identified and either eliminated or managed. Defining platforms, value streams, complicated subsystems, and other aspects of your system and value delivery model may show you different ways to organize your teams.
If you were to go through these exercises of looking at your value streams and system architecture, I would be careful when defining features. Specifically, combining analytics and reporting with user-facing functionality could put you in a tough spot. It may be better to define value streams to different stakeholders and treat the analytics as a separate value stream or as a complicated subsystem.