Fallstricke und Lösungswege bei der agilen Transformation

Agile Entwicklung – ein Wundermittel?

Immer mehr Unternehmen entgegnen den Herausforderungen von morgen — schneller voranzuschreiten und Mehrwert für die Kunden zu liefern — indem die Entwicklungsmannschaft auf “agil” umgestellt wird. Allzu oft führt dies jedoch nicht zum erwarteten Erfolg, ganz im Gegenteil: sogar zu Frustration und Kündigungen unter den Entwicklern.

Vor welchen Herausforderungen viele Unternehmen bei der agilen Transformation stehen, werden wir uns in dieser Beitragsreihe etwas näher ansehen.

Agil ist attraktiv

Es spricht ja viel für das agile Vorgehen: Neue Features kommen schneller zum Kunden, die Qualität des Produkts steigt und die gesamte Effizienz der Mitarbeiter verbessert sich. Logischerweise wollen viele Unternehmen diese Vorteile erreichen und streben deshalb die “agile Transformation” an. 

Leider werden diese angestrebten Effekte nur dann wirksam, wenn die Transformation erfolgreich ist. In einem großen Teil der Anläufe schlägt sie jedoch fehl. Viele Unternehmen versuchen einfach, die agile practices  anzuwenden, ohne die dahinterliegenden Grundlagen verstanden zu haben.

Der schwierigste Teil: Unternehmensstrukturen adaptieren

Die meisten Unternehmen, welche die Vorteile der agilen Entwicklung für sich nutzen wollen, sind klassisch organisiert: strenge Hierarchien, die Grenzen zwischen den Abteilungen sind genau definiert und dank strikt getrennter Budgets herrscht “Silo-Denken”. Niemandem würde es einfallen, ohne Auftrag und Budget etwas für eine andere Abteilung zu tun, und wenn ein Projekt doch abteilungsübergreifend ist, wird es an der Grenze übergeben — oft mit erheblichem Informationsverlust. Bei einem großen Softwareprojekt kommt es spätestens bei der Priorisierung zu den ersten Problemen, selbst wenn alle beteiligten Teams agil handeln: Aufgrund der Kundenbedürfnisse bildet es möglicherweise ganze Geschäftsprozesse integriert ab und setzt diese um, ist aber alleine wegen der zugrunde liegenden Unternehmensstruktur auf drei voneinander getrennte Bereiche aufgeteilt und agiert daher mit drei unterschiedlichen Budgets. Nicht zuletzt basiert es  womöglich auch auf noch drei unterschiedlichen Produkt-Visionen… 

Wenn nun eine Abteilung alleine die Umstellung wagt, ist dieses Umfeld natürlich Gift für alle agilen Vorgehensweisen. Wer schon einmal Water-SCRUM-fall erleben durfte, weiß, wie zermürbend es für das agile Team sein kann, ständig gegen die “Silowände” zu krachen.

Um tatsächlich erfolgreich in einem etablierten, klassisch aufgestellten Unternehmen agile Vorgehensweisen einzuführen, muss man also einen schwierigen, oft schmerzhaften Schritt wagen: die Umstellung der Unternehmenskultur im gesamten Unternehmen. Aber welche Kulturaspekte versprechen, die Erfolgschancen der agilen Transformation zu erhöhen?

Die Scrum-Werte

Alle, die auf agile Methoden in ihrem Team oder in ihrer Abteilung umstellen wollen, sollten sich auf jeden Fall die Scrum-Werte ansehen und entscheiden, ob diese Werte auch eine Chance haben, eingehalten werden zu können — von Management-Seite ebenso wie von Entwickler-Seite. Wenn es von Entwicklern erwartet wird, Spezifikationen genau umzusetzen, ohne Zeit mit Widersprüchen und Diskussionen zu vergeuden, dann wird man wohl wenig Erfolge bei der Umstellung verzeichnen können. Ständige Eingriffe durch das Management und aufwändiges Controlling vertragen sich mit den agilen Philosophien ebenso wenig.

Ein offenes, respektvolles Arbeitsumfeld

Wir befinden uns in einem fiktiven Krankenhaus. Genauer gesagt, auf einer Neugeborenen- Intensivstation. Hier werden alle Frühgeburten beobachtet und gegebenenfalls behandelt, bis sichergestellt ist, dass keine Gesundheitsgefahr mehr besteht. Besonders die Lungen sind hier gefährdet, da dieses Organ als letztes voll reift. Ein Arzt und eine Krankenschwester machen gemeinsam die Runde, um nach den Neugeborenen zu sehen. Dabei fällt der Krankenschwester auf, dass Zwillingen nicht das üblicherweise verabreichte Medikament zur Förderung der Lungenreife bekommen haben. Bevor sie den Arzt darauf aufmerksam machen kann, fällt ihr allerdings ein, dass eben dieser Arzt gestern eine ihrer Kolleginnen lautstark zurechtgewiesen hat. Sie weiß zwar nicht warum, aber vielleicht war es eine “dumme” Frage? Als sie nach kurzem Zögern dann doch etwas zum Arzt sagen will, hat dieser bereits den Raum verlassen…

In einer vergleichbaren Situation war sicherlich jeder schon einmal. Dieses beklemmende Gefühl, Vorgesetzten zu widersprechen oder auf einen Fehler aufmerksam zu machen, führt oft zu Schweigen. Es muss nicht immer zu lebensgefährlichen Situationen führen, aber auch entgangene Chancen können bittere Folgen haben. Wie hätte die Situation ausgehen können, wenn sich die Krankenschwester sicher gefühlt hätte, dass sie keine negativen  Konsequenzen zu befürchten hat?

Die Krankenschwester hätte möglicherweise dazu beigetragen, den Zwillingen lebensrettende Medizin zukommen zu lassen. Vielleicht hätte es sogar dazu geführt, dass eine Checkliste oder ein Protokoll eingeführt wird, um solche Versäumnisse zukünftig zu verhindern. Oder der Arzt hätte der Schwester erklären können, warum diese Medizin in genau diesem Fall nicht angebracht ist, und sie hätte etwas Wertvolles gelernt.

Dieses Konzept der “psychological safety” gilt weithin als grundlegende Basis, auf der die Säulen agiler Werte aufbauen. In einem zukünftigen Beitrag werden wir noch genauer darauf eingehen, welche Folgen das Gefühl von fehlender Sicherheit haben kann und werden auch anhand einiger Beispiele Methoden kennenlernen, mit denen das Konzept erfolgreich in die bestehende Firmenkultur eingeführt werden konnte.

Quelle: Amy Edmondson – The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth

Leader-leader oder leader-follower?

Jede Person in einer Führungsrolle, Management oder Teamleitung trägt auch wesentlich zum Erfolg der agilen Umstellung bei. In der beeindruckenden Erfolgsgeschichte von David Marquet (Turn the Ship Around! A True Story of Turning Followers Into Leaders) berichtet ein ehemaliger Kapitän eines US-U-Boots davon, wie ihn eine ungeplante Kommando-Zuweisung in große Probleme brachte, da es sich um einen anderen U-Boot-Typ handelte als den, auf den sich Kapitän Marquet ein Jahr lang vorbereitet hatte. Dennoch schaffte es die Schiffsbesatzung, sich vom verlachten letzten Platz der US Navy Schiffs-Leistungsbewertungen zur historischen Höchstbewertung hochzuarbeiten. Die präsentierte Vorgehensweise klingt sehr einfach und lässt sich in wenigen Sätzen zusammenfassen, ihre  konsequente Umsetzung ist jedoch nicht so einfach, da man gegen antrainierte Verhaltensmuster und Instinkte handeln muss. Wenn man es jedoch schafft, hat es einen großen Leistungsschub im gesamten Team zur Folge. David Marquet meinte, dass sein U-Boot deshalb allen anderen überlegen sei, weil bei jedem, selbst bei einem ansonsten überlegenen Gegner, ein Kapitän 134 Seeleute lenken musste. Nur auf seinem U-Boot gingen alle 135 Besatzungsmitglieder jede Problemstellung schnellstmöglich gemeinsam an.

Das Prinzip beruht auf dem “empowerment” des Teams. Der Teamleiter wechselt dabei vom detaillierten Anordnen der Tätigkeiten zu Fragen über, die den Teammitgliedern aktiv eigenes Denken und Entscheiden abverlangen, im Endausbau teilweise nur mehr zum Zur-Kenntnis-Nehmen der Entscheidungen und Aktionen der Teammitglieder. Natürlich ist, um hier nicht in totales Chaos zu verfallen, eine Grundvoraussetzung Pflicht: Das Team muss nicht nur die technische Kompetenz haben, eine Aufgabenstellung zu lösen, sondern auch die darüber stehende Gesamtaufgabe erfassen. Es muss die Vision bzw. das Ziel kennen und sich mit dem Rest des gesamten Teams abstimmen. In Turn the Ship Around wird hierfür als Beispiel ein Mechaniker angeführt, der — um entscheiden zu können, ob eine lautstarke Wartung einer Maschine an Bord möglich ist —  wissen muss, ob gerade eine Schleichfahrt ansteht oder ob in den nächsten Stunden Lärm nicht relevant ist. Auf die Softwareentwicklung umgelegt bedeutet dies, dass das Team nicht nur die primäre Funktionalität eines neu entwickelten Features kennen muss, sondern auch einen groben Überblick über den gesamten Kontext, in dem der Kunde dieses Feature nutzt, haben muss.

Schnelles Denken und Einfluss der Sprache

In der Literatur wird häufig auf Daniel Kahnemans Thinking, fast and slow verwiesen, so auch in David Marquets neuem Buch Leadership is Language.  Kahneman stellt das Konzept vor, dass es in unserem Gehirn zwei grundsätzliche Denkpfade gibt: einerseits den schnellen, der uns erlaubt, aus unseren Erfahrungen ähnliche Situationen abzurufen und so auf akut auftretende Ereignisse ohne langwierige Überlegungen effizient zu einem Lösungsweg kommen. Andererseits den langsamen, der eben aktives Nachdenken, Überlegen, Analysieren und Planen umfasst. Dass der schnelle Pfad ein großer Erfolgsfaktor für das Überleben der Spezies Mensch war, liegt auf der Hand.

Auch in den Anfängen der industriellen Revolution wurde stark auf den schnellen Pfad gesetzt: Arbeiter waren für ihre manuelle Tätigkeit gefragt, und durch den Schritt von der Handwerkskunst zur Fließbandarbeit war es auch ohne lange Ausbildung möglich, Arbeitskräfte produktiv zu machen. Da das Nachdenken bewusst nicht gewünscht war, konnte die Produktivität eben dadurch gesteigert werden, den psychischen Druck zu erhöhen (zumindest laut Frederick Winslow Taylors Buch aus dem Jahr 1911, The Principles of Scientific Management).

In der heutigen Arbeitswelt, besonders in der IT-Branche, ist diese alte Denkweise Gift: Viele Studien belegen, dass Kreativität und die Fähigkeit zur Lösungsfindung sehr stark unter einem derartigen Druck leiden. In Leadership is Language wird besonders darauf eingegangen, mit welchen kleinen Änderungen an der Wortwahl Führungskräfte einen Wechsel ins langsame Denken nachhaltig fördern können .

… soll man die Transformation wagen?

Nach diesem kurzen Streifzug durch die Themen, die unserer Ansicht nach die Grundfeste einer erfolgreichen agilen Vorgehensweise bilden, stellt sich dann doch die Frage: “Ist es den Aufwand wert?”

Wir sagen klar “Ja” — wenn das Unternehmen wirklich gewillt ist, von den althergebrachten, vielschichtigen Hierarchien und striktem Abteilungsdenken abzurücken. Eine halbherzige Umsetzung, vielleicht auch nur in einem Teil der Firma, führt zu Frustration in der Belegschaft und Abwanderung der erfahrensten Mitarbeiter.

Wenn die agile Denkweise aber konsequent gelebt wird, dann erhöht das neben der Mitarbeiterzufriedenheit und der damit zusammenhängenden Attraktivität am Arbeitsmarkt auch die Effizienz, Qualität und Kundenzufriedenheit. Auf diese Weise überholen die aufgeschlossenen Unternehmen  jene Mitbewerber, die den Schritt nicht wagten.

#Cloudflight

Benötigen Sie Unterstützung bei der agilen Transformation Ihres Teams? Wir bieten Remote-Workshops zu Agile und Scrum-Methoden an.

Menü