Mythen aus der agilen Welt

Die agile Arbeitsweise bleibt weiter der Megatrend und der große Hype schlechthin. Oft wird Agilität in Unternehmen eingeführt, weil sich die Geschäftsführung viele Vorteile davon verspricht. Im besten Fall sind die Versprechen auch tatsächlich realisierbar. Doch die wenigsten Unternehmen prüfen vorher, worauf die agile Transformation aufsetzt, wo sie enden soll und was überhaupt agil gemacht werden soll.

Auch wenn manche Unternehmen und Teams mittlerweile auf dem Boden der nüchternen Tatsachen angekommen sind, halten sich bestimmte Mythen und auch Märchen doch recht hartnäckig. Deshalb scheint es mir gerade angesichts der atemberaubenden, komplexen und immer kurzfristigeren Veränderungen, die die Corona-Pandemie mit sich bringt, angeraten, falsche „Wunschvorstellungen“ gerade zu rücken. Hilfreich ist dabei wie immer der Abgleich möglicher „Wünsche“ mit den Erfahrungen aus der Berufspraxis als erfahrener Agile Coach. Wer mehr über mögliche „Fallstricke der agilen Transformation“ erfahren will, findet hier mehr dazu.

Konkret will ich im folgenden Blogbeitrag sieben Mythen agiler Arbeitsweise genauer unter die Lupe nehmen:

1. Viel schnellere Software-Entwicklung
2. Änderungen noch in letzter Sekunde
3. Allzweckwaffe und Königsweg
4. Keine Planung mehr
5. Agil ist einfach
6. Agil ist gleich Scrum
7. Nur für Software

Zu jedem Mythos gibt es am Ende noch einen kurzen Tipp von mir, worauf Sie bei der Umsetzung von agilen Arbeitsweisen im Unternehmen achten sollen.

Mythos #1: Software-Entwicklung wesentlich oder mindestens 4x schneller

Tatsächlich hat einer der Erfinder von Scrum, Jeff Sutherland, diesen Mythos mit dem Titel seines Buchs über Scrum selbst in die Welt gesetzt. In einem Vortrag auf dem Scrum Day, den ich erleben durfte, hat Jeff auch zugegeben, dass er heute einen anderen Titel wählen würde als „The Art of Doing Twice the Work in Half the Time“. Praktisch würde das ja die Beschleunigung der Software-Entwicklung um den Faktor vier bedeuten.

Viele Teams, die in einem entsprechenden Rahmen arbeiten können, erreichen tatsächlich eine deutliche Beschleunigung in der benötigten Zeit zur Produktentwicklung. Allerdings ist es in den meisten Unternehmen auch ein etwas längerer Weg, bis dieser Effekt tatsächlich bemerkbar ist. Die Selbstorganisation des Teams oder das Selbstmanagement, wie es seit November 2020 genannt wird, ist tatsächlich einer der Schlüsselfaktoren für mehr Geschwindigkeit.

Ebenso die crossfunktionelle Besetzung des Teams oder die Tatsache, dass ein Scrum Master auch wirklich in der Lage ist, die Hindernisse (impediments) im Unternehmen zu beseitigen und dafür entsprechend vom Topmanagement unterstützt wird. Somit bleibt oft die Feststellung, dass nach einer gewissen Zeit der Umstellung auch tatsächlich die Entwicklungszeit deutlich verkürzt wird. Aber eben auch nur, wenn danach vieles gut bis optimal läuft und umgesetzt wurde.

Dazu der Profi-Tipp von mir: Agilität nur mit dem Ziel der Beschleunigung anzugehen, macht keinen Sinn und erzeugt lediglich den falschen Fokus. Agiles Arbeiten geht einen deutlichen Schritt weiter: weg vom zu starken Fokus auf Effizienz hin zur Maximierung des Lernens und zu mehr Innovation im Unternehmen. Machen Sie sich also vor der Einführung von Agilität klar, was Sie damit erreichen wollen. Mehr Geschwindigkeit ist ein Nebeneffekt, kein Ziel!

Mythos #2: Änderungen noch in letzter Sekunde

Das ist ein Mythos, der Führungskräfte häufig stark begeistert und sich deswegen sehr hartnäckig hält. Welcher Chef träumt denn nicht davon, so eben mal, etwa ein bis zwei Wochen vor dem Go-Live noch eine Änderung in den langwierigen Entwicklungsprozess einsteuern zu können, die dann auch noch umgesetzt wird? Ja, es ist richtig, grundsätzlich können in jedem Sprint neue Backlog Items aufgenommen und auch tatsächlich im nächsten auslieferungsfähigen Produktinkrement umgesetzt werden.

Nur heißt das nicht, dass das auch jedes Mal exakt nach der Wunschvorstellung eines Stakeholders geschieht. Das Product Backlog wird anhand des Nutzens für das Unternehmen (business value) sortiert oder priorisiert. Und das Team wählt für jeden Sprint aus dieser Liste von oben her einige Einträge für das Sprint Backlog aus. Aber eben nur diejenigen, die für den jeweiligen Sprint geeignet sind und „klein“ und „ready“ genug sind. Die meisten Ideen von Führungskräften oder Stakeholdern, die gerne noch kurzfristig über den Zaun geworfen werden, erfüllen diese Anforderung sicher nicht. Und schließlich hat der Product Owner ja auch das letzte Wort, was die Sortierung im Backlog angeht.

Der Profi-Tipp von mir: Führungskräfte müssen ihre Rolle im Kontext von Agilität ziemlich stark überdenken und neu ausrichten. Agiles Arbeiten hat sicher den stärksten Impact auf die Rolle der Führungskräfte, daher ist es so wichtig, dass sie agile Methoden wirklich verstehen. Sorgen Sie dafür, dass Führungskräfte das agile Mindset verstehen, zum Beispiel durch eine Weiterbildung zum Product Owner. Oder stellen Sie Ihnen einen guten Coach zur Seite, um die eigene Rolle zu reflektieren.

Mythos #3: Die Allzweckwaffe und der Königsweg

Puh, ja, es ist ein altbekanntes Thema in der IT. Alle paar Monate kommt eine Neuerung in Form von Technologie oder Methoden, die verspricht, alle Probleme der IT an sich zu lösen. Die Allzweckwaffe, die alle Probleme – wusch – im Handumdrehen beseitigt. Ich selbst bin nun seit über 35 Jahren in der IT unterwegs und habe schon viele solcher „Wunder- oder Allzweckwaffen“ gesehen. Alle waren hilfreich und haben oft zu einer Verbesserung bestimmter Szenarien geführt. Aber keine davon hat alle Probleme gelöst, sondern in der Regel neue Probleme mit sich gebracht. So ist das auch bei Scrum und Agilität. Beides löst typische Probleme der Entwicklung im Wasserfall-Modell. Die Methode bringt aber neue Herausforderungen mit sich und eignet sich nur unter bestimmten Voraussetzungen bzw. Vorarbeiten.

Ebenso wenig ist es der Königsweg, jedes Projekt (streng genommen reden wir bei Scrum ja von Produktentwicklung, nicht von Projektmanagement) nun unbedingt nur noch agil fahren zu wollen. Es wird weiterhin in Unternehmen Projekte und auch Bereiche geben, die mit der klassischen, phasenorientierten Methodik besser und erfolgreicher sein werden als mit agilen Methoden wie Scrum. Sei es, dass die Voraussetzungen nicht gegeben sind oder sei es, dass die Menschen nicht bereit sind. Möglich ist natürlich auch, dass schlichtweg keine sinnvolle Definition von einem Produktinkrement gefunden werden kann. Mir ist noch kein Fall bekannt, wo zum Beispiel ein neuer Firmenstandort agil gebaut oder aufgezogen wurde. Hier ist es aufgrund des ganzen „Drumherum“ weiter okay und sinnvoll, phasenorientiert vorzugehen.

Welche Bereiche arbeiten agil?

Der Profi-Tipp von mir: Überlegen Sie sich frühzeitig, welche Bereiche im Unternehmen agil arbeiten sollen und in welchen Bereichen Agilität einfach keinen Mehrwert erzeugt. In Unternehmensbereichen mit einem hohen Anteil an operativem Tagesgeschäft, wie z.B. Finanzen oder Personal, bringt die agile Arbeitsweise keinen Vorteil. Definieren Sie dort klare Ideen, wie mit agilen Abläufen umzugehen ist, etwa beim Einkauf agiler Entwicklungspartner.

Und vergessen Sie bitte nicht, dass agile Methoden wie Scrum auf die Entwicklung eines Produkts abzielen. Agile Finanzteams, die jeden Monat ein Inkrement des Jahresabschlusses „ausliefern“, sind nicht agil. Glauben Sie mir das, auch wenn ich solche seltsamen Konstrukte schon gesehen habe. Ebenso ist nicht jeder Bereich im Unternehmen plötzlich ein Produkt, nur weil Sie agil arbeiten wollen.

Mythos #4: Keine Planung mehr nötig

Das ist ein Mythos, der wohl viele Projektbeteiligte anspricht. Ja, es stimmt, Planung liegt nicht jedem und ist ein Aufwand, den nicht alle gerne leisten. Dennoch ist Planung im klassischen Projektmanagement nötig und eine wichtige Tugend. Denn sonst werden Projekte eben nicht „in time, in budget, in quality“ abgeschlossen.

Die agile Welt lockt daher bei Scrum auch mit der Idee des Backlogs, in dem ja nur „Backlog Items“ in Form von User Stories enthalten sind. Und die User Stories werden dann in einem Sprint implementiert und ausgeliefert. Stimmt, das klingt zunächst nicht nach Planung, das gebe ich zu. Doch der Schein trügt. Wie schon oben erwähnt, müssen dazu die User Stories in geeigneter Form vorliegen, damit sie implementiert werden können.

Es gibt zwei Ereignisse, in denen User Stories verfeinert und genauer angeschaut werden: das Sprint Planning und das Backlog Refinement. Und überhaupt das Sprint Planning: Hier wird ein Sprint konkret geplant. Auch wenn hier kein Gantt-Chart entwickelt wird, wird natürlich weiter geplant, verfeinert und konkretisiert. Bei Scrum ist viel Planungsarbeit in den Prozess und die Ereignisse sozusagen fest eingebaut. Von einem „keine Planung mehr nötig“ ist also keine Spur!

Dazu der Profi-Tipp von mir: Unterschätzen Sie nicht, wieviel bei der agilen Arbeitsweise in Scrum geplant wird. Ja überhaupt, wie streng Scrum als Ablauf ist. Aber genau damit werden viele Schwierigkeiten und Probleme des traditionellen Phasenmodells eben bei Scrum schon im Prozess gelöst! Das ist in meinen Augen das eigentlich Geniale an der Sache. Nehmen Sie sich also Zeit für die Verfeinerung von User Stories und die Arbeit am Backlog, das gilt besonders für die Product Owner!

Mythos #5: Agil ist einfach

Das ist tatsächlich einer meiner liebsten Mythen beim Thema Agilität. Eigentlich ist das agile Arbeiten ganz einfach – tatsächlich entspricht es auch mehr der intuitiven Vorgehensweise als das Wasserfallmodell mit seinen Phasen. Wer weiß denn schon heute, wie ein Stück Software, das noch entwickelt wird, in den nächsten 18 Monaten wirklich ganz konkret aussieht?
Wenn wir uns Scrum als die am meisten verbreitete Methode ansehen, wird sie oft auf einer einzigen Seite dargestellt (>> hier geht’s zu unserem Einseiter „Scrum in a Nutshell“).

Ich habe auch schon Scrum als Darstellung auf einem Bierdeckel gesehen. Die meisten Unternehmen machen allerdings den Fehler, Scrum gleich zu Beginn anzupassen anstatt aus dem Lehrbuch-Prozess zu lernen. Und dann wundern sie sich, warum Scrum keine Wirkung entfaltet. Oder sie vergessen das Wichtigste an Scrum: die Scrum-Werte Offenheit, Respekt, Fokus, Commitment und Mut. Dazu gehören auch die Säulen von Scrum wie Transparenz und das Prinzip Inspect und Adapt, also das Arbeiten in Iterationen.

Methode oder Mindset?

Wer Scrum nur als Methode versteht, hat Agilität nicht verstanden. Leider stürzen sich Firmen aber bei der Einführung von Agilität gerne auf Scrum als Methode und starten mit einem nicht besonders agilen Mindset. Dieses konsequent täglich zu leben, ist deutlich schwieriger als die Methode Scrum mit allen Rollen, Ereignissen und Artefakten zu verwenden.

Der Profi-Tipp von mir: Verstehen Sie von Anfang an, dass Agilität vor allem eine Frage des Mindsets ist und nicht von Methoden wie Scrum. Fragen Sie sich, wie Sie die Scrum-Werte in ihrem Bereich leben können! Wie können Teams in ihrer täglichen Arbeit Offenheit, Respekt, Fokus, Commitment und Mut leben? Und was bedeutet das für die einzelnen Teammitglieder? Gehen Sie dazu in einen Dialog und lernen Sie auch, in Iterationen zu denken. Wenn Sie dann noch Retros bei jeder möglichen Gelegenheit machen, dann sind Sie auf einem guten Weg zum agilen Unternehmen!

Mythos #6: Agil ist gleich Scrum

Agil und Scrum werden heute fast immer gleichgesetzt. Es stimmt, Scrum ist die agile Methode bzw. Arbeitsweise, die am häufigsten eingesetzt wird: „Mit 84 Prozent ist Scrum weiterhin der meistgenutzte agile Ansatz auf Teamebene“ (Quelle: Status Quo Agile 2019/20 der Hochschule Koblenz). Als weitere agile Ansätze werden oft noch Kanban, DevOps, Lean und Design Thinking genannt. Ich bin mit dieser unscharfen „agilen Wolke“ nicht einverstanden, weil hier Ansätze und Modelle ganz unterschiedlicher Herkunft vermengt werden.

Kanban und Lean gehören in eine eigene Welt. Kanban wird zwar oft als „Einstiegsmodell“ in die agile Welt verwendet, weil es leichter einzuführen ist als gleich mit Scrum zu starten, das ja doch ein recht rigides Vorgehen erzeugt. Jedoch stammt Kanban aus der Welt des Lean Production Systems und dient vor allem dazu, Durchlaufzeiten in Prozessen zu beschleunigen sowie Zwischenergebnisse zu minimieren.

Welche Methode passt wo?

Kanban kennt z.B. keine Iterationen und ist damit für mich kein agiles Modell. Dennoch ist es oft hilfreich, ein Vorgehen in Iterationen vorzubereiten, weil eben die Durchlaufzeiten beschleunigt werden und wir mit Kanban eine deutliche Transparenz über den Entwicklungs-Prozess erzeugen. Damit erfüllt Kanban immerhin eine wichtige Säule von Agilität. DevOps, also die Verzahnung von Entwicklung (Development) und Operations (IT-Betrieb), ist ein Ansatz, der zunächst auch wieder vollkommen unabhängig von Agilität betrachtet und eingeführt werden kann.

Der Profi-Tipp von mir: Verzetteln Sie sich bitte nicht in der Debatte, was agil ist und was nicht. Finden und entwickeln Sie Ihr eigenes Verständnis von Agilität. Mein Job ist es unter anderem, diese Themen zu klären. Ihr Job ist es, das umzusetzen, was in Ihrem Unternehmen funktioniert. Wenn Sie von Kanban profitieren und damit schneller werden oder zu einem klaren Verständnis von Iterationen kommen, ist das schon ein großer Erfolg. Aber fangen Sie nicht mit einem Thema nach dem anderen an: die Liste agiler Methoden ist kein Einkaufszettel.

Mythos #7: Agil passt nur für Software-Entwicklung

Scrum ist eine Methode, die ihren Ursprung ganz klar in der Entwicklung von Software hat. Aber nicht nur dort wird heute Scrum eingesetzt. Oft geschieht dies auch in der Entwicklung von Hardware oder anderen Produkten. Wir erinnern uns: Scrum ist eine Methodik zur Produkt-Entwicklung, sie eignet sich somit auch für andere Produkte in einem komplexen Umfeld. Das bedeutet, überall, wo eine klare Vorstellung des Produkts erst im Entwicklungsprozess entsteht (und nicht von vornherein vollständig beschrieben werden kann), ist eine agile Vorgehensweise durchaus sinnvoll und möglich. Dies gilt beispielsweise auch für Fälle, wo wir viele Stakeholder haben und sowohl deren Feedback als auch das von Kunden miteinbeziehen wollen. Oder wo wir iterativ in Inkrementen arbeiten wollen.

Und sogar darüber hinaus sind viele Unternehmen heute dazu übergegangen, Elemente von Scrum mit Erfolg auch außerhalb von Entwicklungsprozessen einzusetzen. Das Daily wird oft genutzt, um Teams täglich auf Kurs zu halten, ebenso haben Retrospektiven oft zu einer Verbesserung der Feedback-Kultur und mehr offenem Dialog und Partizipation in vielen Unternehmen geführt. Mancher spricht daher auch davon, dass Agilität eine Revolution herbeiführen kann, ja sogar selbst eine Revolution der Arbeitswelt mit sich bringt.

Die Crux langfristiger Planungen

Der Profi-Tipp von mir: Wenn ich Agilität auf ein Element reduzieren sollte, wären es Retrospektiven bei allen möglichen Gelegenheiten. Aber auch ein stärkeres Denken in Iterationen macht heutzutage so viel Sinn und entspricht eher unserer doch sehr volatilen Umwelt. Ich schreibe diese Zeilen während des zweiten Lockdowns, als gerade die Maßnahmen von ursprünglich Ende November in den Januar 2021 verlängert werden.

Die Pandemie zeigt uns deutlich, dass langfristige Planung schlicht nicht mehr möglich ist. Eigentlich war sie das ja noch nie, wenn wir ehrlich sind! Unsere Welt ändert sich einfach zu schnell. Eine Änderung unserer grundlegenden Arbeitsweise auf Iterationen mit Retros als Feedbackschleife könnte tatsächlich der bessere Ansatz sein. Gerade angesichts aktueller Ereignisse wirkt es nicht mehr zeitgemäß, irgendwelche weit entfernt liegenden Jahresziele zu verfolgen, die nach wenigen Wochen schon nicht mehr passen können. Somit bringen agile Methoden vielleicht aktuell auch Impulse für unseren Alltag. Na, wenn das keine Revolution ist! 😉

Foto: Sinnesbichler