Agilität braucht Diversity

Let’s go agile! Mit diesem Wechsel des Vorgehensmodells werden unterschiedliche Hoffnungen verbunden. Zum Beispiel eine indirekte Risikominimierung durch kurze Feedback-Zyklen, mehr Innovation für Anwendende und ein besseres sowie produktiveres Arbeitsklima. Damit diese Transition gelingt, braucht es ein anderes Mindset und mehr Entscheidungsgewalt für die Teammitglieder. Diversity spielt dabei eine entscheidende Rolle, um die komplexen, sich ständig verändernden Herausforderungen bewältigen zu können. Für mich entspricht das genau dem ersten Punkt aus dem agilen Manifest: „Individuals and Interactions over Processes and Tools“. Im Folgenden möchte ich mit einem vereinfachten Modell erläutern, was damit gemeint ist und wie agile Praktiken ein diverses Team bei der Lösung komplexer Probleme unterstützen.

Resilience als Brücke zwischen Diversity und Performance

Eine agile Vorgehensweise eignet sich zur Lösung komplexer Probleme. Komplex heißt, dass die Anforderungen oder die technische Struktur zum Projektstart nicht vollständig bekannt sind. Die Vorteile der Agilität ergeben sich durch eine frühzeitige Auslieferung und Evaluation des Produkts. Agilität ist ein stetiger Lernprozess, bei dem die Erfahrungen aus den bisher ausgelieferten Versionen in eine neue Lösung einfließen.

Resilience (Widerstandsfähigkeit) nennt man die Fähigkeit, diese Herausforderungen bewältigen und sie als Anlass zur Weiterentwicklung nutzen zu können. Resilience ist wesentlich für ein agiles Team. Damit ein Team Resilience aufbauen kann, braucht es verschiedene Kompetenzen und Perspektiven (Diversity), es braucht eine sichere Umgebung (Psychological Safety) und es braucht die Ermächtigung der Teammitglieder zu Selbstbestimmung und Eigenverantwortung (Empowerment). Ein resilientes Team performt dann, indem es komplexe Probleme löst (Ambitious Goals).

So oder in einer ähnlichen Form wird das Modell auch in der Forschung zu agilen Methoden verwendet. Ich nenne es hier einfach das Resilience-Modell.

Fallbeispiel: Die Einführung von Scrum in einem Wasserfallkontext

Ich möchte ein kurzes Beispiel vorstellen, an dem sich erkennen lässt, wie die Einführung von Scrum nicht automatisch zu Agilität führt. Wir stellen uns hierfür ein fiktives Team aus Entwicklerinnen und Entwicklern vor, die bisher nach einem gegebenen Lastenheft gearbeitet haben. Der Projektleitende möchte das Vorgehensmodell auf Scrum umstellen, deshalb absolvieren alle Teammitglieder ein Scrum-Training. Ein Developer wird zum Scrum Master auserkoren. Die Rolle des Product Owners übernimmt jemand aus der Fachabteilung.

Anfangs läuft es etwas holprig, was zu erwarten war. Nach drei Monaten hat sich das Team aber wieder eingespielt und bringt erneut eine gute Performance. Gemessen wird das am prozentualen Fortschritt, verglichen mit dem ursprünglichen Lastenheft. Im Jahresgespräch fragt der Projektleiter nach, wie es gelaufen ist. Er findet heraus, dass das Team eine erfahrene Entwicklerin zum technischen Product Owner bestimmt hat. Ihre Aufgabe im Team ist es, die User Stories so in Aufgaben zu unterteilen, dass dabei möglichst wenige technische Schwierigkeiten aufkommen und wenig weitere Kommunikation geleistet werden muss. In der Sprint-Planung wird dann nur noch festgelegt, wer welche Aufgabe übernimmt und wie man bei der Umsetzung möglichst wenige Merge-Konflikte erzeugt.

Der Product Owner hat sich für die User Stories angewöhnt, das ehemalige Lastenheft zu nehmen und dieses in User Stories umzuschreiben. Der Scrum Master moderiert die Scrum-Meetings, hat ansonsten aber viel Zeit, um sich auf die Entwicklung zu konzentrieren. Bei einer Retro kam einmal die Frage auf, wann das Backlog denn vollständig abgearbeitet sein muss, woraufhin der Scrum Master aufklärte, dass es keine derartigen Deadlines mehr gäbe. Der Projektleiter ist etwas überrascht über die Umsetzung von Scrum, aber gibt sich zufrieden.

Dieses Beispiel zeigt, wie Scrum als Lösung eingeführt wurde, ohne über das eigentliche Problem nachzudenken, das zu lösen versucht wird. Vielleicht war die Motivation, dass die User bisher wenig von den Änderungen profitierten und deshalb ihr Feedback integriert werden sollte. Oder man war sich im Unklaren darüber, ob die technische Architektur überhaupt für das beschriebene System geeignet war, weshalb man funktionsfähige Zwischenversionen erstellen wollte. Oder war es einfach nur der Trend? In dem Beispiel wurde „Scrum“ eingeführt und trotzdem weiter nach dem Wasserfallmodell gearbeitet: Es existieren bereits Anforderungen in Form eines Lastenhefts, welche es möglichst effizient umzusetzen galt. Agilität ist dazu da, ein Team zu ermächtigen ein komplexes Problem zu lösen, nicht um ein Team von Zauberhand schneller oder besser zu machen. Klar kann man Scrum einsetzen, um ein Lastenheft umzusetzen, aber das richtige Werkzeug ist es nicht unbedingt.

Diversity

Das einfachste Modell für Diversity kennt zwei Kategorien, die sogenannte jobrelevante Diversity (zum Beispiel Fachwissen, Erfahrung oder Ausbildung) und die Background Diversity (beispielsweise Geschlecht, Migrationshintergrund oder Behinderungen).

Die jobrelevante Diversity ist wichtig, um vielseitiges Fachwissen zusammenzubringen. Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel. Wenn beispielsweise ein enthusiastisches Entwicklungsteam mit Vorliebe für eine bestimmte Programmiersprache ein Problem lösen möchte, dann wird die Lösung sehr wahrscheinlich ein Stück Software in dieser Programmiersprache sein – ganz unabhängig davon, ob es nicht auch andere, bessere Lösungen geben könnte. Diversity erweitert also den Raum der möglichen Lösungen. In der Situation des Fallbeispiels wäre es beispielsweise sinnvoll gewesen, einige der Stakeholder direkt ins Team einzubinden, statt ein reines Entwicklungsteam unverändert fortzuführen, damit diese ihre Perspektive einbringen und vertreten können.

Die Background Diversity spielt ebenfalls eine wichtige Rolle. Sie hat einen positiven Einfluss auf die Kommunikation und den Informationsaustausch im Team. Es ist gut erforscht, dass dadurch die Resilience des Teams allgemein gestärkt wird. Weiterhin sind diverse Hintergründe und die damit verbundenen Perspektiven ein Nährboden für neue Ideen und damit ein wichtiger Faktor für Innovation. Abgesehen von dieser utilitaristischen, praktisch orientierten Ansicht stellt Diversity auch einen Wert an sich dar.

Unter Softwarearchitektinnen und -architekten heißt es manchmal, es wäre besser, „wenn alle gleich denken“, denn dann gäbe es keine Schwierigkeiten und keine Kommunikationsprobleme. Alles sei dann viel einfacher. Hinter dieser Äußerung verbirgt sich aber immer ein „wenn alle so denken wie ich“. Doch auch in homogenen Gruppen gibt es keine Telepathie oder Hellsicht. Kommunikation ist das A und O. Der Wunsch, dass alle genauso denken oder denken sollten, wie man selbst, ist eher schädlich für agile Teams: Denn die Mehrheitsmeinung wird nicht mehr kritisch hinterfragt und andere mitunter bessere Lösungen werden gar nicht erst in Betracht gezogen. Diversity führt dagegen zu einem Aufeinandertreffen von verschiedenen Perspektiven, Ideen und Meinungen. So entstehen schon früh konstruktive Konflikte, die gelöst werden können. Homogenität dagegen schiebt mögliche Konflikte nur auf, doch irgendwann im Verlauf der Entwicklung treten diese unvermeidlichen Probleme hervor und verursachen hohe Kosten.

Psychological Safety

Um Konflikte aufzudecken und Lösungen zu finden, braucht ein Team eine Umgebung, in der alle Teammitglieder ihre Perspektive einbringen um gewachsene Strukturen hinterfragen zu können. Ein bekanntes Modell für einen solchen Safe Space ist in vier Stufen unterteilt:

1. Die Sicherheit, als Mensch akzeptiert zu werden (Inklusion),
2. die Sicherheit lernen zu können (z.B. durch Fragen oder Feedback)
3. die Sicherheit, etwas Eigenes beitragen zu dürfen und letztlich
4. die Sicherheit, den Status Quo hinterfragen und Meinung diskutieren zu können.

Das ist natürlich ein Idealbild – es sollte aber zumindest angestrebt werden, auch über das agile Arbeiten hinaus. Wenn ein Team groß genug ist, dann kann eine anonyme Umfrage eine Möglichkeit sein, um zu untersuchen, wie die psychological Safety empfunden wird und wie sie verbessert werden kann. Die psychological Safety fördert die positiven Effekte der Background Diversity und mildert eventuelle negative Effekte.

Psychological Safety unterstützt auch das Empowerment, also die Möglichkeit selbstbestimmt und selbstverantwortlich zu arbeiten und die eigenen Gestaltungsspielräume wahrnehmen, nutzen und erweitern zu können. Dazu gehört beispielsweise, dass ich als Entwickler den Fachbereich verstehen möchte, um einen Mehrwert für die Anwenderinnen und Anwender erzeugen zu können. Ich will hinzulernen und meine Kompetenzen erweitern, um den neuen Anforderungen gerecht zu werden. Ich will unabhängiger werden und mein Netzwerk vergrößern, um direkt zu kommunizieren statt über mehrere Ecken. Bezogen auf das Fallbeispiel: Die Zerteilung der User Stories in kleinteilige, technische Aufgaben verhindert, dass die Developer sich mit dem Anwendungsfall auseinandersetzen und nachvollziehen können, welchen Beitrag sie zu diesem leisten.

Agile Praktiken aus Scrum

Um es konkret zu machen, möchte ich einige Scrum-Praktiken aufgreifen und dem Resilience-Modell zuordnen. Dadurch soll deutlich werden, wie agile Methoden zur Resilience und damit zum agilen Arbeiten beitragen. Scrum bringt beispielsweise folgende Praktiken mit:

• Retrospektive: Der Rückblick auf den vergangenen Sprint, um einen Plan für Verbesserungen zu machen. Der Scrum Master schafft einen Raum, in dem offen und positiv diskutiert werden kann. Die Motivation hierbei ist genau die Psychological Safety. Deshalb gibt es auch die Vegas-Regel: „What happens in Vegas, stays in Vegas“. Was in der Retrospektive besprochen wird, das ist vertraulich und bleibt den Teilnehmenden vorbehalten.
• Daily: Tägliche, kurze Standup-Meetings sollen die Kommunikation verbessern und Schwierigkeiten sichtbar machen. Es geht hierbei besonders um Empowerment, denn durch den regelmäßigen Austausch wird ermöglicht, dass alle Teammitglieder die aktuellen Vorgänge kennen und sich gegenseitig bei auftretenden Hindernissen unterstützen können.
• Sprints und Reviews: Die iterative Weiterentwicklung und Auslieferung des Produkts ermöglicht eine direkte Evaluation von Zwischenergebnissen in den Reviews. Das ist eine Grundvoraussetzung für Resilience, da so die explizit und implizit getroffenen Annahmen geprüft werden können.
• User Story: Um aus Resilience auch eine Performance zu machen, braucht es ambitionierte Ziele. Diese werden in Form von User Stories ausgedrückt, die den Anwendenden einen Mehrwert bringen sollen. In einer User Story wird die gesamte Komplexität eines bestimmten Szenarios erfasst, nicht nur technische Einzelschritte. Dieses Prinzip, dass die User Stories den Teammitgliedern den Hintergrund des Anwendungsfalls verständlich machen, gehört auch zum Empowerment.

In der Summe decken diese agilen Praktiken alle Aspekte ab, um nach dem Resilience-Modell aus Diversity eine Performance zu generieren. Auch andere Praktiken können ergänzend hinzugenommen werden, beispielsweise Pair-Programming, um den Wissenstransfer zwischen Teammitgliedern zu verbessern. Wenn man aber Praktiken herausnimmt, wie beispielsweise Retros, dann lässt sich eine Lücke bei der Psychological Safety erkennen.

Fazit

Zusammenfassend möchte ich hervorheben, dass Diversity und Psychological Safety entscheidende Faktoren für die Team Resilience und damit für die Performance in agilen Kontexten darstellen. Agilität heißt, ständig auf neue Anforderungen zu reagieren und aus der Erfahrung zu lernen. Die psychological Safety bietet das richtige Umfeld, damit Diversity und Empowerment zu dieser Team Resilience führen. Denn erst durch die Resilience werden ambitionierte Ziele in konstruktive Konflikte verwandelt und letztlich in Lösungen überführt.

Ihr möchtet mehr über spannende Themen aus der adesso-Welt erfahren? Dann werft auch einen Blick in unsere bisher erschienenen Blog-Beiträge.