Produktorientierte Entwicklung: Pflicht, aber kein Allheilmittel

Bei Capgemini veranstalten wir jedes Jahr ein Kundenforum Architektur, bei dem wir zusammen mit den Architekten unserer Kunden über aktuelle Themen in der IT und deren Auswirkungen auf die Architektur diskutieren. Hierbei zieht sich das Thema Agilität und Produktorientierung wie ein roter Faden durch die Veranstaltungen der letzten Jahre. Während vor einigen Jahren erst die Herausforderungen der Transformation von einer Projektorganisation zu einer Produktorientierung diskutiert wurde, standen beim jüngsten Forum Ende 2021 vor allem neue Herausforderungen durch die Produktorientierung im Mittelpunkt der Vorträge und Diskussionen.

Die agile Produkt-Organisation

Im Rahmen der Digitalisierung sind Unternehmen gefordert sich möglichst schnell anpassen zu können. Dies trieb die traditionelle, funktionale Organisation an ihre Grenzen. Die produktorientierte Organisation mit autarken, cross-funktionalen Teams wurde geschaffen. Diese Produktteams können selbständig entscheiden und schnell agieren, um sich an geänderte Marktanforderungen anzupassen oder neue Chancen zu erschließen.

Für die Enterprise Architektur bedeutet dies insbesondere die Abkehr von konservativen Methoden mit Vorgaben und Regeln für jede Anwendung. Stattdessen versucht man vielmehr einen losen Rahmen zu schaffen und die Teams dazu zu befähigen, sich in der Anwendungslandschaft mit ihren Produkten erfolgreich integrieren zu können.

Produktübergreifende Anforderungen

Doch mit der Produktorientierung bilden sich rund um die Produkte und Teams neue Silos, die es erschweren produktübergreifende Anforderungen umzusetzen. Anforderungen, die mehrere Produkte betreffen, müssen nun koordiniert, abgestimmt und übergreifend priorisiert werden. Dies gelingt bei einer Produktorganisation nicht immer. Bei solchen Anforderungen können sich Teams häufig nicht mit diesen übergreifenden Themen identifizieren und übernehmen nur zögerlich dafür Verantwortung. Es fehlt darüber hinaus die Transparenz in der Umsetzung und später im Betrieb. Änderungen an übergreifenden Prozessen sind dann nicht so schnell umsetzbar wie gewünscht, erzeugen aber Konflikte in der Priorisierung der Produktteams. Konfliktpotenzial gibt es vor allem in zwei Bereichen:

• Austausch zwischen den Teams: Jedes Team hat große Freiheiten – von der Wahl des Vorgehensmodells bis hin zur Architektur und des Technologiestacks. Diese Flexibilität schafft Best-of-Breed Lösungen und erhöht die Motivation für ein höhere Verantwortungsübernahme durch die Teams. Auf der anderen Seite kann sie den Wissensaustauch hemmen und zu „Inselinnovationen“ führen. Erfahrungen und Lösungsansätze aus einem Team können nicht einfach auf ein anderes Team übertragen werden. Teilweise führt dies sogar zu redundanten unterschiedlichen Lösungen für dasselbe Problem.
• Teamzuordnungen: Die Bildung der Produkt-Teams richtet sich idealerweise an den fachlichen Domänen aus. Dabei kann die Anzahl von Anforderungen und Änderungen innerhalb einer Domäne und im zeitlichen Verlauf stark variieren. Dies kann zu Kapazitätsengpässen auf der einen Seite und Überkapazitäten auf der anderen Seite führen. Dadurch werden Teamrotationen und temporäre Unterstützung aus anderen Teams notwendig. Dies wird aber durch die unterschiedlichen Teamkulturen erschwert.

Lösungsansätze: Neue Teamstrukturen schaffen

Eine mögliche Ursache und damit ein Lösungsansatz ist der Schnitt der Produktteams. Idealerweise sollten die Produkte untereinander möglichst wenig abhängig sein, um wirklich autark weiterentwickelt werden zu können. Diesen Schnitt zu finden, ist jedoch alles andere als leicht. Einfach die aktuelle Organisationsstruktur zu übernehmen, könnte hier schon der falsche Ansatz sein. Durch Anwendung des sogenannten Inverse Conway Manövers kann stattdessen eine Struktur forciert werden, welche die Kommunikation und Abhängigkeiten zwischen den Teams optimiert. Nach dem Prinzip des Inverse Conway Manövers wird die Struktur von Team und Organisation so weiterentwickelt, dass sie die gewünschte Anwendungsarchitektur unterstützt. Die Organisation folgt dann im Anschluss dieser neuen Struktur. Produktübergreifende Anforderungen können damit minimiert, allerdings wahrscheinlich nie eliminiert werden.

Die Teamstruktur anzupassen ist aber alles andere als leicht, gerade wenn in größeren Organisationen schon eine Vielzahl von autonomen Teams entstanden sind. In einem solchen Kontext mag die optimale Struktur ohnehin nie gefunden werden und sich durch geänderte Marktbedingungen und Prozesse zudem noch ändern. Daher muss die Produktorientierung durch andere Strukturen ergänzt werden, welche die oben genannten Herausforderungen adressiert. Bei dem bekannten Spotify-Modell wird der Wissensaustausch z.B. über Gilden erleichtert und übergreifende Anforderungen durch dedizierte Stämme (Tribes) umgesetzt. Dies muss allerdings in jeder Organisation so ausgeprägt sein, dass es zu der Kultur des Unternehmens passt. Gleichzeitig schaffen diese zusätzlichen Strukturen aber auch zusätzlichen Abstimmungsbedarf und weniger klare Priorisierungen.

Die Diskussionen auf den Kundenforen Architektur der letzten Jahre haben gezeigt, dass die agile, produktorientierte Entwicklung weiter auf dem Vormarsch ist und sich bei immer mehr Kunden etabliert hat. Nun gilt es als nächsten Schritt die neuen Herausforderungen zu meistern.

Welche Bedeutung hat Produktorientierung in Ihrem Unternehmen? Haben Sie sich schon auf die Reise gemacht und stehen vor ähnlichen Herausforderungen? Oder haben Sie andere Erfahrungen gesammelt? Ich bin gespannt auf Ihre Meinung zu dem Thema, diskutieren Sie mit mir auf LinkedIn.

Mehr zu diesem Thema gibt es auch hier:

Agile IT? Nicht ohne die passende Organisationsstruktur!

Die Corona-Krise – Eine Chance für Architekten und die Digitalisierung?

Vier Praxisbeispiele für agiles Enterprise Architecture Management