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.
📣 Did you know that all the free videos from the "Organizing for Independent #ValueStreams" Bundle in our Academy are available on the @TeamTopologies YouTube channel? Watch them now: https://bit.ly/3TuhbJ0
The bundle includes two self-paced video courses: "#TeamTopologies for Managers" by Matthew Skelton & Manuel Pais and "Independent Value Streams with Domain-Driven Design" by Nick Tune & Kacper Gunia.
Day 1 on Mastodon and I’ve been reblogged and followed by the co author of one of my favourite books at the moment, Team Topologies. We read it as part of a book club in my last team and it just made a whole lot of sense, highly recommend for anyone interested in building and running teams in a modern software engineering organisation - thanks @matthewskelton
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."
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.
Customer question: "In terms of the concept of fully owned systems, what's the best way to approach code repos of shared packages that are contributed to by multiple teams? "
My reply: "Great question. Some further questions to help make decisions:
Why does the code need to be shared? What's the sense of value in the sharing?
What kind of coupling does the code sharing introduce? Do we want that coupling?
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?
Are you signed-up for tomorrow’s discussion with @matthewskelton? Be sure you’ve joined the Google Group at https://dora.community for information on how to join!
This week in the DORA.community, @matthewskelton will join us for a discussion about untangling software delivery with team topologies, flow metrics, and careful decoupling.
Join the Google Group for a calendar invite and information on how to join the discussion on Thursday at 14:00 UTC.
New talk coming: 'How Team Topologies can help to shape cloud-native architectures for better business agility' [K27] Does anyone have any examples or case studies you would like me to include in the talk?
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. 🌱
Messaging apps like Slack are designed in a way to keep us hanging on every message, which means any deep thinking process is continuously disrupted. We’re kept constantly in a state of task switching or trying to repair our working memory. These apps also reinforce a work culture that demands immediate response at the expense of #flow.
Another way to look at messaging apps—especially ones that connect an entire large engineering org—is through the lens of #teamtopologies and Conway’s Law (cf @matthewskelton and @manuelpais ). These tools are vectors for breaking team “encapsulation” in that they encourage intensely and tightly coupled modes of interaction that actually produce badly coupled software architecture. Boy have I been seeing this happen. 😕
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).
@malcolm ... And that is exactly my point 🤓 In a Team Topologies context, a platform is NOT [just] collection of tools. The purpose of a TT platform is to increase flow and reduce extraneous cognitive load for teams using the platform.
A wiki page with a curated set of options or a checklist can act like a flow platform. No need for anyone to build any tools.
Switching focus away from tools to flow seems to help hugely.
TT does NOT claim to maximize value, but instead encourages conditions for discovery of new value, especially previously unexpected value from novel combinations of services and product interactions.
It's a fundamentally different viewpoint.
It's something akin to:
LeSS / Scrum@Scale / etc.: centralized planning 😬
TT / independent value streams: innovation via a cooperative market approach (see Haier) 🔍