“If the architecture of the system and the architecture of the organisation, are at odds. The architecture of the organisation wins.” – Ruth Malan, Software Architecture Consultant
Fundamentally, all organizations are made up of teams. Teams are the primitives and building blocks of modern organizations. Goals, tasks, and even complete products are pursued and delivered by teams.
Nowadays, primarily ‚agile‘ teams. That means they follow an iterative scheme that in theory enables them to independently identify, prioritize, and produce their deliverables regularly.
In most organizations, even agile teams are organized in hierarchical departments. More often than not, these hierarchical models are overlaid by project- or ‚scaled agile‘ constructs combining multiple teams to deliver some desired result or product.
The resulting complex communication structures increase work- (starting with the number of meetings) and cognitive load as anyone working with this type of setup will confirm.
Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”, also appears to hold true. For that reason a different approach than assigning a PO and a Scrum Master, adding a few developers and linking the resulting team to a project plus a hierarchy is required to structure effective organizations.
In their book “Team Topologies” Matthew Skelton and Manuel Pais address this by introducing
4 team topologies with different purposes:
- Stream-aligned team, a team aligned to a business domain’s workflow.
- Enabling team, a specialist team that assists other teams during a transition or learning period.
- Platform team, a team that simplifies a complex technology for use by other teams.
- Complicated Subsystem team, a special team for subsystem that are too complicated to be dealt with by one of the other team topologies.
3 interaction modes for the teams:
- Collaboration, working closely together with another team
- Facilitating, helping another team to clear impediments
- X-as-a Service, consuming or providing something to another team w/minimal collaboration
plus concepts like e.g.:
- a “team first” approach and
- “organizational sensing” for continuous organization development
as building blocks for flow-oriented organizations that minimize unproductive cognitive load.
Below is the link to the “Team Topologies” site. I have added two short articles that provide a foundation and discuss the concepts in the context of product- and dev ops organizations respectively:
Link to the site with the book, intro videos, community- and working materials.
Team topology: 6 “first principles” for product leaders
Afonso Franco’s application of the Team Topologies principles to product teams
Click to view!
Lots of interesting material to keep you busy on a rainy weekend!
All the best,