NBA28: Im Gespräch Felix - Agile at Scale

Hallo und herzlich willkommen bei NoBullshitAdry. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt auf der Praxis, daher auch der Name NoBullshitAdry. In der letzten Folge habe ich über das Potential im Daily gesprochen. Da ging es mir darum, dass man unter anderem auch erkennen kann, wie gut das Team funktioniert, indem man guckt, wie regel die Leute im Daily sind. Deswegen heißt die Folge auch "Regel im Daily". Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du in den Shownotes. Das hier ist die Folge 28 und heute habe ich wieder einen Gast, nämlich den Felix von der Agile Process GmbH und wir unterhalten uns über Agile@Scale. Viel Spaß damit. Ja, wie schon angekündigt. Ich habe heute Besuch, einen Gast, den Felix. Hallo und herzlich willkommen. Hallo, schön, dass ich hier sein darf. Vielen, vielen Dank für deine Zeit. Vielleicht wollen wir einsteigen und du erzählst mal ein bisschen was über dich oder über euch. Klar, also ich bin Felix Stein aus Bonn und wenn du euch sagst, dann meinst du vom dich mich und meine Firma. Ich bin Teil der Agile Process GmbH einer kleinen agilen Unternehmensberatung. Man sagt ja auch Boutiqueberatung, also wenn man sich als Beratungsserverhause auf ein einziges Thema spezialisiert und beim Namen Agile Process GmbH ist ja relativ offensichtlich, was das Thema sein könnte und mit der sind wir halt im Wesentlichen für große Unternehmen, schwerpunktmäßig aus dem Rheinland, aber auch aus dem restlichen deutschsprachigen Raum unterwegs, also Konzerne, Versicherungen, Banken, Energiekonzerne, Automobil, irgendwas in der größten Ordnung. Genau und das jetzt schon seit langer Zeit, also ich selber mache das jetzt knapp 15 Jahre, habe über die Zeit auch sehr viel gefallen an dem Thema Agile Produktentwicklung gefunden bis dahin, dass ich dann irgendwann fahrlässig zugelassen habe, dass es in mein Privatleben rüber geht. Beispielsweise organisiere ich jetzt einmal pro Monat am Abend in Bonn das lokale Agile Meetup mit ein paar Leuten mit, den Bonner Scrumtisch und selbst den versuchen wir dann auch Agile durchzuführen, so als Open Space Format ist übrigens gerade erst gestern gewesen und hat wieder unglaublich viel Energie gegeben. Das kann ich mir sehr gut vorstellen. Die Links zu deinem Unternehmen und natürlich gerne auch zu dem Scrumtisch, die findet wir alle wieder in den Show Notes, das nur als Info am Rande. Sehr schön, genau und wir hatten uns im Vorgespräch ein bisschen drüber unterhalten und ich fand das Thema super interessant Agile at Scale, vielleicht noch mal ganz kurz zu meinem Hintergrund. Wir sind ja relativ wenig Leute in dem Unternehmen, wo ich arbeite. Wir haben drei Teams und wir kommen eigentlich mit den normalen Agile Frameworks super gut klar. Agile at Scale fand ich deswegen interessant, weil es natürlich darum geht, wie kann man Agilität denn größer denken in größeren Unternehmen, was ja schon gesagt, Konzerne, die sind ganz anders aufgebaut, das kenne ich eben von unseren Kunden und ich sage mal, die haben erst einmal ja auch ganz andere Zwänge und da kommt ihr ins Spiel oder du mit der Idee, was muss man denn jetzt tun, um die Agilität in so einem Unternehmen, ich sage mal, vorzubereiten, einzuführen, am Leben zu erhalten und zwar so, dass es wirklich, ich sage mal, tragbar ist. Genau und da kann ich natürlich direkt als erstes das sagen, was ich mindestens einmal pro Gespräch sagen muss. Es kommt darauf an, aber kann natürlich direkt ein bisschen drauf eingehen, worauf das ankommt, denn wir steigen damit unter ja an sehr unterschiedlichen Stellen ein. Also im Idealfall, wenn man so will, ist es natürlich, dass da überhaupt erst mal zu Beginn sich die Frage stellt, was soll denn der Arbeitsmodus sein, mit dem wir als Konzern, welcher Art auch immer, jetzt hingehen wollen, um der sich immer schneller ändern in Arbeitswelt irgendwie gerecht werden zu können. Ja, aber wenn man das macht, dann kann man erst mal von Grund auf sagen, okay, was sind jetzt die verschiedenen Treiber der Disruption, der Veränderung des Wettbewerbs oder was auch immer gerade ein Unternehmen da in diese Idee bringt, wir müssen was ändern. Und dann hat man die Möglichkeit, ganz viel so erst mal auf einer vernünftigen Grundlage aus einem Wurst zu machen. Das was häufiger ist, ist, dass wir mit Konzernen unterwegs sind, die schon vor langer Zeit ihre ersten Versuche gemacht haben, Agil zu arbeiten. Also das ist jetzt schon über den Punkt weg, an dem es eine Mode ist. Und das heißt, jeder halbwegs größere Konzern hat nicht nur eine, sondern zwei oder drei verschiedene Agiletransitionen oder Versuche von Agilentransitionen hinter sich. Und da sind natürlich dann ganz viele Hinterlassenschaften, auf die man dann aufbauen kann oder zum Teil auch aufbauen muss. Da kommen wir auch wieder zu den gerade erwähnten Zwängen, weil die vielleicht eben schon durch ganz viele verschiedene Gremien gegangen sind und aufgrund dessen auch gar nicht mehr so einfach wieder rückgängig zu machen sind. Und an der Stelle ist es dann natürlich deutlich komplizierter, weil man dann gucken muss, okay, was von dem, was wir da vorgefunden haben, ist vielleicht ganz gut. Was ist gut gemeint, aber funktioniert nicht. Und was war vielleicht von Anfang an eine schlechte Idee, um dann gucken zu können, wie kriegt man aus all dem dann noch einen vernünftigen Ansatz zusammen. Und das ganze natürlich unter der Voraussetzung, dass deweilige Kunde die uns beauftragt, das auch genauso sieht. Und ich sage schön, was ihr da ratet, aber ich habe eigentlich ganz andere Vorschläge und wollte euch eigentlich nur herholen, um die für mich umzusetzen. Auch das gibt es, ist zum Glück aber eher selten. Ja, vielleicht eine Detailfrage dazu? Wahrscheinlich ein bisschen damit zusammen, wer euch denn da beauftragt, aber wie geht ihr denn mit der Frustration um? Ich könnte mir vorstellen, wenn die Unternehmen schon auf irgendeine Art und Weise Agilität hier und da eingeführt haben, vielleicht sagen, okay, wir haben zwei Teams und die machen Scrum und wir hatten noch einen Versuch, mit einem Dritten, aber dann spielt es alles nicht mehr so zusammen. Kann ich mir vorstellen, dass in den Teams, vielleicht auch im Management, auch eine gewisse Frustration aufgekommen ist, Agilität funktioniert für uns einfach nicht. Vielleicht so, wie steigt ihr denn da ein? Es ist in der Tat ein ganz wichtiger Punkt und auch da hängt es ein bisschen davon ab, mit wem wir da reden. Denn ich glaube, diese Frustration auf Management Seite, die habe ich schon mehrfach erlebt und die kann ich auch nachvollziehen. Denn wenn jemand mir sagt, wir haben jetzt, ich weiß nicht, ein, zwei oder noch mehr Transitionsversuche gemacht, weil aus verschiedenen Gründen, weil unsere Muttergesellschaft das so will, weil unsere Aktionäre das wollen, weil wir sonst keine neuen Mitarbeiter mehr bekommen, weil die das ja auch erwarten. Und es bringt uns nicht das, was wir gewollt haben. Aber dann habe ich eine Situation und dann kann ich natürlich hingehen und sagen, aus meiner Erfahrung, lass uns mal gucken, was ihr gemacht habt. Und das sind ganz häufig Sachen, bei denen ich dann sagen kann, okay, das liegt vermutlich daran, dass ihr, da können wir gleich mal drauf eingehen, dieses und jenes nicht bedacht habt, was aber ganz zentrale Stellschrauben sind. Und aufgrund dessen ist es zu diesen wenig zu Friedenstellenden Ergebnissen gekommen. Wenn ihr da stattdessen an der Stellschraube anders dreht, dann kann das sehr schnell, sehr viel besser werden. Das ist eine Möglichkeit, wo man den Leuten schon diesen Ausweg aus der Frustration auf dieser Management Ebene bieten kann. Auf der Team-Ebene ist es natürlich ein bisschen schwieriger, denn das muss man eben auch sagen, habe ich schon mehrfach erlebt, wenn an Leute sagen, so fehlig ist, das ist jetzt die vierte oder fünfte Transition, die wir in den letzten sieben Jahren machen. Und da waren drei Agile, zwei digitale und eine Linentransformation dabei. Und am Ende haben sich immer nur Namen geändert und es ist amsonsten immer alles beim Gleichen geblieben, war aber trotzdem ein riesiger Umstellungsaufwand und ich will das einfach nicht mehr. Dann kann ich natürlich sagen, okay, wer könnte das nicht verstehen. Das ist total klar. An der Stelle muss man den Leuten dann sagen, okay, das ist schade. Aber in den meisten Fällen kommt man mit denen schon ins Boot, dass man sagt, findest du denn den Ist-Zuständnis, wie jetzt ist gut? Das ist die Antwort extrem häufig nein. Und da kann man eben auch sagen, dann müssen wir eben doch versuchen dran zu arbeiten, dass wir da rauskommen. Denn die Alternative wäre ja, alle so zu lassen, wie es jetzt ist. Das ist ja meistens auch nicht im Sinn der Leute, denn wenn es so bleiben könnte, wie es ist, kann ich jetzt aus meiner Perspektive dann sagen, dann würde man mich ja in der Regel nicht holen oder unsere Firma nicht holen. Ja, guter Punkt. Wer beauftragt euch denn, ist es eher sehr weit oben angesetzt? Ist es eher, dass aus dem Team heraus oder aus einzelnen Abteilungen heraus so einen verlangen kommen oder ist es einfach total unterschiedlich? Das ist total unterschiedlich und hängt auch mit der Größe des Unternehmens zusammen. Ich bin beispielsweise schon mal in Unternehmen gewesen, die eben die deutsche Landesgesellschaft von einem internationalen Konzern waren. Und in dieser Landesgesellschaft gibt es dann, wie es bei Konzernen auch so ist, verschiedene Untergesellschaften und vielleicht noch unter Untergesellschaften. Und das heißt, man kann dann durchaus von jemandem beauftragt werden, der selber auf seiner Visitenkarte oder in der E-Mail Signatur Geschäftsführer stehen hat, trotzdem aber über sich nochmal fünf bis zehn Hierarchiebenen haben können. Und umgekehrt in anderen Konzernen heißt dann vielleicht jemand, Abteilungs- oder Bereichsleiter, hat dann aber gar nicht so viel weniger Budget und Entscheidungsmacht als jemand, der woanders Geschäftsführer heißt, dass wir von Leuten wirklich ganz oben in der Hierarchie beauftragt werden. Das habe ich auch schon erlebt. Da bin ich auch schon mal in Transitionsteams Mitglied gewesen, die unmittelbar unter einem Vorstand hingen. Ist aber tatsächlich gar nicht so häufig der Fall, weil ab einer bestimmten Unternehmensgröße natürlich auch die einzelnen Einheiten so unabhängig sein können, dass die unabhängig von den anderen auch eher Transformationsprogramme fahren können. Ja, kann ich mir gut vorstellen. Vielleicht mal an der Stelle, wenn wir jetzt da sind, die Leute haben von sich aus einen Anlass ermittelt. In was für eine Situation kommst du dann? Also da gibt es zwei Scrum Teams und die kommen nicht weiter oder es soll erweitert werden. Eine Agilitransformation hast du ja schon erwähnt. Wie sieht so ein Auftrag oder so ein Projekt denn aus? Genau, also das vom Umfänger überschaubarste wäre tatsächlich so etwas, wie du gerade gesagt hast, da hinten sind zwei Teams, die entweder schon nach Scrum arbeiten, wo es aber nicht ganz so funktioniert, wie wir uns das wünschen oder die eben als Pilotprojekt oder wie ich immer mal das nennen möchte, die ersten sein sollen, die jetzt in Richtung Scrum gehen. Kümmer dich doch mal um die und hilft denen beim Start in diese neue Welt. Das ist dann noch relativ einfach unter der Voraussetzung, dass bestimmte Rahmenbedingungen gegeben sind, weil dann kann man ja ganz schlicht sagen, können wir stellen euch mal, nachdem wir miteinander gesprochen haben, was sind eigentlich eure Kunden, eure Produkte und eure Marktumfelder, stellen wir euch die verschiedenen gängigen Agilitr frameworks vor, einigen uns auf einen bestimmten Zeitraum, indem man das, was euch am ersten Pass ausprobieren kann und danach können wir bewerten, ist es in Ordnung und wenn ja, machen wir weiter oder ist es nicht in Ordnung und wir probieren was anderes aus und das dann häufig im Rahmen von sehr beschränkten Beauftragungen, die dann ein paar Sprints, ein paar Monate oder irgendwas in der Richtung sein können. Das gibt es natürlich auch viel größer, dass man sagt, okay, wir möchten eben ganze Ressorts, also ein großer Klassiker ist natürlich immer das IT-Ressort ändern oder was auch eine Möglichkeit ist, dass man sagt, wir bilden hier ein neues Projekt. Ein Klassiker wäre an der Stelle eines, das eine bestimmte Ural-Software durch eine neue Standardsoftware ablösen soll. Das dauert dann ja natürlich nur eine gewisse Zeit und dann braucht man das auch nicht mehr und hilft uns doch, dieses Projekt aufzubauen, zu stabilisieren und in Arbeitsmodus reinzukriegen. Da kommen dann verschiedene Sachen zusammen. Da ist nicht nur der der Arbeitsmodus, welcher auch immer das dann ist, Scrum oder Canvon oder was Ähnliches, sondern da gibt es auch ganz viel einfach. Wie bilde ich denn überhaupt zu einer große Organisationseinheit heraus, die dann auch mal 10, 20 oder 50 Teams haben kann? Das ist das größte, was ich in der Richtung erlebt habe. Das waren tatsächlich so 40 bis 50 Teams und das ist natürlich mal eine ganz andere Hausnummer als diese 2 oder 3. Ja, bei 50 Teams, auch bei 20 Teams, dann sind wir tatsächlich an dem Punkt, wir sind jetzt bei "At Scale", sage ich mal. So stell ich es mir zumindest vor, ein Überbau stattfinden oder einen Schnittstellen existieren vielleicht zwischen den Teams und deswegen brauche ich so ein Überbau. Ist das richtig? So ist das die Interpretation. Also wann brauche ich "At Scale" ist zum Beispiel meine Frage. Genau, also auch da wieder, ich glaube eine wie auch immer geartete Koordination oder Kommunikation brauche ich eigentlich schon ab 2 Teams. Aber auf dieser kleinen Ebene würde ich immer sagen, fangen da gar nicht erst mit irgendwelchen Frameworks oder was auch immer an, sondern die sollen einfach miteinander reden. Das hilft in den allermeisten Fällen ja schon. Irgendwo ist dann die Grenze, wo das nicht mehr reicht. Also je nachdem wen man fragt oder welches Framework man sich anguckt, liegt das dann irgendwo bei 5 bis 10 Teams, hätte ich so erfahrungsgemäß gesagt. Und da kommen dann die verschiedenen Einheiten dann auch ein Spiel, die aus den verschiedenen Frameworks sagen, okay, da muss man demnach koordinieren, sei es der Release Train or Safe oder die maximale Anzahl von Teams, die in large scale scrum also in less zusammenarbeiten können. Irgendwo da, würde ich sagen, geht es dann los. Und die spannende Frage ist, wie kann ich es schaffen, die notwendige Kommunikation und Koordination, die auch Ressourcen und Zeit fressen, möglichst klein zu halten? Denn alles, was natürlich dafür gemacht werden muss, steht mir nicht mehr für meine eigentliche Arbeit für das Entwickeln von Produkten zur Verfügung. Und das ist dann der tatsächlich spannende Punkt, der unglaublich große Auswirkungen hat. Aber zunächst einmal gar nicht mehr so viel mit dem zu tun hat, was wir normalerweise so immer unter dem verstehen, was in unserem Agilen Cosmos, in unserer Agilen Blase drin ist. Also da geht es gar nicht mehr so stark darum, arbeiten wir jetzt in Sprints oder machen wir Retrospectiven oder gibt es ein Product Owner, sondern das sind tatsächlich erstmal so ganz banale Fragen, wie hat dieses Team denn überhaupt in sich Stabilität? Also sind das Leute, die länger zusammen bleiben? Sind die alle in Vollzeit da drin oder sind die auch noch alle in einem zweiten, dritten, vierten Projekt da drin? Haben die denn überhaupt ein gemeinsames Produkt, in dem Sinn, dass sie eine definierte Gruppe von Abnehmern, von Kunden haben, intern oder extern, die sie kennen, mit denen sie reden können, von denen sie wissen, was deren Bedürfnisse sind und sind die überhaupt in der Lage, selber mehr oder weniger Product Ownership zu haben, also zu entscheiden, was sie dieser Kundengruppe bieten wollen und zu Beginn sind in diesen großen Konzernen die Antworten darauf ganz häufig alle nein. Also das ist in der Vergangenheit, wo das alles entstanden ist, vermutlich auch was gewesen, was damals eine Zeit lang gut funktioniert hat, aber das kollidiert halt dann mit dem, wie diese neue Agile Arbeitswellseinsaal, also was wieder häufig vorfinden, sind zum Beispiel Leute, die sehr stark spezialisiert sind, auf was auch immer, irgendwelche Software, Entwicklungs- oder Ingenieurberufe und die dadurch, dass sie so stark spezialisiert sind, in einem Entwicklungsteam von Scrum Team Größe, also bis zu zehn Leuten, gar nicht voll auszulasten wären und die darum alleine um überhaupt durchgehend was zu tun zu haben, sagen müssen, okay, dann gehe ich eben noch in zweites oder ein drittes Team rein. Also beispielsweise Leute, die an irgendeiner zentralen von mehreren Teams genutzten Backend-Komponente sitzen. Es wäre so ein Beispiel, die dann verschiedenen Teams zuarbeiten. Ganz häufig in solchen Fällen dann auch verbunden mit Code Ownership für diesen Bereich, aber das gibt es dann eben beispielsweise auch irgendwo in der Hardware-Entwicklung, also ich kann mich bei einem Kunden erinnern, die Verpackungstechnik, also die Leute, die für das physische Produkt die Verpackung gebaut haben, die hatten dann in den jeweiligen einzelnen Produktteams so wenig zu tun, dass die in fünf oder sechs Teams gleichzeitig sein mussten, was zu den erkennbaren Problemen geführt hat. Aber so was kann man sich auch beispielsweise bei sehr spezialisierten Testern oder IT-Konzeptern oder was auch immer ebenfalls vorstellen. Und das sind dann Sachen, wo man hingehen muss und sagen, okay, lass uns mal überlegen, ist denn diese irgendwann mal aus gutem Grund erstanden, eine extrem starke Spezialisierung, auch das, was es jetzt noch notwendigerweise braucht, wenn wir diese sehr flexiblen autonomen AG in den Teams haben wollen, wenn die Antwort darauf nein ist, was müssen wir dann überhaupt alles umstellen, um dahin zu kommen und da hängt ja unglaublich viel dran. Von den Ausbildungsfaden, von der Zugehörigkeit zu irgendwelchen organisatorischen Einheiten, da hängt die eigene berufliche Identität dran, da hängen so kleine Eitelkeiten dran, wie jetzt auf einmal muss ich zulassen, dass andere Leute meinen Code bearbeiten und ich muss anfangen, woanders am Code mitzuarbeiten, den ich gar nicht kenne und da fühle ich mich unsicher und so weiter und so weiter. Also ganz viele Umstellungen, die in diese Art überhaupt reingehen, die unglaublich viel Zeit in Anspruch nehmen können. Aber dann, wenn man das geschafft hat, auch eine Riesenwirkung entfalten können. Ja, sehr guter Punkt. Und tatsächlich hast du so eine Frage, die ich habe schon ein bisschen mitbeantwortet, nämlich der erste Ansatz könnte ja sein, dass man sagt, können diese Teams in einer von mir aus Zehner Größe, so Scrum Größe nicht so selbstständig sein, dass sie nicht von anderen abhängen, dann hätte ich ja dieses Problemenzweifel nicht. Aber genau wie du gesagt hast, es gibt wahrscheinlich einfach zu viele Abhängigkeiten, die man gar nicht anders lösen kann, so dass es diesen Überbau braucht. Ja, natürlich. Und es gibt eben Sachen, die müssen eben auch übergreifend für ganz viele Produkte da sein. Also auch da ein schlechtes Beispiel, wenn ich in dem Ökosystem von Google zum Beispiel drin bin, ja, mit Gmail, Google Maps und was es da sonst noch alles gibt, dann habe ich ja über alles drüber das gemeinsame Login, wo ich meine eigenen Zahlungsdaten, Samendaten und was auch immer abgelegt habe, auf die alles aber dann zugreifen muss. Ja, das heißt, solche zentralen Funktionen, die habe ich immer wieder und die machen ja in diesen großen Zusammenhängen auch Sinn. Und da gibt es dann auch nicht die eine Antwort darauf, wie ich damit umgehen kann. Es gibt ja mindestens zwei. So Möglichkeit eins, ich baue dafür praktisch ein spezialisiertes Team, das sagt, dieser Signal-Signal-Signal ist unser Produkt und den bieten wir allen anderen Produkt-Team als sehr einfacher Schnittstelle an und die im Zweifel so einfach, dass man da gar nicht groß sich koordinieren muss, sondern jeder, der möchte, der kann sich einfach an dieser Schnittstelle andocken, ohne dass wir sehr viel von unserer Seite tun müssen. Also wenn man so will, Single-Signal und S-Service. Ja, und die andere Alternative könnte natürlich sein, wir erklären diese zentralen Komponenten an diesem einfachen Beispiel, den Single-Sign-On, praktisch zur Collective Code Ownership aller beteiligten Teams. Das heißt, jeder, der möchte, darf da dann rumbauen, was auch funktionieren kann, aber natürlich ganz viele andere Sachen mit sich bringen, wie zum Beispiel Vereinbarungen, wie kann ich oder darf ich vorgehen, wenn ich etwas verändere, wodurch andere Teams betroffen sind. Wie muss ich Sachen zurücklassen, dass andere, wenn sie da dran gehen wollen, das auch verstehen und sich nicht erst mal ewig einarbeiten müssen, um nachzuvollziehen, was mir denn dadurch ein Kopf gegangen ist, als ich das gebaut habe und so weiter und so weiter. Ja, das sind ja reale Fälle. Und auch da kommen wir dann diese großen Sachen rein, bis hin zu dem spannenden Punkt am Ende, dass man sich noch fragen muss, wenn es irgendwann wirklich riesig ist, macht es nicht Sinn, bestimmte Dinge auch halt und dann zu machen. Also ich kann mich hier ändern bei unseren Konzernkunden, da gab es beispielsweise irgendwann mal leuchtige Sachen, wenn wir jetzt einen POST-Eingang für alle unseren verschiedenen Produktgruppen machen, die völlig unterschiedliche Kundengruppen haben, dann führt es dazu, dass diese zentrale POST-Eingangstfunktion so zu einem Flaschenhals für alle anderen wird, dass das eigentlich so für negative Fälle hat, da sind wir lieber so weit und sagen, wir machen jetzt redundant mehrere POST-Eingänge nebeneinander und jeweils für eine Kundengruppe, mit dem Risiko, dass da mal ein Kunde aus Versehen den falschen POST-Eingang benutzt, wo man dann hinten durch mal wieder umleiten muss. Aber auch das sind ja dann so große Entscheidungen, die am Ende auch wieder auf Agilität einzahlen können, in dem Sinn, dass dann Sachen auf einmal unkomplizierter und schneller gehen, weil auf einmal wieder weniger Koordination, weniger Abstimmung notwendig sind, weniger Abhängigkeiten da sind und so weiter. Also für mich als eine Zusammenfassung oder als ein Learning jetzt wäre eigentlich versucht man mit Agile@Scale so etwas wie Kommunikation, Koordination, Produktvision so gut zu gestalten, dass mehrere Teams eben, ich sag mal, mit einer Stimme oder einheitlich in einem Standard, in einer gleichen Qualität, Dogo, Code, alles was dazu gehört, Release, Zusammenarbeit. Diese Looke wird gefüllt von Agile@Scale. Ja, also grundlegend, ja ich würde es ein kleines bisschen anders formulieren, denn ich würde sagen, wenn man das macht, was wir jetzt gerade besprochen haben, also dieses Entkoppeln, Klären, Abbau von Abhängigkeiten, Multimitgliedschaften und was auch sonst immer dazu führt, dass aus diesem Kommunikations- und Koordinationsbedarf diese Bürokratie wird, wenn man all das macht, dann ist das Ergebnis davon Agilityt im großen Maßstab, also Agile@Scale. Agilityt wäre für mich einfach nur, dass da eine Einheit und in dem Fall eine große Einheit ist, die flexibel, beweglich, reaktionsfähig und lieferfähig ist. Und das kann ich eben in weiten Teilen dadurch erreichen, dass ich bevor ich hingehe und groß überrollen und Frameworks und Storypoints und was auch immer nachdenke, mich erstmal hingehen und sage, okay, wie schaffe ich denn, möglichst unabhängige, möglichst crossfunktionale, möglichst systemisch veranlacht und end-to-end verantwortliche kleine lieferfähige Einheiten. Und mit denen kann ich als nächstes hingehen oder im nächsten Schritt sagen, okay, und jetzt fangen wir an, über Kanban oder Les oder Scrum oder was auch immer zu sprechen. Ja, das klingt total sinnvoll. Das waren wieder ein gutes Stichwort. Wir sind ja jetzt an einem Punkt, wo wir ein bisschen darüber gesprochen haben, was bedeutet Agile@Scale, in welchen Situationen sind die Unternehmen so, vielleicht auf der Zielgraden nochmal. Es gibt ja viele Methoden, die das abbilden. Mir fällt halt immer nur Safe ein. Ich habe ganz wenig drüber gelesen und ich weiß, dass viele ein bisschen auch die Nase rümpfen, weil es wirkt natürlich erst einmal komplex, sage ich mal. Es gibt ja noch ein paar weitere. Vielleicht keine Zusammenfassung über was macht jede Methode. Das würde, glaube ich, ein bisschen den Rahmen springen. Ich verlinke da garantiert ein bisschen Website dazu. Aber an irgendeinem Punkt sagt ihr dann, okay, wir haben uns das mal angeguckt und du hast ja gerade gesagt, wir gucken in den Teams auch. Jetzt wenden wir eine von diesen Methoden an im Unternehmen oder bedient ihr euch aus Schnittner daraus und seid dann nicht zu sklavisch und sagt, wir wollen auch praxisnah sein. Also eher das Letzte. Denn ich weiß nicht, was deine Erfahrung ist, aber die wenigsten Teams, die ich erlebt habe, die machen ja wirklich Scrum oder Kanban oder XP oder was auch immer auf Team-Ebene ist in Reinform. Selbst da sind ja schon ganz häufig Kompromisse, die gute und schlechte Gründe haben. Und das Gleiche habe ich natürlich auf einer größeren Ebene umso mehr. Und ich sehe auch in den verschiedenen Ansätzen verschiedene Punkte, die gut oder die schlecht sind. Also ich glaube, das Beispiel Safe, das ist ja wirklich kontrovers. Also viele Konzerne sind davon total begeistert, weil wenn ihr dieses große Wimmelbild sehen, haben die das Gefühl, endlich hat sich mal über alles Gedanken gemacht. Und das ist die Situation, ich kauf mir da die rundum sorglos Lösung. Das Problem ist natürlich, wenn ich das alles bei mir einführe, als die hohe Wahrscheinlichkeit, dass da auch wieder Bürokratie rauskommt. Aber es gibt eben, was man auch sagen muss, dadurch, dass sie ja versucht haben, allein alles zu denken, auch ganz viele Bereiche, wo die hingegangen sind, wo andere agile Frameworks überhaupt keine Lösung für anbieten. Das ist ein ganz einfaches Beispiel, wenn wir über Budgetierung reden. So eine Sache, die wir in ganz vielen Unternehmen haben, die ein riesiger Hammer für agiles arbeiten ist, ist, dass irgendjemand außerhalb der Entwicklungseinheiten das Budget besitzt und sagt, okay, das gebe ich nur für bestimmte Produkte oder sogar nur für bestimmte Features frei. Und wenn irgendein Team dann anfangen will zu arbeiten, dann muss das maximal so viel Arbeit reinstecken, wie eben durch das Budget gedeckt ist. Und darf eben nicht an anderen Features arbeiten, für die kein Budget da ist. Und alleine das nur darauf beschränken zu sein und dem Zweifel hart drum kämpfen zu müssen, auch für andere Sachen, was tun zu können, wo gar kein Budget für da ist. Das kann ja unglaublich viel Energie rausziehen. Und Energie, woanders hin ableiten, wo im Grunde genommen gar keine produktiven Ergebnisse mehr rauskommen. Also da geht man ja praktisch in die Anti-Aggilität rein. Ja. Und bei SAFE hat irgendjemand mal gesagt, kommen wir haben das so ganz einfach. Es gibt ja diese Einheit des Release Trains mit, weil auch immer, fünf, sechs, sieben und ich weiß nicht, wie viele Teams. Und die werden einfach fix budgetiert für bestimmten Zeitraum von mir aus ein Jahr. Und zwar völlig unabhängig davon, was die bauen. Es soll natürlich immer noch eine Art von Priorisierung geben, dass man erkennt, was es für uns gerade wichtig, was es für unsere Kunden gerade wichtig. Und das machen wir als Erstes. Aber eben dadurch, dass man es von dieser Budgetierung entkoppelt, dann wird man ja ganz viele Probleme los. Es auf einmal gibt es nicht mehr die Möglichkeit, dass jemand von außen über das Budget reinregiert. Und auf einmal besteht auch nicht mehr das Risiko, dass man die Teams irgendwann auf einmal von jetzt auf gleich halbieren muss, weil einfach nur noch die Hälfte vom Budget für diese Features übrig ist. Das heißt, sowas ermöglicht dann auf einmal Stabilität. Ja, ja. Auf der anderen Seite, andere Frameworks bin ich zum Beispiel großer Fan davon, zu sagen, wenn es so ist, dass mehrere Teams ein gemeinsames Produkt haben. Und man sagt, ihr arbeitet jetzt daran entweder, damit es schneller geht. Vielleicht weil man am Sonsten das Risiko hat, dass ein Wettbewerber vor einem fertig wird. Oder weil eben so unterschiedliche Teilprodukte da sind, dass es schon Sinn macht, da unterschiedliche Teams dran zu setzen. Zum Beispiel Embedded Software und Cloud Software, die erst in Summe bei irgendeinem kombinierten Hardware Software Produkt zum 50. Ergebnis führen. Dann kann ich aber denen hingehen und sagen, okay, geben wir denen doch ein gemeinsames Backlog mit einem gemeinsamen Product auch noch. Und der kann dann durch seine Priorisierung dafür sorgen, dass zusammengehörige Sachen gleichzeitig fertig werden und dass sich auch Teamübergreifend Inkremente herstellen kann, die für Endkunden nutzbar sind. Im besten Fall noch mit einer gemeinsamen Definition auf dann für die Teams und übergreifenden Planungs- und Sprint-Review-Events. Das ist hier das, was Nexus oder Less machen würden. Das finde ich ebenfalls sehr, sehr charmant. Hat eben ganz andere Aspekte. Und so komme ich dann bei ganz vielen anderen Frameworks auch dazu, dass ich sagen kann, okay, da kann ich was nehmen, da kann ich was nehmen. Und da gibt es ja mittlerweile auch einen wahren Wildwuchs von immer neuen Frameworks, von denen, was man in Anfängerstrichen der Normal-Agilist gar nicht mehr so viel mitbekommt. Ob das jetzt Open Space Agility ist oder das Fast Framework oder Anfix oder Flight Levels und wie sie alle heißen. Und wenn man natürlich so ein kleines bisschen der Methoden nutzt wie ich, dann schaut man sich das gerne an und denkt sich, guck mal, das ist spannend und das könnte ich nehmen und das könnte ich ausprobieren. Und am Ende ist das ja ein bisschen das, warum man dann auch so eine Beratung wie meine holt. Inderhoff, dass da jemand ist, der einem praktisch dieses Buffet ausbreiten kann und mit einem zusammen überlegen kann, okay, was davon wäre denn jetzt die passende Lösung, mit der wir mal probieren können, euer Problem zu lösen? Ja, sehr gut. Haben wir denn irgendwas ganz Wichtiges vergessen? Wir könnten, glaube ich, wirklich locker zwei Stunden füllen mit den Details, aber ich will ja hier gerne ein bisschen Überblick geben. Was haben wir vielleicht vergessen? Ja, ich wollte es gerade sagen. Also, stundenlang könnten wir auf jeden Fall noch vollmachen. Wenn ich jetzt mal auf eine Sache raus sollte, wo ich sage, da sollten wir auf jeden Fall noch gucken, ist es eben die Leute, die einen beauftragen, sind das auch die, die in der Lage sind, die Sachen zu verändern, deren Veränderung notwendig ist. Ja, also beispielsweise, was ich vorhin gesagt habe, dass man diese extrem spezialisierten Teams nimmt und aus denen dann kostfunktionale Teams macht, indem man die Mitglieder neu zusammensetzt. Das muss dann natürlich jemand sein, wenn er einen mit einem solchen Beratungsauftrag reinholt, der so etwas entscheiden darf. Also im Konzern darf er das im Zweifel nicht alleine, da muss dann immer kein Ahnung, Betriebsrat und ich weiß nicht, was sonst noch mitreden, aber er muss diesen Prozess zumindest einleiten können. Und wenn er das nicht kann, dann haben wir ein grundlegendes Problem. Also auch dann ein einfacheres Beispiel. Vor einigen Jahren kam mal hier, ich bin ja in Bonn, jemand von so einer Behörde zu uns. Wir haben ja ganz viel Behörden-IT hier und der verantwortete halt bei irgendeiner mittelgroßen Behörde im V-Modell auf der rechten Seite eine der mittleren Stufen und zahlt dann gesagt, okay, ich habe doch von gehört, Agil, das ist jetzt irgendwie toll und ich erkenne auch den Sinn drin, könnt ihr mir dabei helfen, das zu werden. Und also wir sind dann nach sehr frühen Gesprächen schon direkt auseinander gegangen, weil ich dann auch sagen muss, also sorry. Also rechte mittlere Stufe V-Modell, das heißt du bist irgendwo bei so einer mittleren Teststufe mit granularen Teststufen davor und einer end-to-end Teststufe danach und die Entwicklung ist noch weiter weg und der Betrieb ist auf der anderen Seite noch weiter weg und die Leute, die die Anforderungen schreiben, von denen weißt du nicht mal wer das ist. Natürlich kannst du dann in unserem Kontext nicht sagen, hier werde ich jetzt Agil und dem fehlt ja auch sämtliche Beauftragungen und sämtliches Mandat, um aus dieser kleinen Welt auszubrechen. Ja, und da muss man sagen, also vermutlich tut man niemandem gefallen, wenn man es so versucht. Da hätte man eben den gebraucht, der über alles einmal so weit drüber gucken kann, dass er sagt, okay, da brechen wir jetzt keinen Ahnungsmeldschwung, mal ein Pilotteam raus, das in einem einzigen Bereich end-to-end verantwortlich ist. Oder da gehen wir nach und nach hin und versuchen vielleicht mal zwei von diesen Stufen zusammen zu schließen und dann nochmal zwei und viertel Jahr später nochmal zwei, um irgendwann dann diese end-to-end Verantwortlichkeit zu haben. Also was auch immer der Ansatz ist, da gibt es auch nicht den einen, aber man bräuchte halt, um wirkungsvoll zu sein, jemanden, der einen wahlweise sponsert oder beauftracht, der in der Lage ist, Veränderungen auf dieser größten Ordnung einzuleiten. Das ist, glaube ich, im Konzern extrem wichtig. Ja, das klingt total plausibel. Ich habe noch eine abschließende Frage. Was ist dein coolstes Agiles-Erlebnis gewesen? Ich überlege gerade, ob es ein total cooles Erlebnis gibt, das aus vielem rausbricht, aber etwas, was ich immer wieder erlebt habe, also jetzt nicht alltäglich, aber doch mehr als zwei, drei Mal, ist, dass irgendwo agile Transformationsprogramme in Konzernen, was ja leider immer wieder vorkommt, ganz übel schief gegangen sind. Also man hat das total gut gemeint und wollte auch eigentlich das Richtige, hat aber aus versehen über allem nur noch Bürokratie ausgerollt. Also wir ändern diese Budgetierungs- und Team- und Irgendwasstrukturen nicht, aber zwingen alle dann keine Ahnung, OKR oder Safe oder irgendwas auf und wundern uns, dass es nicht funktioniert. Und das ist jetzt noch nicht das coole. Aber in diesen Kontexten gibt es immer wieder Einheiten, die gesagt haben, okay, dieses agile Arbeiten, also die kennen dann nur das unter dem Label Agile und halten das dafür und finden das ganz furchtbar. Dieses agile Arbeiten ist ganz schlimm. Wir kämpfen uns jetzt einen Freiraum, um irgendwo nicht agile Arbeiten zu dürfen und in deren Sicht ist dieses nicht agile Arbeiten dann einfach unkompliziert, direkt miteinander reden, frei von sinnlosen Regeln, Ergebnis fixiert und so weiter und so weiter. Und man kommt dann als externer Berater oder Aether Coach dahin und mit so einer Mischung aus trotzigem Stolz und Schadenfreude und was auch immer, stellen die sich dann vor mich hin und sagen, guck mal, wir haben uns geweigert, agile zu arbeiten und stattdessen haben wir das gemacht und das ist total toll. Ja, und das ist agile. Ihr müsst das nicht so nennen. Aber herzlichen Glückwunsch. Ich habe euch nicht mehr so viel beizubringen. Das sind dann sehr spannende Momente. Aber das ist dann das, wo ich sage, das finde ich eigentlich immer großartig, weil gerade wenn so etwas aus der Einheit heraus selber entstanden ist, als Reaktion auf irgendeine offensichtliche Notwendigkeit, mit Ergebnisorientierung, dann sage ich immer, genauso soll es eigentlich sein. Aber die Erlebnisse, die freuen mich, werden ich sie habe extrem. Ja, das kann ich gut nachvollziehen. Toll. Ja, super Abschluss. Felix, ich danke dir nochmal ganz viel für deine Zeit. Ich weiß, dass der Tag heute lang für dich war. Ja, aber jetzt geht er ja im Ende entgegen. Ganz genau. Vielen, vielen Dank. Ich kann mir gut vorstellen, dass wir nochmal eine Folge zusammen aufnehmen. Ja, würde Spaß machen, auf jeden Fall. Super. Dann ganz, ganz vielen Dank. Mach's gut, Felix. Mach's gut, bis denn. Ja, vielen Dank nochmal an dieser Stelle an Felix. Schöne Grüße. Vielen Dank für deine Zeit. Fand ich war ein ganz tolles Gespräch und ich denke, damit sind wir heute auch schon durch. Wie immer interessiert mich und ich denke auch den Felix. Wie ist eure Meinung zu dem Thema? Was habt ihr vielleicht so in der Praxis erlebt? Kennt ihr das vielleicht? Gebt mir und dem Felix dann entsprechend dazu gerne Feedback. Du erreichst mich zum Beispiel per Mail unter nobs@gmail.com. Du findest mich auch auf Mastodon. Und parallel zum Podcast gibt es ja noch ein Forum, in dem wir anfangen zu Themen zu diskutieren. Da gibt es dann genau zu dieser Folge einen einzelnen Thread. Ihr könnt aber gerne auch selber einen Thread eröffnen, wenn ihr Fragen habt oder auch Themen vorstellen wollt. Und wenn du Lust hast, mit mir auch hier in dem Podcast mal über agile Themen zu besprechen, dann melde ich einfach gerne. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. [Musik] [Musik] [Aufregende Musik]