Der Weg zu Agilität ist steinig. Regelmäßig scheitern Unternehmen daran, agile Vorgehensweisen einzuführen. Wir sprechen in dieser Folge über die zehn größten Hemmnisse für Agilität – seien es inkonsistente Prozesse und Praktiken zwischen den Teams, generell einschränkende Organisationskultur, die den agilen Werten widerspricht, fehlendes Wissen und Erfahrung oder auch ein zu geringes Interesse des Managements an echter Veränderung. Wir beleuchten alle Aspekte aus unserer Erfahrung und geben dir Ideen mit an die Hand, was du in deinem Umfeld tun kannst, um diese zu adressieren.
Kai:
Warum Agilität scheitert? Es ist herausfordernd, Agile zu arbeiten. In dieser Folge hörst du die Top 10 Gründe, woran agiles Arbeiten scheitert und was du tun kannst in deinem Team und deinem Umfeld, damit das nicht passiert.
Sprecher
Herzlich willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.
Kai:
Herzlich willkommen zum Agile Growth Podcast. Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen agiler Vorgehensweisen in der Praxis einzulösen ohne IT Wissen vorauszusetzen. Und heute geht es darum, warum Agilität scheitert. Das hat, glaube ich, mittlerweile schon jeder wahrgenommen, dass es auf dem Weg zur Agilität viele, viele Hindernisse gibt und dass das auch in vielen Fällen einfach nicht funktioniert die Arbeitsweise so zu verändern, dass man wirklich zu agilem Arbeiten kommt. Wir schauen uns in dieser Podcastfolge die Top 10 Gründe an, an denen Agile Vorhaben scheitern und was du entsprechend tun kannst, damit das nicht dir auf die Füße fällt.
Jasmine:
Und bevor wir jetzt da reingehen ist mir noch mal so ganz wichtig – ich hatte diese Woche einen Workshop und ich find das so spannend. Der Workshop war wirklich zu Agilität – wie können wir das für uns nutzen? Und ich find es so spannend, wenn ich so Workshops habe, kommt immer als allererstes von mindestens einem Teilnehmer oder einer Teilnehmerin. Ja, Agilität ist ja völlig undefiniert. Das versteht ja jeder so für sich selber, wie er es versteht. Ja, kann ja sein.
Jasmine:
Und ich würde dem vehement widersprechen. Für mich ist Agilität sehr wohl definiert. Wir haben das Agile Manifest und für mich ist ein Ausrichten unserer Arbeitsweise an dem agilen Manifest und den Prinzipien bedeutet für mich Agilität. Und ich glaube, für dich ist es auch so, Kai.
Kai:
Genau da gibt es eine klare Definition. Die besteht aus Werten und Prinzipien. Und wenn man sich die Frage stellt – Arbeiten wir eigentlich agil? Dann ist das das, was bei uns im Hintergrund abläuft. Handeln wir nach den Werte-Betonungen, die da stecken, und setzen wir diese Prinzipien um? Das heißt, dass ist kein beliebiger Begriff. Mein BMW kann auch agil fahren. Nein, das ist es nicht, sondern man kann das wirklich abgrenzen. Und falls dich das interessiert, unsere zweite, dritte, vierte Podcastfolge, müsste man schauen
Kai:
Geht darum Agiles Manifest – was hat das eigentlich so auf sich? Aber darum soll es heute nicht gehen, denn heute gucken wir – Woran scheitert das denn, wenn man dann agil arbeiten möchte?
Jasmine:
Aber an der Stelle für dich zum einordnen, superwichtig: auf was beziehen wir uns, wenn wir von Agilität reden? Das ist für uns nicht undefiniert und schwammig und jeder kann das selber definieren. Der erste Grund:
Kai:
Wir haben vor dem Podcast mal den Fifteenth State of Agile Report uns angeguckt. Das ist ein jedes Jahr raus kommender Report, wo viele Agilisten und auch Unternehmen entsprechend dazu beitragen. -Wie ist denn so die Lage in Bezug auf Agilität? Und da gibt es ein ganzes Listing von noch mehr Gründen, woran Agilität scheitert.
Kai:
Wir gehen jetzt mal nur auf die Top Ten ein, weil die uns auch irgendwie bekannt vorkommen aus den letzten Jahren und unseren Ideen dazu. Und wir starten mit dem ersten. Und das ist nämlich, dass es Inkonsistenzen gibt in den Prozessen und Praktiken zwischen den Teams. So, jetzt denkt man im ersten Moment ja Moment mal Scrum zum Beispiel ist ja ein Rahmenwerk, das darf doch jedes Team extra irgendwie ausfüllen, so wie das es gerne hätte. Das ist damit nicht gemeint an der Stelle, sondern – vielleicht hast du das auch schon mal erlebt.
Kai:
Wenn es dann so richtig durchstartet und die Leute in die Selbstverantwortung kommen, dann haben die auch einen ziemlichen Drive drauf. Und bei einem unserer Kunden war das mal so, dass diese Teams so schnell geworden sind, dass die Product Owner gar nicht hinterher kamen, die Backlogs zu füllen. Also die sind ständig leer gelaufen, weil das Team einfach schneller war als alles drumherum. Und das ist dann eben so eine Inkonsistenz zwischen den Vorgehensweisen. Wenn du so ein Speed Boot, dann hast, um mal in so einer Bild-Metapher zu sprechen und das hat aber noch ein paar Taue zu dem Tanker, der die Restorganisation ist, dann ist das natürlich schwierig.
Kai:
Stichwort Abhängigkeiten irgendwie erfolgreich zu sein mit Agilität oder du hast einen großen klassischen Projekt Überbau, dann hast du da drin irgendwie ein kleines agiles Team – das funktioniert ziemlich schlecht. Deswegen ist das so Top 1 Grund, warum Agilität nicht gut funktioniert in Unternehmen. Und jetzt ist natürlich die Frage was kann man da machen?
Jasmine:
Das ist auch wenn du übergeordnet einen Riesen Wasserfall Prozess hast und da drin versuchst irgendwie Scrum zu machen oder da drin versuchst agil zu agieren, das fühlt sich immer ein bisschen komisch an und das wird da auch nicht so ganz funktionieren. Und für mich kommt da der Scrum Master als Nummer 1 Person mit ins Spiel. Als Scrum Master haben wir einen Dienst an den Entwicklern, einen Dienst an dem Product Owner, aber auch an der Organisation. Das heißt, sich da zusammen zu setzen, mit anderen Scrum Mastern zusammenzuschließen und zu gucken – Hey, wie können wir die Prozesse unser Gesamtorganisation ändern, damit auch die einzelnen Teams ihre Agilität voll leben können, ist unglaublich wichtig.
Jasmine:
Und da brauchen wir, glaube ich, ganz, ganz gute Turnschuhe, weil wir laufen da von einem Flur zum anderen. Also das ist wirklich auch so ein bisschen Klinkenputzen, ganz viele Gespräche suchen, gucken, wo finden sich Initiativen, wie wir gemeinsam diese großen riesen Abhängigkeis-Prozesse umgestalten können.
Kai:
Die entstehen manchmal auch daraus. Und darüber haben wir in der Folge über Skalierung auch schon mal gesprochen. Also Skalierung ist ja Agil mit mehreren Teams, dass man einfach sagt hey, ich habe 100 Leute, wie kann ich die agil organisieren? Das ist aber das ist falsche Frage, denn die Frage ist ja, wie viele Leute brauche ich denn, um das Produkt zu bauen? Und das sind vielleicht nur 13 von den 100 und. dann muss ich gar nicht so viel Abhängigkeiten managen, weil dann habe ich irgendwie ein Team, vielleicht zwei Teams, die das Produkt bauen und muss gar nicht so rückwärts denken.
Kai:
Denn das ist natürlich schon ein echtes Hindernis für agie Teams, wenn die harte Abhängigkeiten haben. Und da ist immer die Frage Wie kann ich die reduzieren? Also erst mal erkennen, managen, reduzieren, dass man da hin kommt, dass diese Teams beweglich sind und bleiben. Und da kann man sogar mal verstoßen gegen so Sachen wie – Ich habe beim Informatikstudium gelernt, irgendwie Redundanzen sind des Todes. Also eigentlich willst du gar nichts doppelt haben. Irgenwie, ein Quellcode und so weiter.
Kai:
Das führt natürlich dazu bei der technischen Lösung, dass du dann Sachen raus extrahierst irgendein Rahmen-Framework, dann hast auf einmal zack Abhängigkeiten drin und vielleicht willst du diese sogar zurückbauen. Also und das Thema ist aber so breit, dass wir an der Stelle auch jetzt nicht sagen können Pauschal macht das, sondern die Grundintention ist, Abhängigkeiten erst mal erkennen und dann zu versuchen zu reduzieren. Und dazu gibt es einfach viele, viele Strategien und das ist sehr kontextabhängig von deiner Umgebung, was genau da der nächste Schritt ist, um da weiterzukommen.
Jasmine:
Was mir an der Stelle immer hilft, ist wirklich den Kundenfokus herzustellen. Das ist für mich ein ein Grund-Ding der Agilität, dass wir einen radikalen Kunden Fokus herstellen und vom Kunden her denken um zu gucken was braucht denn der und wie müssen wir unsere Organisation aufstellen, damit unser Kunde möglichst den besten Mehrwert hat? Und da kommen wir vielleicht auch schon zum Zweiten Punkt, der sehr, sehr schwierig ist, wo Agilität oft scheitert, nämlich da, wo die Organisationskultur nicht passt mit den agilen Werten.
Jasmine:
Ich war schon mal unterwegs in einem Kontext, da hatte ich ständig diese Diskussion von „Ja, aber unser Kunde weiß ja gar nicht, was er will. Unser Kunde ist ja blöd. Unser Kunde ja, nee, wir wissen’s ja besser als der Kunde.“ Ja, das ist dann schwierig, weil das führt alles ad absurdum. Dann muss ich auch nicht regelmäßig und schnell liefern, weil wenn ich dem Kunden etwas zeige, regelmäßig und schnell und der sowieso nicht weiß, was er will und sowieso doof ist, dann wird er mir auch kein passendes Feedback geben.
Jasmine:
Das heißt, ich kann da gar nicht iterativ arbeiten. In so Kontexten wird Agilität sehr, sehr schwierig einzuführen sein. Oder wenn wir eben diesen radikalen Kunden Fokus nicht herstellen können, weil wir noch 300 Hierarchieebenen haben, die auch alle wichtig sind und vielleicht sogar wichtiger als unser Kunde.
Kai:
Das war auch ein Umfeld, das ich auch schon mal hatte ein hochpolitisches Unternehmen. Das war also so als wir mit Agilität dann losgelegt haben, hat man einfach sehr klar gesehen, dass so ein Produkt-Backlog nicht sortiert ist nach dem höchsten Wert für den Anwender, sondern nach politischem Gefallen innerhalb der Organisation. Und wenn das ein Entwicklungsteam dann sieht und spürt, dann fassen sich natürlich schon alles ein bisschen an den Kopf und denken so okay, aber das ist doch jetzt nicht Agile.
Kai:
Also wir wollten doch jetzt den idealen Wert liefern hier für unsere Anwender. Und das ist dann auch richtig schmerzhaft und macht den Leuten gar keinen Spaß, weil das natürlich auch irgendwie komplett gegen die Werte und Philosophie dahinter steht. Und was es da gebraucht hätte, wäre die Führungsperson, also der Sponsor, in dem Fall mehr mit Agilität zu konfrontieren. Ich gebe zu, da war ich noch relativ unerfahren, was Agile anging und habe da nicht die Führungskraft genug mitnehmen können in diese Richtung, um einfach diesen Dialog und das Sparring zu haben, weil die Führungsperson da ganz, ganz klar diese Organisationskultur auch mitgeprägt hat.
Kai:
Und ja, das ist vielleicht auch der Teil. Kultur ist natürlich eher so der Schatten der Organisation, die kann man nicht so direkt anpacken und sagen wir drehen jetzt die Kultur irgendwie anders. Aber man kann natürlich mit den Menschen arbeiten, die die Kultur ganz, ganz stark prägen. Und das hat eben auch viel mit dem Führungsverhalten zu tun, was in der Organisation okay ist, geahndet wird, nicht geahndet wird und auch den Märchen und Geschichten, die man sich erzählt von früheren Zeiten in der Organisation.
Jasmine:
Und was mir als Scrum Master da immer hilft, wenn ich in solche Situationen komme, in Umfelder dann reinkomme, ist nicht anfangen zu missionieren und zu sagen Kuck mal, das sind die Agile Values, die müssen wir jetzt leben, weil sonst wird das alles hier den Bach runtergehen, sondern wirklich zuerst mal zu analysieren und zu gucken was haben wir denn für eine Organisationskultur? Ist die eher kompetitiv oder ist die kollaborativ? Ist sie eher Zahlen, Daten, Fakten getrieben? Oder sind wir alle Gefühlsmenschen und so weiter?
Jasmine:
Da kann ich mal einfach reingehen um zu gucken wo stehen wir denn grade in unserer Organisationskultur? Und dann gucke ich mir die agilen Werte an und gucke – Und welcher Wert ist der einfachste zum Erreichen?
Kai:
Und das wird tatsächlich mit der Zeit auch einfacher. Stelle ich fest. Denn wenn man viel in so agilen Umfeldern arbeitet, dann merkt man, wenn das nicht passt, in dem System, wo man beauftragt wird oder auch wenn es dein eigenes Unternehmen ist, wenn du da mal in ein Nachbar-Team reingehen sollst oder so. Dann kriegst du vielleicht so einen Impuls und der heißt renn ja – also versuch irgendwie hier nichts zu machen, weil das passt kulturell irgendwie gar nicht da hin. Mit dem gesagt:
Kai:
Sowas wie Scrum ist natürlich auch ein Kulturwandler. Das heißt auch durch das Tun entstehen andere Werte. Und das ist eben auch dieser große Konfliktpunkt. Dann kommen nämlich die Scrum Werte Mut, Fokus, Offenheit, Commitment, Respekt. Einfach in den Kontrast zu denen, die bisher da sind. Und das kann eben passen oder auch nicht. Also insofern ist auch mit Scrum anfangen eine Möglichkeit, so eine Kultur zu wandeln. Aber da braucht es eben auch dann die Führung mit an Bord.
Kai:
Das funktioniert ja nicht nur im Team, dann eigentlich was zu machen.
Jasmine:
Ich hatte ein total spannendes Gespräch mit einem Teammitglied letztens, mit dem wir schon ein bisschen länger arbeiten mit dem Team mit der Abteilung arbeiten wir schon ein bisschen länger und dieses Teammitglied meinte „Ja, ich war jetzt gerade so in Terminen außerhalb von unserer Abteilung in so Community Runden und die haben da irgendwie alle gemeckert und gelästert und es war irgendwie eher trübe Stimmung. Und ich glaube noch vor einem Jahr hätte ich total verstanden, was die alle sagen und meinen. Und mit der neuen Erfahrung, die ich jetzt gemacht habe, habe ich mir nur so gedacht Jungs, hört auf zu meckern, kann man alles anders machen, kann man alles anders organisieren.“
Jasmine:
Und das ist das, wo ich immer denke, was am meisten hilft ist, wenn man so kleine Kultur Bubbles anfängt zu etablieren, weil die ganze gesamte Organisationskultur auf einmal zu verändern. Das werden wir nicht schaffen, das schaffen vor allem nur durchs Tun. Am Anfang ist meistens das Tun, die neue Beziehungserfahrung, die neue Arbeitserfahrung schaffen und dadurch wird sich die Kultur wandeln. Das werde ich nicht – zack – in der gesamten Organisation hinkriegen. Deswegen ist mein Gedanke ganz oft.
Jasmine:
Den habe ich bei Michael Sahota mir geholt :Lass uns Kultur Bubbles machen, lasst uns gucken, wie wir einzelne Kultur Bubbles machen können in der Organisation, weil die werden sich ausweiten und da drin neue Beziehungserfahrungen, neue Arbeitserfahrungen schaffen, damit wir da drinnen eine neue Kultur erschaffen können, die sich dann meistens auf das Recht des Unternehmens auswirken wird. Und am Anfang kann das sein, dass ich relativ hohe Steuern zahlen muss ins Rest des Unternehmens, weil ich eine andere Kultur erschaffe, mir da drin, weil ich eine neue Arbeitsweise habe.
Jasmine:
Und diese Steuern kann ich dann anfangen zu minimieren, um das mal so bildlich gesprochen zu haben. Und an der Stelle auch zu sagen: Wenn wir den Report angucken, der kommt ja jährlich, diese Komponente „Die Organisationskultur passt nicht zu den agilen Werten. Die war jetzt wirklich top top top of Hindernisse die ganze Zeit. Jetzt ist es schon an zweite Stelle gerückt, sprich: Es ist gar nicht mehr ganz so schlimm.
Kai:
Dann sind wir beim dritten Faktor, nämlich dass eine Organisation generell Widerstand hat gegen Veränderung. Das kennst du vielleicht auch persönlich. Also wenn man jetzt mal Organisation als einen Organismus nimmt und dich selbst als einen Organismus, wie viel Veränderung hast du schon probiert? Wie viel haben geklappt? Und ja, es gibt einfach Leute, die haben mehr Disziplin und Drive, um Veränderungen in ihr Leben reinzubringen. Und ich glaube, für alle ist es hart, wenn man – je nach Treiber, die man so hat für die Veränderung.
Kai:
Manchmal passieren schreckliche Dinge im Leben und man muss dann einfach und dann hat man vielleicht auch den Drive, das durchzuziehen und viele andere Sachen bleiben stecken bei dem frohen Neujahrswünsche, wo man dann denkt, das wäre doch toll, wenn wir das machen könnten und so ist das mit Organisationen nicht anders. Auch da gibt es die Fresszellen, die Killerzellen, die sehen – „Oh, ein Eindringling ist jemand Neues da – den müssen wir vernichten und ausstoßen.“ Und je nachdem, wie eine Organisation da drauf ist und die das eher gewöhnt ist, neue Ideen zu integrieren oder eben neue Ideen auszustoßen.
Kai:
Und da es halt nicht anders als andere Ideen, da ist es erst mal eine Idee und die wird dann eliminiert und rausgeschmissen.
Jasmine:
Und auch das darf eine Organisation üben. Also für mich geht das sehr, sehr stark Hand in Hand mit: „Die Organisationskultur passt nicht zu den agilen Werten. Natürlich muss ich als Organisation oder darf ich es als Organisation üben, neue Ideen zu akzeptieren in einer komplexen Welt, wo ich nicht weiß, was ich nicht weiß. Da werden immer wieder neue Ideen kommen und diese neuen Ideen werden mir vielleicht nicht immer gefallen, weil Veränderung ist für uns Menschen echt „a bitch“. So mögen wir nicht so ganz so gerne, also auf jeden Fall ich nicht.
Jasmine:
Und ich glaube, ich bin schon ein Mensch, der eigentlich viel Veränderung erträgt, akzeptiert und auch selbst mit initiiert. Und trotzdem fühlt sich das halt immer mal wieder echt doof an. Und das fühlt sich für den Einzelnen doof an. Das fühlt sich dann für die Gruppe doof an. Es fühlt sich für das ganze Organisationssystem doof an. Sprich wir dürfen das an der Stelle lernen, Veränderung mit in unseren Alltag zu integrieren, zu akzeptieren und damit umgehen zu können.
Kai:
Und so ein bisschen der Lackmustest für dich ist, wenn du in Kontakt kommst mit dem System und da reiten jetzt mittlerweile auch viele Agilisten darauf rum. Das machen wir auch so: „Start with the Why“ – Wieso überhaupt Agilität? Denn das ist ja auch irgendwie ein Mittel zum Zweck, hätte ich fast gesagt. Auch wenn es natürlich auch eine Haltung ist, also mehr als nur ein Mittel. Aber es braucht einen Treiber dafür und da kann man halt andocken bei ich sag mal klassisch Freud, Schmerzvermeidung oder Lustgewinn auch für die Organisation und die Leute, die das entsprechend beauftragen und das dann erst mal rauszufinden, um zu gucken „Gibt es hier irgendeine Kraft?
Kai:
Eine Welle, auf der wir so eine Veränderung mit rein tragen können?“ Das ist dann das, was wir ganz, ganz viel tun am Anfang, in der Auftragsklärung. Um das klar zu haben und nicht an dieser generellen Organisationsresistenz einfach abzuperlen.
Jasmine:
Oder wenn wir es mit Virginia Satir sagen, die sagt ja, Leute verändern sich dann, wenn der Schmerz der Veränderung kleiner ist als der Schmerz, den ich gerade ertrage, wo ich stehe. Es gibt auch andere Veränderungs-Theorien, die sagen wir verändern uns auch aus anderen Gründen, aber ich finde das ist immer so ein ganz guter Treiber, mit dem „Why“ zu starten. Was für ein Problem haben wir denn wirklich? Was wollen wir lösen mit Agilität? Und wenn es da keins gibt, dann wird unsere Agile Transition oder wie auch immer wir das nennen wollen wahrscheinlich scheitern.
Jasmine:
Der vierte Punkt auf den größten Hindernissen zum Weg von Agilität ist, dass die Leute zu wenig Skills und Erfahrung mit Agilität haben. Und das ist für mich immer so ein Punkt. Ich bin ja nicht der gute Verkäufer. Nicht unbedingt. Und das fühlt sich dann immer so ein bisschen an, als würde ich jetzt meine Coaching-Fähigkeiten verkaufen. Aber mir hat mal eine Kundin von mir gesagt: „Guck mal, Jasmine, wir haben, bevor du gekommen bist, Bücher gelesen.
Jasmine:
Wir haben unser Wissen aufgestockt. Wir haben Leute in Scrum Master Kurse geschickt. Wir haben alles getan an Wissen aufbauen, was wir konnten, damit wir dieses Agile Scrum Ding irgendwie meistern können. Aber niemand von uns hat das mal gefühlt gehabt vorher. Niemand von uns hat die Erfahrung gemacht, so müsste sich das anfühlen, wenn es mal fluppt oder – So könnte das irgendwie sein. Und dadurch konnten die das für sich gar nicht umsetzen. Weil alles, was wir ja neu lernen, setzen wir in den Referenzrahmen des Lernens, den wir schon jetzt haben.
Jasmine:
Und wenn wir da keine Erlebbarkeit drin haben als Mensch, dann wird das natürlich erheblich schwierig mit einem Buch oder auch mit einem zwei, drei Tage Scrum Master Kurs zurückzugehen und zu sagen: „Wir probieren das jetzt direkt aus.“ Da hilft es wirklich, einen Menschen an der Seite zu haben, der diese Erfahrung schon gemacht hat. Und das kann man auch verschiedene Methoden ja bewerkstelligen. Also man kann sich einen Coach reinholen, der einem oder die einen da begleitet. Ich kann aber auch einen Mitarbeiter von außen rein holen, der oder die schon viel Agilität erlebt hat und mithilft, das in unsere Firma rein zu tragen.
Jasmine:
Ich glaube einfach, wenn ich noch keine Referenz-Erfahrung dafür gemacht habe, wie sich das anfühlt, dann wird es echt schwierig.
Kai:
Fünfter Punkt: Nicht genug Leadership-Partizipation also nicht genug Teilnahme vom Management an dieser ganzen Geschichte, dieses Agile. Wasch mich, aber mach mich nicht nass hier in der Abteilung. Also bitte probiert mal die Probleme meines Teams zu beheben. Das sind dann manchmal die Mandate, die wir bekommen. Wir sagen, dass das nicht immer so direkt aus dem Kopf raus, aber uns natürlich schon. Klar. Das heißt hier, wir müssen auch definitiv mit dem Management arbeiten und wir haben es beim letzten Kunden so ein bisschen übertrieben.
Kai:
Die haben dann gesagt, bitte geht jetzt mal endlich in die Teams, wir haben jetzt irgendwie 3-4 Wochen mit euch „Agile und warum? Und was ist das und wollt ihr das wirklich? Und so weiter. Und fangt doch mal endlich an mit dem Team zu arbeiten“. Weil wir eben ganz, ganz sicher sein wollen, dass die Leute das Mitgehen und dieses Mitgehen vom Management, dieses am eigenen Leib erfahren was das heißt und am besten selber vielleicht in einem Veränderungs-Team so zu arbeiten. Das ist wichtig, denn nur dann kann man auch wirklich mitbekommen.
Kai:
Was heißt das denn als Implikation für meine Teams, für meine Mitarbeiter? Wieso verhalten sie sich jetzt anders? Wieso brauchen die jetzt was anderes und wie lasse ich überhaupt die Kontrolle los, damit die in Selbstverantwortung kommen können?
Jasmine:
Weil es heißt ja dann auch für das Management und mit dem Management meine ich vom Vorstand über Geschäftsführung zu Abteilungsleiter, zu Teamleiter. Also ich meine da alle, ich muss lernen, anders zu führen. Dinge, die ich vorher getan habe, werde ich vielleicht nicht mehr tun. Und ich darf mir auch Gedanken darum machen, wie gehe ich mit dieser Veränderung um? Weil wenn ich vorher sehr, sehr stark fachlich geführt habe und auf einmal einfach nur noch Rahmen hinstelle und sage ja Fachlichkeit mache ich jetzt nicht mehr.
Jasmine:
Ich bin jetzt eine Agile Führungskraft, ich mache ja nur noch Rahmen, dann werden meine Mitarbeiter genauso lost sein, wie wenn ich weiter nur noch fachlich führe und da fest halte und denen eigentlich gar nicht die Freiheit zur Entfaltung gebe. Das heißt, wenn ich da anfange mit Agile oder mittendrin bin, mit Agile, wird das ein kontinuierlicher Prozess sein zu gucken was ist unser Führungsbild, was ist unsere Führungsparadigma und wie darf sich das auch wandeln mit dem Wandel der Teams?
Jasmine:
Und das ist so ein ganz, ganz wichtiger Punkt. Wenn Teams anfangen agil zu arbeiten, dann fangen die an, sich ständig zu hinterfragen, zu reflektieren und ihren eigenen Prozess zu verbessern. Sprich was heute gut war für die, wird in zwei Jahren nicht mehr gut für die sein und vielleicht schon in zwei Monaten nicht. Ich muss als Führungskraft da ja dann mit am Ball bleiben, mich selber hinterfragen und reflektieren und stetig gucken „Und wie darf ich jetzt als Führungskraft sein, damit ich meine Teams optimal unterstütze?“
Jasmine:
Das ist für mich so ein bisschen wie meine Mutterrolle. Also ich weiß, die von euch, die Kinder haben, vielleicht kennt ihr das – man hat immer wieder so Situationen, die sind anstrengend mit den Kindern. Dann denkt man so Boah, warum geht das jetzt nicht mehr? Warum ist es echt so anstrengend hier zu Hause und dann macht es irgendwann mal auf einmal klick und dann läuft’s. Und dann denkt man so, boah, jetzt ist wieder cool! Und die nächste anstrengende Situation, die ist dann einfach nur gleich ums Eck, weil das ja ein konstanter Wandel ist.
Jasmine:
Unsere Kinder wandeln sich konstant, die wachsen konstant und bei den Kindern sagen wir auch das ist völlig normal, die müssen sich ja entwickeln. Irgendwann mal, wenn wir da so erwachsen werden, ist das anscheinend nicht mehr normal, dass wir uns konstant entwickeln, sondern wir wollen, dass die Menschen gleich bleiben. Das ist ein bisschen paradox und widerspricht einfach dem agilen Gedanken. Wir werden uns als Mensch ständig wandeln und weiterentwickeln, als Team ständig wandeln und weiterentwickeln, als Organisation ständig wandeln und weiterentwickeln.
Jasmine:
Und entsprechend darf sich auch das Leadership, das Management auf allen Ebenen ständig wandeln und weiterentwickeln. Wir gehen weg von: „Was Hänschen nicht lernt, lernt Hans nimmermehr“ hin zu: „Was Hänschen nicht lernt, ist eine große Chance für Hans, später Fun zu haben.“
Kai:
Und ich glaube, damit haben wir den sechsten Punkt auch direkt mit erschlagen, nämlich unadäquate Management-Unterstützung und unadäquate Schirmherrschaft. Ja genau, also da muss jemand sein, der will das dann auch wirklich und er weiß auch, warum man das möchte und was das für Konsequenzen hat.
Jasmine:
Was wir ganz oft machen mit unseren Kunden. Also hier noch mal ein Tipp, wie das so funktionieren kann, ist, dass wir wirklich ganz konkret sagen: Okay, wenn wir hier mit einem agilen Vorhaben beginnen, dann bedeutet das für dieses Vorhaben, dass die Mitarbeiter da drin gewisse Freiheiten brauchen im Organisations-Kontext, den sie sonst vielleicht nicht hätten. Dafür brauchen wir die Schirmherrschaft. Dafür brauchen wir einen Menschen, der möglichst irgendwo hoch ist, damit wir Regeln brechen können, weil nur dann können wir als Organisation ja auch lernen.
Jasmine:
Welche Regeln hindern uns und welche Regeln sind gut für uns? Und das ist ein ganz großes Umlernen der Organisation: Wo fesseln wir uns selber oder wo tut uns der Rahmen auch gut? Und dieses Agile Vorhaben darf dann öfters einfach – das hat so ein bisschen Narrenfreiheit. Die dürfen tun und lassen – nicht was sie wollen – aber die dürfen sehr viel mehr tun und lassen als andere, dürfen viel mehr Regeln brechen, um genau das rauszufinden. Und es braucht ein großes Augenmerk drauf. Das braucht eine gute Schirmherrschaft drauf und das braucht ein ganz anderes Management-Paradigma dahinter.
Jasmine:
Der nächste Punkt ist unadäquates Training oder Wissen.
Kai:
Ohne ein gemeinsames Bild davon, was überhaupt Agilität ist und wie sich das anfühlt und das mal im geschützten Rahmen zu erleben ist das wirklich schwer, dann auch gemeinschaftlich Energie freizusetzen und in die gleiche Richtung zu gehen. Und ja, natürlich, das ist bei uns immer eine der ersten Maßnahmen, die wir machen, entsprechend ein Training durchzuführen – Scrum Trainings zum Beispiel – falls du dich da weiter vertiefen willst, wir haben auch letztens ein Buch drüber veröffentlicht.
Kai:
Das heißt auch Scrum Training. Und da geht es natürlich schon darum, auch mal das einmal gemeinschaftlich dieses Wissen aufzubauen und die ganzen agilen Mythen mal platt zu klopfen. Denn es gibt ja doch ganz viel mittlerweile dazu, was alles irgendwie Agile sein soll angeblich und was irgendwie Teile von Scrum sind und was man noch an Kanban reingedichtet hat und so weiter und so fort.
Jasmine:
Und wir haben festgestellt, dass es relativ viele Trainings auf dem Markt gibt, die einfach ein riesen Bild machen und das ist manchmal dann sehr, sehr schwierig und viele Trainings sind auch sehr sehr global und behandeln dann gar nicht das Problem, das wir in der Organisation gerade haben. Also ich bin ein totaler Fan von einem Grundlagen-Training, damit wir alle mit der gleichen Basis starten, damit wir eine gemeinsame Sprache sprechen, damit wir alle wissen wohin wir wollen und dann müssen wir und dürfen wir auf dem Weg immer wieder rausfinden.
Jasmine:
Und wo brauchen wir weiteres Wissen und das wird für jede Organisation anders sein. Also wenn ein Kunde auf mich zukommt und es kommen manchmal Kunden, die sagen wir brauchen jetzt hier ein ganzes Education-Konzept. Da kann ich sagen kann ich euch nicht bieten. Das wird für jedes Team bisschen anders sein. Es gibt Teams, wenn die wirklich Softwareentwicklung machen, die merken an einer gewissen Stelle relativ schnell: Oh Mist, wir wissen nicht, wie wir wirklich kontinuierlich integrieren.
Jasmine:
Wir haben zu wenig Ahnung von Testen, damit wir das guten Gewissens machen können. Wir brauchen da Training. Es gibt andere Organisationen, die merken: Wir sind sehr, sehr schwach auf der Brust, was dieses Product Ownership angeht. Wir haben da ganz wenig Ahnung von wie Produktmanagement wirklich geht. Die brauchen da mehr Unterstützung. Oder es gibt Organisationen, die haben diesen ganzen Komplex von menschlicher Arbeit. Wie arbeiten wir als Mensch gut Facilitation Skills, also diese ganze Scrum Master hin zu Agile Coach Geschichte nicht drauf etc.
Jasmine:
Da gibt es ganz, ganz viele Dinge und da können wir nicht so einen Kahlschlag machen. Die meisten agilen Teams, die ich kenne, brauchen irgendwann mal ein erhebliches Budget für Wissensaufbau und auch da darf man als Team wieder in die Kommunikation gehen. Was stimmt denn für uns und was passt für uns? Einige Leute lernen gut, indem sie ein Buch lesen und das anwenden. Andere wie Kai: machen super gerne Online-Kurse. Ich hasse Online-Kurse. Also andere Menschen wie ich gehen auf Konferenzen, trinken da ganz viel Kaffee mit Leuten und bekommen da ihr ganzes Wissen mit.
Jasmine:
Ich gehe auf Konferenzen ja selten in Vorträge rein außer ich halte ihn selber. Da muss ich da sein. Also es gibt so ganz unterschiedliche Lerntypen. Ich sauge mir das Lernen meistens aus Konversation raus. Open Spaces, das perfekte Format für mich zum Lernen. Da dürfen wir uns über das Thema unterhalten. Wie lernt jeder einzelne, was für Skills brauchen wir? Ich liebe es da eine Skill Matrix mit den Teams zu machen, was für Skills brauchen wir die nächsten sechs Monate und welche Lern Formate wenden wir wo an?
Jasmine:
Für wen? Damit wir diese Skills draufhaben?
Kai:
Dann sind wir beim Punkt Nummer 8, nämlich dass sich so traditionelle Entwicklungs-Methoden einfach rein gekrallt haben in die Organisation und da ganz lange geprägt haben, wie man eigentlich entwickelt. Zum Beispiel hatte ich mal ein Unternehmen, die haben auch physikalische Produkte gemacht im Kunststoff Bereich und die waren ganz lange so Stagegate Prozesse gewöhnt, wo es immer so Freigabe Punkte gab, wo es auch eine bestimmte Dokumentation brauchte und so weiter. Und wenn du jetzt damit Agil um die Ecke kommst, dann haben die halt in ihrem mentalen Modell immer gedacht: „Okay, das ist dann was für das machen wir von der Phase 1 bis 2, iterieren wir irgendwie drüber oder so“, aber diese Dinge sind so inkompatibel miteinander, dass das irgendwie gar nicht passt.
Kai:
Also vom Denkrahmen her. Und wenn es dann natürlich viele Menschen gibt, die das bisher gewöhnt waren und das auch nicht loslassen wollen, weil das einfach lange, lange Zeit einen Nutzen hatte oder auch noch kein Nutzen in der Veränderung erkannt worden ist, dann hält man daran fest, wie man das schon immer gemacht hat, weil das bisher natürlich auch der Weg des Erfolgs war.
Jasmine:
Was an der Stelle wiederum hilft, ist wirklich: Problem erkennen, Problem anerkennen, Problem entpersonalifizieren an den meisten Stellen. Wir sind sehr, sehr schnell dabei zu sagen: Ja, aber das ist ja nur der Hans, der nicht mitgehen möchte. Das ist ja nur der hmhmhm, wenn der nicht wäre, dann und so weiter. Also wirklich das Problem entpersonalifizieren und zu gucken: okay, wenn wir so sehr anhaften an irgendwas, dann muss es uns ja auch was geben.
Jasmine:
Eine Sicherheit, irgendein positiverr Benefit muss für uns irgendwann mal dagewesen sein oder ist immer noch da und dann können wir gucken: Und was wäre denn jetzt noch besser? Was gäbe uns noch mehr positiven Benefit? Wir werden uns nicht verändern des Veränderung Willens, sondern die meisten Menschen verändern sich und auch die Systeme verändern sich, weil sie den Drang dazu haben, weil da hinten was besseres wartet. Und dieses Bessere unglaublich gut zu formulieren hilft dann – vorheriger Punkt Wissen rein zu holen, wenn mir denn Wissen fehlt oder eine neue Gewohnheit etablieren, die uns hilft diese neue Entwicklungs-Methode umzusetzen.
Kai:
Eine ganz pragmatische Variante, damit umzugehen mit traditionellen Umfeldern in der Produktentwicklung war für mich auch immer selber Vorreiter zu sein. Also als ich meinem ersten Team Agilität eingeführt habe, habe ich mich selber als Entwickler reingekniet in so Praktiken wie Testgetriebene Entwicklung oder Behavior Driven Development. Und habe da einfach den Vorreiter gemacht und habe die anderen dazu als quasi von innen heraus Teammitglied dazu ermuntert, doch mehr da rein zu investieren in Agile Softwareentwicklung und das Extreme Programming. Diese Techniken, die dahinter stehen.
Kai:
Und wenn man da jemand Gutes finden kann, den man in sein Team reinstafft, dann hat das auch direkt einen Einfluss auf das Team, was dieses Team tut, was das investiert. Also von innen heraus das mitzugestalten durch einen geschickten Recruiting Prozess hätte ich fast gesagt. Das macht auch sehr sehr viel Sinn, wenn man das kann und keine Fähigkeit im Team hat, weil einfach alle gewöhnt sind anders zu arbeiten.
Kai:
So der neunte Punkt, ein fehlendes Geschäftsmodell dahinter oder auch kein Zugriff auf die Kunden oder kein klar umrissenes Produkt.
Kai:
Das klingt ja erst mal total, als ob das wenig Firmen betreffen würde. Aus der Praxis heraus habe ich aber schon den Eindruck, was wir an Visions-Workshops gemacht haben mit Leuten und Visions-Formate irgendwie erklärt und reingebracht, um überhaupt mal zu klären: Was ist denn das Produkt? Was ist denn der Mehrwert dieses Produkts? Was ist das Abgrenzungsmerkmal? Kann ich das schon nachvollziehen, auch der ominöse Kunde, der dann doch teilweise relativ weit weg ist. Also in den letzten Mandaten hatten wir ja bisher Glück.
Kai:
Da konnten wir tatsächlich die Anwender, die das Produkt nutzen, immer wieder in die Sprint Reviews reinholen. Dass da wirklich auch das Entwicklungsteam lernt, was sie an Assumptions, was sie an Hypothesen im Kopf hatten und was davon passt oder nicht.
Jasmine:
Und ich würde sagen, wir hatten kein Glück. Wir haben mittlerweile die Erfahrung gemacht, dass das möglich ist. Und wir sind sehr, sehr, sehr persistent darin, Leute zu nerven, herauszufinden, wie wir das möglich machen. Und bei 100 Prozent – allen Kunden kriegen wir erst mal die Rückmeldung: Das ist bei uns nicht möglich. Immer. Also wenn du da bist und denkst, bei uns ist das aber nicht möglich. Es ist möglich. Also außer du machst
Jasmine:
eine Software für Insolvenz Betreibungen, dass vielleicht der Mensch, der betrieben wird, jetzt nicht unbedingt in deinem Sprint-Review drin ist und gut gelaunt Feedback gibt. Ja, okay.
Kai:
Na gut, du kannst einen Kreis von Insolvenzverwaltern fragen. Also irgendein Feedbackgeber gibt es immer der deine Assumptions irgendwie herausfordern kann.
Jasmine:
Aber an der Stelle, was für die meisten echt echt schwierig ist, ist rauszufinden wer ist wirklich unser Kunde und was ist wirklich unser Produkt? Weil wir unsere Firmen so extrem verzettelt aufgebaut haben und so extrem in die Spezialisierung gegangen sind, dass wir oft einfach unglaublich weit weg sind und nur ein Mini Teilschritt von einem Produkt machen. Sprich wenn wir dann in eine Agile Arbeitsweise gehen, muss uns bewusst sein, dass das bedeutet, dass wir die gesamte Organisation umbauen, nämlich an unserem Kundenstrom entlang.
Jasmine:
Wenn wir das nicht tun. Dann fühlt sich Agilität, also insbesondere Scrum echt dröge an, weil wenn mein Kunde für mein Produkt einfach nur die nächste Abteilung ist oder das nächste Team, dann habe ich kein Produkt. Und das sind so die Gedanken, die wir mit Kunden dann ganz oft machen. Wofür werden wir bezahlt? Wofür kriegst du Kohle? Und dann an dem Punkt anzufangen, also ganz hinten anzufangen, wofür kriegen wir Kohle? Und was ist denn genau das Produkt dann?
Jasmine:
Und das kann sein, dass das mehrere Teams betrifft. Es kann sein, dass das ein Team betrifft, aber da braucht es oft relativ viel Analyse. Und dann auch der Gedanke „Und wie bauen wir jetzt die gesamte Organisation um, damit wir an diesem Wertestrom sind?“
Kai:
Also was kannst du konkret tun: die Menschen, die Kunden reinholen in das Sprint Review, dafür Sorge tragen, dass diese Feedback Schleife geschlossen ist und dafür Sorge tragen, dass das Produkt definiert ist. Dass jemand mal in einem Elevator Pitch sagen kann im Aufzug in 30 Sekunden: Wir bauen dieses Produkt und das hat diesen Nutzen. Und das ist anders als das andere am Markt, was es auch noch gibt.
Jasmine:
Der letzte Punkt auf unserer Liste für heute ist die fehlende Bereitschaft, Fehler zuzugeben und aus Fehlern aus der Auslieferung zu lernen. Ich habe hier letztens ein Mitglied aus einem größeren Team von einem Kunden von uns so gefeiert, als dieses Mitglied in einem Event gesagt hat: „Leute, ich glaube wir sind viel zu Sicherheitsbedacht hier unterwegs. Wir machen gerade viel zu wenig Fehler.“ Und das fand ich so cool, weil dieses Mitglied einfach meinte: „Hey, wir müssen noch mehr Risiken eingehen, dann kommen wir noch näher an das Kundenbedürfnis ran.
Jasmine:
Und ja, das kann heißen, dass es mal irgendwie kacke läuft. Oder dass wir einen Fehler machen. Aber dann lernen wir daraus, weil Fehler sind Gold wert.“
Kai:
„Wir machen Fehler schneller als alle anderen“ – war mal so ein Leitmotto, ich weiß leider nicht mehr, von welchem Manager, ich müsste das jetzt mal googeln. Aber diese Haltung dahinter. Also „fail early“ und dann aber auch daraus zu lernen – es geht natürlich nicht darum, also der Fehler macht ja keine Freude. Der Fehler ist einfach nur ein Schritt, um mehr zu erkennen, was der Markt will und was die Kunden brauchen. Und deswegen brauchen wir das um uns da ran zu tasten.
Kai:
So ein bisschen wie Autofahren im Nebel. Man fährt immer so ein Stückchen, dann guckt man irgendwie, wo ist da die Kante. Und das will ich mit meinem Produkt auch machen. Das tun ja Startups die ganze Zeit, die pivotieren, die gucken, wo kann ich mich am Markt irgendwie etablieren? Was wird gefragt, was wird gebraucht? Und um da reinzukommen, brauche ich einfach regelmäßig Fehler. Ich fahre ein Stück weit gegen eine Wand oder mit dem Reifen so ein bisschen ab von der Spur und muss dann wieder korrigieren, um entsprechend der Straße weiter folgen zu können, wo ich eigentlich hin möchte.
Jasmine:
Und das braucht natürlich in der gesamten Organisation ein Umdenken, was die Fehlerkultur angeht. Und viele sagen ja dann schon: „Ne, das ist keine Fehlerkultur, es ist eine Lernkultur. Ja, natürlich ist es eine Lernkultur, aber wenn ich gerade in einer sehr Sicherheitsbedachten Kultur unterwegs bin, dann ist Fehler machen einfach per se mal eine riesen riesen Gefahr. Auch einfach für mein Gehirn. Das ist nicht so einfach das umzudenken und da werden auch „Fuck up Nights“ jetzt nicht helfen, weil was passiert an „Fuck up Nights“ ganz schnell ist:
Jasmine:
Irgendjemand stellt sich auf die Bühne, sagt ich habe hier Scheiße gemacht, aber jetzt bin ich der Held. Das ist dann irgendwie diese Sicherheitskultur nochmal untermauern. Was ich da gerne mache, ist wirklich im Kleinen anzufangen, im Team anzufangen. Gucken, dass wir Fehler da sicher machen können, die psychologische Sicherheit extrem zu erhöhen. Und wie schon gesagt in der Folge zu Psychologische Sicherheit: Das kann ich nicht über das ganze Organisation und Unternehmen machen, sondern das ist ein Team Konstrukt.
Jasmine:
Das muss jedes Team für sich selber machen. Und da zu gucken: „Hey, wie können wir es sicher machen Fehler zu machen und daraus zu lernen?“ Weil das ist der zweite Schritt. Es geht nicht darum Fehler zu machen, einen Schuldigen zu suchen, sondern Fehler zu machen und zu gucken wie können wir gemeinsam lernen. Und das braucht ganz oft sehr, sehr viel Diskurs, sehr viel Diskussion und auch wieder sehr viele Iterationen drüber: Wie ist denn das für uns?
Kai:
Wenn man einen Fehler gemacht hat, dann ist man in seinem Team auch meistens mit Schuld beladen, also man selber es ist einem ja unangenehm. Es ist peinlich. Man will das nicht machen. Da hilft das natürlich nicht auf den drauf zu picken, der jetzt einen Fehler gemacht hat. Der weiß ja eh schon, dem geht es eh schon schlecht und dem tut es eh schon leid. Deswegen gibt es einen kleinen Kulturhack für Teams, den finde ich ganz nett, das mache ich auch öfters mal ein „Failure Bow“, das ist so aus dem Künstlerischen stammend, einfach so eine kurze Verbeugung.
Kai:
„So, ich habe verkackt.“ Und das nimmt einem diesen sozialen Druck des Fehlers weg und dann kann man wieder weiterarbeiten, dann kann man auch gucken, wie kann ich das System so optimieren, dass weniger dieser Fehler passieren? Denn das ist ja der andere Blick, den wir immer wieder haben. „A bad system will beat a good person every time“, hat Deming ja gesagt. Also wie kann ich das System so verändern, dass die Einzelperson weniger in diese Fettnäpfchen rein tritt?
Jasmine:
Und damit sind wir am Ende der 10 Top Gründe, warum Agile schiefgehen kann. Wir hoffen, du hast ganz, ganz viel Spaß mit dieser Folge gehabt. Wir freuen uns unglaublich auf Feedback auf dem Twitter-Kanal und wir freuen uns auch über eine gute Sternchen Bewertung
Kai:
Und wir hören uns ganz bald wieder im Agile Growth Podcast – übrigens Agilität hat auch noch mal einen ganz schönen Aufschwung gekriegt über diese Corona-Zeit habe ich letztens eine Statistik gelesen. Es gibt deutlich mehr Organisationen, die auf Agilität jetzt setzen.
Kai:
Insofern spannende Zeiten in der Welt. Alles bewegt sich ein bisschen schneller. Wir hoffen, dass das bei dir natürlich nicht scheitert, die Agilität, sondern du aus dem Podcast auch mitnehmen kannst, was du tun kannst, damit das bei euch funktioniert. In diesem Sinne bis zum zum nächsten Mal. Wir freuen uns.
Bei unserem letzten Treffen des 
In gut eineinhalb Stunden findet unser Team von Pizzabäckern vom intuitiven Weg, Pizza zu produzieren zu einem effizienteren Prozess – mit Spaß und durch gute Zusammenarbeit. Wollen wir das nicht auch im Berufsleben? Das Team hat sich deutlich gesteigert im erwirtschafteten Gewinn, auch durch Einsparung von Verschwendung, neue Produkte ins Portfolio aufgenommen und an kontinuierlicher Verbesserung gearbeitet.
Da die Simulation völlig technologiefrei ist, eignet sie sich übrigens auch für alle anderen Teams, die ihre Teamarbeit mit IT-Kanban verbessern möchten. Längst sind agile Methoden ja außerhalb der Softwareindustrie im Einsatz.
Probleme rufen nach einer Lösung.
Stellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?
Eine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden.
Am letzten Freitag konnten sich davon auch die Gäste der Einweihnungsfeier überzeugen und wünschten einen „guten Start in den neuen Räumen“ – der vermutlich einzigen agilen Mühle in Deutschland.