Dieser Artikel ist ein Beitrag zur Blogparade “Achtung. Zukunft. – 8. PM Camp Berlin Online”. Die Blogparade begleitet das PM Camp, eine Unkonferenz rund um Projektmanagement im weitesten Sinne, die am 11. und 12. September 2020 online stattfindet. 

In diesem Beitrag schlage ich einen Bogen von der Vergangenheit von “Agilität” zu ihrer Zukunft. Ich möchte meine Beobachtung teilen, wie Agilität sich verändert im Kontext dessen, was agile Produktentwicklung heute leisten muss.

Die erste Phase der Agilität 

Die Methoden und Ansätze, die mit dem agilen Manifest und Vorgehensmodellen wie Scrum vor rund 20 Jahren eingeführt worden sind, möchte ich als “erste Phase der Agilität” bezeichnen. Was hat damals diesen Ansätzen den Weg geebnet? 

Der Ausgangspunkt war die Erkenntnis, dass unsere Welt komplex geworden ist. Im geschäftlichen Kontext bedeutet Komplexität ein dynamisches Marktumfeld. Dadurch werden Entwicklungen der Zukunft unvorhersehbar und klassische Planung weitgehend wertlos. Um mit dieser Unsicherheit und Unplanbarkeit umgehen zu können, müssen wir schnell iterieren können, d. h. Dinge ausprobieren, daraus lernen, unser Vorgehen neu ausrichten und den nächsten Schritt ausprobieren. 

Weder mit der monolithischen Softwaretechnik noch mit den monolithischen Organisationsformen der Vergangenheit war dies möglich. Beide waren nur sehr langsam änderbar und wenig flexibel. Daher betont die erste Phase der Agilität vor allem ein Prinzip: Das Herunterbrechen und Teilen in kleine Einheiten, die ein Lernen und Anpassen erlauben – und zwar in der Technologie wie in der Organisation.

Die erste Phase der Agilität lässt sich folgendermaßen charakterisieren: 

• Ein Product Owner verantwortet “sein” Produkt und „verwaltet“ das Backlog.
• Das Umsetzungsteam erhält von diesem Anforderungen als fertig formulierte User Stories, setzt diese um und liefert die Story dann “zur Abnahme” wieder ab.
• Typische KPIs sind Velocity oder Cycle Times. Die Teamleistung wird auf Durchsatz (Output) optimiert.
• Das Herunterbrechen in kleine Einheiten und deren Autonomie ist ein Kernprinzip: 
  • Organisationen werden in kleine Einheiten zerlegt, die so unabhängig wie möglich in ihrem Zuständigkeitsbereich experimentieren und entwickeln können. Das Bild der “Schnellboote” im Unterschiede zu den schwerfälligen “Tankern” verdeutlicht diesen Ansatz.
  • Product Owner kümmern sich um ihr – möglichst unabhängiges und tendenziell kleines – Produkt und verstehen dieses perfekt.
  • Um dieses unabhängige Agieren technisch zu ermöglichen, werden die vorherigen Software-Monolithen zerlegt in Microservices, die weitgehend unabhängig von umliegenden Services angepasst werden können.

Was fehlt?

Nun hat die erste Phase der Agilität enorme Fortschritte in der digitalen Produktentwicklung gebracht. Dennoch hat sie auch einige Nachteile: 

Am schwersten wiegt für mich dabei die Produktsicht: Der möglichst unabhängige Verantwortungsbereich von Product Ownern und Teams hat einen folgenschweren Effekt: In der ersten Phase der Agilität denken wir nicht groß, wir optimieren im Kleinen. Im eigenen Verantwortungsbereich lokal optimieren anstatt global zu innovieren ist der gängige Modus. Eine an der ersten Phase der Agilität orientierte Unternehmung verlernt womöglich als Organisation die Fähigkeit der internen Kooperation. Die einzelnen Einheiten sollen ja möglichst autonom agieren. 

Auch dezentrale Microservice-Architekturen haben Nachteile, so etwa die unter Umständen sehr teure Redundanz von Daten, die sich aus dem Prinzip des “Shared Nothing” ergibt (benötigt ein Service Daten, so soll er diese lokal vorhalten und nicht von einem anderen Service abhängen). 

In der ersten Phase der Agilität denken wir nicht groß, wir optimieren im Kleinen.

Die erste Phase der Agilität bleibt Antworten schuldig, wenn es um digitale Produktentwicklung mit vielen Teams geht. Vielleicht sollte sie aber auch gar keine Antwort auf diese Fragen liefern, sondern sich eben nur um die Softwareentwicklung in einem einzelnen Team kümmern. Unter anderem dieses Defizit hat Frameworks wie LeSS oder SAFe hervorgebracht. 

Was braucht moderne Produktentwicklung?

Unabhängig davon, was die erste Phase der Agilität erreichen wollte, fehlt eine Perspektive. Welche das ist, wird deutlich, wenn man die obige Argumentationskette für die erste Phase der Agilität durch die folgende ersetzt:

In einem dynamischen Marktumfeld bin ich nicht erfolgreich, weil ich im Kleinen optimiere. Ich bin erfolgreich, wenn ich echte Innovationen im Markt einführe. Tue ich das nicht, machen mich die Innovationen der Wettbewerber unter Umständen überflüssig. Die vielzitierte “Disruption” lässt grüßen. Wir müssen also größer denken und handeln. Wie kann das gelingen?

Die zweite Phase der Agilität

Eine notwendige Veränderung ist die vom backlog-verwaltenden Product Owner zum strategisch arbeitenden Product Manager. Agile Frameworks wie Scrum geben keine Antwort darauf, wo die Kundenanforderungen genau herkommen und wie wir die wichtigen auswählen. Product Manager müssen das beantworten und zwar aus einer übergreifenden, strategischen und kundenzentrierten Sicht. Sie müssen dafür stärker zusammenarbeiten mit User Research und UX Design um Kundenbedürfnisse zu verstehen. Sie müssen die Richtung vorgeben: Welche Kundenprobleme lösen wir heute nur schlecht oder gar nicht? Welche wollen wir lösen durch neue Features, Produkte, Geschäftsideen?

In einem dynamischen Marktumfeld bin ich nicht erfolgreich, weil ich im Kleinen optimiere. Ich bin erfolgreich, wenn ich echte Innovationen im Markt einführe.

Wenn Product Manager sich mehr um die strategische Arbeit kümmern, wer übernimmt dann die operative Backlog-Verwaltung? Eine Möglichkeit ist es sowohl Product Owner als auch Product Manager zu haben, die dann die operative bzw. die strategische Arbeit erledigen. Wo es geht, plädiere ich jedoch dafür diese Verantwortung einer anderen Rolle zu geben, deren Potenzial wie das der Product Owner bisher nicht ausgeschöpft wurde: dem Entwicklungsteam. Engineers können mehr als fertig definierte User Stories zu implementieren. Sie können die Themenverantwortung übernehmen, Ziele in Aufgabenpakete herunterbrechen, Abhängigkeiten mit Stakeholdern und Nachbar-Teams selbst klären etc. 

Bedeutet das, dass Entwicklungsteams ihre User Stories selbst schreiben sollen? Natürlich können sie das. Sie müssen am Ende sowieso verstehen, was sie umsetzen sollen und vor allem auch, wie sie das technisch machen. Und wenn sie von Anfang an Fragen mit den Kunden und Stakeholdern klären, dann können sie das auch umso leichter, wenn während der Implementierung Rückfragen zu Details nötig sind. Niemand braucht dann auf einen Product Owner/Manager zu warten um diese zu beantworten. Natürlich sollte ein Product Manager zumindest auf einer höheren Ebene (z. B. auf Ebene von Epics) ebenfalls daran mitwirken. Er muss aber nicht alles im Detail definieren, was das Entwicklungsteam evtl. sowieso besser kann.

Damit lässt sich eine zweite Phase der Agilität folgendermaßen charakterisieren:

• Product Manager identifizieren und bewerten Kundenprobleme.
• Sie erarbeiten und priorisieren Lösungen in Form von übergreifenden Features, Produkten oder Geschäftsideen. 
• Entwicklungsteams übernehmen die Umsetzungsverantwortung. 
• Typische KPIs sind Business KPIs. Die Teamleistung wird auf Impact (Outcome) optimiert.
• Die KPIs aus der ersten Phase der Agilität dienen zur Optimierung der internen Zusammenarbeit.
• Von der Autonomie zur Kooperation:
  • Die Zusammenarbeit verschiedener Entwicklungsteams ist notwendig um große Innovationen umzusetzen und muss effizient funktionieren.
  • Product Manager arbeiten an größeren Themen, über Domänen hinweg und auch mit verschiedenen Entwicklungsteams zusammen. Die Funktion des Projektmanagements wird dadurch wieder etwas wichtiger.
  • Technische Unabhängigkeit sollte möglichst erhalten bleiben. Aber eine zusätzliche Sicht auf die gesamte Systemlandschaft ermöglicht globale Optimierungen, die z. B. für das Skalieren von erfolgreichen Geschäftsmodellen nötig sind.

Fazit

Man kann den Wechsel von der ersten zur zweiten Phase der Agilität auch so zusammenfassen: Wir gehen von der Optimierung des Output zur Optimierung des Outcome oder Impact – und zwar nicht stattdessen, sondern zusätzlich: Wir brauchen auch weiterhin effiziente Teams. Aber wir brauchen auch eine effektive Gesamtorganisation. Anstatt kleine Schnellboote zu schaffen, machen wir große Tanker schnell und wendig. 

Natürlich können diese Änderungen nicht von heute auf morgen passieren. Wenn wir Rollen und Zusammenarbeitsmodelle verändern, ist das wie immer eine Kulturfrage. Die zweite Phase der Agilität braucht reife Entwicklungsteams und reife Product Manager, die jeweils mehr Verantwortung übernehmen. Das erfordert andere Kompetenzen, die nicht über Nacht da sind. Aber es sollte die Richtung sein, in die wir Mitarbeiter und Kultur entwickeln. Denn es lohnt sich – und nicht nur für die Unternehmung: Meiner Erfahrung nach führen größere Verantwortung und die Möglichkeit zu wachsen auch zu größerer Motivation und Zufriedenheit. 

Wir gehen von der Optimierung des Output zur Optimierung des Outcome.

Wenn ich persönlich noch einen Wunsch für die zweite Phase der Agilität loswerden kann, so ist es der folgende: Ich wünsche mir, dass wir mit diesem Wechsel auch wegkommen von der Methodendogmatik der ersten Phase und hin zu einer Kunden- und Ergebniszentrierung. Damit würden wir zusätzlich viel gewinnen.

Ich freue mich darauf. Wie siehst du das?