In diesem Artikel erklären wir dir was die 5 größten Herausforderungen einer Agile Transformation und wie man diese verbessern oder gar verhindern kann und natürlich auch was sich für Vorteile dann ergeben.
In der letzten Folge haben wir dir alles rund um die Theory of Constraints von Goldratt erklärt. Also was ist ein Bottleneck (Flaschenhals) bzw. ein Constraint (Einschränkung), was die Schritte dieser Methode sind und wir haben natürlich auch genügend Beispiele für die Theory of Constraint geben.
Schau also unbedingt hier vorbei, falls darüber noch mehr wissen willst 😉
Eine der ersten Herausforderungen, der man sich bei einer Agile Transformation stellen muss ist, dass nun Entscheidungen an anderen Stellen getroffen werden, als bisher.
Klassisch wurden alle wichtigen Entscheidungen vom Management getroffen und je wichtiger die Entscheidung ist, desto weiter nach oben wurde diese Entscheidung eskaliert. Die Probleme hierbei sind folgende:
Aber das mit Abstand größte Problem einer Agile Transformation hierbei ist, dass nicht nach Art der Entscheidung unterschieden wird, sondern einfach alle wichtigen Entscheidungen, egal ob technisch oder strategisch werden vom Management gefällt bzw. müssen vom Management abgesegnet werden.
In einem agilen Umfeld hingegen müssen Entscheidungen nicht erst bis zur höchsten Hierarchieebnen eskaliert werden, sondern die Entscheidungen werden dezentral gefällt.
Der wichtigste Punkt bei Agile ist, dass unterschieden wird um welche Art von Entscheidung es sich handelt!
So werden alle technische Entscheidungen rund um Umsetzungen (WIE etwas umgesetzt wird) von den Entwicklern selbst getroffen, da diese alle Informationen haben, die für die Entscheidung nötig sind oder diese sehr schnell bekommen können. Auch haben die Entwickler das technische Verständnis, was diese Entscheidungen für Vor- bzw. Nachteile und Konsequenzen haben werden.
Dahingegen werden alle Prioritätsentscheidungen von den Product Ownern oder Area Product Ownern getroffen. Das sind alle Entscheidungen bezüglich WAS umgesetzt wird und vor allem auch in welcher Reihenfolge. Dies ist die alleinige Aufgabe der Product Owner, da sie genau an der Schnittstelle zwischen technischem Bedarf (Entwickler), Kundennutzen (Stakeholder/User) und strategischen Zielen (Management) sitzen und somit als einzige dieses Gesamtbild haben. Das ist natürlich eine sehr große Herausforderung und macht die Rolle des Product Owners deshalb so wichtig. Wichtig hier ist auch, dass der Product Owner eng mit den entsprechenden Personengruppen zusammenarbeitet und die wichtigsten Informationen zu im kommen (Stichwort: gute Kommunikation), aber auch, dass der Product Owner das nötige Vertrauen genießt, um die Entscheidungen treffen zu können. Und ja jeder macht mal Fehler. Auch Product Owner sind Menschen. 😉
Kommen wir nun noch zu den taktischen und strategischen Entscheidungen. Dies sind alle Entscheidungen WARUM etwas gemacht wird bzw. nicht gemacht wird. Es handelt sich also hier um die Vision bzw. Roadmap. Diese kann nur vom Management auf der jeweiligen Ebene gefällt werden. Daher sind Manager in Agile weiterhin extrem wichtig und unbedingt nötig. 😉 Wichtig ist aber, dass jeder auf seiner Ebene bleibt, weil sonst das gesamte System nicht skaliert und die am meisten beschäftigte Person den Flaschenhals des Systems bildet (hier kann ich nur nochmal unseren Artikel zur Theory of Constraints empfehlen 😉 ).
Ja diese Liste ist noch nicht vollständig, da es z.B. auch noch Personalentscheidungen oder Entscheidungen über Richtlinien im Unternehmen gibt, aber wir können hier nur auf die wichtigsten Punkte und Herausforderungen eine Agile Transformation eingehen. Falls du noch Fragen zu den anderen Kategorien hast, schreib uns gerne einen Kommentar oder direkt per Mail. 😉
Die Herausforderung während der Agile Transformation und auch danach besteht darin, dass manche Menschen nicht loslassen können, wenn sie gewohnt sind bestimmte Entscheidungen zu treffen und dann Anfangen zu kontrollieren oder Micromanagement zu machen.
Eine weitere Herausforderung ist, dass nun jeder verantwortlich ist für bestimmte Entscheidungen und auch für die Konsequenzen dieser Entscheidungen. Wichtig hierbei ist, dass Verantwortung heißt, dass man keine Fehler machen darf, sondern nur, dass man aus diesen lernt und vermeidet, dass diese nochmal passieren. Das hängt mit einer weiteren Herausforderung zusammen, aber dazu später mehr.
Wichtig ist hierbei zu allererst ein Verständnis zu schaffen, warum diese neue Art der Entscheidungsfindung so funktioniert, nötig ist und auch, dass jeder weiterhin eine wichtige Rolle in diesem System spielt. Ein wichtiges Argument hier sind auch die Vorteile, die mit der neuen Herangehensweise kommen (z.B. keine Flaschenhälse und Überlastung von Managern mehr; schnellere Reaktionsfähigkeit auf sich ändernde Umstände,…)
Hat man die erste Herausforderung der Agile Transformation gemeistert und das Verständnis für die neue Art der Entscheidungsfindung geschaffen, folgt auch direkt schon die zweite Herausforderung.
Denn nur all zu oft ist dieses Verständnis und die Entscheidungsgewalt nur auf dem Papier bei den Teams bzw Product Ownern. Das zeigt sich z.B. darin, dass das wichtigste Item im Product Backlog nicht vom Product Owner kommt, sondern von einem Manager weiter oben in der Hierarchie und, dass dieses Item jetzt, sofort, unbedingt fertiggestellt werden muss. Am besten kommt das Item noch während des Sprints dazu, obwohl das Team bereits keinen Puffer mehr hat. Und auch hier ist das Verständnis für das Management wichtig, aber sollte man sich als Manager auch immer Fragen warum taucht dieses Item mitten im Sprint auf bzw. ist es wirklich das wichtigste Item mit dem meisten Nutzen für den Kunden oder ist es nur für mich extrem wichtig?
Gründe hierfür sind, aus unserer Erfahrung, häufig eine fehlende Roadmap/Vision beim Management (sonst würde das Item ja nicht plötzlich auftauchen) und ein mangelndes Vertrauen in den Product Owner oder fehlende Kommunikation zwischen Product Ownern und Management.
Das gleiche Spiel kann natürlich auch auf der Ebene der Entwicklerteams stattfinden, wenn z.B. technische Entscheidungen zur Umsetzung eines Items nicht von den Entwicklern selbst, sondern vom Product Owner oder gar vom Management gefällt wird.
Gründer hierfür sind z.B., dass der Product Owner der frühere Team- bzw. Technical-Lead war und es einfach gewohnt war diese Entscheidungen zu treffen und einfach nicht loslassen kann.
Wichtig ist hier immer ein Verständnis für das Gesamtsystem zu schaffen und zu verdeutlichen, dass Micromanagement und Kontrolle in einem komplexen System nicht skalieren bzw. Doppelarbeit oder gar wertlose Arbeit (waste) erzeugen.
So muss man dem Product Owner z.B. klarmachen, dass er sich nicht gleichzeitig um alle Stakeholder und technische Entscheidungen gleichzeitig kümmern kann, weil er sonst einfach überladen mit Arbeit ist. Darum steht im Scrum Guide auch explizit, dass er bestimmte Aufgaben delegieren kann, aber – ganz wichtig – weiterhin dafür verantwortlich ist.
Gerade in einem skalierten Umfeld ist das extrem wichtig.
Das gleiche gilt übrigens auch für den Manager. Hier ist es entscheidend ein Verständnis zu schaffen, dass der Product Owner das beste Verständnis von den Kundenwünschen- und -bedürfnissen hat und nur durch zahlenden Kunden auch Gewinne erzielt werden.
Laut des 14. State of Agile Reports von 2020 ist dies die viergrößte Herausforderung einer Agile Transformation und rund 44% der rund 40.000 Teilnehmer haben dieses Problem in ihrem Unternehmen.
Zunächst müssen wir aber definieren, was Kultur eigentlich bedeutet. Eine der besten Definitionen von Kultur, unserer Meinung nach, ist dabei die von Simon Sinek:
Culture = Behaviour + Values – Simon Sinek
Und oft stimmen diese Werte, die aktuell im Unternehmen gelebt werden nicht mit den Scrum Values oder DevOps Prinzipien überein.
Wichtig ist uns hier zu betonen, dass es Values + Behaviours heißt. Es also auch um unsere Verhaltensweisen und Taten geht. Das heißt wir sollten die Scrum Werte eher als Verben sehen anstatt als Substantive, wie es hier dargestellt ist. So bedeutet das z.B.:
Die Herausforderung, die eine agile Transformation hier gegenübersteht ist, dass häufig die Werte von Unternehmen sich nicht mit diesen Werten decken oder gar keine Werte sind.
So ist „Innovation“ z.B. kein Wert.
Ich kann nämlich nicht zu meinen Mitarbeitern ins Büro gehen und sagen:
„Heute bitte ein bisschen mehr Innovation als gestern.“ – Boss
Was aber möglich ist, ist zu sagen:
„Macht Experimente und schaut euch das Problem aus vielen verschiedenen Blickwinkeln an und schaut, was wir daraus lernen können und ob unsere Kunden Wert darin sehen.“ – Leader
Wichtig ist auch, dass es sehr schwer bis unmöglich ist eine Kultur vorzuschreiben. Die einzige Möglichkeit ist es eine Kultur vorzuleben und sich entsprechend der Werte zu verhalten (nochmal: Culture = Values + Behaviours).
Tipp: Hat man mehr als fünf Werte sind in der Regel mehrere redundant. Und fünf Werte sind auch mehr als genug.
Wichtig für eine Agile Transformation ist, dass diese Werte und die Kultur nicht einfach nur irgendwo an einer Wand stehen, sondern, dass man als Führungskraft darüber spricht oder entsprechende Anreize schafft, die im Einklang mit den Werten sind. So stimmen z.B. die Werte „gemeinsam vorankommen“ und die Beförderung eines egoistischen Teammitglieds, dass die anderen Teammitglieder auf der Strecke lässt nicht überein. Und das spürt jeder Mitarbeiter. Wirklich. Jeder. Und dann können wir uns diese Werte auch sparen, wenn man als Mitarbeiter weiß, dass diese zwar gepredigt werden, aber nicht danach gehandelt wird.
Und die Kultur beginnt bereits beim Einstellungsprozess. Wenn wir wissen, dass wir diese Werte leben, dann stellen wir auch Personen ein, die nach diesen Werten leben und an ähnliche Werte glauben. Und das ist durchaus auch eine legitime Frage während eines Jobinterviews: „Was sind ihre Werte?“, „Was ist ihnen an einer Unternehmenskultur wichtig?“. Und wenn diese Werte garnicht mit den Werten des Unternehmens übereinstimmen, so sollte man diese Person, egal wie gut sie ist, eigentlich nicht einstellen.
Schaut man sich den 14. State of Agile Report weiter an so haben sogar 46% aller Teilnehmer bei ihrer Agile Transformation die Herausforderung, dass das Management nicht genug Unterstützung zeigt bzw. zu wenig beteiligt/present ist.
Und auch das sehen wir sehr häufig in Unternehmen. So kommt es nicht selten vor, dass die meisten Entwickler das Management nur alle X Wochen kurz bei einer Townhall oder ähnlichem sieht und dann verschwinden diese wieder in ihrer Etage/Büro.
Das Problem ist, dass wir in einem agilen Umfeld sehr schnell an den Punkt kommen, wo alle Probleme innerhalb der Teams gelöst sind oder nun die größten Probleme außerhalb einzelner Teams liegen. Und hier kommen die Scrum Master aber auch die Manager ins Spiel, da nur diese (leider) meistens die Befugnis/Macht haben teamübergreifende oder domänenübergreifende Probleme zu lösen in einem engen Austausch mit anderen Managern z.B. Wenn wir es nicht schaffen diese Probleme zu lösen bringt es nichts mit den Teams jeden Sprint eine Retro zu haben und zu verlangen, dass diese sich noch 0,5% verbessern, wenn das eigentliche Problem außerhalb liegt, aber nicht gelöst wird.
Was man dann leider, aber auch zu Recht, von den Teams in der Retro hört ist: „Warum soll ich überhaupt in die Retro kommen?“ „Das bringt doch eh nichts.“ oder „Es ändert sich sowieso nichts.“. Hier muss man als Scrum Master hellhörig werden und entsprechend den Kontakt zu den Führungskräften suchen und auch ein Verständnis für deren Position bekommen. Vielleicht sind diese ja auch vollkommen mit Arbeit überladen (hier heißt es meist wieder Vertrauen schaffen und Arbeit abgeben können).
Ein weiteres Problem ist, dass in einem Umfeld, in dem eigenständige Teams arbeiten und Entscheidungen treffen können, unbedingt einen engen Austausch mit den Managern brauchen und auch eine klare Vision und Roadmap benötigen, da dies extrem motivierend für die Mitarbeiter ist. Fehlt einer dieser Punkte, so verpufft die Motivation und das Engagement der Mitarbeiter schnell und wir werden nicht die Vorteile von Agile erzielen.
Der wichtigste Punkt ist hier von Anfang an während der Agile Transformation ein klares Verständnis für die neuen Aufgaben und Verantwortlichkeiten jeder Rolle in diesem agilen Umfeld zu schaffen und zu definieren. So sind diese klar und jederzeit nachvollziehbar.
Ein sehr extremes Beispiel, das aber massive Verbesserungen gebracht hat, ist in dieser Rollendefinition des Management festzuhalten, dass diese mehr Zeit mit den Leuten „unter“ ihnen (für die sie nämlich verantwortlich sind) zu verbringen als mit den Leuten „über“ ihnen. So ist nämlich garantiert, dass sich um jeden gekümmert wird, außer die oberste Führungsebene und diese sind genau dort, weil sie führen und nicht, weil sich um diese am meisten gekümmert werden muss. Ist es nämlich genau andersherum, so wird sich um die unterste Ebene (in der Regel die meisten Leute im Unternehmen) am wenigsten gekümmert. Und ich hoffe, dass das sich nicht nur für uns falsch anhört. 😉
Das ist die Nummer Eins der Herausforderungen jeder Agile Transformation.
Und das ist ein ganz natürliches Verhalten, da wir Menschen Gewohnheitstiere sind und Neues immer ungewohnt ist oder ein unbekanntes Risiko bergen könnte.
Eines der besten Zitate, um das grundlegende Problem zu beschreiben ist unserer Meinung:
People often get wrong, what is the difference between different and wrong. – Nigel Baker
Ein komplizierter Satz, aber er trifft es auf den Punkt. Oft antizipieren wir etwas, das anders ist als falsch und das rein aus dem Grund, dass es anders ist und nicht weil es tatsächlich falsch ist. Das herauszuarbeiten ist sehr schwer und erfordert auf jeden Fall erfahrene Coaches.
Ein weiterer Punkt, den man bei allen Transformationen, egal ob agile oder DevOps oder …, beachten muss ist, dass alles ein Prozess ist und wir nicht eine Transformation ankündigen und dann über Nacht alles besser ist und sich alles zum Guten verändert hat. Es ist also z.B. „transformieren“ über „transformiert“ oder „anpassen“ über „angepasst“.
Es gilt also die Klarheit für diesen fortlaufenden Prozess zu schaffen und das auf allen Ebenen im Unternehmen.
Eine der häufigsten Herausforderungen einer Agile Transformation (das gleiche gilt aber für jede Transformation 😉 ) und eines der grundlegendsten Probleme ist und bleibt der Mangel an Trainings, Wissen und den nötigen Skills.
So haben 41% aller Teilnehmer des State of Agile Reports 2020 das Problem, dass die Fähigkeiten bzw. Erfahrung mit den agilen Methoden wie Scrum, Kanban, LeSS, Nexus,… fehlen und 39% haben das Problem, dass es zu wenig Trainings bzw. (Aus)Bildung gab.
Das sind zwischen ca 16.000 Menschen, die dieses Problem haben.
Und dabei ist es die absolute Grundlage für eine erfolgreiche Agile Transformation. Denn ohne das nötige Wissen und die Erfahrung im Unternehmen, werde ich mich zwangsläufig wieder zurück zum Bekannten (in der Regel Wasserfall und klassisches Projektmanagement) entwickeln und damit keine Vorteile erzielen, sondern nur Verwirrung und Geldverschwendung.
Und nein eine 90-Tage Agile Transformation ist nicht der richtige Weg zum Ziel.
Das ist nur eine Crash-Diät mit genau dem gleichen Jojo-Effekt (dazu wird bald auch noch ein kritischer Artikel von uns erscheinen 😉 ).
Das wichtigste ist eine gute Basis zu schaffen auf der man Aufbauen kann und dieses Geld ist wertvoll investiert (mit Return on Invest), wenn man sich motivierte Coaches sucht, die das richtige Mindset und die Richtige Haltung mitbringen.
Um ehrlich zu sein, kommen die ganzen Vorteile einer Agile Transformation erst dann richtig zum tragen, wenn man die ganze Herausforderungen auf dem Weg dorthin gemeistert hat.
Das heißt erst dann ergeben sich die ganzen Vorteile, wie z.B.:
Und ja diese Liste ist auf keinen Fall vollständig, aber das ist auch nicht der Punkt. Worauf wir hinauswollen ist, dass die wichtigsten Punkte und Vorteile auf der Liste erst kommen, wenn wir uns den Herausforderungen stellen und diese wirklich angehen, denn…
Eine Agile Transformation ist kein Spaziergang. Es gibt viele Herausforderungen auf dem Weg.
Du siehst es gilt sehr viele Herausforderungen zu meistern während einer Agile Transformation bzw. DevOps Transformation. Die meisten dieser Herausforderungen treten dabei in jedem Unternehmen auf und meistens auch in der gleichen Reihenfolge. Damit du nicht die gleichen Fehler nochmal machst, ist die Unterstützung von erfahrenen, externen Coaches extrem hilfreich und sogar günstiger auf lange Sicht.
Du brauchst Unterstützung von erfahrenen Coaches bei der Umsetzung deiner Agile Transformation bzw. der Einführung dieser Konzepte?
Dann melde dich einfach direkt bei uns: Kostenlose Beratung buchen!
Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!
Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.
Und auch der ist komplett kostenlos. Du findest den Glossar hier:
In der nächsten Folge erklären wir dir, was es alles für Herausforderungen geben kann in einem DevOps Umfeld bzw. bei der Transformation hin zu einem DevOps Unternehmen.
Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:
Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:
Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.
Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.
Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.
Wir freuen uns auf dich in der nächsten Folge.
Deine Agile Coach Academy Gründer Ben und Alex
Mit * markierte Links sind Affiliate-Links mit denen du uns unterstützt dir weiterhin so guten Content zu liefern.
Vielen Dank für deinen Support 🙂
Note: Wir gehen keine Affiliates mit Amazon ein (auch wenn es hier mehr Möglichkeiten gäbe für uns), da die Mitarbeiter hier nicht fair behandelt werden und wir das nicht unterstützen!