11.12.2017

Agilität ist Kopfsache

Blogbeitrag von Michael Mlynarski, Christian Brandes und Peter Hartauer

Was mich nicht umbringt, macht mich stärker‟​ hat Friedrich Nietzsche in seiner Götzendämmerung‟​ gesagt. Auf das Thema Agilität übertragen bedeutet das: alle Fehler, die ich bei einem Umstieg auf agile Vorgehensweisen mache, machen mich - hoffentlich - schlauer. Aber müssen wirklich immer wieder die gleichen Fehler begangen werden? Betrachten wir dazu als Einstieg eine kleine Geschichte über ein fiktives Projekt:

Let's go agile!

Das Management einer IT-Firma hat auf einer der zahlreichen Leadership-Konferenzen das Stichwort „agil" aufgeschnappt und sieht sowohl Geschäfts-Potenzial als auch eine gewisse „Sexyness‟ darin, „agil‟ zu werden „wie alle anderen‟. Die Verheißungen klingen ja auch verlockend: höhere Produktqualität, höhere Mitarbeiterzufriedenheit, und beides bei kürzerer Time to Market! Nach mehreren Vorgesprächen mit der eigenen Mannschaft wird es dann offiziell verkündet - „wir werden agil‟! Das Management blickt erwartungsvoll in die goldene agile Zukunft, und die bestehenden Teams freuen sich, etwas neues auszuprobieren und das ominöse Scrum (oder wahlweise Kanban) zu erlernen. 

Ein erster Blick in die gängigen Scrum-Leitfäden wirkt vielversprechend: Prinzipien wie „Vertrauen‟, „Selbstorganisation‟ oder „kontinuierliches Lernen‟ klingen attraktiv (und werden natürlich längst praktiziert!). Also wird ein erstes Scrum-Team gebildet, ein Projektleiter wird zum Product Owner ernannt, ein Scrum Master wird eingekauft, und das Sprinten kann beginnen! Der Scrum Master bringt zum Glück erste praktische Erfahrungen mit und empfiehlt einen „Sprint 0‟. Klingt wunderbar, da das Team auf diese Weise viel ausprobieren und Infrastruktur sowie erste Prozesse definieren kann, ohne sofort massiven Druck zu verspüren. Irgendwann ist der Tag mit dem ersten Sprint Planning endlich gekommen und der erste Sprint startet. Die Stories werden klarer, die ersten Zeilen Code entstehen und die ersten User Acceptance Tests stehen an. Aber dann...

...fällt das Sprint Review auf die Nase. Irgendwie wurden offenbar doch nicht alle Stories vom Team korrekt verstanden und folglich am Ende auch nicht abgenommen. Das Team entscheidet etwas ernüchtert, diese Stories in den nächsten Sprint zu übernehmen und plant fleißig weitere neue Stories dazu, da inzwischen auch das Management vorbeischaut. 

Der folgende 2. Sprint scheint schon besser zu laufen, und mit ein wenig „Augenzudrücken‟ werden alle Stories vom Product Owner abgenommen. Dumm nur, dass das Feedback von Fachbereich und Management im Review nur mäßig gut ausgefallen ist. Erste unterschwellige Aussagen wie „Aber so langsam solltet ihr mal was liefern!‟ tauchen auf. Also begibt sich das Team angezählt in seinen 3. Sprint und schreibt fleißig Bug- und CR-Tickets, um die vorhandenen Fehler und Lücken zu stopfen. Dabei taucht nun ärgerlicherweise ein erstes massives Architektur-Problem auf, und die Infrastruktur kommt auf einmal nicht mehr nach. Die gefundenen Fehler werden in nächtlichen Sitzungen gefixt - und führen prompt zu weiteren Fehlern. Das Team entscheidet sich, die Lage erst am Ende des Sprints an das Management zu kommunizieren, da die Reaktion sich mühelos erahnen lässt. Das Sprint Review verläuft allerdings schlichtweg tragisch, da die Demo überhaupt nicht funktioniert. Das verärgerte Management beschließt daraufhin zu reagieren: Man müsse „durchgreifen‟ und organisiert ein Eskalations-Meeting (dem schnell weitere folgen). Dumm nur, dass - etwas verfrüht - nach Sprint 5 das Release geplant wurde. Das Management erklärt dem enttäuschten Kunden, dass es „Lessons Learned‟ aus der Funktionsweise von Scrum gezogen hat, und gelobt Besserung. Sämtliche Product Owner und Scrum Master werden ausgetauscht und ein tägliches Reporting wird eingeführt. Beschlüsse müssen dokumentiert werden, keine Änderung ist mehr ohne Ticket erlaubt. Aber sonst bleibt alles beim alten guten Scrum... und man nennt das entstandene Vorgehen selbstverständlich weiterhin „agil‟.

Was war da los?

Woran liegt es, dass viele Projekte mit großer Euphorie als „agil‟ gestartet werden und dann doch in den Fängen „klassischer Arbeitsweisen‟ landen? Sind es die gewählten Methoden und Prozesse, die ein Projekt erst agil machen? Oder ist es doch etwas anderes? Die Wahrheit heißt: Agilität fängt im Kopf an. „Agil‟ werden bedeutet, die Bereitschaft zu haben, etwas Altes, vielleicht Gewohntes und Sicheres loszulassen und Neues zu wagen. Genau das ist das Mindset, das einen agilen Mitarbeiter ausmacht.

„A ship in a harbour is safe, but that is not what a ship is built for.‟ - Grace Brewster Murray Hopper

Mut hilft natürlich, wenn es darum gehen soll, neue Wege zu beschreiten. Neugier und Entdeckergeist helfen, Wege zu finden und abseits von ausgetretenen Pfaden zu denken. Doch wenn man sich unser Team aus dem fiktiven Beispiel-Projekt ansieht, dann wurde dort vermutlich nicht wirklich Entdeckergeist an den Tag gelegt. Es war auch wenig Mut zu sehen, denn es wurden einfach „Scrum-Standards‟ auf das Projekt angewendet. Aber das ist nicht das Ziel einer agilen Softwareentwicklung, auch Scrum muss nicht dogmatisch umgesetzt werden. Natürlich haben die einzelnen Praktiken und Methoden darin ihren Sinn und helfen, die agilen Werte leichter, besser oder schneller umzusetzen. Doch nicht jede Firma ist in der Lage, diese „Idealbedingungen‟ zu schaffen. Und hier muss dann wieder das agile Mindset einspringen: mutig sein, experimentieren, Veränderungen akzeptieren.

Mut, Neugierde und Entdeckergeist sind aber nur ein Teil der Fähigkeiten, die ein agiler Mitarbeiter haben sollte. Auch das Lernen sollte nicht unterschätzt werden. Hat unser Beispiel-Team etwas gelernt? Nun, es hat natürlich Erfahrungen hinzugewonnen, aber ob ihm das alleine hilft, seine Ziele zu erreichen, ist fraglich. Am auffälligsten ist die Tatsache, dass die anfangs beschriebene Freiheit schnell bedroht wurde: liefert das Team nicht schnell etwas, das den Fachbereich zufriedenstellt, gibt es Probleme, Stress und Druck. Lernen unter permanentem Druck hat aber noch nie funktioniert. Unser Team durfte nicht lernen, was es heißt, gute Stories zu schreiben, zu verstehen, zu schätzen, umzusetzen, zu testen. Unser Team durfte nicht die Erfahrung machen, einen Schritt zu gehen, der erfolgreich war. Was bleibt, ist der bittere Geschmack des Scheiterns. Und danach wird es ungleich schwerer, agil zu werden.

Aber nicht nur das Team muss ein agiles Mindset haben, auch das Management und der fachliche Auftraggeber müssen sich agiler positionieren. Das wichtigste Schlagwort heißt: Vertrauen (gemeinsam mit Transparenz und Kommunikation). Das zweite heißt: Fokus. Nur mit der Kombination dieser beiden Einstellungen kann für das Team ein Rahmen geschaffen werden, in dem es das oben genannte Mindset erfolgreich einbringen kann.

Was heißt nun Vertrauen? Die Scrum-Teams „blind‟ arbeiten lassen? Nein! Häufiges und schnelles Feedback sowie konstruktive Kritik sind unverzichtbar. Ein Scrum-Team benötigt permanentes Feedback, um sicherzugehen, dass der eingeschlagene Weg in die richtige Richtung weist. Und es benötigt das Vertrauen, dass die Wegwahl vielleicht nicht die der Geschäftsführung ist, aber das Team auf diesem Weg schneller, einfacher oder hochwertiger sein Ziel erreicht. Diese Ungewissheit verlangt Vertrauen und muss ausgehalten werden. Natürlich kann es Enttäuschungen geben. Deshalb ist Sozialkompetenz beim Management und der Fachseite gefordert. Unserem Beispiel-Team wurde dieses Vertrauen nicht wirklich gegeben. Letztendlich hatte es keine Chance, sich Vertrauen zu erarbeiten. Hier ist das Management nicht mit Vertrauen an die Sache herangegangen, sondern mit der Forderung, dass das Team das schon „richtig‟ (d.h. im Sinne des Managements) macht. Und als dann dieses Team, das gerade erst anfing, Scrum für sich zu erlernen und zu definieren, die ersten Prüfungen nur mit Ach und Krach besteht, wird es mit einer tiefen Enttäuschung des Managements konfrontiert.

Alice: „Kannst du mir sagen welchen Weg ich gehen soll?‟ „Das hängt davon ab, wohin du gehen willst.‟, sagte die Grinsekatze. „Das ist mir eigentlich egal‟, antwortet Alice. „Dann ist es auch egal, welchen Weg du einschlägst.‟, erwiderte die Grinsekatze. - Lewis Carroll, Alice im Wunderland

Der zweite wichtige Aspekt für das Management ist die Fokussierung auf das Ergebnis. Nur mit einem konkreten Ziel können Projekte wirklich erfolgreich abgeschlossen werden. Diese „Fangt-schon-mal-an-Mentalität‟, die vielen agilen Projekten innewohnt, hinterlässt bei Teams große Unsicherheit. Die Symptome sind im Beispiel-Projekt zu sehen: User Stories werden falsch verstanden und fehlerhaft umgesetzt. Der Fachbereich schlägt die Hände über dem Kopf zusammen, zweifelt dieses neumodische Scrum-Zeug an und fordert eine höhere Kontrolle des Teams, damit die nicht das ganze vereinbarte Budget verbrennen.

Leider ist das Festlegen von Zielen nicht einfach, aber man kann es lernen. Ziele für agile Teams müssen den Zielzustand („Product Vision‟ und „Business Goals‟) so genau und konkret wie möglich beschreiben, messbar sein und auch eine zeitliche Abschätzung ermöglichen. Aber sie dürfen keinesfalls den Weg vorgeben, wie dieses Ziel erreicht wird. Hier sind wir dann wieder beim Vertrauen.

Zu guter Letzt gibt es noch eine Fähigkeit, die alle mitbringen müssen, wenn ein Projekt oder gar eine Organisation agil werden soll: Kommunikation. „Ja, aber wir reden doch!‟ ist ein oft gehörtes Statement. Doch wie hört sich das in Meetings an? „Entwickler A hat seinen Code noch nicht eingecheckt. Ich kann nicht weiter testen.‟ „Der Product Owner muss die User Stories besser schneiden. So kann ich das nicht umsetzen.‟ Hört auf, übereinander zu reden und fangt an, miteinander zu reden! In unserem Beispiel schaut auch noch gelegentlich das Management vorbei, d.h. es spielt den Durchlauferhitzer für den Kunden, der anscheinend gar keinen Kontakt zum Team hat. Für agiles Arbeiten ist die direkte Kommunikation mit dem Auftraggeber ein wesentlicher Erfolgsfaktor.

Das also sind die Elemente eines agilen Mindsets: Mut, Neugierde, Entdeckergeist, Lernen, Vertrauen, Fokussierung und Kommunikation. Man muss sie nur noch praktizieren.

Ohne Vertrauen ist alles nichts

Entscheidend ist: erst, wenn diese Voraussetzungen - Team-Mindset und Management-Vertrauen - gegeben sind, dann können die heute wohlbekannten agilen Entwicklungs-Praktiken und -Techniken wirklich greifen! Denn wie soll beispielsweise erfolgreich mit ATDD (Acceptance Test Driven Development) gearbeitet werden, wenn die Zusammenarbeit mit der Teamumwelt von Misstrauen und Kontrolle geprägt ist (und Abnahmekriterien erst kurz vor dem Rollout zugeliefert werden)? Wie soll das Team Verantwortung übernehmen, wenn es vom Management mit Vorschriften, Extrawünschen und Forderungen überhäuft wird? Wie sollen Testerinnen und Tester in einem agilen Team gleichberechtigt zum Zuge kommen, wenn die Entwicklung nach der Devise „Wir wollen uns in unserer DONEness nicht vom Test behindern lassen‟ arbeitet? (Letzteres ist übrigens ein authentisches Zitat.)

Schauen uns wir uns einige weit verbreitete agile SWE-Praktiken an, die direkt oder indirekt von den Erfolgsfaktoren „Team-Mindset‟ und „Management-Vertrauen‟ profitieren:

  • für die Planung: iterative Zyklus-Planung mit verhandelbarem Inhalt, Aufwandsschätzung und Commitment durch das gesamte Team, Daily-Standup-Meetings (mit Taskboard und Burndown), Definitions of Ready & of Done, Zeit für Klärungsarbeiten wie Sprint 0 oder Spikes
  • für die Zielsetzung: Prototypen und Mockups für die Produkt-Vision
  • für das Team: cross-functional, gegenseitiges Lehren und Lernen, Retrospektive-Meeting für Team- und Prozess-Themen, verantwortliche Prozessgestaltung (Artefakte, Ausbildung, Werkzeuge)
  • für die Anforderungen: Teamraum, On-Site-Customer, User Stories/Epics/etc als Planungs- und Kommunikations-Grundlage, Backlog Grooming, testbare Akzeptanzkriterien
  • für die Implementierung: Clean Code, Collective Code Ownership, Pairing (mit anderem Entwickler/Tester), testgetriebene Entwicklung (TDD, BDD, ATDD)
  • für den Test: agile Teststrategie, risikobasiertes Testen, reife/wartbare Testautomatisierung, Pairing (mit Tester/Entwickler/Product Owner), Continuous Integration
  • für den Rollout: Sprint Review/Abnahme, DevOps.

Einzelne dieser Maßnahmen können auch in einem nicht-agilen Vorgehen Nutzen stiften (etwa das Daily Standup), aber ihre volle Schlagkraft werden sie erst entfalten können, wenn die genannten Rahmenbedingungen in den Köpfen anzutreffen sind. Genauso wenig wie also die bloße Anschaffung eines Werkzeugs Projektprobleme löst, ist es leichtfertig zu glauben, dass Agilität nur durch den Umstieg auf agile Praktiken erreichbar ist. Dass viele Projekte und Unternehmen, die sich „agil‟ nennen, bei genauerem Hinsehen alles mögliche sind, aber sicher nicht agil, ist eine Beobachtung, die uns letztlich zu diesem Beitrag geführt hat. Anders gesagt: „Agile Done Right‟ funktioniert nicht von oben verordnet und meist auch nicht von heute auf morgen.

Und Sie?

Apropos „voneinander lernen‟ und Agilität im Alltag: wie sieht es bei Ihnen aus? Konnten Sie sich in den Ausführungen zur Agilität auf Team- und Management-Ebene wiederfinden? Diskutieren Sie manchmal auch ewig, ob sie wirklich agil sind oder nicht? Eine überspitzte Sichtweise hierzu: Wenn Sie schon darüber diskutieren müssen, ob Sie agil sind, dann könnte das schon darauf hindeuten, dass Sie es vielleicht gar nicht sind? Wie bei Scrum gilt die Devise: einfach machen! Jeder, der 3-5 Sprints und ein High-Performance-Team in Aktion erlebt hat, wird fürs Leben geprägt. Das heißt nicht, dass immer alles klappt - wichtig ist der Wille, als Team Großartiges zu leisten, lernen zu wollen, sowie die Unterstützung der Gesamtorganisation. In diesem Sinne: „Do things that matter!‟ :-)

Bilder: iStock

back

Kommentare