Team Topologies
Effective software teams are essential for any organization to deliver value continuously and sustainably. But how do you build the best team organization for your specific goals, culture, and needs? Team Topologies is a practical, step-by-step, adaptive model for organizational design and team interaction based on four fundamental team types and three team interaction patterns. It is a model that treats teams as the fundamental means of delivery, where team structures and communication pathways are able to evolve with technological and organizational maturity. In Team Topologies, IT consultants Matthew Skelton and Manuel Pais share secrets of successful team patterns and interactions to help readers choose and evolve the right team patterns for their organization, making sure to keep the software healthy and optimize value streams. Team Topologies is a major step forward in organizational design for software, presenting a well-defined way for teams to interact and interrelate that helps make the resulting software architecture clearer and more sustainable, turning inter-team problems into valuable signals for the self-steering organization.
Stats for nerds
24recommend
51mentions
46people
2019–2026years
53% recommend37% neutral10% critical
Mentions per year
What Hacker News says
- Trust as delegation is an interesting angle; if you’ve not read Team Topologies I’d recommend it. These topics are treated pretty well.
- This is literally the approach recommended in Team Topologies. The same team should own vN and vN+1, so that they both have to operate their own design and have the opportunity not to make the same mistakes again. It should be the default.
- "Team topologies" by Matthew Skelton might be a good read
- Similar size company and over the past 2y we transitioned from technology based teams to stream-aligned teams that include engineering, product, and design within each team. The book Team Topologies is a good reference for this and fairly quick read.
In my experience, the pros of stream-aligned teams vastly outweigh the cons. The major pros are reduced cross-team dependencies and fewer hand-offs, more ownership over work, focusing people on a narrower set of customer/business problems, and that stream-aligned teams are easier to refactor and decompose as the organization grows.
What I learned along the way is that you will still have some cross-team dependencies based on technical expertise. So you will benefit from your engineering leaders explicitly and regularly discussing these needs, then incorporating some resource sharing into their plans. For instance, you might have an engineer who really knows one area of the product or technology brought into another team's kickoffs and design reviews or even joining the other team temporarily.
- My related comments recently: https://news.ycombinator.com/item?id=37233790
To your question:
- It depends on what you mean by "Agile"
- If you want to make sense of "original Agile", read "The Agile manifesto" (2001), it's 2 short pages, we can wait for you to get back.
- Criticisms of modern "agile" are actually the same as the problems that spawned that agile movement in the first place. It has become what it reacted against.
- There are practitioners of OG Agile still around and talking / Writing. Dave Farley for one.
- The scientific method does not need to be replaced, hard no. An experimental, incremental, iterative, learning framework is the way forward. The specific rituals of Jira-based scrum, those could go and not much of value would be lost.
If you're looking for a new framework, are you familiar with the Accelerate book? How about Team Topologies ? The Goal ?
Related
Accelerate
31 recommend · 41
Peopleware
276 recommend · 637
Team of Teams
17 recommend · 25
The Five Dysfunctions of a Team
44 recommend · 66
Team Geek
11 recommend · 15
Structured Computer Organization
21 recommend · 34
Distributed Systems
14 recommend · 28
