Agile Veränderung findet auf vielen Ebenen statt

Agil(er) werden!
Kommentare

„Agil“ ist die Projektforderung 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 Arbeitnehmermarkt ist die Rede, für den Unternehmen attraktiv werden müssen. Dafür brauche man agile Projektmethoden, sonst sei man auß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

Softwareprojekte sind immer umfangreicher 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 und User Experience häufig unter Wachstumsdruck erfüllen müssen. Um ein Softwareprojekt mit vielen komplexen Anforderungen und Begleitparametern erfolgreich zu vollenden, genügt die einfache Aufgabenliste da nicht mehr. 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: Anstelle der bisherigen Wasserfallmethode 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 durch 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 Wasserfallverfahren. Typische Methodenbausteine der „So wie beim letzten Mal-“Projektmethode sind eine lange To-do-Liste, Kick-off-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 behalten 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 von Dave Snowden beschreibt (Kasten: „Cynefin: Wie schwierig ist unsere Projektaufgabe?“).

Cynefin: Wie schwierig ist unsere Projektaufgabe? 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 (Abb. 1). 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 To-do-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-Wirkungs-Mechanismus 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 dringendste und wichtigste Aufgabe, die Projektumgebung zu bestimmen und eine passende Projektmethode explizit zu benennen und ans Laufen zu bringen.
Abb. 1: Cynefin-Framework mit fünf Projektumgebungen

„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, das Wasserfallmodell 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 derart geschnitten, dass eine Leitungskraft oder ein Leitungstandem die Aufgaben gut im Blick behalten können.

Insofern würde es einem Team, das von einem offensichtlichen in ein kompliziertes Habitat gewechselt ist, helfen, wenn das Team einen Projektrhythmus 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 Feedbackkultur. 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 auf den Befreiungsschlag mit dem Aufsetzen der Projektmethode Scrum. Dies ist aber vor allem einem hohen Zertifizierungsgrad der Beteiligten als Scrum Master oder Product Owner geschuldet, aber leider 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 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, Lernen und Anpassen der Prozesse wesentliche Elemente, um überhaupt zum Ziel kommen zu können. 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: 1. Ist die Aufgabe klar zu beschreiben? 2. Was ist der bekannte Anfangs-, was der bestimmte Zielzustand? 3. Kennen wir alle Rahmenbedingungen? 4. Kennen wir alle Anforderungen? Werden sie sich wahrscheinlich ändern? Haben die Änderungen voraussichtlich große Auswirkungen? 5. Sind Störungen und Anforderungsänderungen zu erwarten? Welches Ausmaß haben sie? 6. 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.

[ header = Seite 2: Tipp 2: Agile Projektmethoden für komplexe und chaotische Habitate ]

Tipp 2: Agile Projektmethoden für komplexe und chaotische Habitate

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: • 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 Teammitglieder gut erreichen? • Wie erkennen wir und das einzelne Teammitglied, 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 Wasserfallmodell, also seriell und aufeinander aufbauend. In den anderen Habitaten ist meistens ein lernendes, iteratives Vorgehen effizienter. In einigen komplizierten, vor allem 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 ein ganz anderer Wunsch liegen. Das agile Manifest fordert „ Individuen und Interaktionen mehr als Prozesse und Werkzeuge“. Darüber hinaus wird mit dem vierten und fünften Prinzip interdisziplinäre Teamarbeit gefordert: • „Fachexperten und Entwickler müssen während des Projekts 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 voranbringen würden. Sie fühlen auch, dass anstelle 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 Chaosstudie, dass nur 14 Prozent der klassisch geführten IT-Projekte zum Erfolg kommen – im Gegensatz zu 42 Prozent 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 (Kasten: „Agil: Transparenz, Feedback und Selbstorganisation“).

Agil: Transparenz, Feedback und Selbstorganisation Agiles Arbeiten basiert auf den drei Grundwerten Transparenz, Feedback und Selbstorganisation (siehe auch). • 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 Unternehmenskulturdefinition „This is how we do things around here“ (Quelle: Human Resource Management: Concepts and Practices). Damit die Handlungen zur agilen Kultur passen, müssen Organisationsstruktur und Prozesse angepasst werden. Durch die Ausprägung einer (womöglich fluiden, beweglichen) Organisation und agiler Prozesse werden die Unternehmensziele beeinflusst (Abb. 2).

Abb. 2: Drei Parameter wirken abhängig voneinander auf die Organisation ein

Die Forderung agilen Arbeitens führt also zu komplexen Veränderungen in der gesamten Organisation. Wer die implizite 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, denn 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 machen 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 Stand-ups •    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, wird jährlich ein neues „Goal No. 1“ ausgerufen. Die Triebfeder für die gesamte Entwicklung 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 zur 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 Arbeiternehmermarkts sie ohne agiles Arbeiten an Attraktivität verlieren, und führen daher 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 jedoch nicht gelingen. Die Einführung verkommt dann zu einer Alibiveranstaltung. 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 entsprechenden Prozesselemente (z. B. in Form von „Lessons learned“-Sitzungen oder Retrospektiven) statt. Von der Einführung agiler Projektmethoden zur Erhöhung der Arbeitgeberattraktivität ist abzusehen. Dieses Alibianliegen wird scheitern und auf alle Beteiligten nur frustrierend wirken. Wer eine neue Unternehmenskultur basierend auf agilen Prozessen etablieren möchte, sollte diesen Weg sehr 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!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -