Judith Andresen berichtet in der Windows Developer 10/2014 über die verschiedenen Bedeutungen des "Agil(er) Werdens" für Teams & Unternehmen.
Agile Veränderung findet auf vielen Ebenen statt!
„Agil!“ ist die Projekt-Forderung unserer Zeit. Projektmanager preisen die Effizienz agiler Projektmethoden – klein, schnell und robust sei der Entwicklungsprozess. Und man könne noch spät Anforderungen ändern – super! Andere zeigen auf einen anderen Aspekt: Von einem Arbeitnehmer-Markt ist die Rede, für den Unternehmen attraktiv werden müssen. Dafür brauche man agile Projektmethoden, sonst sei man draußen vor. Andere sprechen von einem vollständigen Kulturwandel für Unternehmen. Sind das alles unterschiedliche Aspekte einer agilen Transition? Oder steckt etwas Anderes dahinter?
„Wir arbeiten so ungefähr nach SCRUM“ ist eine häufige Erklärung, wie agiles Arbeiten in Unternehmen funktioniert. Auf Nachfrage erläutern die Beteiligten dann, dass im Grunde alle SCRUM-Artefakte „irgendwie“ benutzt würden – nur für die Retrospektive hätten alle Beteiligten keine Zeit.
Diese Art des „agilen Arbeitens“ ist sehr weit verbreitet. Und diese Art trifft die agile Idee nicht im Mindesten.
"So wie beim letzten Mal" wird durch "agil" abgelöst
Software-Projekte sind immer komplexer geworden. Aus einer einfachen Aktivitätenliste mit vielleicht zwanzig Punkten sind heute hoch komplexe Projekte geworden, die unter anderem Anforderungen aus den Bereichen
- Geschäftswert
- Corporate Design
- Sicherheit
- User Experience
häufig unter Wachstumsdruck erfüllen müssen. Um ein Software-Projekt mit vielen komplexen Anforderungen und Begleitparametern erfolgreich zu vollenden, genügt die einfache Aufgabenliste nicht.
In vielen Fällen ist für eine einzelne Person, den Projektmanager oder die Projektmanagerin, das Gesamtprojekt nur noch schwer zu übersehen. Es stellen sich Fehler ein. Die einfache Lösung: an Stelle der bisherigen Wasserfall-Methode solle eine agile Methode eingeführt werden.
Da viele Unternehmen mit der Zeit in diese komplexe Projektwelt hineingewachsen sind, haben die Beteiligten zu keinem Zeitpunkt klar über die Projektmethode reflektiert. Das bisherige Vorgehen entstand unreflektiert durch jeweils Kopieren des letzten Projekts. Die Projektmethode „So wie beim letzten Mal“ kopiert so auch die Fehler des letzten Projekts – ohne einen Erkenntnisgewinn oder die Verbesserung der Methodenbausteine.
Viele Teams verwechseln „So wie beim letzten Mal“ mit dem Wasserfall-Verfahren. Typische Methodenbausteine der „So wie beim letzten Mal-“Projektmethode sind eine lange ToDo-Liste, KickOff-Meetings mit der Verteilung aller Aufgaben im Voraus, Aufgabensteuerung und Erfolgskontrolle über Tickets sowie der Erwartungshaltung, dass das Projektmanagement auch die Qualitätssicherung übernimmt.
Diese Methodenbausteine reichten für eine Aufgabe im offensichtlichen Projekthabitat aus. Wenn aber die Abhängigkeiten und die Anforderung für Projekte in dem betreffenden Unternehmen deutlich komplexer geworden sind, helfen diese Methodenbausteine nicht, um den Überblick zu halten und eine Prozessanpassung an die komplexen Anforderungen zu ermöglichen.
So gerät das Projektteam durch die Anwendung von „So wie beim letzten Mal“ in den Status „Disorder“, wie ihn das Cynefin-Framework (Dave Snowden)[1] beschreibt.
Wie schwierig ist unsere Projektaufgabe?
Der Walise Dave Snowden unterscheidet fünf Projekthabitate mit dem Cynefin-Framework. Abhängig vom Habitat empfiehlt es sich, grundsätzliche Fragestellungen mit der Projektmethode zu beantworten.
-
Obvious: Im offensichtlichen Habitat besteht ein klarer Wirkungsmechanismus zwischen Aufgabe und Lösung. Hier helfen „Best Practices“ zur Lösung der Aufgabe. Es gilt zu analysieren, welche Aufgaben
In diesem Habitat agiert häufig eine direktive Leitung nach dem V-Modell mit ToDo-Listen zur Erfassung und Steuerung der Aufgaben.
-
Complicated: Im komplizierten Habitat sind Ursache und Wirkung zeitlich und räumlich voneinander getrennt. Im Prinzip ist aber der gesamte Verlauf vorhersagbar. Aus „Best Practices“ werden hier „good practices“. An Stelle eines einfachen Kopierens von Erfolgsrezepten werden diese an den entsprechenden Fall angepasst.
Es sind entweder direktive Leitungstandems mit Projektplänen (nach ITIL) oder über Kanban selbstorganisierte Teams aktiv.
-
Complex: Im komplexen Habitat ist kein klarer Ursache-Wirkungsmechanismus mehr erkennbar. Es gibt in Teilen erkennbare Muster und etliche Unbekannte. Komplexe Habitate fordern eine Projektmethode, die Lernen zulässt und fördert. Hier sind agile Methoden wie Kanban oder SCRUM zu Hause.
-
Chaotic: Im chaotischen Umfeld ist eine neue Aufgabe in einem neuen Umfeld zu bewältigen. Es gibt viele Unbekannte und viele Turbulenzen. Das Projektteam wird Themen prototypisch entwickeln und aus dem Verlauf lernen, wie es zum Beispiel durch die Methode XP ermöglicht wird.
-
Disorder: Wenn die Projektanforderungen und die gelebte Projektmethode nicht miteinander im Einklang stehen, befindet sich das Projekt in „Disorder“. Es ist die dringenste und wichtigste Aufgabe, die Projektumgebung zu bestimmen und eine passende Projektmethode explizit zu benennen und ans Laufen zu bringen.
„Disorder“ ist ein denkbar schlechtes Projekthabitat. Die angewendeten Projektmethoden passen nicht zur Aufgabenstellung. Dieses Missverhältnis nehmen viele Unternehmen wahr. An Stelle einer klaren Aufgabenanalyse, einer Einordnung in das „offensichtliche“, „komplizierte“, „komplexe“ oder „chaotische“ Habitat und der nachfolgenden Methodenwahl erklären Teams häufig, dass Wasserfall-Modell habe nicht funktioniert – es müsse nun eine agile Projektmethode her.
In offensichtlichen und komplizierten Habitaten sind aber direktive Projektmethoden agilen Projektmethoden häufig überlegen. Die Projektumgebung, die sehr klar und vorhersagbar ist, fordert kein Teamwissen, sondern eine klare Aufgabeneinteilung. Die Aufgaben sind der Art geschnitten, dass eine Leitungskraft oder ein Leitungstandem die Aufgaben gut im Überblick behalten können.
Insofern würde es einem Team, das von einem offensichtlichen in ein kompliziertes Habitat gewechselt ist, helfen, wenn das Team einen Projektrythmus einführt und Zwischenabnahmen nutzt.
Alternativ könnte dieses Team eine bessere Projektsteuerung im komplizierten Habitat mit der agilen Methode Kanban erreichen. Diese Projektmethode setzt auf eine Visualisierung des Prozesses und klare Modellierung des Vorgehens, basierend auf einer hohen Feedback-Kultur. Kanban stammt ursprünglich aus der Fertigungsindustrie und kann daher gut in komplizierte Projektumgebungen übertragen werden.
Eine bewusste Auseinandersetzung mit der Projektumgebung und der nachfolgenden Auswahl der passenden Projektmethode unterlassen viele Unternehmen. Stattdessen hoffen alle durch den Befreiungsschlag durch das Aufsetzen der Projektmethode SCRUM. Dies ist aber vorallem einem hohen Zertifizierungsgrad der Beteiligten als SCRUM-Master oder Product Owner geschuldet – leider aber nicht der Analyse der Projektanforderungen.
"Agile Projektmethoden" ohne Retrospektiven sind nicht agil!
Das bloße Anwenden einer Projektmethode wird das betreffende Team nicht aus der Projektumgebung „Disorder“ herausführen.
In vielen Fällen unterlassen Teams die Basismethoden, die agiles Arbeiten ausmachen. So führen viele Teams viele Methodenbausteine und Rollen einer agilen Projektmethode ein, verzichten aber aus Zeitdruck auf die Retrospektiven, wie sie das zwölfte Prinzip hinter dem agilen Manifest [2] fordert: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“
Der angewendete Methodensatz verzichtet also auf eine Kernforderung des agilen Manifests. Dieser ist nicht mehr als agil zu verstehen.
Für komplexe oder chaotische Projektumgebungen sind aber Feedback und Lernen wesentliche Elemente, um überhaupt zum Ziel kommen zu können. Wenn die Komplexität der Aufgabenstellung es erfordert,
sind Lernen und Anpassen der Prozesse ein wesentlicher Erfolgsfaktor.
Während der Verzicht auf regelmäßige Retrospektiven in einem offensichtlichen oder komplizierten Projekthabitat passen kann, führt er für komplexere Aufgaben direkt ins Habitat „Disorder“. Das Team kann ohne Lernelemente nicht auf geänderte Anforderungen oder Rahmenbedingungen sinnvoll reagieren.
Tipp 1: Bestimmt das Projektvorgehen mit dem Cynefin-Framework
Damit das Team auf die richtige Projektmethode setzt, sind zur Bestimmung des passenden Cynefin-Frameworks einige Fragen zu beantworten:
-
Ist die Aufgabe klar zu beschreiben?
-
Was ist der bekannte Anfangs-, was der bestimmte Zielzustand?
-
Kennen wir alle Rahmenbedingungen?
-
Kennen wir alle Anforderungen? Werden diese sich wahrscheinlich ändern? Haben die Änderungen voraussichtlich große Auswirkungen?
-
Sind Störungen und Anforderungsänderungen zu erwarten? Welches Ausmaß haben diese?
-
Unter welchem Zeitdruck stehen wir? Bringt dieser Zeitdruck Turbulenzen ins System?
In Abhängigkeit von den Antworten sortiert das Team die Aufgabe in eines der vier Habitate „obvious“, „complicated“, „complex“ beziehungsweise „chaotic“ ein und bestimmt eine passende Projektmethode.
Die erste Forderung nach einer agilen Projektmethode basiert häufig auf dem Unbehagen über die aktuelle Projektmethode „So wie beim letzten Mal“.
Um die nächste Pleite zu vermeiden, ist sicherzustellen, dass die nächste Projektmethode zu den Teamaufgaben passt. Eine bewusste Wahl wird helfen, die richtige (womöglich agile) Projektmethode zu wählen.
Tipp 2: Agile Projektmethoden für komplexe und chaotische Habitat
Analysiert Euer Projekthabitat und wählt anschließend passende Methodenbausteine für Euch!Ihr solltet Methodenbausteine definieren, die die nachfolgenden Fragen beantworten. Diese Fragen orientieren sich an den zehn Wissensbereichen des Projektmanagements [3]:
-
Wie wird die Anforderungsaufnahme funktionieren?
-
Wie werden Anforderungsänderungen erfasst?
-
Wie werden die Aufgaben abgeleitet und verteilt?
-
Wie funktioniert unsere Qualitätssicherung?
-
Wie stellen wir sicher, dass die Projektinformationen die Team-Mitglieder gut erreichen?
-
Wie erkennen wir und das einzelne Team-Mitglied, wann Aufgaben fertig sind?
-
Wie werden Risiken erfasst und verarbeitet?
-
Wie und wann werden wir lernen? Inhaltlich und im Prozess?
-
Wie erfassen wir den Projektstatus?
-
Wie unterstützen wir uns gegenseitig?
In offensichtlichen Projekthabitaten wird es branchenweite oder zumindest firmenweite „Best Practices“ geben, die diese Fragen sinnvoll beantworten. Für komplizierte Habitate gilt es diese so
anzupassen, dass alle Fragen gut beantwortet werden. Die Anforderungsaufnahme und -bearbeitung erfolgt in diesen Habitaten meistens im Wasserfall-Modell, also seriell und aufeinander
aufbauend.
In den anderen Habitaten ist meistens ein lernendes, iteratives Vorgehen effizienter. In einigen komplizierten, vorallem in komplexen und chaotischen Projekthabitaten sind agile Projektmethoden unerlässlich. Durch Retrospektiven und eine gemeinsame Statuserfassung und Aufgabenverteilung bringt das Team das Wissen und Know-How zusammen, um die schwierigen Aufgaben gemeinsam zu meistern.
Agil bedeutet interdisziplinär, auf Augenhöhe mit einer kooperativen Führung
Hinter der Forderung nach agilem Arbeiten kann aber auch eine ganz anderer Wunsch liegen. Das agile Manifest fordert „ Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ [3]. Darüber hinaus wird mit dem vierten und fünften Prinzip interdisziplinäre Teamarbeit gefordert:
-
„Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.“
-
„Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“
Viele Mitarbeiter und Mitarbeiterinnen fühlen, dass Projekte besser zu meistern wären, wenn sie gleichberechtigt und auf Augenhöhe mit der Führungsebene die Projekte voran bringen würden. Sie fühlen auch, dass an Stelle einer autoritären Führung, die alle Entscheidungen für sich in Anspruch nimmt, eine kooperative Führung, die den Raum für Entscheidungen gibt und diese absichert, die Projekte weiterbringen würde.
Hinter dem Wunsch, agile Projektmethoden einzuführen, kann also auch der implizite Wunsch nach einer anderen Führungs- und Feedbackkultur stehen – und auch der implizite Wunsch nach mehr Erfolg. Agil durchgeführte Projekte sind erfolgreicher als klassisch geführte Projekte. 2011 zeigte die Chaos-Studie [5], dass nur 14% der klassisch geführten IT-Projekte zum Erfolg kommen – im Gegensatz zu 42% Erfolgsquote in agilen Projekten.
Agile Projekte sind im Schnitt kleiner als klassisch geführte Projekte, setzen auf Feedback, Transparenz und Selbstorganisation des Teams – und sind so erfolgreicher als klassisch geführte Projekte, die gleichzeitig fachlich-technische Exzellenz und Prozesswissen von einer Person, dem Projektmanager oder der Projektmanagerin, fordern.
Agil: Transparenz, Feedback & Selbstorganisation
Agiles Arbeiten basiert auf den drei Grundwerten Transparenz, Feedback und Selbst-Organisation [6].
-
Das Team stellt intern und gegenüber den Auftraggebern und Auftraggeberinnen zu jedem Zeitpunkt Transparenz über die Qualität, den Grad der Aufgabenerfüllung, Risiken und Störfaktoren her. Alle Beteiligten sind ehrlich zueinander und begegnen sich auf Augenhöhe.
Entscheidungswege werden offengelegt. -
Alle im System geben sich regelmäßig Feedback sowohl über Arbeitsstände als auch über das Verhalten. Kooperative Führungskräfte führen durch Coaching. Auftraggeber und -geberinnen werden in das Feedback mit eingeschlossen. Der Umgang ist partnerschaftlich.
-
Alle Beteiligten organisieren sich und Prozesse selbst, wie es am effizientesten für die Aufgabenerfüllung ist. Oberstes Maß für gute Prozesse ist ein hoher Geschäftsbeitrag, der von allen Beteiligten angestrebt wird. Die Selbstorganisation der Teams wird von den Führungskräften gefordert und ermöglicht.
Mit diesen Werten wird eine bestimmte Kultur gefordert. Kultur entsteht aber nicht durch das Benennen von Leitwerten. Kultur zeigt sich in den Handlungen der Beteiligten – entsprechend der Unternehmenskultur-Definition „This is how we do things around here“ [7, Amazon-Link].
Damit die Handlungen zur agilen Kultur passen, sind Organisationsstruktur und Prozesse anzupassen. Durch die Ausprägung einer (womöglich fluiden, beweglichen) Organisation und agiler Prozesse werden die Unternehmensziele beeinflusst.
Die Forderung agilen Arbeitens führt also zu komplexen Veränderungen in der gesamten Organisation. Wer der impliziten Forderung nach einer agilen Kultur durch die Einführung von agilen Projektmethoden beantwortet, wird also im Nachgang auch Änderungswünsche in anderen Bereichen erleben.
Wenn dieser Prozess nicht offensiv eingefordert und gefördert wird, sind Konflikte im Unternehmen unabwendbar. Während die einen gerne in ihrer klassisch geführten Welt verbleiben möchten, wünschen die anderen mehr Beteiligung und mehr Einbindung in Prozesse.
Der explizite Wunsch nach einer Kulturveränderung durch die Leitungsebene und das Aufsetzen eines geeigneten Prozesses macht dagegen die Veränderung zum agilen Arbeiten und Denken, also die agile Transition, notwendig.
Tipp 3: Eine agile Transition ist ein komplexes Projekt
Die agile Transition beschreibt den Prozess des klassisch geführten zu einem agil operierenden Unternehmen. Dieser Prozess ist komplex. Es gibt viele Unbekannte und viele konkurrierende Umsetzungsideen.
Daher ist die agile Transition als agiles Projekt aufzusetzen. Die Projektführung gehört in die Hände eines sich selbstorganisierenden Teams. Um die Arbeit erfolgreich abzuschließen, empfiehlt die Autorin mindestens die agilen Basismethoden:
-
Wandzeitung / agiles Board
-
Daily StandUps
-
Reviews
-
Retrospektiven
Die Arbeit des Transitionsteams sollte in Sprints erfolgen. Durch geeignete Großgruppenmoderation wird das gesamte Unternehmen regelmäßig über den Projektstand informiert und in die Aktivitäten integriert. Agile Transitionen funktionieren dann besonders gut, wenn man Personen ins Team holt, die eine Transition in einen anderen Kontext oder Unternehmen bereits erfolgreich absolviert haben.
Eine agile Transition führt zu Veränderungen auf vielen Ebenen des Unternehmens. Entsprechend lange dauert dieses Projekt. Durch die Etablierung von Feedback und Selbstorganisation wird das Ergebnis nicht statisch sein, sondern das Unternehmen wird einen Weg gefunden haben, sich entsprechend der Marktanforderungen immer wieder anzupassen und neu auszurichten. Treibend für diese Entwicklung ist die agile Wertewelt. So beschreibt einer der jimdo-Gründer Fridtjof Detzner die Arbeit in dem Unternehmen zu einem Zeitpunkt mit 80 Mitarbeitern und Mitarbeiterinnen so: „Wir arbeiteten damals nicht nach SCRUM. Und wir hatten Kanban noch nicht für uns etabliert. Wir waren aber transparent miteinander und wollten voneinander lernen. Wir waren also agil, ohne es zu nennen.“. Mit seinen heute nahezu 200 Kollegen und Kolleginnen hat jimdo weltweit über vier Standorte Kanban als übergreifende agile Projektmethode etabliert. Um die Arbeit über die gesamte Arbeit hinaus zu priorisieren und die Kräfte zu bündeln, ruft jimdo jährlich ein neues „Goal No. 1“ aus. Die Triebfeder für die gesamte Entwicklung jimdos war das grundsätzliche Verständnis der Gründer, wie sich ein Unternehmen anfühlt, für das der oder die Einzelne gerne arbeitet.
Die agile Arbeitsweise zeigt sich also in den formulierten und gelebten offenen und kommunikativen Werten, den auf Kanban basierenden Prozessen und einer auf diese Prozesse und Denkweise abgestimmte Formulierung der Ziele.
Agile Projektmethoden alleine machen noch kein agiles Unternehmen
Für viele Mitarbeiter und Mitarbeiterinnen ist ein agiles Unternehmen anstrebenswert. Das Gegenmodell der autoritären, sich nicht erklärenden Führung zeigt sich in einem kooperativen, interdisziplinären und transparenten Umgang.
Viele Unternehmen spüren heute, dass im Zeichen eines Arbeiternehmer-Marktes sie ohne agiles Arbeiten an Attraktivität verlieren. Um weiterhin als attraktiv wahrgenommen zu werden, führen diese Unternehmen dann agile Projektmethoden ein. Neben der Attraktivitätssteigerung lassen sich die Beteiligten von dem Versprechen leiten, dass agile Projekte effizienter verlaufen als klassisch geführte Projekte.
Ohne eine Kulturänderung und das Ermöglichen der interdisziplinären, transparenten Zusammenarbeit – auch mit den Auftraggebern und Auftraggeberinnen und anderen beteiligten Abteilungen – wird die Einführung agiler Projektmethoden nicht gelingen.
Die Einführung verkommt dann zu einer Alibi-Vorstellung. Gerade in solchen Unternehmen unterlassen viele Projektteams die Durchführung von Retrospektiven. Eine wirkliche Veränderung von Prozessen ist nicht erwünscht und nicht möglich. Weil Teams das spüren, setzen sie sich erst gar nicht frustrierenden Sitzungen aus.
Wer wirklich agil arbeiten möchte, orientiert sich an agilen Werten
Um die Arbeit in dem jeweiligen Habitat optimal zu erfüllen, definieren die Teams sich eine passende Projektmethode. Dabei sollten sie sich aus allen bekannten Projektmethoden bedienen, egal ob sie aus der klassischen oder der agilen Welt stammen. Insbesondere sind immer Methodenbausteine zu definieren, die Lernen und eine Prozessoptimierung ermöglichen. Je einfacher das Projekthabitat ist, desto seltener finden die entsprechendenen Prozesselemente (z.B. in Form von „Lessons learned“-Sitzungen oder Retrospektiven) statt.
Von der Einführung agiler Projektmethoden zur Erhöhung der Arbeitgeber-Attraktivität ist abzusehen. Dieses Alibi-Anliegen wird scheitern und für alle Beteiligten nur frustrierend wirken.
Wer eine neue Unternehmenskultur basierend auf agilen Prozessen etablieren möchte, sollte diesen Weg bewusst gehen. Dafür wirkt ein Transitionsteam als Takt- und Impulsgeber in dem Unternehmen. Der Impuls, agile Werte zu formulieren und eine agile Projektmethode mit dem Transitionsteam vorzuleben, wird gute Früchte im Unternehmen tragen. Versprochen!
Dieser Artikel ist die Zweitveröffentlichung des Beitrags "Agil(er) werden" von Judith Andresen in der Windows Developer 10/2014 | Weitere Artikel in der Artikelübersicht.
- Nächster Artikel: Windows Developer | Agil(er) werden!
- Vorheriger Artikel: "In allen Interviews wurde klar, dass Manager nicht mehr planen können."
Kommentar schreiben