A value stream team should have the ability to “deliver significant increments without waiting on another team”. It should minimize the cognitive load of the team. It’s cross functional.
It’s an “entity with its own learning, goals, mission and reasonable autonomy”.
The EPT model could be considered an approach to team autonomy. Building better models with domain experts and customers. Focusing on outcome over output.
I think most of us reside in some sort of “value stream” team, as a product or part of. The client might not call if that, but it’s the closest if we were to map it to team topologies.
Hopefully all have experience from a cross-functional team with different levels of autonomy in regard to tech and business outcomes.
The Book Team topologies define four types of teams; “Stream aligned”, “Platform”, “Enabling” and “Complex subsystem”.
This makes it interesting to look at what skills/traits are more important in different kinds of teams.
In recent years in a strive towards technical autonomy, “you build it, you run it” mentality has led to moving ops into the teams through DevOps, but autonomy regarding what to do, to achieve desired outcomes is the goal.
The maturity of this journey leads to a lot of different team setups out there.
To decrease cognitive load, a platform team could support multiple “value stream teams” with complex technology. This means moving out certain technical scope for the “value stream team”. A member of the “platform” team could be seen as a platform engineer. Platform teams are product teams, building the (internal developer platforms) IDPs. - How platform engineering is different from devops and SRE
An enabling team “assists other teams in adopting and modifying software as a part of transition or learning period”.
A complex subsystem team develops “subsystems require particular skill sets and deep knowledge to be designed and developed. Since stream-aligned teams do not have these, complicated-subsystem teams enter the scenario” - like different kinds of AI - Complicated subsystem teams
In these autonomous teams, team scope architecture could be approached in a few ways by the team, but teams and their systems (team scope architecture) are part of a bigger surrounding system.
Using topologies on architecture has led to writing about - Architecture topologies (slides), Architecture as Enabling Team and Product Architects.
Data is more important than ever, for a team to be able use feedback from data to drive the right decisions. Data-Mesh is an approach to move data closer and offer up a mesh of team data (data product), where the team is responsible for their data and services.
But if the value stream team moved out responsibilities to be able to focus, moving data closer adds to the cognitive load. The data mesh architecture site provides a lot of insights and examples how this could relate to team topologies.
Could these topologies and examples aid in how you look at your current and future roles?
In what kind of team(s) do you fit, and what skills/traits are important?
Since teams seldomly are alone, the collaboration and communication between teams is crucial. Team topologies describe three different kinds of interaction modes between teams. If we look at model relationships between contexts, domain driven design establishes seven different kinds. So, collaboration and visualization are always a core skill.