Aller Abschied fällt schwer. Was im Privaten nach einem schönen Wochenende mit Freund:innen gilt, gilt auch im Beruflichen, z.B. wenn ein Team die Entwicklung eines liebgewonnenen Softwareprodukts an ein anderes übergibt. Es gibt viele triftige Gründe für Software-Transitionen; im Wesentlichen sind hier zwei gegenläufige Trends zu beobachten: In- und Outsourcing.

Zu den Hauptgründen für das Outsourcing zählen der Wunsch nach einer Kostenersparnis, gefolgt von der Möglichkeit, auf einen größeren Talentpool zuzugreifen. Darüber hinaus ist auch die Auslagerung von eher reiferen Produkten eine beliebte Strategie, um mit der dadurch gewonnenen Kapazität neue innovative Produkte zu entwickeln.

Ein eher neues Phänomen ist das Insourcing von Softwareprodukten. Dahinter steckt die Erkenntnis, dass Software nicht mehr nur ein Nice-to-have oder Mittel zur Effizienzsteigerung ist, sondern im Kern der Wertschöpfung eines Unternehmens liegt. So ist es sinnvoll, diese zentrale Aufgabe nicht externen Dienstleistern zu überlassen, sondern sich selbst darum zu kümmern.

Auch wenn es keine aktuellen, systematisch erfassten und ausgewerteten Studien zu erfolgreichen und gescheiterten Transitionen gibt, so hört man doch immer wieder in Gesprächen mit Manager:innen, dass Transitionen nicht rund laufen. Im schlimmsten Fall muss eine Software-Übergabe sogar wieder rückgängig gemacht werden. Dies führt zu massiven finanziellen und organisatorischen Problemen – die Mitarbeitenden des abgebenden Teams sitzen schließlich nicht herum und warten darauf, dass ihr Produkt zu ihnen zurückkommt.

In diesem Artikel gehe ich auf die Ursachen von gescheiterten Transitionen ein und stelle einen alternativen Ansatz vor, den ich bereits in mehreren Transitionen erfolgreich angewendet habe. Dieser greift Ideen und Prinzipien der agilen Software-Entwicklung auf und überträgt sie auf Transitionsvorhaben. Im Kern geht es darum, iterativ durch enge Zusammenarbeit echtes Können und das Gefühl von Verantwortung im neuen Team aufzubauen. Dabei liegt die Steuerung der Transition bei dem übernehmenden Team selbst, inklusive der Zeitachse. Der Artikel richtet sich an Manager:innen, die Software-Transitionen verantworten und ein entsprechendes Umfeld gestalten wollen.

Ich habe vor allem als Projektmanager in den letzten 15 Jahren mehrere Transitionen von Softwareprojekten nach Indien, Polen und Portugal betreut. Bei der hier vorgestellten Transition durfte ich zwei Produktteams bei Futurice als Agile Coach unterstützen.

Ursachen für gescheiterte Software-Transitionen

Es lassen sich im Kern drei Ursachen für gescheiterte Transitionen identifizieren:

1. Mangelnder Fokus auf Ownership

In allen agilen Frameworks finden wir die Idee von Ownership. Hierunter wird die Philosophie verstanden, dass ein cross-funktionales Team die gesamte Verantwortung für sein Produkt übernimmt. In Abgrenzung hierzu, verantworten Teams in einer tayloristisch geprägten Produktentwicklung immer nur genau ihr Gewerk (Design, Code, Test usw.). Eine übergeordnete Instanz – üblicherweise ein:e Projektmanager:in – trägt die Verantwortung dafür, dass sich das "Stückwerk" der einzelnen Gewerke nachher zu einem großen Ganzen zusammenfügt.

Auch bei Software-Transitionen wird das Produkt oft in einzelne Gewerke aufgeteilt und Schritt für Schritt entlang dieser Gewerke übergeben. Ein Beispiel: Eine individuell entwickelte Enterprise-Applikation für einen Zertifizierungsprozess sollte von einem europäischen Team an ein indisches Team übergeben werden. Ziel dieses Outsourcings war es vorrangig, Kosten zu senken. Die Entwicklung der Applikation wurde in die Bereiche "Fachliches Design" und "Technische Entwicklung" aufgeteilt – mit klar zugeschnittenen Verantwortungen für die jeweiligen Gewerke. Im ersten Schritt übernahm das neue Team nur die Verantwortung für die technische Entwicklung. Das abgebende Team war weiterhin für das fachliche Design zuständig. Die dadurch entstehenden Probleme sind aus dem Wasserfallmodell bereits bestens bekannt: zu lange Durchlaufzeiten, technisch schwer umzusetzende fachliche Anforderungen und Missverständnisse in der Kommunikation zwischen den beiden Teams. Das war insbesondere deshalb fatal, weil die initial erhofften Einsparungspotenziale nicht erreicht werden konnten. Im Gegenteil, die Entwicklung wurde langsamer und teurer.

Eine andere gängige Variante bei Software-Transitionen ist die Einsetzung eines:einer Proxy-Product-Owner:in (im Folgenden: Proxy-PO). Hierbei verbleibt die Person mit der "richtigen" Product-Owner-Rolle im abgebenden Team, während im neuen Team nur ein:e Proxy-PO sitzt. Diese Person übernimmt im Wesentlichen die Anforderungen des:der Product Owner:in und reicht sie an das neue Team weiter. Konkret bedeutet das: Es findet kaum noch eine direkte Kommunikation zwischen Product Owner:in und Team statt, sondern nur noch über den Umweg des:der Proxy-PO. Das erinnert nicht nur an das Spiel Stille Post, mit all den damit verknüpften Effekten, sondern schränkt auch den Handlungsspielraum des Teams ein. Das Team wird dadurch zu einer Feature-Factory degradiert, die nur noch genau das liefert, was ihr in das Backlog geschrieben wird, aber darüber hinaus keine echte Verantwortung für den Erfolg ihres Produkts übernimmt.