Im digitalen Wandel neigen Organisationen zu impulsivem Aktionismus: irgendwie agil, irgendwas mit Cloud, IoT oder ganz bestimmt Blockchain. Der digitale Wandel lässt sich mit einer Symptomkur nicht bewältigen. Die veränderten Anforderungen an die Organisation und wie sie ihr Geschäft betreibt, erfordern eine umfassende Anpassung. Wie jede Änderung beginnt und endet auch diese bei den Menschen. Es braucht ein Mehr an Kooperation, Innovation und Flexibilität.
Diese Attribute werden oft Startups zugeschrieben, daher sehen wir Bewegungen wie Lean Startup und Ausgliederungen wie Digital Labs. Doch diese Lösungen haben auch Nachteile: Eine Ausgliederung muss wieder eingegliedert werden, die Herausforderungen des Wandels sind hier nur aufgeschoben. Eine Methode wie Lean Startup kann die Organisation überfordern oder zu falsch verstandenen Fehlimplementierungen führen.
Ein guter Mittelweg kann die Orientierung auf produktorientierte Teams sein. Ich persönlich nenne diese gern Digital Squads, um sie vom Team-Begriff klassischer Semantik abzugrenzen. Was ist denn anders, mag sich nun der geneigte Leser fragen. Notwendige Merkmale eines solchen Digital Squads für mich sind Autonomie, Interdisziplinarität, produktorientierte Vorgehensweise und komplette Verantwortung für den Erfolg des Produkts.
Ich möchte hier diese vier Aspekte im Einzelnen beleuchten. Doch Achtung! Alle vier interagieren mehr oder minder miteinander.
Produktorientierung
Was bedeutet es eigentlich, produktorientiert vorzugehen? Und was ist der Unterschied zu anderem Vorgehen? Zunächst ist es als Denkweise gemeint, auch wenn man nicht unbedingt ein Produkt entwickelt. Mit dieser Denkweise ist es verbunden, das Problem zu erkennen, das es zu lösen gilt, und es auf eine Weise zu lösen, die den Betroffenen des Problems so hilft, dass sie dafür (theoretisch) zahlen würden. Das steht im krassen Kontrast zu traditionellen Entwicklungsteams oder Abteilungen, die oftmals kaum mehr als eine Liste von Anforderungen abarbeiten. Ein Produktteam beginnt schon deutlich vorher. Es identifiziert das Problem, recherchiert den Markt, den potentiellen Nutzer und mögliche Lösungsansätze. Daraus generiert es die Anforderungen, wenn es das als hilfreich erachtet, entwickelt die Lösungen und validiert deren Effekt und Erfolg. Ja, die Entwicklung beginnt nicht mit den Anforderungen, und es endet auch nicht mit dem Rollout. Was uns zum nächsten Aspekt führt.
Verantwortung für den Erfolg des Produkts
Um die Innovationskraft kleiner, beweglicher Teams zu entfalten, muss man diesen den nötigen Raum, eine Richtung und einen Satz von Rahmenbedingungen geben. Die Verantwortung für den Gesamterfolg des Produkts ist ein wichtiges Mittel hierfür. Es ist ein ähnlicher Ansatz wie die Collective Code Ownership in agiler Entwicklung, doch viel weitreichender. Es versetzt das Team in den Startup-Modus, in dem jeder das Notwendige für den Erfolg tut. Alle sitzen im selben Boot und müssen am selben Strang ziehen. Damit die Verantwortung für den Erfolg des Produktes ein Antrieb und keine Belastung ist, muss der Erfolg entsprechend greifbar und begreifbar sein. Das heißt, es braucht konkrete Metriken und realistische Ziele sowie Grenzen in Budget, Zeit oder anderen Ressourcen. Dies gibt dem Team die Möglichkeit, seinen Fortschritt zu kontrollieren und Entscheidungen aufgrund von Daten zu treffen.
Interdisziplinarität
Damit das Team diese Verantwortung tragen und den Erfolg erreichen kann, braucht es auch alle dazu nötigen Rollen und Fähigkeiten. Nicht nur Entwickler und Ingenieure, nicht nur Designer und Tester, nicht nur Operations und Business Analysten. Auch Customer Care und Marketing, Vertrieb und vielleicht sogar Einkauf und weitere Funktionen werden mitunter in dem Team benötigt. Das klingt nun gerade heftig überfrachtet, doch die Dosis macht die Medizin. Nicht jede Funktion muss in gleicher Stärke und Verfügbarkeit im Team sein. Wichtig ist, dass es Teil des Teams ist, wenn es benötigt wird. Teilzeitkräfte, coachend Agierende oder auf Auftragsbasis arbeitende Funktionen sind okay, solange sie ausreichend verfügbar und eng-genug am Produkt sind, sowie denselben Zielen verpflichtet sind und deren Erfolg am Erfolg des Teams gemessen wird. Wenn man die passende Balance findet, dann stärkt man damit die Autonomie.
Autonomie
Ein Faktor, der Startups so innovativ macht, ist deren Unabhängigkeit. Sie spielen auf grünem Feld, manchmal sogar auf unbekanntem Terrain. Sie sind auf sich selbst angewiesen, und können bzw. müssen jede Entscheidung selbst treffen. Auch ein Digital Squad braucht einen hohen Grad an Autonomie. Damit ist jedoch nicht gemeint, dass das Team machen kann, was es will. Es kann Rahmenbedingungen geben, die Entscheidungsmöglichkeiten einschränken. Doch diese Rahmenbedingungen sind klar und deutlich festgelegt. Die Autonomie ist viel mehr zu verstehen als Unabhängigkeit von Dritten, wenn es um produktrelevante Entscheidungen geht. Das Team muss keine Freigaben einholen, muss nicht warten, dass irgendwer irgendwas woanders implementiert. Die vorhandenen teamexternen Abhängigkeiten blockieren das Team nicht. Das erreicht man durch eine Kombination aus Reduktion der Abhängigkeiten, Möglichkeiten organisatorische Regelungen zu umgehen, und das Mandat für das Team, als budgetrelevanter Auftraggeber aufzutreten. Das letztere erlaubt es den Squads, in die Organisation aber auch zueinander wie auf dem freien Markt mit klaren Kontrakten zu arbeiten und die Risiken der Abhängigkeiten handhabbar zu machen. Die bedeutet für die umgebende Organisation, dass der Erfolg des Squads intern über „das übliche“ Vorgehen gestellt wird.
Gradueller Prozess
Dieser Ansatz der autonomen, interdisziplinären, produktorientierten Teams kann graduell eingeführt werden, indem es diesen Teams erlaubt wird, von vornherein außerhalb der Organisation zu denken und erst im zweiten oder dritten Schritt zurück in die Organisation zu integrieren. Die neuen Anforderungen, die diese Teams dann in die Organisation tragen, erheben sie nicht schlagartig. Durch das Beobachten der Squads kann man schon früh erkennen, was benötigt wird und die Organisationsstrukturen darauf vorbereiten und anpassen. Mit jedem weiteren Team werden diese Anforderungen diverser, aber die Kurve des Anpassungsdrucks ist kontrollierbar und flacher. Wichtig für das höhere Management ist jedoch, diesen Prozess trotzdem nicht zu unterschätzen. Einerseits brauchen die Squads Champions im Management, andererseits muss auch die übrige Organisation auf diese Veränderungen neugierig und bereit dafür gemacht werden.
Zum Titelbild: Der erste motorisierte, bemannte und gesteuerte Flug der Gebrüder Wright war ein Durchbruch, der unsere Welt für immer veränderte. Und er war das Resultat einer bemerkenswerten Teamleistung.
Schöner Artikel. Erinnert ein bisschen an das Spotify-Modell: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ bzw. https://spotifylabscom.files.wordpress.com/2014/03/spotify-engineering-culture-part1.jpeg
Joa, zumindest der erste Teil vom ersten Teil. Allerdings kann ich nicht empfehlen den kompletten Weg zu beschreiten, der in dem Artikel da gezeigt wird. Nicht mal Spotify selbst ist ihn wirklich gegangen -> https://www.jeremiahlee.com/posts/failed-squad-goals/
Das ideal des Autonomen Teams ist allerdings auch keine Erfindung von Spotify. Studien zu dem Thema sind schin deutlich älter, auch Methoden wie Toyota Produktionssystem (TPS) fördert Autonomie und Beteiligung am Gesammterfolg.