Agilität ist aus unserer Sicht eines der großen Missverständnisse des Digitalisierungszeitalters, da häufig Arbeits- mit Denk- und Verhaltensweisen verwechselt werden. Also in etwa so, als würde man die einwandfreie Moral eines Menschen damit begründen, dass er noch nie eine Straftat begangen hat.
Wir wollen in den nächsten Wochen mithilfe der Frage “Sind wir agil, wenn…?” mit einigen Missverständnissen und Mythen von Agilität, welche uns in der Praxis immer wieder begegnen, aufräumen und unsere Sicht dazu darstellen. Außerdem stellen wir euch einen “Agile Team Health Check” bereit, mit dessen Hilfe ihr einen Eindruck bekommt, wie agil ihr tatsächlich seid und woran ihr arbeiten könnt.
Los geht’s mit der ersten Frage.
Sind wir agil, wenn wir nach Scrum arbeiten?
Gegenfrage: Lebst du gesund, wenn du dich vegetarisch ernährst?
Nur weil man einem bestimmten Vorgehen folgt, ein Framework oder eine Methode anwendet oder eben einen bestimmten Lebensstil pflegt, heißt das noch lange nicht, dass man auch den Nutzen erhält, den man sich davon verspricht.
Es ist zum Beispiel ganz entscheidend, wie man ein Vorgehen anwendet (man kann auch ganz fleischlos seinem Körper schlechtes antun), was man "außerhalb" des beschriebenen Frameworks tut (ein Vegetarier wird wohl nicht allzu gesund sein, wenn er weiterhin raucht und trinkt) oder wie konsequent man bei der Anwendung ist.
An erster Stelle steht jedoch die Frage, warum man Scrum oder ein anderes agiles Framework einsetzen möchte. Wenn man sich in einer komplexen Situationen befindet, in welcher vieles nicht planbar und vorhersagbar ist, in der man sich immer wieder herantasten muss, um festzustellen, ob der gewünschte Effekt eintritt, dann sind wichtige Voraussetzungen erfüllt. Agiles Vorgehen nur um des agilen Vorgehens Willen ist bestimmt kein guter Grund.
Wenn man agil sein bzw. werden möchte, kann es grundsätzlich total sinnvoll ein, ein Vorgehen - wie bspw. Scrum - zu wählen, welches sich für viele Teams in verschiedenen Situationen etabliert hat und den meisten Mitarbeitern mehr oder weniger bekannt ist.
Allerdings trägt das Vorgehen alleine höchstens indirekt zu einer Veränderung der Denk- und Verhaltensmuster bei - beispielsweise durch "positive" Routinen und Rituale.
Ganz davon abgesehen, dass man ein Vorgehen auch völlig "falsch" und damit kontraproduktiv einsetzen kann, etwa weil dieses nicht zu den gegebenen Rahmenbedingungen passt. Wir verkneifen uns an der Stelle den Vergleich mit dem Hammer und dem Nagel.
Sind wir agil, wenn wir Dailies machen?
Gegenfrage: Lebst du gesund, wenn du jeden Morgen einen Smoothie trinkst?
Gegenfrage: Lebst du gesund, wenn du jeden Morgen einen Smoothie trinkst?
Rituale können dabei helfen, sich gewünschte Denk- und Verhaltensweisen anzugewöhnen. Das alleine wird allerdings kaum zum gewünschten Ziel führen.
Im Falle des Daily Stand-Ups kann die Etablierung von Ritualen auch zu schlechten Angewohnheiten führen und damit kontraproduktiv sein: Wenn es nur dafür genutzt wird, dem Scrum Master zu berichten, was man am gestrigen Tag getan hat und in welchen Meetings man saß, ist es vermutlich reine Zeitverschwendung und damit hinderlich für das Team beim Erreichen seiner Ziele.
Wenn es allerdings als Planungsmeeting verstanden wird, in dem sich das Team synchronisiert, Abhängigkeiten bespricht, Unterstützungsbedarf anzeigt, wichtige Informationen teilt und Erfahrungswerte austauscht, dann kann das sehr zur Zielerreichung des Teams beitragen.
Sind wir agil, wenn wir Retros machen?
Klassische Beraterantwort: "Es kommt darauf an."
Und zwar darauf, was die Ergebnisse der Retrospektiven sind, wie sie erzeugt wurden und was damit im Nachgang geschieht.
Retrospektiven sollten dazu dienen, die Zusammenarbeit im Team und mit Stakeholdern zu reflektieren und Experimente zur Verbesserung dieser anzustoßen. Wenn das geschieht, ist ein wichtiger Aspekt von Agilität erreicht: der kontinuierliche Verbesserungsprozess (oder sagen wir lieber “Inspect & Adapt”, nicht dass jemand den “Prozess” wörtlich nimmt).
Nicht selten kommt es allerdings vor, dass Retrospektiven der verzweifelte Versuch von Scrum Mastern sind, den Regeltermin wie geplant durchzuführen und aus dem Team händeringend Input und Ideen für Maßnahmen herauszukitzeln. Was dann in den meisten Fällen mit den Ergebnissen (also den Action Items) passiert, ist wohl relativ klar - nämlich nichts.
An dieser Stelle möchten wir zum ersten Mal auf den Unterschied zwischen Output und Outcome hinweisen.
Wir laden euch ein, euch selbst die Frage zu stellen: Haben Retrospektiven einen wirklichen Nutzen (Outcome)? Indem regelmäßig Erfolge gefeiert, Probleme aufgedeckt und Hindernisse im Anschluss tatsächlich beseitigt werden, was wiederum zu einer höheren Zufriedenheit oder Wertschöpfung führt? Indem nach der Umsetzung einer Maßnahme ermittelt wird, ob tatsächlich der gewünschte Effekt eingetreten ist oder ob es weiterer Änderungen bedarf?
Oder geht es eher darum eine Bucket-List abzuarbeiten? Am Ende eines Sprint macht man nun mal eine Retro. In einer Retro definiert man nun mal Action Items. Action Items arbeitet man nun mal im nächsten Sprint ab. Nutzen? Fehlanzeige.
Wir möchten damit nicht empfehlen, keine Retrospektiven mehr zu machen, wenn sie keinen Mehrwert bringen. Ganz im Gegenteil. Wir wollen Mut machen, Retrospektiven mal ganz anders zu machen. Es muss nicht immer der 90-min-Termin mit dem gesamten Scrum-Team sein…
Sind wir agil, wenn wir ein gemeinsames Task Board verwenden?
Transparenz über Arbeit und Fortschritt ist ein wesentliches Merkmal von Agilität. Für das gemeinsame Board gibt es also definitiv einen Daumen nach oben. Allerdings ist das natürlich nicht alles. Wir haben nicht selten Boards gesehen,
- welche auf einem Backlog basieren, das die nächsten 3 Jahre füllen würde,
- bei denen 27 Stories gleichzeitig “in progress” sind,
- auf dem die Stories außer einem Titel keinerlei Informationen beinhalten.
Das sind Muster, die nicht für Transparenz sorgen, sondern höchstwahrscheinlich zu einem riesigen Overhead führen. Die Teams werden sich immer wieder die gleichen Fragen stellen und beantworten müssen: "Was war nochmal der Stand bei der Story?", "Was wollten in dieser Story eigentlich nochmal genau tun?". Planungen (egal ob im Daily, Sprint oder Release Planning) werden unnötig lange dauern, da man sich stets durch eine riesige Anzahl an Stories wühlen muss und keine weiteren strukturierenden Elemente wie Epics, Features oder einfach Tags vorhanden sind.
Sind wir agil, wenn wir in Sprints arbeiten?
Ein iteratives Vorgehen haben alle agilen Frameworks gemein. Es ist eine der Grundideen von Agilität kontinuierlich kleine Teile des großen Bilds fertigzustellen und zum Kunden zu bringen. Anstatt eines großen Rollouts am Ende eines jahrelangen Konzeptions-, Entwicklungs- und Testprozesses.
Nur genau das ist der springende Punkt: Liefert das Team am Ende jedes Sprints etwas an den Kunden aus (stellt also einen wirklichen Mehrwert bereit und verprobt diesen in der Praxis) oder ist das Team lediglich in Sprints organisiert? Gibt es konkret definierte Sprintziele, die das Team erreichen will, oder ist der Sprint eine Ansammlung beliebiger User Stories?
Der Sprint ist ein Vehikel (wie bspw. auch ein Release oder Daily Stand-Up), um größere, komplexe Ziele und Herausforderungen in kleinere, besser beherrschbare Pakete aufzuteilen. Er soll damit für Fokussierung und eine gewisse Planbarkeit der näheren Zukunft sorgen. Für Vertrauensbildung seitens Kunden und Stakeholder und regelmäßige Erfolgserlebnisse.
Wenn diese Wertversprechen allerdings nicht erfüllt werden, dann arbeitet das Team zwar in Sprints, ist von Agilität jedoch wahrscheinlich weit entfernt.
Sind wir agil, wenn wir nicht mehr planen?
Agiles Vorgehen nutzt stets ein ausgewogenes Zusammenspiel aus dem Blick in die Zukunft (durch Planung), dem Blick in die Vergangenheit (bspw. durch Reviews und Retrospektiven oder die - teilweise unbewusste - Anwendung von Erfahrungen) und der Umsetzung in der Gegenwart.
Ein erfolgreiches Vorhaben beinhaltet daher auch entsprechende Planungen! Alleine schon deshalb, um zu erkennen, wenn man vom ursprünglichen Plan abweicht und in der Lage zu sein gegenzusteuern und Anpassungen vorzunehmen. Anpassungen am Vorgehen, an Rahmenbedingungen, am Ziel, an den eingesetzten Werkzeugen, …. Oder eben am Plan.
Leider wird Agilität beim Aspekt der Planung immer noch häufig falsch verstanden. Agilität heißt niemals Planlosigkeit, Chaos oder "jeder macht, was er will".
Vielmehr bedeutet Agilität sogar sehr viel häufiger zu planen. Allerdings nur das zum jeweiligen Zeitpunkt Notwendige und Nützliche (“just-in-time Planung” sozusagen).
Je kleiner und kurzfristiger dabei der betrachtete Zeitraum ist, desto detaillierter wird die Planung. Von der höchsten Flugebene einer Roadmap bis hin zum laut Scrum Guide “actionable plan for the next day of work” im Daily Stand-Up (über das Daily als Planungsmeeting schrieben wir bereits in “Sind wir agil, wenn wir Dailies machen?“).
Für uns ist die Planung darüberhinaus ein wesentliches Werkzeug zur Kommunikation. Sei es die Sprint Planung zur Kommunikation mit dem Team, Releaseplanungen zur Kommunikation mit Kunden oder Roadmaps und Budgetplanungen zur Kommunikation mit Sponsoren oder dem Lenkungskreis.
Planungen sorgen für ein gemeinsames Verständnis von inhaltlichen, zeitlichen und kostenbezogenen Aspekten innerhalb und außerhalb des Teams.
Sind wir agil, wenn wir flexibel auf alle Veränderungen reagieren?
Für uns ist "Flexibilität" das Unwort überhaupt im Bezug zu Agilität.
Natürlich ist auch Flexibilität eine Eigenschaft, die agile Teams haben. Wenn man einer bekannten Wissenschaftsplattform glaubt, ist Flexibilität bzw. Anpassungsfähigkeit "die Fähigkeit, sich im Erleben und Verhalten wechselnden Situationen schnell anzupassen". Klingt wichtig in einer komplexen Wirklichkeit, in welcher wir uns mit agilen Vorgehensweisen befinden.
Allerdings wird mit dem Gleichsetzen von Agilität und Flexibilität meist völlige Planlosigkeit, fehlende Priorisierung und Fokus oder unzureichende Vorbereitung suggeriert.
Getreu dem Motto: "Es ist doch völlig normal, sich ständig mit neuen oder geänderten Anforderungen auseinanderzusetzen, das Team wäre ja schließlich agil, äh, flexibel.”
Anpassungen und Änderungen sind ständiger Begleiter in agilen Vorgehen. So spricht auch bspw. der Scrum Guide von den Anforderungsänderungen, die selbst spät in der Entwicklung willkommen geheißen werden sollen. Allerdings sollte das nicht als Ausrede für fehlende Zielvorgabe, Richtung, Priorisierung, Analyse, etc. herhalten.
Denn eines sollte einem bewusst sein: Die kurzfristige Anpassung von Plänen sorgt für Kosten. Nicht nur die offensichtlichen Kosten, die aus den bereits geleisteten Aufwänden für die ursprünglich geplanten Themen resultieren (die auch durch eine spätere Wiederaufnahme dieser Themen nicht vollständig eliminiert werden können). Sondern zusätzliche Overheads durch Fokuswechsel, ad-hoc-Meetings oder andere Tätigkeiten, die nicht dem eigentlichen Entwicklungsprozess des Teams entsprechen. Ebenfalls ist nicht zu unterschätzen, was es mit einem Team macht, wenn selten etwas fertiggestellt und damit kaum Mehrwert geliefert wird, da immer wieder andere Themen eingeschoben werden.
Daher sollte bei ständigen Veränderungen dringend untersucht werden, was die Ursachen und Gründe dafür sind.