„Wir werden jetzt agil!“, verkündet der Abteilungsleiter. Also werden Rollen benannt, neue Terminserien definiert, Backlogs angelegt und los geht’s – natürlich mit einer besseren Fehlerkultur und höheren Geschwindigkeit als zuvor. Der frischgebackene Product Owner stellt dem Team im ersten Sprint Planning seine vorbereiteten User Storys vor. Spontan meldet sich ein Mitarbeiter aus dem Fachbereich – ihm ist noch eine dringende Änderung eingefallen. Der Product Owner verfasst dazu noch schnell eine Story und schätzt sie grob. Endlich kann die Planung beginnen. Weil das Backlog einige Features enthält, die aus fachlicher Sicht nicht verhandelbar sind, schlägt der Product Owner vor, die Themen in den Sprint aufzunehmen, obwohl die Zeit eigentlich zu knapp bemessen ist. Das Sprintende in acht Wochen ist noch weit weg, da kann man das eh nicht so genau planen. Außerdem ist ja Zeit für Backlog Grooming, Retrospektive und Schulungen eingeplant, die man ausnahmsweise ausfallen lassen kann. Beim Blick auf die Uhr fällt auf, dass der Termin bereits deutlich überzogen wurde. Das Team ist unsicher, ob der Vorschlag wirklich eine gute Idee ist. Leider ist der Scrum Master gerade nicht erreichbar, da er in einer Retro mit seinem anderen Scrum Team steckt. Da niemand einen besseren Einfall hat, einigt man sich auf diesen Vorschlag.

~Typisches Projekt

So oder so ähnlich erleben wir in unserem Alltag häufig Agilität. Vieles deutet jedoch darauf hin, dass hier die Agilität in ihrem Kern nicht verstanden wurde. Doch was genau ist dabei eigentlich problematisch?

Zum einen herrscht bei Entscheidern oft eine falsche Erwartungshaltung. Ganz nach der Devise „Wir wollen mehr in kürzerer Zeit“ wird eine agile Arbeitsweise fälschlicherweise mit schneller Entwicklungsleistung gleichgesetzt. In Wirklichkeit erhöht Agilität aber vor allem die Nutzbarkeit des Erarbeiteten. Das Produkt wird dem Kunden möglichst schnell präsentiert, um früh Feedback zu erhalten. Dieses wird wiederum genutzt, um weniger überflüssige Features zu entwickeln. Zum anderen werden die gewünschten neuen Unternehmenswerte häufig einfach deklariert („Wir sind jetzt agil!" oder „Wir haben jetzt eine Fehlerkultur!"). Was hier jedoch übersehen wird: Werte lassen sich nicht einfach ändern, sondern sind Teil einer gewachsenen Unternehmenskultur.

Wie steigern wir also Nutzen und Werte in unserer Organisation?

Führt man eine agile Transformation mithilfe von Vorgehensmodellen (wie Scrum) oder Tools (wie Jira) durch, birgt das eine Gefahr: Diese werden als weniger bürokratische Alternativen zum Wasserfall wahrgenommen und nicht als Hilfsmittel einer agilen Arbeitsweise. Dies führt dazu, dass die zugrundeliegenden agilen Werte und Prinzipien den Mitarbeitern verborgen bleiben, was wiederum einen Kulturwandel erschwert (oder gar verhindert). Kommt es im Projektalltag zu Zeitdruck oder Verunsicherung, greifen die Menschen meist auf gewohnte Verhaltensmuster zurück, um mit Problemen umzugehen. Das Ergebnis: Die Umstellung wird als Selbstzweck empfunden, Agilität als nicht wirkungsvoll.

Wir beobachten drei Erfolgsfaktoren, welche sich in unseren Projekten als besonders geeignet erwiesen haben, um agile Werte zu vermitteln. Ihre Umsetzung muss dabei nicht einmal Teil einer groß angelegten agilen Transformation sein. Sie stiften auch für sich genommen bereits großen Nutzen.

Inspect & Adapt praktizieren

Der wichtigste Erfolgsfaktor für einen erfolgreichen agilen Wandel ist die Anwendung von „Inspect & Adapt“. Hierbei geht es darum, seine eigene Arbeitsweise zu analysieren und beständig zu verbessern. Wie zentral dieser Gedanke ist, sieht man schon im agilen Manifest, das mit den Worten „Wir erschließen bessere Wege, Software zu entwickeln…“ eingeleitet wird. Dabei beschreibt „Erschließen“ eine explorative Tätigkeit, die kontinuierlich durchgeführt werden muss und nie abgeschlossen ist.

Aus diesem Grund spielt Inspect & Adapt auch in Scrum eine zentrale Rolle. Das wohl bekannteste Beispiel hierfür ist die Retrospektive, in der das Team am Ende jeder Iteration die eigene Arbeitsweise reflektiert. Umso verheerender ist es, dass gerade dieser Termin im Projektalltag gerne als erstes ausgelassen wird, wenn die Zeit eng ist. Und ganz ehrlich – das ist sie eigentlich immer. Tatsächlich ist in Scrum nicht nur die Retrospektive eine Ausprägung von Inspect & Adapt, sondern jedes einzelne Team-Event: Sprint Plannings betrachten die Planung, Reviews das Produkt und Daily Scrums den Fortschritt.

Der zentrale Erfolgsfaktor für Agilität ist die Anwendung von „Inspect & Adapt“.

Wir haben mit Inspect & Adapt sehr gute Erfahrungen bei einem Automobilhersteller gemacht. Dort wurde ein Online-Marktplatz entwickelt, der europaweit eingeführt werden sollte. Unsere Aufgabe war die Unterstützung der IT im Requirements Engineering. Während die IT bereits mit agilen Elementen arbeitete (Backlogs, Iterationen, …), stand uns ein klassisch organisierter Fachbereich gegenüber. Dieser gab die Rollout-Planung für die verschiedenen europäischen Länder in Form von eng getakteten Meilensteinen vor. Doch dann passierte, was immer passiert: Schon der erste Rollout kam mehrere Monate verspätet. Daraufhin wurde der Rollout umgeplant, doch auch nach dem neuen Plan verzögerte sich der zweite Rollout massiv. Als wir nach den Ursachen suchten, stellten wir fest, dass zwischen IT und Fachbereich stark auseinanderklaffende Vorstellungen vom Aufwand für Rollout und Weiterentwicklungen herrschten.

Mit Hilfe eines agilen Coaches und viel Überzeugungsarbeit erreichten wir die Einführung eines gemeinsamen Backlogs von IT und Fachbereich, in den sowohl Rollout als auch Weiterentwicklung aufgenommen wurden. Zu Beginn jeder 2-monatigen Iteration kamen die Beteiligten aus Fachbereich und IT zu gemeinsamen Planungsevents zusammen, in denen alle Backlog-Items gegeneinander priorisiert und transparent eingeplant wurden. Konfrontiert mit der Notwendigkeit zu priorisieren, hatte der Fachbereich eine wichtige Erkenntnis über die eigenen Ziele: Rollout hatte Priorität. Durch die wiederkehrende Planung konnte die Schätzung des Rollout-Aufwandes validiert („inspect“) und verbessert („adapt“) werden. Nach drei in-time Rollouts seit der Einführung von Backlog und Planungsevents besitzt das Programm nun erstmalig eine realistische Rollout-Planung.

Transparenz schaffen

Transparenz hat zwei Effekte. Zum einen setzt man sich Feedback aus, was Qualität stiftet. Zum anderen macht sie Überlegungen und Entscheidungen nachvollziehbar, was Akzeptanz und gemeinsames Verständnis schafft. Wichtig hierbei ist, dass Transparenz von allen Beteiligten praktiziert wird. Denn häufig beobachten wir, dass Transparenz in erster Linie von der IT erwartet wird (etwa in Form von öffentlicher Fortschrittsmessung und Software-Demos), jedoch weniger vom Fachbereich. Allerdings sollte dieser gleichermaßen gefordert sein, seine Pläne transparent zu machen und früh lesbare Dokumente zu veröffentlichen.

Der Fachbereich ist genauso gefragt, stets seine Pläne transparent zu machen und früh lesbare Dokumente zu veröffentlichen.

Eine interessante Ausprägung von Transparenz zur Qualitätssteigerung ist das Phänomen „Open Source“. Netflix veröffentlicht beispielsweise den Code für zahlreiche Komponenten im Netz und erläutert dazu: „What we’ve learned is that a component may be ‘Good enough for running in production, but not good enough for Github’.“

Ein Beispiel für Transparenz als Treiber von Akzeptanz haben wir in einem Data-Science-Startup erlebt: Fachbereich und Entwicklungsteam waren unzufrieden mit der gegenseitigen Erwartungshaltung. Der Fachbereich hatte den Eindruck, dass die Entwicklung neuer Funktionalität nicht vorangeht. Aus vorherigen Projekten wusste man jedoch, dass das zuständige Entwicklungsteam kompetent und schnell arbeitet. Die Entwickler hingegen fühlten sich nicht genügend wertgeschätzt. Sie hatten die schwierige Aufgabe, eine sehr große Menge an Internet-Daten zu verarbeiten. Dafür war viel zeitaufwendige Wartungs- und Architekturarbeit nötig. Das Entwicklungsteam ging jedoch davon aus, dass dies allen und insbesondere dem Fachbereich klar sein müsse.

Wir beschlossen gemeinsam mit dem Entwicklungsteam eine veränderte Kommunikationsstrategie: Die Entwickler begannen oft und häufig zu kommunizieren, was sie in Sachen Wartung und Architekturarbeit unternommen hatten und wie die Kapazitätsplanung prognostiziert war. Durch diese Transparenz konnte beim Fachbereich mehr Verständnis geschaffen und die Erwartungshaltung justiert werden.

Entscheidungen dezentralisieren

Entscheidungen dezentralisieren bedeutet, sie dorthin zu verlegen, wo die Informationen sind, um sie bestmöglich zu treffen. Die Alternative – die Information an die Stelle zu befördern, wo die Entscheidungsbefugnis ist – bildet nicht nur ein Bottleneck, sondern verhindert auch, dass Unternehmen in kritischen Situationen handlungsfähig und schlagfertig bleiben. Die Teammitglieder, die die Arbeit verrichten, treffen in operativen Fragen im Schnitt die besseren Entscheidungen als Vorgesetzte oder Manager – was nicht heißt, dass sie nicht auch mal falsch liegen können. Dennoch werden zentrale Entscheidungen weiterhin benötigt, nämlich wenn sie strategisch – also langfristig oder weitreichend – sind.

Auch wenn es schwierig klingen mag, Entscheidungen in einem Unternehmen zu dezentralisieren: Es geht sogar auf einem Atom-U-Boot der US Navy (vgl. L. David Marquet „Turn the Ship Around“). Auch im übrigen US-Militär gibt es eine Entwicklung von einer hierarchischen Organisation hin zu dezentralen Entscheidungsstrukturen (vgl. Stanley McChrystal „Team of Teams“). Der Grund: Dezentrale Entscheidungsstrukturen glänzen da, wo traditionelle Strukturen scheitern – nämlich im Umgang mit Veränderungen und Überraschungen.

Auch wenn es schwierig klingen mag, Entscheidungen in einem Unternehmen zu dezentralisieren: Es geht sogar auf einem Atom-U-Boot der US Navy.

Den Wandel hin zu einem effektiven, selbstbestimmten Team haben wir in einem Fachbereich einer Bank begleitet. Die Entscheidungskultur war zentral-hierarchisch. Die Mitarbeiter des Teams kamen mit Themen zur Projektleiterin, die Entscheidungen fällte. Sie hatte den Wunsch, ihre Mitarbeiter stärker in die Pflicht zu nehmen, um nicht zum Bottleneck für das Team zu werden und die Identifikation der Mitarbeiter mit den Entscheidungen zu erhöhen.

Um dies zu erreichen, entwarfen wir zusammen mit der Projektleiterin Entscheidungsmeetings, in denen die Mitarbeiter untereinander die Frage diskutierten und gemeinsam Entscheidungen trafen. Die Projektleiterin befragte die Mitarbeiter nach den Gründen, machte aber bewusst keine Vorgaben und entschied nicht mit. Getroffene Entscheidungen akzeptierte sie, auch wenn sie nicht in jedem Fall ihrer Entscheidung im alten Modell entsprochen haben. Überraschend musste sich das Verfahren früher beweisen als geplant: Die Projektleiterin fiel krankheitsbedingt für längere Zeit aus und fachlich gab es keinen Ersatz. Die Mitarbeiter hatten in den neu geschaffenen Entscheidungsrunden genug Erfahrung und den nötigen Mut gesammelt, selbstbewusste Entscheidungen zu treffen. Und sie setzten dies auch in Abwesenheit ihrer fachlichen Projektleiterin fort.

Agil in die Transformation

Inspect & Adapt zu praktizieren, Transparenz zu schaffen und Entscheidungen zu dezentralisieren sind in unserer Erfahrung Erfolgsfaktoren für eine agile Transformation. Sie fördern agile Werte und sind daher essenziell für eine nachhaltige Transformation. In unseren Beispielen haben wir gezeigt, dass eine Anwendung in unterschiedlichem Kontext – von Konzern bis Startup – und in unterschiedlichem Umfang – von Team- bis Programmebene – möglich ist.

Zwar stehen diese Erfolgsfaktoren im Zentrum einer agilen Arbeitsweise, sie sind jedoch nicht erschöpfend. Wirft man einen Blick auf die Werte und Prinzipien im Agilen Manifest, finden sich dort noch weitere wichtige Facetten. Vor allem die Kundenorientierung und die technische Agilität sind für eine nachhaltige Unternehmensagilität unerlässlich.

Die Kultur eines Unternehmens zu verändern ist eine sehr schwierige und langfristige Aufgabe, die mit Unwegsamkeiten verbunden ist. Agilität beginnt daher bereits bei der Transformation selbst: Transparenz über die Ziele und Absichten schaffen, regelmäßig das Vorgehen überprüfen und (neu) auf die Ziele ausrichten sowie die Voraussetzungen für lokale Entscheidungen schaffen.