Ausgangslage

Das Team, um das es hier geht, ist Teil eines sogenannten Corporate Startups. Dabei gründen etablierte, traditionell organisierte und geführte Unternehmen neue Startups, um den Herausforderungen der Digitalisierung zu begegnen. Das Corporate Startup soll das erreichen, was der Muttergesellschaft schwerfällt – die erfolgreiche Entwicklung neuer, digitaler Produkte und Geschäftsmodelle. Im Corporate Startup wird anders gearbeitet als im Konzern: agil und international. Dort finden sich häufig junge und internationale Spezialisten, welche iteratives, verteiltes und kollaboratives Arbeiten gewohnt sind. Auf der anderen Seite stehen die Mitarbeiter aus dem klassisch arbeitenden Konzern.

In der Zusammenarbeit ergeben sich zahlreiche Gelegenheiten für Missverständnisse und Konflikte. Dennoch können sich auch aus solchen Situationen erfolgreiche Teams entwickeln, wie im Folgenden beschrieben ist.

Das Corporate Startup, zu dem das von mir betreute Team gehörte, besteht zu Beginn bereits seit ca. zwei Jahren und hat 120 Beschäftigte, die auf das Hauptquartier des Konzerns in Deutschland und auf weitere Standorte in Europa verteilt sind. Das rasant wachsende Unternehmen betreibt ein digitales Medienprodukt mit mehreren Millionen aktiven Nutzern. Neben der praktischen Bewältigung seines Wachstums beschäftigen die Mitarbeiter Fragen wie Wachstum versus Gewinn und Nutzerorientierung versus Vermarktung.

Das Team

Das Team (Team Plattform), auf das sich dieser Erfahrungsbericht konzentriert, ist eines von mehreren technischen Produktentwicklungsteams. Es besteht aus Softwareentwicklern mit unterschiedlicher Spezialisierung, anderen technischen Experten und einem Product Owner. Thematisch arbeitet das Team an interner technischer Infrastruktur und Softwareanwendungen für den internen Gebrauch (Backoffice). Bezugspunkte bestehen u.a. zu den anderen Produktentwicklungsteams und der Buchhaltung, die stark durch den nicht-agilen Teil des Corporate Startups geprägt ist, der aus dem Mutterkonzern stammt.

Das andere Team

Ein anderes Team (Team Forschung) widmet sich der Erforschung von technologischen Themen im Bereich der künstlichen Intelligenz. Deren Projekte sind weitgehend unabhängig von anderen Projekten, haben jedoch langfristig allgemein erhebliche Auswirkungen, da sie das Produkt wesentlich verbessern können. Für seine Arbeit setzt Team Forschung auf der vom Team Plattform verantworteten Infrastruktur auf. Weitere Berührungspunkte bestehen initial nicht. Der Product Owner bereitet die Anforderungen vor, priorisiert und gibt sie ins Team Plattform. Das Team entscheidet im Sprint Planning, ausgehend von der Priorität und in Abstimmung mit dem Product Owner, was es in einen Sprint nimmt und bearbeitet. Am Ende des Sprints wird der Status der Anforderungen im Sprint Review besprochen.

Sprint Retrospektiven sind eine etablierte Praxis in allen Teams des Corporate Startups. Dort wird die Zusammenarbeit im vorangegangenen Sprint besprochen und Verbesserungsmaßnahmen abgestimmt. Aussagefähige, qualitative Sprintziele gibt es nicht. Stattdessen setzt sich das Sprint Backlog aus den vom Product Owner eingeplanten, mehr oder weniger zusammenhanglosen Tickets zusammen. Bei den Tickets handelt es sich entweder um Teilaufgaben eines größeren Features, von internen Stakeholdern angefragte Anpassungen oder Bugfixes. Nach meiner Erfahrung ist diese Auslegung von Scrum, bei der ein Team mit Tickets "gefüttert wird", sehr verbreitet. Diese Umsetzung widerspricht der Grundidee von Scrum, gemeinsam und iterativ Ziele zu verfolgen. Dies ist den Handelnden in der Regel jedoch nicht bewusst.

Das Team Forschung arbeitet ohne formal definierten Prozess. Es ist weitgehend sich selbst überlassen und fällt effektiv durch das organisatorische Raster. Zwar kann das Team vergleichsweise selbstorganisiert arbeiten. Es fehlt ihm jedoch die Verbindung zum Unternehmen und seiner Strategie. Niemand hinterfragt, ob die bearbeiteten Themen Nutzen für das Unternehmen stiften, und wie es mit dem Fortschritt aussieht. Aus meiner Sicht ist das Einfordern von Leistung und die Verknüpfung mit einem übergeordneten Sinn wesentlich, damit ein Team fokussiert an der Zielerreichung arbeitet und sich nicht in nebensächlichen Details verliert.

Es gibt einen Agile Coach im Unternehmen, der die Teams unterstützt. Kurz vor dem hier beschriebenen Zeitpunkt habe ich diese Rolle übernommen und später begleite ich ein anderes Team (Team Forschung) einen Teil ihrer gemeinsamen Reise. Kein Team hat einen festen Scrum Master. Diese Vorgehensweise ist aus meiner Sicht nicht ungewöhnlich in einem Umfeld, in dem vergleichsweise viel Erfahrung mit agiler Arbeit vorhanden ist. Bei Bedarf übernehmen Agile Coaches Aufgaben der Scrum Master Rolle.

Führung und Selbstorganisation

Die disziplinarische Führung erfolgt durch People Manager, die selbst als Softwareentwickler in den Teams mitarbeiten. Ein Chief Technology Officer (CTO) leitet den Bereich Technology und gibt die technologischen Leitlinen vor. Der Chief Product Officer (CPO) führt die Product Owner und gehört zur erweiterten Geschäftsführung. Ebenso entscheidet dieser über die Product-Roadmap und hat auch die disziplinarische Führung der Product Owner inne.

Selbstorganisation

Heutzutage wird Selbstorganisation gerne mit Selbstführung gleichgesetzt. Ursprünglich bezieht sich das Konzept Selbstorganisation im Kontext agiler Softwareentwicklung darauf, dass es crossfunktionale Teams sind, die innerhalb eines gesetzten Rahmens gemeinsam Verantwortung übernehmen; insbesondere dafür, wieviel Arbeit sie annehmen (Pull-Prinzip) und wie die die Aufgaben lösen ("How"). Die Frage, was bearbeitet wird ("What"), entscheidet der Product Owner unter Beteiligung des Teams und aufgrund von Vorgaben (des Managements). Fragen der Strategie ("Why") werden auf vielfältige Weise entschieden.

Weit verbreitet ist, dass das Top Management die Strategie vorgibt, nach Beratung mit dem mittleren Management. Daneben gibt es diverse partizipative Ansätze unterschiedlichster Ausprägung. Eine andere Form der Mitgestaltung wäre zum Beispiel das Holocracy Modell zur Organisation. Hierbei wird die hierarchische Organisation vollständig aufgegeben und durch ein System von Kreisen ersetzt, die jeweils einen festgelegten Zweck haben und wo jeder Mitarbeiter die Möglichkeit hat, mitzuarbeiten. Ein Mittelweg ist die gemeinsame Erarbeitung der Strategie in Form von Workshops – je nach Größe der Organisation mit allen Mitarbeitern oder mit Delegierten.

In den meisten Unternehmen, gerade auch denen mit langjähriger agiler Erfahrung, beschränkt sich das Thema Agilität auf die Softwareentwicklung und ist in eine mehr oder wenige traditionelle Organisation und Führung eingebettet.

Die Frage nach dem Gestaltungsspielraum eines agilen Teams gehört zu den zentralen Arbeitsbereichen eines Agile Coaches. Damit agile Arbeitsweisen ihr Potential entfalten können, ist es wesentlich, die Möglichkeit zur Gestaltung zu dezentralisieren. Gleichzeitig darf die Organisation damit nicht überfordert werden, um ein Scheitern der Veränderung zu verhindern.

Meine Arbeitsweise als Agile Coach