Es scheint doch ein wenig paradox zu sein. Will man sich mit Agilität auseinandersetzen, dann sind die Grundlagen in nur wenigen Stunden bereits verstanden. "Profi"-Kurse dauern nur wenige Tage. Obwohl es so einfach scheint, hören wir regelmässig von grossen Herausforderungen, wenn Agilität eingeführt oder gelebt werden soll. In diesem Blog ist es uns wichtig, dass wir nicht nur das beobachtete Verhalten von Teams und Unternehmen beschreiben. Wir möchten mit euch einen Blick hinter die Symptome werfen und analysieren, welche Ursachen dazu führen, dass "schlanke" Frameworks in der praktischen Umsetzung auf grosse Herausforderungen stossen. Bei der Recherche sind wir dabei auf ein spannendes Webinar von Bill Burnett von der Stanford University gestossen. Auf seinen Erkenntnissen über Hürden bei der Einführung von innovativen Methoden möchten wir aufbauen und diese mit unseren SwissQ-Erfahrungen ergänzen. Dieser Artikel ist eine Gemeinschaftsarbeit von Paul Boekhout und Achim Pogadl.
(Quelle: SwissQ)
Ursache #1: Der Cargo Cult
Ob die Gründe im Marketing, in der Pädagogik oder in der Methodik selbst zu finden sind: Agile Frameworks sind schlank und einfach beschrieben. Es handelt sich schliesslich um ein Framework und keine bis ins letzte Detail ausformulierte Projektmanagementmethode. Das führt unserer Meinung nach gleich zu zwei Problemen. Zum Einen wird suggeriert, dass die Einführung von Agilität ebenfalls einfach und eine professionelle Unterstützung durch einen erfahrenen Coach nicht notwendig ist. Zum Anderen ist (bewusst) viel Platz für Interpretationen, wie das Framework in der Praxis implementiert werden kann. Gerade für neue Teams auf dem Gebiet der Agilität es schwer, die Hintergedanken der Framework-Macher zu verstehen. Der Fokus wandert schnell zum Scrum Framework, ohne dass das darunter liegende Agile Manifesto oder die grundlegenden 12 Prinzipien verstandenen werden. Es wird Scrum "gemacht" und nicht richtig "gelebt". Dieses Verhalten ist auch als Cargo Cult bekannt.
- SwissQ-Erfahrung
Im Mandat konnten wir ein Team erleben, welches im Daily Scrum brav die drei Fragen des Scrum Guides durchexerziert hat (Was habe ich gemacht? Was werde ich machen? Wo brauche ich Unterstützung?). Sie haben aber nicht miteinander gesprochen oder sich zugehört. Das Daily Scrum war ein Rapportierungsmeeting an den Scrum Master und Product Owner. Erst als wir die drei Fragen abgestellt und Scrum Master und Product Owner vorübergehend aus dem Daily ausgeladen wurden, hat das Team verstanden, dass das Meeting für die Abstimmung und Unterstützung untereinander ist.
Ursache #2: Den Sieg zu früh feiern
"Aber das funktioniert doch nicht bei uns. Wir sind doch nicht Spotify". Mal ehrlich: Wer hat den Satz noch nicht gehört? Ja, es stimmt, agile Frameworks sind an manchen Stellen sehr radikal und teilweise sogar utopisch formuliert. Um die Frameworks umzusetzen, sind umfangreiche Veränderungen notwendig. Beim Start in diese Transformation beginnen Teams und Organisationen oftmals mit den einfachen Dingen (Quick Wins sind das Stichwort). Meetings werden schnell aufgesetzt, neue Tools eingekauft und Rollen besetzt. Viele Unternehmen hören nach den ersten und einfachen Schritten bereits mit der agilen Transformation auf. Agilität ist hier aber bei Weitem noch nicht erreicht. Jetzt geht es darum, dass Prozesse verändert werden, neue Werte und Verhaltensmuster Einzug finden und dass sich die Kultur im Unternehmen verändert. Doch dafür braucht es mutige Vorreiter und die richtigen Rahmenbedingungen.
- SwissQ-Erfahrung
In einem Kundenmandat in der Automobilbranche konnte ich erleben, wie der CIO die Einführung von Agilität forciert hat. Konkret bedeutete dies: Neue Tools wurden eingeführt (Jira/Confluence), das Gebäude wurde umgestaltet (beschriftbare Wände, flexible Möbel, Tischkicker) und Rollen wurden umbenannt (Business-Projektleiter wurde zum PO, IT-Projektleiter wurde zum Proxy-PO, etc.). An das Thema Werte und Kultur hat jedoch niemand gedacht. Wenig verwunderlich, dass hier die Agilität keine grosse Veränderung gebracht hat.
Ursache #3: Die "Insel" in der alten Arbeitswelt
Wie wird Agilität am besten eingeführt? Die Literatur ist sich grösstenteils einig: Starte im Kleinen (z. B. bottom up). Fange mit einem Team an und verbreite von hier aus die Agilität im Unternehmen. Das heisst aber auch: David gegen Goliath. Selbst mit dem notwendigen Support stösst das agile Team regelmässig an seine Grenzen, da es ein Nukleus in einer von Wasserfall dominierten Projektlandschaft ist. Die gesamten Prozesse und Verhaltensweisen sind auf ein phasenorientiertes Vorgehensmodell abgestimmt. Das Releasemanagement hält an lange geplanten und festen Releaseterminen und Freezes fest. Das Testmanagement kennt fixe Testphasen. Die Infrastruktur ist nicht skalierbar. Das Management fordert Forecasts und Berichte, die mit Agilität nicht vereinbar sind. Das Team wird indirekt von der Umgebung gezwungen, sein Verhalten an die Rahmenbedingungen anzupassen, sodass ein agiles Arbeiten nur pseudomässig möglich ist.
- SwissQ-Erfahrung
In einem Projekt in der Automobilbranche rückte nach der Einführung von Agilität im Gesamtprogramm das Jahresende immer näher. Die Teams mussten für das nächste Jahr eine Gesamtplanung erstellen, inklusive Budget-Verbrauch und genau welche Anforderungen implementiert werden. Gerade die Fixierung der umzusetzenden Anforderungen stellt im iterativ-inkrementellen Prozess eine grosse Herausforderung für die Teams dar. Nur mit viel Aufwand konnte das Management letztendlich überzeugt werden, dass neue Managementwerkzeuge in der agilen Welt notwendig sind.
Ursache #4: Das fehlende Vertrauen und grosser Erfolgsdruck
Wer ein Musikinstrument gelernt hat, weiss: In der Theorie weiss man, wie es geht, aber in der Praxis muss man üben, üben und noch mal üben! Beim Instrument fangen wir mit einfach Stücken an und steigern uns kontinuierlich. Aber wie ist es beim agilen Arbeiten? Auch hier erlernen wir eine neue Fähigkeit. Unglücklicherweise beobachten wir regelmässig, dass hier jedoch mit den richtig schweren Stücken begonnen wird. Ja, Agilität eignet sich für komplexe Projekte. Aber auch hier müssen zunächst Erfahrungen gesammelt und Vertrauen in das neue Vorgehen gewonnen werden. Wenn die Teams dieses Vertrauen nicht bekommen und direkt unter hohem Erfolgsdruck mit einer neuen Methodik arbeiten müssen, werden sie wieder auf alte Verhaltensweisen, Methoden und Prozesse zurückgreifen.
- SwissQ-Erfahrung
Bei einer Versicherung wurde sehr viel Aufwand in die Vorbereitung der agilen Transformation gesteckt. Die Aufmerksamkeit des Managements war sehr hoch und die Erwartungen an die Agilität überspannt. Es gab für die Teams zu wenig Freiraum, damit es sich agil bewegen konnte. Fixe Anforderungen, fixe Deadlines und eine starke "Commitment Politik" haben dazu geführt, dass die Teams den agilen Pfad verlassen haben.
Ursache #5: Die neue Teamzusammensetzung
Mit der Einführung von Agilität wird auch die Zusammenarbeit in crossfunktionalen Teams gefördert. Für einige Unternehmen ist es heute noch ein Novum, wenn plötzlich Business und IT eng miteinander zusammenarbeiten. Es prallen nicht nur unterschiedliche Fachgebiete, sondern auch unterschiedliche Verhaltensweisen, Kulturen und Sprachen aufeinander. Die Zusammenarbeit im Team kann nur gelingen, wenn diese Unterschiede bewusst sind und am gegenseitigen Verständnis gearbeitet wird. Wenn diese Unterschiede ignoriert werden, entstehen Missverständnisse und (unterschwellige) Konflikte im Team. Eine performante und vertrauensvolle Zusammenarbeit im Sinne der Agilität ist dann nur sehr schwer möglich.
- SwissQ-Erfahrung
Im Rahmen einer agilen Transformation in der Automotive-Branche in Deutschland wurden cross-funktionale Teams mit Mitgliedern aus Business und IT gegründet. Dabei ist erst nach einigen Wochen aufgefallen, dass die Fachvertreter einen Arbeitsvertrag mit 35 Stunden Wochenarbeitszeit hatten und eher früh mit dem Arbeiten anfangen und aufhören. Auf der anderen Seite hatten die IT'ler einen Arbeitsvertrag mit einer Wochenarbeitszeit von 42 Stunden und fingen tendenziell später mit der Arbeit an. Im Team fehlte nicht nur das Verständnis für den anderen Fachbereich, sondern auch für die entsprechende Arbeitsweise des Gegenübers.
Ursache #6: Die fehlende Perspektive (für Führungskräfte)
Agile Transformation bedeutet auch Veränderung für Führungskräfte. Bei vielen agilen Transformationen wird Zeit investiert in das Aufsetzen von neuen Teams, Methoden und Tools. Leider werden die Effekte auf Projekt-, Team- oder Ressourcenleiter zu wenig beleuchtet. Auch wenn die agile Transformation vom C-Level Management und den Teams aktiv unterstützt wird, ist es sehr wichtig, dass die Mitarbeiter im mittleren Management abgeholt und konkrete Transformationspfade aufgezeigt werden. Sie müssen verstehen, mit welchen Rollen beziehungsweise mit welchen Aufgaben sie in Zukunft betraut werden können. Fehlt diese Perspektive, können einflussreiche Führungskräfte die agile Transformation bewusst manipulieren. Sie nehmen negativen Einfluss auf ihre Teammitglieder oder halten bewusst an alten Strukturen und Prozessen fest. Durch diese unsichtbaren Barrieren kann die agile Transformation nachhaltig geschädigt werden. Ganz nach dem Motto "Ich habe euch doch gesagt, dass das nicht funktioniert. Das Projekt bleibt beim Wasserfall und ich bei meiner alten Rolle".
- SwissQ-Erfahrung
In einem Pilotprojekt mit agilen Teams wurden Scrum Teammitglieder immer wieder von ihren Vorgesetzten aus Meetings geholt. Meetings mit den Vorgesetzten ("Status Meetings") wurden mit hoher Priorität parallel zu Scrum Events geplant, damit das agile Vorgehen torpediert wird. Das hatte zur Folge, dass die betroffen Teammitglieder das agile Team nicht genügend unterstützen konnten und der gewünschte Nutzen der Agilität nicht zum Tragen kam. Ausserdem hat es die Teammitglieder demotiviert, da sie sich in einen Spagat gezwungen fühlten.
Wie sieht es bei dir aus?
Konntet ihr euch und euer Umfeld in den sechs Punkten erkennen? Was denkt ihr, welche Ursachen in eurem Team oder Unternehmen dazu geführt haben, dass die Agilität nicht zum "Fliegen" kommt? Schreibt uns doch gerne direkt an Paul oder Achim. Oder konntet ihr bereits die Ursachen identifizieren und auflösen? Wir freuen uns über einen Austausch mit euch.
