Agile Methoden

Um agile Prinzipien und Ideen in die unternehmerische Realität einzubauen, braucht es konkrete agile Methoden und Tools. Diese Methoden können an unterschiedlichen Punkten ansetzen, z.B. bei Teams (z.B. Scrum und Kanban), beim Kunden (z.B. Customer Journey), bei der Unternehmensorganisation oder bei der Zielsetzung und Strategie (z.B. Objectives und Key Results - kurz OKRs).

Eine Studie von McKinsey aus dem letzten Jahr (2021) zeigt, dass cross-funktionale Teams in etwa 75 Prozent aller befragten Unternehmen eingesetzt werden (74 Prozent). Selbstorganisierte Teams kommen in etwa der Hälfte der Unternehmen vor (49 Prozent), ein Lean-Ansatz bei 44 Prozent. Methoden zur Teamorganisation, wie Scrum oder Kanban kommen in 40 Prozent aller befragten Unternehmen zum Einsatz.

Schaut man sich Organisationen an, die bisher noch keinen Plan für eine agile Transformation haben, werden vor allem “andere Prioritäten auf der Agenda” (52 Prozent) und “Unwissen über Agilität/agile Methoden” (49 Prozent) genannt. Den ersten Punkt haben  wir in unserem Blogartikel zur Frage, warum digitale Transformationen in Unternehmen scheitern, bereits aufgegriffen. Kurz zusammengefasst: “Die digitale Transformation scheitert am Allerhäufigsten, weil Sie nicht angegangen wird.“ Damit Unwissenheit Sie nicht weiter abhält, werfen wir in diesem Artikel einen Blick auf unterschiedliche agile Methoden und zeigen, welche Ideen und Konzepte ihnen zu Grunde liegen.

Vorteile agiler Methoden

Eine (erfolgreiche) agile Transformation bringt viele Vorteile mit sich - von Mitarbeiterzufriedenheit über Schnelligkeit und Effizient zu messbar verbesserten Finanzkennzahlen. Um diese Vorteile im eigenen Unternehmen nutzen zu können, gibt es eine Reihe von agilen Methoden, die das recht abstrakte Thema “Agilität” so weit herunterbrechen, dass konkrete Handlungsschritte und Prozesse abgeleitet werden können. Im Folgenden schauen wir uns einige dieser Methoden genauer an. Wichtig ist zu verstehen, dass diese Methoden sich gegenseitig ergänzen können und damit eine Entscheidung für eine Methode keine automatische Entscheidung gegen eine andere ist.

Design Thinking

Die Grundidee des Design Thinking als agiler Methode besteht darin, Ideen zu entwickeln und sie immer wieder auszuprobieren, bis man mit dem Endergebnis zufrieden ist oder bis ein Produkt oder ein Feature funktioniert.  Der Design Thinking Prozess besteht aus sechs Phasen: Verstehen, Beobachten, Sichtweise definieren, Ideen finden, Prototypen entwickeln und Testen.

Wie die Grafik zeigt, sind diese Schritte miteinander und untereinander stark vernetzt und werden in Schleifen durchlaufen. Das Scheitern bzw. die Iteration (d.h. Wiederholung) ist ein zentraler Punkt der Methode, denn nur so können Entwürfe und Ideen verbessert werden. Die ersten Ansätze zur Anwendung des kontinuierlichen Prozesses von “Trial and Error” (Versuch und Scheitern) in Unternehmenskontexten wurden von der amerikanischen Beratungsfirma IDEO vorgestellt, und von den beiden Gründern Bill Moggridge und David Kelley stetig weiterentwickelt. Der deutsche SAP-Gründer Hasso Plattner war von diesem Ansatz bei einem Besuch in Stanford so beeindruckt, dass er die D-School mit stolzen 30 Millionen Dollar finanzierte und 2007 das Konzept in seine deutsche Heimat brachte, indem er eine zweite D-School in Potsdam gründete - das Hasso-Plattner-Institut (HPI).

Agile Methode: Lean Startup

Der Lean Startup Ansatz geht auf den US-Gründer, Tech-Unternehmer und Softwareentwickler Eric Ries zurück, der das Konzept mit seinem 2011 erschienenen Buch „The Lean Startup“ manifestierte. Lean Startup bedeutet auf deutsch übersetzt so viel wie “schlankes Unternehmen” oder “schlanke Gründung” und zielt darauf ab, die Entwicklungszyklen von Produkten zu verkürzen. Ähnlich wie beim Design Thinking geht es beim Lean Startup darum, mit Ideen zu experimentieren und in iterativen Prozessen dazuzulernen, Feedback zu bekommen und Produkte kontinuierlich anzupassen und weiterzuentwickeln.

Kennzeichnend für den Lean Startup Ansatz ist der “Build-Measure-Learn”-Zyklus. Die Feedbackschleife besteht aus den drei Stationen “Build” (dem Bauen und Entwerfen einer Idee oder eines Produkts), “Measure” (dem Sammeln von Daten und dem Messen von Erfolg und Misserfolg) und “Learn” (der Auswertung und Evaluation der Daten, um einen neuen Zyklus vorzubereiten). Der Prozess ist bewusst als Kreis angelegt, da es darum geht, mit jeder neuen Schleife neue Annahmen zu testen, dazuzulernen, Dinge anzupassen und so kontinuierlich besser zu werden. Komplizierte und komplexe Businesspläne finden beim Lean Startup Ansatz keinen Platz; hier geht es darum, schnell und unkompliziert Ideen und Hypothesen zu testen, zu widerlegen bzw. zu bestätigen und dann weiterzuentwickeln.

Typisch für den Build-Measure-Learn-Prozess des Lean Startup ist das sogenannte “Minimum Viable Product” (kurz MVP). Das MVP ist die kleinste/schmalste Version eines Produktes, die entwickelt wird, um Kundenfeedback einzuholen oder Funktionsweisen zu testen. Ein Produktentwurf mit minimalen Anforderungen soll es möglich machen, grundlegende Hypothesen und Ideen zu testen, ohne direkt ein Produkt mit einer langen Liste an (möglicherweise unnötigen/unpraktischen/teuren) Features zu entwickeln. Ein MVP ermöglicht schnelle Feedbackschleifen und einen unkomplizierten Test, ob man in die richtige Richtung denkt bzw. entwickelt.

Design Sprint als agile Methode

Abgeleitet aus dem Design Thinking und Lean Startup ist die agile Methode des sogenannten Design Sprint. In einem solchen Design Sprint geht es darum, konzentriert an zentralen Produkt- oder Strategiefragen zu arbeiten. Ein Sprint dauert i.d.R. fünf Tage (d.h. eine Arbeitswoche) und ist nach einer Iteration zu Ende. Innerhalb eines Sprints wird der oben beschriebene Design Thinking Prozess durchlaufen, sodass am Ende ein Ergebnis bzw. Prototyp vorgestellt werden kann. Design Sprints sind eine agile Methode, die sich besonders eignet, um neue Themen oder Ideen in einem abgesteckten Zeitraum zu “durchdenken”. Die Phasen des Design Thinking Prozesses ermöglichen es, ein ganzheitliches Bild einer Fragestellung oder eines Themas zu bekommen, ohne dabei den Fokus zu verlieren. Die zeitliche Begrenzung sorgt dafür, dass erste Ergebnisse bereits nach einer Woche (sprich: einem Sprint-Durchgang) besprochen werden können (Siehe hierzu auch die Rolle des Product Owner). 

OKRs

Die Abkürzung OKRs steht für “Objectives and Key Results”. OKRs helfen dabei, Ziele im Unternehmen und in einzelnen Abteilungen festzuhalten und zu managen - mit qualitativen Zielen (den Objectives) und quantitativen Metriken (Key Results). Ein Objective ist das, meist ambitionierte, Ziel eines Unternehmens oder Teams, das erreicht werden soll. Dieses Objective ist meist qualitativ und beschreibt einen gewünschten Zielzustand. Zahlen, Daten und Fakten kommen bei den Key Results ins Spiel. Hier geht es um die Konkretisierung des Objectives und um ein messbares Ergebnis, anhand dessen abgelesen werden kann, ob ein Ziel erreicht wurde oder nicht. Ein Objective soll emotional aktivieren und motivieren. Es ist klar und für alle verständlich formuliert und beschreibt einen gewünschten Zielzustand für die Zukunft und keine konkreten Aktivitäten. Ein Objective soll positiv formuliert sein und nicht auf Vermeidungen aufbauen, d.h. es geht nicht um “weniger Kontrolle”, sondern um “mehr Selbstbestimmung”. 

Zu jedem Objective gehören mehrere Key Results, die das große Ziel durch konkrete Maßnahmen konkretisieren und die Erreichung messbar machen. Idealerweise gibt es zwei bis fünf Key Results pro Objective, die eine eindeutige Bewertung zulassen, ob ein Ziel erreicht wurde oder nicht. Key Results bestehen daher immer aus konkreten Zahlen (z.B. “A steigt auf/sinkt auf..”; “B bleibt über/unter..”). OKRs sind nicht nur zur (kurzfristigen) Planung von konkreten Zielen in einem Teilbereich geeignet, sondern können mittel- und langfristig helfen, die verschiedenen Ziele einer Organisation zu synchronisieren und aufeinander abzustimmen. Um OKRs im gesamten Unternehmen einsetzen zu können, wird häufig zwischen  “Top Level OKRs” und “Operativen OKRs” unterschieden. “Top Level OKRs” beziehen sich auf strategische Ziele und haben daher einen langfristigen Planungshorizont von beispielsweise 1-3 Jahren. “Operative OKRs” sind die Ziele und Ergebnisse, die in konkreten Abteilungen und Teams erreicht werden sollen. Hier können Iterationen viel kurzfristiger stattfinden, beispielsweise 1x/Halbjahr oder 1x/Quartal. Die Erfahrung hat gezeigt, dass maximal drei OKRs pro Team/Abteilung für eine Iteration eine gute Anzahl sind, die ambitioniert, aber schaffbar ist. Agilität kommt bei OKRs dazu, wenn es darum geht, genau diese Iterationen zu evaluieren, in welchem Rahmen die selbst gesteckten Ziele erreicht wurden und wie sie ggf. für eine nächste Iteration angepasst werden sollten.

Scrum

Wie viele der hier vorgestellten Methoden kommt auch Scrum ursprünglich aus der Softwareentwicklung, hat sich aber mittlerweile in der BWL durchgesetzt und wird in verschiedenen Unternehmen eingesetzt. Scrum folgt einem klaren Framework, um einen idealtypischen agilen Prozess abzubilden. Viele Elemente, die bereits in anderen Methoden vorgestellt wurden, kommen auch bei Scrum vor - z.B. Iterationen oder Sprints. 

Bei Scrum wird mit sogenannten Scrum-Zyklen gearbeitet, die i.d.R. maximal vier Wochen dauern. Zu Beginn gibt es ein sogenanntes “Sprint-Planning”, bei dem das Scrum Team schaut, welche Aufgaben im kommenden Sprint priorisiert werden sollen. Dieses Treffen kann bis zu einen vollen Arbeitstag (d.h. 8 Stunden) in Anspruch nehmen, da hier die Grundlagen für die kommenden Wochen gelegt werden. Während der mehrwöchigen Umsetzung findet täglich das “Daily” statt, ein kurzes Meeting zu Beginn des Tages, um sich zu synchronisieren und die Prioritäten des Tages abzustecken (max. 15min). Zum Ende jedes Sprints gibt es ein “Sprint Review”, um auf die Arbeitsergebnisse zurück zu blicken, inhaltliche Anpassungen vorzunehmen und Themen für kommende Sprints zu priorisieren. Für dieses Treffen sollte ca. ein halber Arbeitstag (d.h. 4 Stunden) eingeplant werden. Ein gemeinsames Reflexionsmeeting, die sogenannte “Retrospektive” hilft, Vereinbarungen für den kommenden Sprint zu treffen, um im agilen Prozess stetig besser zusammenzuarbeiten. Auch hier sind ca. vier Stunden eine gute Dauer, um allen Beteiligten Raum zu geben, zu reflektieren, Erkenntnisse zu verdichten und To Dos für den kommenden Sprint zu definieren.

Im Scrum Framework gibt es feste Rollen und Verantwortlichkeiten: Einen Product Owner, einen Scrum Master und ein Entwicklerteam. Was genau es mit diesen Rollen auf sich hat und wie ein Scrum-Team am besten zusammenarbeiten kann, haben wir in unserem Blog zusammengefasst.

Kanban

Wer Kanban hört, denkt vermutlich zuerst an das bekannte Kanban-Board. Das Board hilft Teams dabei, ihre Aufgaben innerhalb von Projekt im Blick zu haben, Fortschritte zu sehen und jederzeit transparent zu wissen, wer gerade an welcher Aufgabe arbeitet oder an bereits erledigten Aufgaben gearbeitet hat. Kanban kommt ursprünglich aus dem Japanischen (Bedeutung: Signalkarte) und wurde von Toyota im Produktionsprozess von Autos eingesetzt.

Ein Kanban-Board besteht klassischerweise aus drei Spalten: “To Do” (dt.: zu bearbeiten); “Doing” (dt.: in Arbeit) und “Done” (dt.: Erledigt). Die zentrale Idee ist es, dass jeder Arbeitsschritt bzw. jede Aufgabe in einem Projekt auf einen Zettel (z.B. ein Post-It) geschrieben wird und dann, je nach Bearbeitungsstatus, das Kanban-Board von links nach rechts durchläuft. Offene Aufgaben starten in der “To Do”-Spalte. Die Teammitglieder suchen sich eigenständig die Aufgaben und Projekt aus, an denen sie arbeiten wollen und schieben sie dann während der Bearbeitung in die “Doing”-Spalte. Ist eine (Teil-)aufgabe erledigt, wird die Karte mit der Aufgabenbeschreibung in die letzte Spalte (“Done”) geschoben, sodass für alle im Team ersichtlich ist, dass diese Aufgabe fertig bearbeitet bzw. umgesetzt wurde. In erweiterten Boards kann es zusätzliche Spalten geben, z.B. eine “Backlog”-Spalte oder eine “On hold”-Spalte. Die Backlog-Spalte ist eine Art Sammelbecken für alle Aufgaben, die im Laufe eines Projektes anfallen. 

Damit die Zusammenarbeit gelingt, sollten zu Beginn einige “Spielregeln” festgehalten werden. Es sollte z.B. darüber gesprochen werden, welchen Arbeitsumfang ein Post-It umfassen sollte, oder wann etwas final in die “Done”-Spalte geschoben werden kann. Je nach Projekt und Deadlines kann außerdem eine Priorisierung einzelner Aufgaben helfen, den Fokus zu wahren. Ein Kanban-Board kann physisch (z.B. in einem Büro) mit Hilfe von Pinnwänden oder Whiteboards abgebildet werden. Für die digitale Zusammenarbeit eignen sich Tools wie Trello, Jira oder Microsoft Planner.

Weitere agile Methoden, neben den hier vorgestellten, sind: Crystal, Extreme Programming (XP), Feature-Driven Development (FDD), Domain-Driven Design (DDD), Dynamic Systems Development Method (DSDM), Soziokratie, Holokratie, Scaled Agile Framework, ScrumBan und Scrum XP Hybrid (auch das Business Modell Canvas könnte als agile Methode gewertet werden). 

Zusammenfassung I Agile Methoden auf einen Blick

Um eine erfolgreiche agile Transformation zu begleiten und erfolgreich zu arbeiten, braucht es das richtige “Handwerkszeug”. Die hier vorgestellten agilen Methoden können dieses Handwerkszeug sein, doch sollte vorab immer klar sein, dass die Tools nicht zum Selbstzweck eingesetzt werden, sondern auf einem tiefgreifenden Verständnis von Agilität als Mindset aufbauen. Vor jedem Einsatz sollte sich gut überlegt werden, wofür und mit welchem strategischen Ziel eine dieser Methoden verwendet werden soll. Dieser Blogartikel soll dabei helfen, hinter ein paar bekannte Methoden, wie Design Thinking, Scrum oder Kanban zu schauen, sodass nach dem “wofür”  individuell eine fundiertere Entscheidung getroffen werden kann, welcher Ansatz für welches Ziel, welches Team und welche Projektphase der richtige sein kann.