Scrum Think b!g - Leserstimme von Jürgen Margetich

Unternehmen, die sich auf den Weg machen, ohne formales Linienmanagement auszukommen, entwickeln in jedem Mitarbeiter die Kompetenz des Managens.In gewohnt provokanter Art führt Boris Gloger in Dichotomien, die so vielleicht nicht zu halten sind, zum Beispiel ergebnisorientierte Arbeit am Projekt vs. karriereorientierter Gremienarbeit und Political Engineering. Dennoch muss man schon genau prüfen, ob das nicht jene Systemeffekte sind, mit denen wir tagtäglich zu kämpfen haben. Und damit hätte Gloger recht behalten. Es lohnt daher, sich spielerisch auf die Provokationen einzulassen und zu Lernfeldern zu reframen.Das erste Drittel des Buchs ist Grundlagenwiederholung - für den Leser, der Neues sucht, vielleicht irritierend. Warum ich es dennoch genau gelesen habe und das auch weiterempfehlen möchte, ist der Umstand, dass wir (selbst ich als Berater) im Alltag vor allem mit klassischer Führung und Struktur, mit klassischen Organisationen und Projekten konfrontiert sind. Da lohnt es sich, einen Schritt zurück zu machen und zu fragen: Was soll denn hier überhaupt skaliert werden? Die Pyramide – oder eine agile Organisation? Sich die zu skalierende Basis genau anzusehen, ist möglicherweise der wichtigste Teil des Buchs. Vielleicht hätte ich mir am Anfang eine Kernaussage zur Skalierung gewünscht. Quasi das Architekturbild dazu, um dann nachzulesen, was dahintersteckt - welche Basis, welche Prinzipien etc.Geht es hier ums Skalieren oder um die Basics? Ohne Basics kein Skalieren. So stellt Boris zum Beispiel auch den Bezug zu Alistair Cockburn´s Definition zu Agilität her: Collaborate, Deliver, Reflect, Improve. Hätte Boris in seinem Buch noch Checkboxes oder Skalen (1 – 10) nachgesetzt, könnte sich der an Skalierung interessierte Leser gleich selbst überprüfen und seine Organisation auch. Arbeiten wir zusammen? Liefern wir? Reflektieren wir? Verbessern wir uns? So einfach ist die Welt. Und wenn überall ein deutliches Ja steht oder eben eine 10: Wer würde sich dann noch die Mühe machen, die Bürokratie von SAFe zu implementieren, zu betreiben und zu verwalten? Richtig – nur Bürokraten.

Was hatte ich erwartet?

Ich hatte ein Buch erwartet, das sich - so wie es andere zum Thema Skalierung tun - mit skalierten Prozessen, Strukturen, Organisationsformen, der Anpassung von Zusammenarbeitsmodellen und ggf. adaptierten bzw. neuen Rollen befasst und diese vermittelt. Also ein Organizational Engineering Book. Was habe ich gelesen: Den Erfahrungsbericht eines durch und durch agilen Unternehmensführers, der erkundet, was Wachstum und Skalierung entlang der agilen Prinzipien bedeuten kann.Wer à la SAFe ein Prozess-Organigramm zur nachfolgenden Implementierung erwartet, wird enttäuscht sein. Wer seine Organisation entwickeln möchte – Agilität skalieren, in diesem Sinne verbreitern, – der wird in den Grundprinzipien bestärkt seinen eigenen Weg entlang der Erfahrungsberichte, Praxisbeispiele und Gastkommentare finden. Ein Buch zum selber Arbeiten, nicht zum Implementieren.

NEIN.

Wenn wir von Skalierung sprechen, dann ist wohl der Aspekt des JA zum NEIN in der Organisation entscheidend. Boris Gloger rührt an mehreren Stellen an dieser Widerspruchsfähigkeit, die in eine klassisch gebildete, hierarchische Organisation erst eingebracht werden muss. Offen bleibt leider die Frage des systemischen Neins, also der Frage nach der Fähigkeit der Organisation, mit Hilfe vieler Neins an vielen Stellen des Unternehmens konstruktiv die eigene Stärke auszubauen, Wettbewerbsvorteile zu gewinnen und in der innerbetrieblichen Competition langfristig zu bestehen. Wie bei allen bisherigen Büchern von Boris Gloger dürfen wir auch hier eine zweite und ggf. dritte Auflage erwarten. In dieser wünsche ich mir dann Betrachtungen und fundierte Untersuchungen zu diesem Aspekt.

Alte Wunden

Mit seinem Hinweis auf die Theory of Constraints legt Boris seinen Finger tief in eine der ältesten Wunden der Skalierung. Skaliert wird, wenn der Ausweg aus einer Lieferunfähigkeit oder gefühlter bzw. realer Verspätung von Lieferungen durch Größe behoben werden soll. Was also passiert, ist: Das System, das in eine problematische Situation geführt hat, wird weiter ausgedehnt und verursacht so noch größere Schäden. Selten habe ich in meiner Beraterlaufbahn gesehen, dass diese Skalierungen (ungeachtet ihres methodischen Setups) erfolgreich gelaufen wären.Daher lohnt es sich, einige einfache Prinzipien, wie Gloger sie auch im Buch aufführt, zu berücksichtigen: Anforderungen reduzieren, Auslastung auf 60–70 Prozent runterfahren, vom Multi-Project- zum Single-Project-Focus. Dafür eben liefern und verkaufen.Etwas kontraintuitiv, aber wirksam: „weniger“, dafür „erfolgreich“.

Thema Vertrauen

Die schwerste Managementaufgabe in der Skalierung: Führung schafft Vertrauen. Boris Gloger stellt in seinem Buch eine hohe, fast schon nervige Forderung: Manager müssen ihren Teams vertrauen. Gleichzeitig attestiert er dem Management, im Dauer-Panikmodus zu arbeiten. An dieser Stelle könnte man das Buch entspannt zur Seite legen, sich ärgern und Gloger vorwerfen, er wisse nicht, wovon er spricht/schreibt. Und vor allem würde man sich angesichts der eigenen Geschichte enttäuschten Projektvertrauens noch mehr ärgern. Ehrlich.Unterstellen wir mal den grundsätzlichen Willen zum Vertrauen, denn auch Manager wollen ja nicht per se misstrauen. In wie vielen Fällen hat man als Manager das Gefühl, das investierte Vertrauen wurde enttäuscht? So ist es auch mir beim Lesen dieser Passage (Seite 154) gegangen. Dann habe ich kurz nachgedacht und zwei Bausteine aus der bisherigen Lektüre dieses Buchs zusammengefügt:

1. Für Agilität und hohe Beschleunigung wird von allem mehr gebraucht als notwendig – mehr Teammitglieder, mehr Platz, mehr Kompetenz, mehr Wissen …
2. Ein Team, das das Ziel versteht und auch frei gewählt hat.

Und dann fiel es mir wie Schuppen von den Augen. Wann habe ich, wann haben Sie, geschätzte Co-Leser, beide Voraussetzungen geschaffen? Also 1. mehr … als notwendig bereitgestellt und 2. ein Team, das von sich aus „gepullt“ hat. Und hier ist schon die Misere.Also frage ich mich, und vielleicht ist das auch die Motivation hinter dem Lesen dieses Buchs: Wie kann es mit einem Mangel - also „weniger … als notwendig“ - und einem eingeteilten, beauftragten Team gelingen, Vertrauen aufzubauen und nicht enttäuscht zu werden? Das ist die eigentliche Frage. Vielleicht braucht es auch ein anderes Buch: agil Skalieren in einer traditionellen Mangelwirtschaft unter veralteten Arbeitsverträgen? Nun gut. Also lese ich weiter und folge der Vorstellung der idealen Welt. Vielleicht kann ich ja aus dieser etwas in meine ganz und gar suboptimale, reale Welt mitnehmen.

Die fraktal skalierte Organisation

Ein neuer alter Begriff: das Fraktal.Je weiter man sich an das Ende des Buchs heranliest, desto öfter wird man mit diesem Begriff konfrontiert. Weniger als Anleitung, mehr als Feststellung zur agilen Organisation in Skalierung. Wer mag da nicht denken, das Ende des großen Ganzen stünde an? Das eine Ganze würde substituiert durch die vielen kleinen Fraktale, die das große Ganze in sich tragen, selbiges aber würde nicht mehr in Erscheinung treten.Wer für diesen Gedanken reif ist, der kann sich auch der Skalierung in und von agilen Organisationen/Teams/Projekten stellen. Noch eins weitergedacht: Erst wer diesem Gedanken folgt, kann sich überhaupt gelebter, wirksamer Agilität zuwenden.

Und so sollten Sie dieses Buch lesen

Fangen Sie mit Kapitel 6.3. „Die Skalierungstoolbox“ an. Während des Lesens dieses Kapitels können Sie gleich Ihr Projekt/Ihre Organisation skalieren. Entweder sind Sie jetzt enttäuscht (das Ganze ist ja immer noch hauptsächlich Scrum, halt ein wenig erweitert) oderSie sind begeistert (denn das Ganze ist ja immer noch hauptsächlich Scrum, halt ein wenig erweitert, z.B. um das Konzept der „Gilden“).Dann lesen Sie von Kapitel 1 weg mit Stift und der permanenten Fragestellung: Machen wir das so wie beschrieben oder nicht?Wenn ja, lesen Sie weiter. Wenn nein, wissen Sie ja, was es zu ändern gilt, um mit der Skalierungstoolbox, wie von Boris Gloger beschrieben, erfolgreich zu arbeiten.Und schließlich lesen Sie den letzten Teil des Buchs. Darin finden Sie die richtigen Herausforderungen der Skalierung, vorausgesetzt, Sie haben die ersten beiden Schritte befolgt.Hinter dem Berater und Trainer Boris Gloger spürt man in diesem Buch auch den gelernten Philosophen. Reich an Quellenangaben lässt sich der eigene Bücherschrank mit guten Buchempfehlungen aus dem Quellenverzeichnis füllen. Wer durch die Quellen (dabei auch HBR und zahlreiche Videos) zumindest querliest und surft, hat das Thema Agilität in vielen Facetten schnell umrissen und sich ein ausreichend gutes Überblicksbild geschaffen, um damit erste Schritte in der Skalierung zu wagen und eigene Erfahrungen zu sammeln.Als langjährigem Weggefährten von Boris Gloger mag man mir beim Lesen dieses Buchs und meinen Kommentaren einen allzu freundlichen Blick vorwerfen. Aber wo soll ich ansetzen? Den Ausweg habe ich in folgender Frage gefunden, die Boris bisher – wie übrigens alle anderen Autoren der agilen Szene, soweit mir bekannt ist - komplett unbeantwortet gelassen hat: Wie sieht die agile Organisation, wie Boris sie beschreibt, in ihrer Skalierung in Zahlen, in Geld ausgedrückt aus? Auch das vielleicht ein Wunsch an die nächste Ausgabe: Szenarien gerechnet im Vergleich von klassischer zu agiler Organisation in Skalierungsvarianten.Wenn Sie dieses Buch gelesen und sich der Mühe unterzogen haben werden, sich nochmals mit den Prinzipien und Grundsätzen agiler Teams auseinanderzusetzen, werden Sie unter Umständen zum gleichen Schluss kommen wie ich: Skalierung ist in erster Linie eine Aufgabe der Organisationsentwicklung und erst in zweiter Linie eine Frage der Methodik, Praktiken und Organisation.

“Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”