unFIX – Kann alles und nix

Seit Anfang 2022 geistert das unFIX-Modell von Jurgen Appelo durch den digitalen und mittlerweile analogen Raum. Inzwischen schießen die Events dazu förmlich aus dem Boden, sodass man vielleicht schon von einem echten Hype sprechen könnte.

Ich konzentriere mich dabei auf die im unFIX-Modell verwendeten Teamtypen, um es mit den Team Topologies von Matthew Skelton und Manuel Pais in Kontrast setzen zu können. Das unFIX-Modell selbst ist jedoch noch viel umfangreicher und auch in den nicht hier besprochenen Bereichen existieren diverse Probleme, die ich hier bewusst ausklammern werde.

Das unFIX-Modell stellt Dir neben vielen anderen Elementen 7 verschiedene Teamtypen zur Verfügung. (Die hier allerdings Crews genannt werden.) Darunter befinden sich:

Die Mehrzahl dieser Teamtypen ist offensichtlich von den Team Topologies kopiert inspiriert worden. Einige Teamtypen sind allerdings auch hinzuerfunden worden und erweitern diese. (Namentlich Partnership & Experience Crew) Der Teamtyp Governance Crew ist ebenfalls neu, allerdings spielt er bei der Wertschöpfung keine direkte Rolle. (Weshalb ich ihn im Folgenden ausklammern werde.)

Value Stream Crews haben im unFIX-Modell die volle Verantwortung für einen (ihnen zugeordneten) Wertstrom, den sie selbstorganisiert und autonom bedienen.

Um Wert für Kunden zu stiften, gibt es deshalb auch keine Übergaben zu anderen Teams. (Weil diese Übergaben erfahrungsgemäß zu Verzögerungen und Abhängigkeiten führen.)

Damit sind Value Stream Crews vollkommen identisch mit den Stream-aligned Teams aus den Team Topologies. (Mit dem einzigen Unterschied, dass sie anders heißen.)

Der zweite Teamtyp im unFIX-Modell ist die sogenannte Facilitation Crew. Die Hauptaufgabe einer solchen Crew ist es, Value Stream Crews dabei zu unterstützen, ihre Aufgaben gut erledigen zu können. (Während sie selbst keinen eigenen Wertstrom bedient.)

Faciliation Crews erreichen das vor allem durch den Aufbau von Know-how, weshalb ihr tägliches Doing aus Facilitation und Coaching besteht.

Auch wenn auf der betreffenden Seite des unFIX-Modells Gegenteiliges behauptet wird, sind Facilitation Crews damit vollkommen identisch mit den Enabling Teams der Team Topologies.

Die Capability Crew ist ein Team, das Fähigkeiten besitzt, die sich (zumindest laut Jurgen Appelo) unmöglich in allen Value Stream Crews aufbauen lassen. Sie unterstützt deshalb Value Stream Crews mit ihrem speziellen Know-how, wenn diese alleine nicht mehr weiterkommen.

Auch die Capability Crew geht zurück auf das Complicated-Subsystem Team der Team Topologies, wurde aber (fahrlässig) verändert. Es geht hier nicht mehr darum, eine komplexe Komponente oder Themen, die Spezialwissen benötigen, aus dem Wertstrom anderer Teams herauszulösen, sondern Expertise anzubieten, wenn diese notwendig ist.

Die Platform Crew bietet Services für Value Stream Crews an, die von Letzteren “einfach genutzt” werden können.

Inhaltlich unterscheidet sich die Platform Crew im unFIX-Modell damit in keinster Weise von den Platform Teams der Team Topologies.

Auch hier wird allerdings auf der dazugehörigen Webseite wieder Gegenteiligtes behauptet. (Warum das so ist, bleibt allerdings schleierhaft, weil faktisch keinerlei Unterschiede vorhanden sind.)

Die Experience Crew des unFIX-Modells sorgt dafür, dass Kunden und Nutzer eine tolle Nutzererfahrung haben. Sie sind damit diejenigen, die sich darum kümmern, die Customer Journey als Ganzes zu optimieren.

Gleichzeitig sind die Teammitglieder der Experience Crew auch in verschiedenen Value Stream Crews und bilden sozusagen ein “querliegendes Unterteam”, dem eine Sonderaufgabe obliegt.

Vereinfacht gesagt ist die Experience Crew damit eigentlich eine Facilitation Crew mit einer fest definierten Aufgabe (Customer Journey).

Ähnlich wie die Experience Crew kümmert sich die Partnership Crew des unFIX-Modells um besondere Aufgaben. Nur sind es in diesem Fall nicht die Kunden und Nutzer, sondern Anbieter, Partner, Freelancer, Angestellte oder Gigworker.

Wenn eine Organisation also mit solchen Menschen zusammenarbeitet, sorgt die Experience Crew dafür, dass diese Menschen bestmöglich integriert und fair behandelt werden.

Auch hier gibt es in den Team Topologies keine Entsprechung für die Partnership Crew.

Zusammenfassend lassen sich die Gemeinsamkeiten und Unterschiede zwischen dem unFIX-Modell und Team Topologies deshalb wie folgt darstellen:

Auf den ersten Blick mag Dir das unFIX-Modell als praktische Hilfe erscheinen, Deine Organisation agiler aufzustellen.

Jurgen Appelo geht in seinem unFIX-Modell davon aus, dass es Skills gibt, die Du nicht in allen Value Stream Crews aufbauen kannst oder willst. Seine Lösung hierfür ist die Capability Crew, die Value Stream Crews das notwendige Know-how bei Bedarf zur Verfügung stellt. Das mag “schön aussehen”, wenn Du mit dem unFIX-Modell bunte Kärtchen auf den Tisch legst. In der Praxis ist dieses Vorgehen jedoch höchst problematisch.

Denn wenn Du nur 2 UX-Designer hast, jedoch 10 Value Stream Crews (die UX-Know-how benötigen), dann müssen diese immer auf Deine beiden UX-Designer zurückgreifen, die in der Capability Crew sind. Dieses Vorgehen führt jedoch das Konzept autonomer Value Stream Crews ad absurdum. Denn wie soll das Team autonom arbeiten, wenn ihm Know-how fehlt?

Das unFIX-Modell macht Dich jedoch gar nicht auf dieses Problem aufmerksam, sondern verschleiert es, weil Du “einfach eine Capability Crew hinzufügen” kannst.

Team Topologies hingegen macht Dich sehr wohl auf dieses Problem aufmerksam. Denn im Denkansatz von Skelton und Pais bedeutet es, dass Du das benötigte Know-how entweder mit Hilfe eines (temporären) Enabling Teams in Deinen Stream-aligned Teams aufbaust oder mit Hilfe eines Complicated-Subsystem Teams so zur Verfügung zu stellst, dass es von diesen so einfach wie möglich genutzt werden kann.

Das ist sicherlich die schwierigere und aufwändigere Lösung. Aber dafür funktioniert sie auch.

Neben dem höchst problematischem Teamtyp Capability Crew fehlt dem unFIX-Modell im Vergleich zu Team Topologies ein zentrales Element: Interaktionsformen. Mit Hilfe von Team Topologies definierst Du also nicht nur Teamtypen, sondern auch die sinnvollste Interaktionsform mit anderen Teams.

Jurgen Appelo hingegen wahr wohl nicht ganz klar, wozu diese Interaktionsformen gut sind:

I have difficulty understanding the added value of using these “modes” and I suspect most teams probably apply a combination of these. […] I’ve decided not to prioritize “interaction modes” as I don’t think this is a crucial concept for now.

Interaktionsformen sind in Team Topologies ein Mittel, um festzustellen, ob die aktuelle Teamstruktur in Deiner Organisation tatsächlich gut funktioniert oder eben nicht. So ist eine permanente, teamübergreifende Kollaboration zwischen Stream-aligned Teams im Denkansatz von Matthew Skelton und Manuel Pais beispielsweise ein starker Indikator dafür, dass etwas nicht stimmt. Etwa, weil das notwendige Know-how über mehrere Teams verteilt ist. Oder weil die Verantwortungsbereiche nicht klar genug definiert wurden.

Ein Stream-aligned Team, das ständig mit anderen Teams kollaborativ Lösungen erarbeitet bzw. erarbeiten muss, kann seinen eigenen Wertstrom offensichtlich nicht autonom bedienen.

Das unFIX-Modell hingegen hat hier einen blinden Fleck und kann Dich nicht auf problematische Interaktionsformen aufmerksam machen, weil sie gar nicht vorhanden sind.

Auch das Konzept Cognitive Load wurde im unFIX-Modell komplett ausgespart. Team Topologies hingegen nutzt es als zentrales Gestaltungselement für den Aufbau von Teamstrukturen.

Die dahinterliegende Idee ist es, Stream-aligned Teams mit ihrem Verantwortungsbereich nicht mental bzw. kognitiv zu überlasten.

Tatsächlich ist es sogar so, dass Complicated-Subsystem Teams und Platform Teams vor allem dazu dienen, den Cognitive Load für Stream-aligned Teams zu reduzieren.

Das bedeutet auch, dass Du gar keine Platform Teams oder Complicated-Subsystem Teams aufstellen solltest, wenn der Cognitive Load in den Stream-aligned Teams aktuell vollkommen in Ordnung ist.

Neben den wichtigen Interaktionsformen aus Team Topologies fehlt das Cognitive-Load-Prinzip jedoch ebenfalls im unFIX-Modell. Du hast deshalb keinerlei Entscheidungskriterium, ob ein Platform Team aktuell Sinn ergibt oder nicht.

Das Hauptproblem des unFIX-Modells ist, dass es nur eine umfangreiche Sammlung an Vorlagen und Optionen ist, die alle “irgendwie gleichberechtigt” nebeneinander stehen. So ist die Bezeichnung des Modells als Pattern Library sowohl treffend als auch gleichzeitig entlarvend:

The unFIX model is NOT a framework. The definition of “framework” suggests an essential supporting structure. But there is nothing essential in unFIX. Everything is optional. A better description would be a pattern library.

Mit unFIX kannst Du Dir daher alles, was Du willst, zusammenbauen. Die Frage ist nur: Was ist damit gewonnen? Die Antwort darauf kann schlechterdings nur lauten: Nichts.

Denn wenn Du Dir alles, was Du möchtest, zusammen- oder nachbauen kannst und alles optional ist, wobei soll es Dir dann helfen?

Was dem unFIX-Modell schlichtweg fehlt, sind klare Prinzipien und Entscheidungskriterien (wie beispielsweise Cognitive Load und Interaktionsformen), nach denen Du bewerten und erkennen kannst, ob eine Option in dieser Pattern Library für Dich und Deine Organisation aktuell sinnvoll ist oder nicht.

So gesehen hilft Dir das unFIX-Modell genauso viel weiter wie das Spotify-Modell. (Ach so, das kannst Du mit unFIX natürlich auch wunderbar nachbauen.