In dieser Folge wird die komplexe Dynamik der agilen Transformation in Unternehmen beleuchtet, wobei besonders auf die unterschiedlichen Wege eingegangen wird, wie Unternehmen solche Initiativen starten können. Die Beauftragungen für agile Projekte kommen dabei aus verschiedenen Hierarchieebenen, von Geschäftsführern großer Konzerne bis hin zu Abteilungsleitern in kleineren Einheiten. Die Aufträge können unterschiedlich umfangreich sein, von der Begleitung einzelner Scrum-Teams über die Unterstützung bei der Implementierung agiler Frameworks bis hin zur Umgestaltung ganzer Ressorts oder Projektstrukturen. Der Fokus liegt auf der Anpassung der bestehenden Strukturen und der Reduzierung von Bürokratie, um die Agilität auf größere Skalen zu übertragen.

Ein zentrales Thema ist das "Agile at Scale", also die Skalierung agiler Methoden auf große Organisationseinheiten. Hier wird die Notwendigkeit unterstrichen, Kommunikations- und Koordinationsaufwände zu minimieren und Teams möglichst unabhängig und crossfunktional zu gestalten. Die Diskussion umfasst auch verschiedene agile Frameworks wie SAFe, LeSS und Nexus, wobei deutlich wird, dass keine universelle Lösung existiert. Stattdessen sollte eine maßgeschneiderte Kombination der besten Elemente aus verschiedenen Methoden verwendet werden, um die spezifischen Herausforderungen eines Unternehmens zu bewältigen. Am Ende steht die Erkenntnis, dass echte Agilität durch die Schaffung flexibler und autarker Einheiten erreicht wird, und dass oft auch einfache, pragmatische Ansätze effektiver sein können als komplexe Frameworks.

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile. 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 No Bullshit Agile.

In der letzten Folge habe ich über das Potenzial im Daily gesprochen. Da ging es mir darum, dass man unter anderem auch erkennen kann, wie gut das Team funktioniert, indem man guckt, wie regelmäßig 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 Felix von der Agile Process GmbH, und wir unterhalten uns über Agile at 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 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 mich und meine Firma. Ich bin Teil der Agile Process GmbH, einer kleinen agilen Unternehmensberatung. Man sagt ja auch Boutique-Beratung, also wenn man sich als Beratungshaus auf ein einziges Thema spezialisiert. Und beim Namen Agile Process GmbH ist ja relativ offensichtlich, was das Thema sein könnte. Mit der sind wir im Wesentlichen für große Unternehmen unterwegs, schwerpunktmäßig aus dem Rheinland, aber auch aus dem restlichen deutschsprachigen Raum, also Konzerne, Versicherungen, Banken, Energiekonzerne, Automobilunternehmen, irgendwas in der Größenordnung. Genau, und das jetzt schon seit langer Zeit. Also ich selber mache das jetzt knapp 15 Jahre und 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übergeht. 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 agil durchzuführen, so als Open-Space-Format. Übrigens, das war gerade erst gestern 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 finden wir alle wieder in den Shownotes, das nur als Info am Rande.

Sehr schön, genau. Und wir hatten uns im Vorgespräch ein bisschen darüber unterhalten, und ich fand das Thema superinteressant: 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 agilen Frameworks supergut 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. Wie du ja schon gesagt hast, Konzerne sind ganz anders aufgebaut. Das kenne ich eben von unseren Kunden, und ich sage mal, die haben erst einmal 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 ich kann natürlich direkt ein bisschen darauf eingehen, worauf das ankommt, denn wir steigen damit 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 ändernden 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 in diese Idee bringt: Wir müssen was ändern. Dann hat man die Möglichkeit, erst mal auf einer vernünftigen Grundlage etwas zu machen.

Was häufiger vorkommt, 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 hinaus, an dem es eine Mode ist. Und das heißt, jeder halbwegs größere Konzern hat nicht nur eine, sondern zwei oder drei verschiedene agile Transitionen oder Versuche von agilen Transitionen hinter sich. Und da sind natürlich dann ganz viele Hinterlassenschaften, auf die man 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. 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 schauen zu können, wie man aus all dem noch einen vernünftigen Ansatz zusammenbekommt. Und das Ganze natürlich unter der Voraussetzung, dass der jeweilige Kunde, der uns beauftragt, das auch genauso sieht. Und nicht sagt: 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? Das hängt 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?

Das ist in der Tat ein ganz wichtiger Punkt. 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 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 zufriedenstellenden 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 Leute sagen: "So Felix, 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 Lean-Transformation dabei. Und am Ende haben sich immer nur Namen geändert, und es ist ansonsten 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, indem man sagt: Findest du denn den Ist-Zustand, wie er jetzt ist, gut? Da ist die Antwort extrem häufig nein. Und da kann man eben auch sagen: Dann müssen wir doch versuchen, daran zu arbeiten, dass wir da rauskommen. Denn die Alternative wäre ja, alles so zu lassen, wie es jetzt ist. Das ist ja meistens auch nicht im Sinne der Leute, denn wenn es so bleiben könnte, wie es ist, kann ich 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 von sehr weit oben angesetzt? Kommt es eher aus dem Team heraus oder aus einzelnen Abteilungen? 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 in Unternehmen gewesen, die die deutsche Landesgesellschaft eines internationalen Konzerns waren. In dieser Landesgesellschaft gibt es dann, wie es bei Konzernen üblich ist, verschiedene Untergesellschaften und vielleicht noch Unter-Untergesellschaften. Das bedeutet, man kann von jemandem beauftragt werden, der zwar Geschäftsführer auf seiner Visitenkarte oder in der E-Mail-Signatur stehen hat, aber trotzdem über sich noch fünf bis zehn Hierarchiebenen hat.

Umgekehrt kann in anderen Konzernen jemand, der Abteilungs- oder Bereichsleiter ist, gar nicht so viel weniger Budget und Entscheidungsmacht haben als jemand, der in einem anderen Unternehmen als Geschäftsführer bezeichnet wird. Es kommt auch vor, dass wir von Leuten wirklich ganz oben in der Hierarchie beauftragt werden. Ich war schon in Transitionsteams, die unmittelbar unter einem Vorstand angesiedelt waren. Das ist jedoch eher die Ausnahme, da ab einer bestimmten Unternehmensgröße auch die einzelnen Einheiten so unabhängig sind, dass sie unabhängig von den anderen Transformationsprogramme fahren können.

Vielleicht mal an der Stelle, wenn wir jetzt davon ausgehen, dass die Leute von sich aus einen Anlass ermittelt haben: In welcher Situation kommst du dann ins Spiel? Gibt es zwei Scrum-Teams, die nicht weiterkommen, oder soll es erweitert werden? Eine Agile-Transformation hast du ja schon erwähnt. Wie sieht so ein Auftrag oder ein Projekt aus?

Das vom Umfang her Ü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 als Pilotprojekt die ersten sein sollen, die in Richtung Scrum gehen. „Kümmere dich doch mal um die und hilf ihnen beim Start in diese neue Welt.“ Das ist dann noch relativ einfach, unter der Voraussetzung, dass bestimmte Rahmenbedingungen gegeben sind. Man kann dann sagen: „Nachdem wir miteinander gesprochen haben, stellen wir euch die verschiedenen gängigen agilen Frameworks vor, einigen uns auf einen bestimmten Zeitraum, in dem ihr das Passendste ausprobieren könnt, und danach bewerten wir, ob es in Ordnung ist und ob wir weitermachen oder etwas anderes ausprobieren.“

Das findet häufig im Rahmen von sehr beschränkten Beauftragungen statt, die dann ein paar Sprints, ein paar Monate oder etwas in dieser Richtung dauern können. Es gibt natürlich auch viel größere Aufträge, bei denen man sagt: „Okay, wir möchten das gesamte Ressort – ein großer Klassiker ist natürlich immer das IT-Ressort – ändern.“ Oder eine andere Möglichkeit ist, dass ein neues Projekt aufgesetzt wird, beispielsweise eines, das eine bestimmte Uralt-Software durch eine neue Standardsoftware ablösen soll. Das dauert dann natürlich nur eine gewisse Zeit, und dann wird das Projekt abgeschlossen. Dann lautet der Auftrag: „Hilf uns doch, dieses Projekt aufzubauen, zu stabilisieren und in einen Arbeitsmodus zu bringen.“ Da kommen dann verschiedene Aspekte zusammen, nicht nur der Arbeitsmodus, sei es Scrum oder Kanban, sondern auch die Frage, wie man eine große Organisationseinheit herausbildet, die dann 10, 20 oder 50 Teams haben kann. Das größte Projekt, das ich in dieser Richtung erlebt habe, hatte tatsächlich 40 bis 50 Teams. Das ist natürlich eine ganz andere Hausnummer als zwei oder drei Teams.

Bei 50 Teams, auch schon bei 20 Teams, sind wir tatsächlich an dem Punkt, wo man von „Agile at Scale“ sprechen kann. Da muss ein Überbau stattfinden oder es müssen Schnittstellen zwischen den Teams existieren, die diesen Überbau rechtfertigen. Ist das richtig? So interpretiere ich das zumindest. Wann brauche ich „Agile at Scale“?

Auch hier wieder: Eine wie auch immer geartete Koordination oder Kommunikation braucht man eigentlich schon ab zwei Teams. Aber auf dieser kleinen Ebene würde ich immer sagen: Fangt gar nicht erst mit irgendwelchen Frameworks an, sondern lasst die Teams einfach miteinander reden. Das hilft in den allermeisten Fällen schon. Irgendwo liegt dann die Grenze, wo das nicht mehr ausreicht. Je nachdem, wen man fragt oder welches Framework man sich anschaut, liegt diese Grenze bei 5 bis 10 Teams, hätte ich erfahrungsgemäß gesagt. Da kommen dann die verschiedenen Einheiten ins Spiel, die in den unterschiedlichen Frameworks sagen: „Okay, da muss man jetzt koordinieren“, sei es der Release Train in SAFe oder die maximale Anzahl von Teams, die in Large-Scale Scrum (LeSS) zusammenarbeiten können. Irgendwo da würde ich sagen, geht es dann los.

Die spannende Frage ist, wie man es schafft, die notwendige Kommunikation und Koordination, die natürlich Ressourcen und Zeit fressen, möglichst klein zu halten. Denn alles, was dafür gemacht werden muss, steht nicht mehr für die eigentliche Arbeit, das Entwickeln von Produkten, zur Verfügung. 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 in unserem agilen Kosmos oder in unserer agilen Blase verstehen. Es geht dann gar nicht mehr so stark darum, ob wir in Sprints arbeiten, Retrospektiven machen oder ob es einen Product Owner gibt, sondern um ganz banale Fragen wie: „Hat dieses Team überhaupt in sich Stabilität?“

Sind das Leute, die länger zusammenbleiben? Sind sie alle in Vollzeit im Team oder arbeiten sie auch noch in einem zweiten, dritten oder vierten Projekt? Haben sie ein gemeinsames Produkt, in dem Sinne, dass sie eine definierte Gruppe von Abnehmern oder 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 sie überhaupt in der Lage, selbstständig Product Ownership zu übernehmen, also zu entscheiden, was sie dieser Kundengruppe bieten wollen? Zu Beginn sind in großen Konzernen die Antworten darauf ganz häufig alle „Nein“.

Das, was in der Vergangenheit entstanden ist, hat damals möglicherweise gut funktioniert, kollidiert aber mit der Art und Weise, wie diese neue agile Arbeitswelt aussieht. Häufig finden wir zum Beispiel Leute, die stark spezialisiert sind, auf was auch immer – Softwareentwicklung, Ingenieurberufe – und die dadurch, dass sie so stark spezialisiert sind, in einem Entwicklungsteam der Scrum-Team-Größe (also bis zu zehn Leuten) gar nicht voll ausgelastet wären. Diese müssen dann, um überhaupt durchgehend etwas zu tun zu haben, in ein zweites oder drittes Team gehen. Beispielsweise Leute, die an einer zentralen, von mehreren Teams genutzten Backend-Komponente arbeiten, wären so ein Beispiel. Diese arbeiten dann verschiedenen Teams zu, häufig verbunden mit Code Ownership für diesen Bereich. Aber das gibt es beispielsweise auch in der Hardware-Entwicklung. Ich erinnere mich an einen Kunden, bei dem die Verpackungstechnik – also die Leute, die die Verpackung für das physische Produkt gebaut haben – in den einzelnen Produktteams so wenig zu tun hatte, dass sie gleichzeitig in fünf oder sechs Teams tätig sein mussten, was zu erkennbaren Problemen führte.

Ähnliches kann man sich bei sehr spezialisierten Testern oder IT-Konzeptern vorstellen. Hier muss man sich dann überlegen, ob diese Spezialisierung, die irgendwann einmal aus gutem Grund entstanden ist, auch jetzt noch notwendig ist, wenn wir flexible, autonome, agile Teams haben wollen. Wenn die Antwort darauf „Nein“ lautet, was müssen wir dann alles umstellen, um dahin zu kommen? Dabei hängt unglaublich viel daran, von Ausbildungswegen über die Zugehörigkeit zu organisatorischen Einheiten, bis hin zu beruflicher Identität. Da hängen auch kleine Eitelkeiten dran, wie: „Jetzt muss ich zulassen, dass andere Leute meinen Code bearbeiten, und ich muss anfangen, an Code mitzuwirken, den ich gar nicht kenne, was mich unsicher macht.“ Und so weiter und so fort.

Also ganz viele Umstellungen, die in diese Richtung überhaupt reingehen, können unglaublich viel Zeit in Anspruch nehmen, aber dann, wenn man das geschafft hat, auch eine riesige Wirkung entfalten.

Ja, sehr guter Punkt. Und tatsächlich hast du eine Frage, die ich habe, schon ein bisschen mitbeantwortet. Der erste Ansatz könnte ja sein, dass man sagt: Können diese Teams in einer von mir aus zehnköpfigen Größe, also Scrum-Größe, nicht so selbstständig sein, dass sie nicht von anderen abhängen? Dann hätte ich dieses Problem im Zweifel nicht. Aber genau wie du gesagt hast, es gibt wahrscheinlich einfach zu viele Abhängigkeiten, die man gar nicht anders lösen kann, sodass es diesen Überbau braucht.

Ja, natürlich. Und es gibt eben Sachen, die müssen übergreifend für ganz viele Produkte da sein. Ein schlechtes Beispiel wäre, wenn ich im Ökosystem von Google bin, 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 dann zugreifen muss. Das heißt, solche zentralen Funktionen habe ich immer wieder, und die machen in diesen großen Zusammenhängen auch Sinn.

Da gibt es dann auch nicht die eine Antwort darauf, wie ich damit umgehen kann. Es gibt ja mindestens zwei Möglichkeiten: Erstens, ich baue dafür ein spezialisiertes Team, das sagt, dieser Single-Sign-On ist unser Produkt, und das bieten wir allen anderen Produktteams als sehr einfache Schnittstelle an – im Zweifel so einfach, dass man da gar nicht groß koordinieren muss, sondern jeder, der möchte, kann sich einfach an dieser Schnittstelle andocken, ohne dass wir viel von unserer Seite tun müssen. Das wäre so etwas wie "Single-Sign-On as a Service".

Die andere Alternative könnte sein, wir erklären diese zentralen Komponenten – in diesem Beispiel den Single-Sign-On – praktisch zur Collective Code Ownership aller beteiligten Teams. Das heißt, jeder, der möchte, darf da dann mitarbeiten. Das kann auch funktionieren, bringt aber ganz andere Herausforderungen mit sich, wie zum Beispiel Vereinbarungen darüber, wie man vorgeht, wenn man etwas verändert, das andere Teams betrifft. Wie muss ich Sachen zurücklassen, sodass andere, die daran arbeiten wollen, es auch verstehen und sich nicht erst ewig einarbeiten müssen, um nachzuvollziehen, was mir durch den Kopf ging, als ich das gebaut habe, und so weiter und so weiter.

Ja, das sind reale Fälle. Und auch da kommen dann diese großen Themen ins Spiel, bis hin zu dem spannenden Punkt, an dem man sich fragen muss: Wenn es irgendwann wirklich riesig ist, macht es nicht Sinn, bestimmte Dinge auch redundant zu gestalten? Ich erinnere mich an einen Konzernkunden, da gab es beispielsweise irgendwann die Überlegung: Wenn wir jetzt einen Posteingang für alle unsere verschiedenen Produktgruppen machen, die völlig unterschiedliche Kundengruppen haben, führt das dazu, dass diese zentrale Posteingangsfunktion zu einem Flaschenhals für alle anderen wird. Das hat so viele negative Folgen, dass wir lieber redundant mehrere Posteingänge nebeneinander betreiben, jeweils für eine Kundengruppe. Das Risiko besteht dann darin, dass mal ein Kunde aus Versehen den falschen Posteingang benutzt, den man dann hinten durch umleiten muss.

Aber auch das sind große Entscheidungen, die am Ende wieder auf Agilität einzahlen können, indem Dinge auf einmal unkomplizierter und schneller gehen, weil weniger Koordination, weniger Abstimmung notwendig sind und weniger Abhängigkeiten bestehen, und so weiter.

Für mich als eine Zusammenfassung oder als ein Learning wäre: Eigentlich versucht man mit Agile at Scale, Kommunikation, Koordination, Produktvision so gut zu gestalten, dass mehrere Teams eben – ich sage mal – mit einer Stimme sprechen oder einheitlich in einem Standard, in einer gleichen Qualität arbeiten, was Code, Releases, Zusammenarbeit usw. betrifft. Diese Lücke wird durch Agile at Scale gefüllt.

Ja, grundsätzlich ja. Ich würde es ein kleines bisschen anders formulieren: Wenn man das macht, was wir gerade besprochen haben – also dieses Entkoppeln, Klären, Abbau von Abhängigkeiten, Multimitgliedschaften und was auch immer dazu führt, dass aus diesem Kommunikations- und Koordinationsbedarf Bürokratie wird – wenn man all das macht, dann ist das Ergebnis davon Agilität im großen Maßstab, also Agile at Scale. Agilität bedeutet für mich, dass da eine Einheit – in diesem Fall eine große Einheit – ist, die flexibel, beweglich, reaktionsfähig und lieferfähig ist.

Das kann ich in weiten Teilen dadurch erreichen, dass ich, bevor ich über Rollen, Frameworks und Story Points nachdenke, zuerst daran arbeite, möglichst unabhängige, crossfunktionale, systemisch veranlagte und end-to-end verantwortliche kleine, lieferfähige Einheiten zu schaffen.

Mit denen kann ich dann im nächsten Schritt hingehen und sagen: Okay, jetzt fangen wir an, über Kanban, LeSS, Scrum oder was auch immer zu sprechen.

Ja, das klingt total sinnvoll. Das ist wieder ein gutes Stichwort. Wir sind jetzt an einem Punkt, wo wir darüber gesprochen haben, was Agile at Scale bedeutet und in welchen Situationen Unternehmen das anwenden. Vielleicht zum Abschluss noch: Es gibt viele Methoden, die das abbilden. Mir fällt da immer nur SAFe ein. Ich habe darüber wenig gelesen, und ich weiß, dass viele da ein bisschen die Nase rümpfen, weil es erst einmal komplex wirkt. Es gibt ja noch ein paar weitere. Vielleicht keine Zusammenfassung, was jede Methode macht – das würde, glaube ich, den Rahmen sprengen. Ich verlinke da garantiert eine Website dazu. Aber an irgendeinem Punkt sagt ihr dann: Okay, wir haben uns das mal angeschaut, und du hast ja gerade gesagt, wir gucken in den Teams. Wendet ihr dann eine dieser Methoden im Unternehmen an, oder bedient ihr euch aus Schnittmengen und seid dabei praxisnah?

Also eher Letzteres. Ich weiß nicht, wie deine Erfahrung ist, aber die wenigsten Teams, die ich erlebt habe, machen wirklich Scrum, Kanban, XP oder was auch immer auf Team-Ebene in Reinform. Selbst da gibt es häufig Kompromisse, die gute und schlechte Gründe haben.

Das Gleiche gilt umso mehr auf einer größeren Ebene. Ich sehe in den verschiedenen Ansätzen verschiedene Punkte, die gut oder schlecht sind. Das Beispiel SAFe ist ja wirklich kontrovers. Viele Konzerne sind davon total begeistert, weil sie das große Wimmelbild sehen und das Gefühl haben, endlich hat sich mal jemand über alles Gedanken gemacht. Das ist die Situation, in der ich mir die Rundum-sorglos-Lösung kaufe. Das Problem ist natürlich, wenn ich das alles bei mir einführe, dass auch wieder Bürokratie entstehen kann. Aber man muss auch sagen: Da SAFe versucht, alles zu bedenken, gibt es viele Bereiche, die dort abgedeckt sind, für die andere agile Frameworks überhaupt keine Lösung anbieten.

Ein einfaches Beispiel ist die Budgetierung. Eine große Hürde in vielen Unternehmen ist, dass jemand außerhalb der Entwicklungseinheiten das Budget besitzt und sagt: Das gebe ich nur für bestimmte Produkte oder sogar nur für bestimmte Features frei. Wenn ein Team dann anfangen will zu arbeiten, muss es maximal so viel Arbeit reinstecken, wie durch das Budget gedeckt ist, und darf nicht an anderen Features arbeiten, für die kein Budget da ist. Allein diese Beschränkung und der Kampf darum, auch an anderen Sachen arbeiten zu können, für die kein Budget da ist, können unglaublich viel Energie rauben. Das kann in die Anti-Agilität führen.

Bei SAFe hat jemand mal gesagt: Wir machen das ganz einfach. Es gibt die Einheit des Release Trains mit fünf, sechs, sieben oder wie vielen Teams auch immer, und diese werden einfach fix budgetiert für einen bestimmten Zeitraum, z. B. ein Jahr – völlig unabhängig davon, was sie bauen. Es soll natürlich immer noch eine Art von Priorisierung geben, damit man erkennt, was gerade wichtig ist. Das machen wir als Erstes. Aber dadurch, dass man es von der Budgetierung entkoppelt, wird man viele Probleme los. Auf einmal gibt es nicht mehr die Möglichkeit, dass jemand von außen über das Budget reinregiert. Auf einmal besteht auch nicht mehr das Risiko, dass man die Teams plötzlich halbieren muss, weil nur noch die Hälfte des Budgets für diese Features übrig ist.

Das ermöglicht dann auf einmal Stabilität. Auf der anderen Seite bin ich z. B. ein großer Fan davon zu sagen: Wenn es so ist, dass mehrere Teams an einem gemeinsamen Produkt arbeiten, und man sagt, ihr arbeitet jetzt daran, damit es schneller geht, z. B. weil man sonst das Risiko hat, dass ein Wettbewerber vor einem fertig wird, oder weil es so unterschiedliche Teilprodukte gibt, dass es Sinn macht, unterschiedliche Teams daran zu setzen – z. B. Embedded Software und Cloud Software, die erst in Kombination bei einem Hardware-Software-Produkt zum endgültigen Ergebnis führen –, dann kann man hingehen und ihnen ein gemeinsames Backlog mit einem gemeinsamen Product Owner geben. Der kann dann durch seine Priorisierung dafür sorgen, dass zusammengehörige Sachen gleichzeitig fertig werden und teamübergreifend Inkremente entstehen, die für Endkunden nutzbar sind.

Im besten Fall gibt es noch eine gemeinsame Definition of Done für die Teams sowie übergreifende Planungs- und Sprint-Review-Events. Das ist, was Nexus oder LeSS machen würden. Das finde ich ebenfalls sehr charmant. Es hat eben ganz andere Aspekte. Und so komme ich auch bei anderen Frameworks zu dem Punkt, dass ich sagen kann: Okay, da kann ich was nehmen, da kann ich was nehmen.

Mittlerweile gibt es auch einen wahren Wildwuchs von immer neuen Frameworks, von denen der "normale" 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, 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, in der Hoffnung, 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: Sind die Leute, die einen beauftragen, auch diejenigen, 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 crossfunktionale Teams macht, indem man die Mitglieder neu zusammensetzt. Das muss dann natürlich jemand sein, der, wenn er einen mit einem solchen Beratungsauftrag reinholt, so etwas entscheiden darf. Im Konzern darf er das im Zweifel nicht alleine, da muss dann immer, keine Ahnung, der Betriebsrat und ich weiß nicht, wer sonst noch mitreden. Aber er muss diesen Prozess zumindest einleiten können. Und wenn er das nicht kann, dann haben wir ein grundlegendes Problem.

Ein einfacheres Beispiel: Vor einigen Jahren kam mal hier – ich bin ja in Bonn – jemand von so einer Behörde zu uns. Wir haben hier ganz viel Behörden-IT, und der Verantwortliche hat bei irgendeiner mittelgroßen Behörde im V-Modell auf der rechten Seite eine der mittleren Stufen gesagt: "Okay, ich habe doch gehört, Agil, das ist jetzt irgendwie toll und ich erkenne auch den Sinn darin, könnt ihr mir dabei helfen, das zu werden?"

Und also, wir sind dann nach sehr frühen Gesprächen schon direkt auseinandergegangen, weil ich dann auch sagen musste: Sorry, aber rechte mittlere Stufe im 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, 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." Dem fehlt ja auch jegliches Mandat, um aus dieser kleinen Welt auszubrechen. Ja, und da muss man sagen: Vermutlich tut man niemandem einen Gefallen, wenn man es so versucht. Da hätte man eben jemanden gebraucht, der über alles einmal so weit drüber gucken kann, dass er sagt: "Okay, da brechen wir jetzt, keine Ahnung, mit einem 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 zusammenzuschließen, und dann nochmal zwei, und ein Vierteljahr 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 beauftragt, 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 herausragt, 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 schiefgegangen sind. Man hat es 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-, Team- und Irgendwasstrukturen nicht, aber zwingen alle, keine Ahnung, OKR oder SAFe oder irgendetwas anderes 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 agil arbeiten zu dürfen." Und in deren Sicht ist dieses nicht agile Arbeiten dann einfach unkompliziert, direkt miteinander reden, frei von sinnlosen Regeln, ergebnisfixiert und so weiter.

Und man kommt dann als externer Berater oder Coach dahin und mit so einer Mischung aus trotzigem Stolz und Schadenfreude und was auch immer stellen sie sich dann vor mich hin und sagen: "Guck mal, wir haben uns geweigert, agil 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 freuen mich, wenn 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 zu Ende.

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 nobsagile@gmail.com. Du findest mich auch auf Mastodon.

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 im Podcast mal über agile Themen zu sprechen, dann melde dich einfach gerne. Habt noch eine ganz tolle Woche und bis zum nächsten Mal.

NBA28: Im Gespräch Felix - Agile at Scale

Shownotes

Zusammenfassung

Transkript

Featured

Subscribe

Tags