Die besten agilen Methoden im Job
E-Book, Deutsch, Band 341, 256 Seiten, E-Book
Reihe: Haufe TaschenGuide
ISBN: 978-3-648-14188-5
Verlag: Haufe
Format: EPUB
Kopierschutz: Wasserzeichen (»Systemvoraussetzungen)
Inhalte:
- Das agile Change 4.0-Modell für eine Welt mit geringer Planbarkeit
- Vom Modell, dem Mindset, der Haltung und Co-creation
- Tools und ihre Einsatzgebiete im Überblick: Design Thinking, Lego Serious Play, Canvas, Kanban, Scrum, OKR und EPIC Meeting
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
Inhalt
Agiles Arbeiten: viel mehr als ein Trend
- Der Klassiker: Planen nach der Wasserfallmethode
- Alles ist planbar? Ein Irrtum!
- Agil versus klassisch
- Reif für Agilität?
Ihr Weg in die Agilität
- Jede Reise braucht ein Ziel
- Ihr Navigationssystem: das Nickel&Keil-Umsetzungs-Modell
- Wie fit ist Ihr Unternehmen für den Change?
- Agilität beginnt mit der richtigen Haltung
- Co-Creation - gemeinsam oder gar nicht
Die agilen Tools
- ROTI
- Business Model Canvas
- Kanban
- QuICk: der Quality Improvement Check
- Sprint Meetings
- Storytelling
- Persona
- Das agile Handlungsleitbild
- LEGO® Serious Play
- Working out Loud: WOL
- Purpose Circle Theater
- Agiles Mission Statement
- Viraler Schneeball
Die agilen Prozesse
- Scrum
- Agiles Coaching
- Design Thinking
- Objectives and Key Results: agiles Management mit Zielen
- Lean Startup
Die Umsetzung: Auf das Tun kommt es an
- Widerstand hat einen Grund
- Das Neue zur Gewohnheit machen
- Agiles Alignment: gemeinsam geht es schneller und besser
Stichwortverzeichnis
Die Autoren
Agiles Arbeiten: viel mehr als ein Trend
Agilität ist zwar kein Allheilmittel für Unternehmen. Sie ist jedoch wesentlich mehr als ein vorübergehender Hype oder ein Special für Softwareentwickler. In diesem Kapitel erfahren Sie u. a., wer vom agilen Arbeiten profitiert, auf welchem Fundament es gründet, ob Ihre Organisation reif für Agilität ist. Der Klassiker: Planen nach der Wasserfallmethode
Vermutlich wissen Sie, wo München ist. Aber kennen Sie Kohfidisch? Wahrscheinlich nicht. Susanne Nickel wohnt in München und Gunhard Keil in Kohfidisch, und als die Vision entstand, gemeinsam ein Unternehmen zu gründen, war klar, dass dies mit häufigeren Reisen verbunden sein würde. Mit der Arbeit an diesem TaschenGuide, den Sie hier in Ihren Händen halten, wurden der Abstimmungs- und damit auch der Reisebedarf gleich nochmals intensiver. Aber wie kommt man von Kohfidisch nach München? So eine Reise symbolisiert (fast) alle Prinzipien des Projektmanagements nach der klassischen Wasserfall-Methode: Vom Anfang bis zum Ende wird alles geplant. Mit klaren Messgrößen wird das Ziel beschrieben und der Weg zum Ziel anhand von Meilensteinen definiert. Die Reise startet in Kohfidisch Richtung Oberwart um 6.15 Uhr. Um 7 Uhr fährt der Anschlussbus nach Wien los und kommt dort um 8.30 Uhr an. Ab Wien geht es weiter mit dem Zug. Wenn alles gutgeht, also kein Stau, Unfall oder technisches Problem auftaucht, erreicht der ICE um 13.37 Uhr den Münchener Hauptbahnhof. Nach 15 Minuten Fußmarsch beginnen wir beide versorgt mit einer Tasse Kaffee um 13.52 Uhr am nächsten Kapitel zu arbeiten. Eine Reise von Kohfidisch nach München zu planen, ist zwar kompliziert, aber machbar, denn alles was man zur Planung benötigt, ist bekannt. Kein auch nur halbwegs organisierter Mensch würde auf die Idee kommen, seine Reisen nicht zu planen. Ungeplant kann die Reise deutlich länger dauern, und sehr viel mehr kosten. Doch nicht jedes Projekt funktioniert wie eine Reise. Es gibt Projekte, die nicht so planbar sind. Viele. Auch dieses Buch haben wir nicht nach dem klassischen Wasserfallmodell Kapitel für Kapitel geplant. Alles ist planbar? Ein Irrtum!
Seit 1994 untersucht die Standish Group, eine unabhängige Beratungsfirma für IT-Forschung, in ihren Chaos-Studien die Erfolgs- und Misserfolgsfaktoren in IT-Projekten (siehe www.standishgroup.com). Zu Beginn der Untersuchungen dominierten noch die nach der klassischen Wasserfall-Methode durchgeplanten IT-Projekte. Sie wiesen jedoch keine sehr beruhigende Statistik auf: Nur 16 % von ihnen wurden in vorgesehener Zeit, Qualität und Budget abgeschlossen, 53 % dauerten zu lange, kosteten zu viel und/oder erreichten nicht den angestrebten Funktionsumfang. Auch im Jahr 2015 kamen nur 29 % wie geplant über die Ziellinie, während 52 % zu teuer waren, zu lange dauerten oder nicht zufriedenstellend abgeschlossen wurden. Stattliche 19 % der IT-Projekte mussten – vermutlich aufgrund zu hoher Kosten – vorzeitig abgebrochen werden. Bei der Suche nach den Ursachen für diese schlechten Quoten kristallisierte sich heraus: In der Softwareentwicklung gibt es zu viele unbekannte Größen, als dass man alles von Anfang bis zum Ende planen kann. Und nicht nur dort: Tatsächlich hatte ja schon die Planwirtschaft der ehemaligen kommunistischen Länder bewiesen, dass zumindest das Wirtschaftsleben so nicht funktioniert. Schnell stellte sich die Frage: Wie kann man es besser machen? Klar, aufhören zu planen und einfach mal machen, ist ein Weg. Aber wer ist schon bereit, sein Geld auf die Aussage: »Schauen wir mal, …« zu investieren? Würden Sie das riskieren wollen? Vermutlich nicht. Die Wiege alles Agilen: das Agile Manifest
Stellen Sie sich vor, Sie entwickeln Software. Sie arbeiten Tag und Nacht, engagieren sich und am Ende haben Sie eine Erfolgsquote wie ein Arzt im Mittelalter. Das frustriert natürlich auf Dauer ungemein. Und so trafen sich 2001 in Utah 17 engagierte Software-Entwickler, um Abhilfe zu schaffen. Ihr Ziel war es, der einengenden, streng formalistischen und ausgeplanten Wasserfall-Methode, in der jeder einzelne Schritt und Meilenstein im Programm beschrieben ist, eine Alternative entgegenzusetzen. Das Ergebnis des Treffens in Utah war das Agile Manifest. Es wurde damals von seinen 17 Schöpfern und inzwischen von mehreren 100.000 Entwicklern unterzeichnet. Sie alle bekennen sich zu den im Agilen Manifest verankerten vier Grundwerten und zwölf Prinzipien des agilen Arbeitens. Die agilen Grundwerte
Das Agile Manifest stellt klar, dass neben den agilen Grundwerten auch die Werte aus dem klassischen Projektmanagement geschätzt werden. Wenn als Grundwert im Agilen Manifest festgelegt ist, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge, dann heißt das nicht etwa, dass es nun keine Prozesse mehr braucht oder dass Tools unwichtig sind. Es bedeutet vielmehr, dass es wichtig ist, auf Menschen und deren Interaktionen zu achten, damit Tools und Prozesse richtig eingesetzt werden. Die agilen Grundwerte Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge In der klassischen Entwicklung galt die Erfolgsweisheit: »Follow the protocol«: Es wurde stur den ursprünglichen Prozessanweisungen gefolgt. Diese mechanistische Vorgehensweise hilft natürlich, wenn im Prozess ausreichend Erfahrung verankert ist und die Situationen, für die diese Prozesse geschrieben wurden, typischer Standard sind. BEISPIEL: Die Reanimation eines Verunglückten muss tatsächlich »nach Protokoll« durchgeführt werden. Es ist sogar gefährlich, wenn die Wiederbelebung nach eigenem Gutdünken geschieht. Prozesse und Werkzeuge sind also durchaus wichtige Hilfen, wenn es darum geht, Standards einzuhalten, Funktionalität zu garantieren und vorhandenes Wissen zu verankern. Ist es jedoch das Ziel, Neues zu schaffen, sieht das anders aus. In solchen Fällen ist es tatsächlich wichtiger, die Erfahrungen und Beobachtungen aller Beteiligten erst einmal zu sammeln, auch wenn Regeln und Vorschriften vielleicht anderes vorsehen. Die Qualität des Dialogs steht hier im Vordergrund, denn durch die gemeinsame kreative Auseinandersetzung werden Innovationen gefördert, wie wir später in diesem TaschenGuide noch sehen werden. Funktionierende Produkte sind wichtiger als umfassende Dokumentation Im Agilen gibt es nur so viel Papierkram, wie tatsächlich notwendig ist. Viel wichtiger ist es, dass das Produkt für den Kunden sinnvoll einsetzbar ist. Statt ihre Energie in Aktenvermerke und Protokolle zu stecken, sollen die Beteiligten sich also auf eine gute Abstimmung untereinander und mit dem Kunden konzentrieren. Erst dann geht es auch um die Dokumentation, um Nachvollziehbarkeit zu schaffen. Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen Wenn es um Entwicklung und Innovation geht, sollte klar sein, wem neue Produkte, Services und Vorgehensweisen dienen sollten: den Kunden. In der agilen Welt arbeiten die zukünftigen Anwender und Entwickler eng zusammen. Das wird auch durch die Rollen im Scrum (siehe das gleichnamige Kapitel) deutlich: Der Product Owner ist jemand, der die Anforderungen der Zielgruppe versteht und diese für die Entwickler verständlich übersetzen kann. Das geschieht nicht nur, wenn das Lastenheft erstellt wird, sondern laufend in kurzen Abständen. Natürlich braucht es auch formelle Grundlagen für eine erfolgreiche Zusammenarbeit, doch die enge Abstimmung mit dem Kunden steht im Vordergrund. Die Reaktion auf Änderungen hat Vorrang vor strikter Planverfolgung Hat der Zug Verspätung, nützt der beste Fahrplan nichts. Dann heißt es möglichst rasch reagieren, denn wichtig ist die Ankunft am Zielort, nicht der Plan. Ebenso ist es in Projekten: Wenn während der Entwicklung eines neuen Produktes klar wird, dass andere Funktionen gebraucht werden, ist es eben wichtiger, sich rasch an die neue Situation anzupassen und nicht stur nach Plan etwas zu entwickeln, was nachher keiner brauchen wird. Bleiben wir noch kurz bei unserer Reise-Metapher: Solange alle Rahmenbedingungen bekannt sind – Fahrpläne, Hotelverfügbarkeiten und -preise, Öffnungszeiten usw. –, liefert die Wasserfall-Methode die besten Ergebnisse. Wenn Sie aber eine Expedition in unbekanntes Gebiet planen, sieht das anders aus. Alles, was Sie dann tun können, ist, agil vorzugehen: so viele Informationen sammeln wie möglich, dafür sorgen, dass das Team gut funktioniert und dann von Etappe zu Etappe die beste mögliche neue Route zum Expeditionsziel definieren. Die agilen Prinzipien
Doch nicht nur die Grundwerte sind...
