In a customer session yesterday there was a misunderstanding about "long-lived teams". People felt that the need to keep teams around long-term was a high bar preventing swarming and discovery.
"Long-lived teams" is instead of short-lived teams (2 weeks, 3 months, etc.) that ignore the "superpowers" of well-functioning teams.
Keep the teams together after they have developed a good working pattern, then bring work to that team.
"You mean each value stream should have its own legal/sales/HR... activities not reused across value streams? "
Yes, this is exactly what some organizations do: core business capabilities aligned to and focused on specific value streams or business areas.
The entire of Team Topologies is about thinking where certain capabilities should best sit and the extent to which - and context in which - some capabilities might be reused when we need to go quickly.
I am starting to explore words/phrases other than "ownership" to convey a sense of "looking after a thing in a healthy way":
custodian / custodianship
curator / curation
caretaker / caretaking
This is in the context of long-lived software-enriched services (online IT/software services, legal services, accounting services, HR services, etc.) and emphasizing the need for long-term care, not short-term "throw the feature over the fence".
I personally am moving towards the use of "flow platform" when I talk about TT platforms because "flow platform" captures like 90% of the spirit of what we mean by "platform" and avoids most of the other meanings (technology, marketplace, etc).
It feels that stream-aligned teams and the fluid teams is a big conflict? And I'm wondering what kind of tradeoffs you've found when working with one or the other?
For example, how do devs build deep domain expertise in fluid teams?
Or if you do TeamToplogies, does it always mean that you might need to rework your architecture so teams can work on value and not just on individual components?
📢 I have decided to make the core operation of Team Topologies non-profit. TT authors Manuel Pais and I are committed to the core mission : "...to make work more humane and more effective for everyone ..." and means I will not be able to profit personally from core TT activities. 💵🚫
More details over the coming weeks as changes happen...
Ever wondered when/how to effectively move a task/responsibility outside the team? To a Global/shared Function, a Subject Matter Expert, an external contractor, an Agency, a Team Topologies’ Platform team or a Complicated subsystem team.
🧠 Big mindset change for fast flow: don't PUSH synchronous changes through the system; instead, PULL changes asynchronously working backwards from outcomes.
"The authors also show that the individual productivity improvements stagnate with increasing group size - in other words, above a specific team size (and it is rather small, approx. 10-15 people) almost no additional productivity gains can be observed."
Gentle reminder. There is no Team Topologies certification program. No 2-day quick course, no special letters after your name for your CV, no certification circus. 🚫🤡
Instead, we are cultivating an ecosystem of informed practitioners. This is less "monetizable" but ultimately more valuable to all. 🌱
Who in Denmark is the premier torchbearer in the intersection of #Architecture, #Agile, team dynamics, optimizing for flow #TeamTopologies, domain driven design #DDD, systems thinking, and all the other sociotechnical challenges in and around IT?
I've got exciting news! 🤩 I’m developing an online course on "Effectively Manage Team Cognitive Load." Targeted at managers, senior managers, executives, agile coaches, and software architects. Or anyone responsible to shape org structures, processes or software.
Das #unFIX-Modell von Jurgen Appelo erfreut sich aktuell einer wachsenden Beliebtheit.
Allerdings hat es (gerade auf Ebene der #Teamtypen) einige gravierende Probleme und blinde Flecken, die es vollkommen nutzlos machen, um wirklich gute Entscheidungen für Dein Organisationsdesign zu treffen.
In meinem neusten Blogartikel nutze ich die #TeamTopologies von @matthewskelton, um die Probleme der Pattern Library aufzuzeigen.
From an upcoming talk: "Architecture for fast flow resembles an ecosystem of loosely-coupled independently-viable services with clear boundaries and ownership aligned to the flow of business value."