Agil skalieren ohne Framework - darf man das?

Ja, wir alle wissen es. Unsere Umweltfaktoren ändern sich täglich. Genau deshalb versuchen die meisten Firmen agil zu arbeiten: Sowohl für das Unternehmen als auch für die Kunden ändern sich die Rahmenbedingungen stetig. Somit müssen sowohl Arbeitsweisen als auch Produkte angepasst werden. Doch meistens haben Unternehmen mehr als ein Team, mehr als eine Abteilung und vor allem bereits vorhandene Strukturen und Prozesse und schnell stellt sich die Frage, wie man denn agil skalieren könne. Glücklicherweise gibt es dafür Frameworks: Anleitungen, wie mehrere Teams gemeinsam agil arbeiten können.

Anleitungen können ein praktisches Hilfsmittel sein – solange sie auf die eigene Situation passen. Wenn wir uns einen neuen Schrank kaufen ist eine Anleitung super. Wenn wir Bretter und Latten kaufen, die wir zu einem Regal unter unserer Dachschräge zusammenbauen möchten, hilft uns keine von jemand anderem gefertigte Anleitung. Wir können sie nur als Ansatz, als Idee nutzen und müssen sie selbst auf unsere Situation anpassen. Genauso ist es mit agilen Frameworks wie LeSS, Nexus oder SaFe. Es ist gut, dass es sie gibt. Eine 1:1 Übertragung ist wahrscheinlich nicht sinnvoll. Besser ist es, Frameworks als Toolbox zu sehen und einzelne Elemente aus ihnen auf die jeweilige Unternehmenssituation zu adaptieren. Allerdings ist der Ansatz recht unbeliebt, denn so sind keine langfristigen Planungen im Vorfeld möglich. Es gibt keine Meilensteine, keine Projektampeln, keine konkreten Zwischenprodukte. Dafür gibt es viele Tests, viel “schauen wir mal” und noch mehr “das kommt jetzt darauf an…”

Viele Unternehmen entscheiden im Management, dass eine agile Arbeitsweise sinnvoll ist, und versuchen top-down einen Kulturwandel und eine neue Art des Arbeitens einzufordern. Meist geschieht das mit einem Projektplan und einem Framework.

“Die da oben schon wieder…”

…denken viele Mitarbeiter, die aufgrund von schlechten Erfahrungen in vergangenen Projekten zunächst eigentlich nur eines wollen: Ihren Job machen. Im Fachjargon sprechen wir von “Change Saturation”, im Alltag finden wir weniger schmeichelhafte Formulierungen. Warum? Veränderung heißt Neues, Neues heißt nicht immer besser und gebranntes Kind scheut das Feuer. Zu beachten ist, dass dieses Denken keinerlei fachliche Komponente hat. Die meisten mögen ihre Arbeit, sind aber auch Menschen, und Veränderungen bereiten uns Schmerzen.

Deswegen nutzen wir gerne Frameworks, etwas, das schon für uns vorbereitet wurde. Nun müssen wir nur noch Namen zu den Rollen schreiben, und schon haben wir agil skaliert. Haben wir?

In den letzten Jahren habe ich unterschiedliche Teams in diversen Bereichen begleitet. Dabei war es entscheidend, dass sowohl die Teams als auch ihre Führungskräfte etwas an der bestehenden Arbeitsweise ändern wollten. Und das hatte zur Grundlage, dass das Management darüber den Führungskräften freie Hand ließ. Häufig wird bei der Einführung skalierender Frameworks zunächst ein zeitlich und inhaltlich langes Konzept entwickelt, von dem man nicht weiß, ob es funktionieren wird. Wir haben stattdessen einfach mit den Teams Dinge ausprobiert - mal analog, mal digital. Natürlich hat nicht immer alles sofort funktioniert. Das war allen Beteiligten klar, dennoch wurde der Weg weiter gegangen und konnte so eine hohe Akzeptanz und den Willen zur Weiterentwicklung erreichen. Basis war immer das Scrum-Framework – und das passt immerhin auf einen Bierdeckel.

Scrum passt nicht auf einen Bierdeckel

Allerdings kenne ich auch den anderen Weg. Monatelange Auswahlprozesse für das “richtige” Framework, theoretische Adaption, Anpassung von Software und Prozessen und Mitarbeitergespräche über Mitarbeitergespräche, welche Rolle sie ab Datum x einnehmen, welche Aufgaben dazu gehören und welche Kennzahlen erfüllt werden müssen.

Mittlerweile bin ich davon überzeugt, dass der erste Weg steiniger, jedoch zielführender ist. Denn worum geht es denn eigentlich? Fernab von individuellen Befindlichkeiten, welcher Titel denn nun unter welchem Namen steht und wer am Ende des Tages Anforderungen priorisiert, soll nämlich eigentlich eines im Fokus stehen: der Kunde. Und der Kunde möchte, dass das Produkt seinen Bedürfnissen, seinen Anforderungen, gesetzlichen Normen und gesellschaftlichen Werten entspricht. Doch genau diese Umweltfaktoren ändern sich dauernd. Deswegen versuchen die meisten Firmen agil zu arbeiten: damit sie sich schnell auf sich verändernde Rahmenbedingungen einstellen können, um den Kunden mit ihren Produkten glücklich zu machen.

Doch gibt es dafür ein Rezept? Meistens scheint das 40 Seiten Konzeptpapier ein solches zu sein. Es spricht von “bewährten skalierbaren Frameworks” und zugehörigen Success Stories. Das, neben den ganzen aufgelisteten Zertifizierungen der Umsetzenden klingt vertrauenerweckend.

Back to the roots

Jedoch ist das weit weg von den ursprünglichen Gedanken. Einfach machen. Sehen, dass etwas (nicht) funktioniert und verbessern. Natürlich, keiner muss bekannte Fehler wiederholen, trotzdem sind wir am Ende keinen Schritt weiter, wenn vor der Einführung von agilen Methoden das über ein halbes Jahr akribisch aufbereitete 40 Seiten Konzept steht, wie das denn nun von statten zu gehen hat. Vielleicht haben manche Leser bereits Erfahrungen dieser Art gemacht und miterlebt, wie Agilität über einen Phasenplan eingeführt wurde, der für sich selbst schon das Gegenteil des agilen Manifests darstellt. Bis es vom Konzept für das Management über die Abteilungsleiter zu den Teamleitern bis zu den Mitarbeitern vorgedrungen ist vergeht Zeit und Inhalt. Zeit, weil die Organisation meist vorgegebenen Kommunikationslinien folgt und Inhalt, weil dieser mit jeder Kommunikation weiter konsolidiert wird. Während das Management mit der Genehmigung des nächsten Projekts beschäftigt ist, ist das Thema Agilität bereits ein alter Hut für sie. Währenddessen wird bei den Mitarbeitern wahrscheinlich noch geschult und eingeführt.

Für mich ist nicht die Zahl der Zertifizierungen oder die Perfektion der PowerPoint Präsentation ausschlaggebend. Wie alte Fotos landen sie doch meistens in einer Ablage und fristen dort ihr Dasein, bis ein technischer Umzug oder eine Aufräumfrist dazu führt, dass sie verschwinden. Dennoch sind gewissen Rahmenkenntnisse unausweichlich. Nur mit einer gemeinsamen Sprache kann gegenseitiges Verständnis erzeugt werden. Nur mit einer pragmatischen Herangehensweise an existierende Prozesse, Systeme und Kulturen kann Erfolg erzielt werden. Nur mit Empathie und durch Zuhören können Menschen überzeugt werden. Nur Erfahrung lässt uns praktische Expertise sammeln.

Fazit

Letztlich muss der Kunde im Fokus stehen. Das kann er nur, wenn Unternehmen nicht dauerhaft mit sich selbst beschäftigt sind. Kontinuierliche Anpassungen an sich ändernde Umweltfaktoren schaffen einen Rahmen, in dem kundenorientiert gearbeitet werden kann. Genau deshalb ist “die Einführung von Agilität” kein Projekt, ganz egal ob mit oder ohne Framework. Vielmehr sollte Agilität als Basis die intrinsische Motivation der Mitarbeiter haben, um gemeinsam bessere und schnellere Ergebnisse erzielen zu können. Mit ein bisschen Freiraum, der Schaffung von theoretischen Grundlagen, der Begleitung und ein paar Experimenten gelingt das meistens.