Fehlgeschlagene Scrum-Einführungen gibt es zuhauf, vor allem in größeren Softwareorganisationen, und vor allem in Organisationen, die schon lange bestehen. Warum ist das so? Und muss das wirklich so sein? Wie ginge es anders?

Überlebende Organisationen

Ein Unternehmen, das schon eine ganze Weile am Markt besteht und Software baut, tut ja genau dies: es besteht schon eine ganze Weile am Markt. So falsch kann das also nicht gewesen sein, was in der Vergangenheit bis in die Gegenwart hinein getan wurde. Mit Fug und Recht praktizieren Mittelmanagement und Mitarbeiter etablierte Vorgehensweisen. Vielleicht gab es ja einen Ausflug in Scrum, aber dann eben nur die reinen Entwicklungsteams, und die mussten feststellen, dass das nicht so wirklich etwas bringt, wenn sie allein in Scrum rumrühren.

So hat sich die Entwicklungsorganisation vielleicht einige Aspekte herausgegriffen, die oft auch in Scrum-Organisationen vorkommen. Ich schreibe absichtlich von Aspekten, die auch vorkommen, nicht Aspekten von Scrum, weil das zwei verschiedene Dinge sind. So finden sich Ticketsysteme, meist JIRA, um anstehende Entwicklungsaufgaben zu verteilen (sic!). So finden sich Build-Server, auf denen neu erstellter Code entweder nächtlich (Nightly Build) oder kontinuierlich (Continuous Integration) integriert und getestet wird. Wie umfassend und gut Nightly bzw. Continuous Integration für die Software laufen, hängt davon ab, wie wichtig frühe Softwarequalität für die Entwicklungsteams ist.

So richtig agil fühlt sich das für die Teams noch nicht an, weil viele Stücke des Codes schon ziemlich lange existieren, die ganze Architektur nicht gerade änderungsfreundlich ist, und weil jedes Softwaremodul wieder von vielen anderen Modulen abhängt, die andere Teams betreuen. Die Softwaretests abseits der Continuous Integration werden von wieder ganz anderen Teams durchgeführt, weil sie so zeitaufwändig sind.

Wenn es kundenspezifische Software ist, liefert die Organisation vielleicht sogar alle zwei, vier oder acht Wochen Software an den Kunden aus, aber irgendwie mit einem flauen Gefühl, weil alle wissen, was alles nicht gemacht oder nicht getestet wurde.

Produkte oder auch Projektergebnisse liefert die Organisation dann, wenn sie halt soweit ist. Das kann früher oder später sein, manchmal auch bis zu Terminen, die mit wichtigen Kunden abgestimmt sind. Ausgelieferte Software ist hier manchmal auch bei Produkten für den jeweiligen Kunden konfiguriert, ein spezieller Software-Build. Bisweilen ist die Grenze zwischen Produktsoftware und kundenspezifischer Software also fließend.

Oder aber die Exekutiv-Ebene spricht davon, die Leute „ins Boot zu holen“[1] und ihnen das passende Mindset zu verpassen wollen. Mindset ist jedoch als Bearbeitungsziel ungeeignet, denn „Kreativität ist eine Handlung, kein Gefühl“.[2] [3]

Warum überhaupt agil werden müssen?

Eine mit agiler Softwareentwicklung arbeitende Organisation ist kein Selbstzweck. „Wir müssen agiler werden“ ist an sich nicht unbedingt eine wahre Aussage, wenn sie von einem Vorstandsmitglied getroffen wird. Denn wieso müssen? Und wer ist überhaupt wir? Was ist mit agiler gemeint? Agiler als was?

Wenn Kunden der Ansicht sind, ein Softwarelieferant müsse agiler werden, dann kann es durchaus sein, dass sich der Kunde wünscht, dass seine Änderungswünsche rascher umgesetzt werden. In dem Fall wünscht sich der Kunde dann durchaus mehr Agilität, ja. Das trifft auch dann zu, wenn der Kunde gar keine Änderungswünsche per se hat, also keine Wünsche, die die Kundenorganisation nicht schon von Anfang an hatte und die die Software derzeit eben nicht befriedigt.

Wir müssen agiler werden ist also unspezifisch und oft nicht auf den Markt gerichtet, sondern wird als rein interne Referenz verwendet.[4] Schlimmer noch, wenn die Einführung von agilen Frameworks von ganz oben verordnet wird, sind das starre Regeln, und diese „hebeln das Denken aus“.[5]

Die Frage ist also: Wieso müssen wir agiler werden? Was ist die Annahme, die auf eine Notwendigkeit einer agilen Transformation hinweist? Und woher wissen wir, wie agil wir jetzt sind und wie agil wir werden „müssen“? Das kling alles sehr unspezifisch.

Wieso also sollte eine Softwareorganisation agiler werden wollen oder müssen? Was ist der Marktdruck, der dieses Müssen verursacht? Da gibt es mehrere Möglichkeiten:

• Kunden möchten oder brauchen schnellere Lieferungen nach ihren Anfragen, schnellere erste Lösungen.
• Wettbewerber liefern vergleichbare Leistungen in flotterer Abfolge, und das bei gleichen oder geringeren Preisen.
• Kunden wünschen sich bessere Reaktionsfreudigkeit auf Änderungswünsche, weil sich das im Moment immer arg zieht.
• Ausgelieferte Neuigkeiten in der Software werden von Kunden schlecht angenommen, weil die Notwendigkeit für die Features schon nicht mehr gegeben sind.
• …und vieles mehr.

Es ist sehr wahrscheinlich, dass bei den meisten Kunden eine Gemengelage aus verschiedenen Gründen für einen agiler agierenden Softwarelieferanten besteht, aber die Zusammensetzung ist bei jedem Kunden anders.

Was also ist der überbordenden Grund für einen Entscheidungsträger im Unternehmen, die Notwendigkeit für Agilität auszurufen? Und was bewirkt das überhaupt, Agilität als Zielbild auszurufen?

Wieso überhaupt agil? Und wieso verordnen?

Und das ist die zweite Frage, mit etwas anderer Betonung. Wieso überhaupt agil? Und wieso muss das jemand von deutlich oberhalb oder außerhalb der Ausführungsebene verordnen?

In einer Wissensgesellschaft darf die Führungsebene davon ausgehen, dass die Ausführungsebene samt Mittelmanagement sich ziemlich gut auskennt, auf welche Weise ein Job ganz gut ausgeführt werden kann. Schlimmer noch: eine methodische Bevormundung von oben wird oft als Eingriff in die Methodenautonomie angesehen, und letztlich kann man es immer wie einen Unfall oder unglückliche Umstände aussehen lassen, wenn eine Einführung von bestimmten Methoden nicht funktioniert. Den Nachweis zu führen, dass das bei uns eben nicht funktioniert, ist stets möglich.

Machen wir uns nichts vor: Agilität ist in der Regel nicht das, was das Top-Management wirklich will.[6] Das ist auch völlig in Ordnung, denn agil an sich ist ja kein Geschäftserfolg, sondern nur das, was daraus erwächst. Was die Organisation will, ist überleben, wachsen, Erfolg am Markt haben. Wenn es dafür Agilität braucht, schön. Wenn es ohne geht, auch schön.

Es gilt die Prämisse der Führung: Du kannst Spezialisten entweder sagen was das Ergebnis ihres Tuns sein soll, oder aber wie sie arbeiten sollen. Spezifiziere ich beides sehr eng, werde ich Konfusion oder gar Insubordination ernten.[7] [8]

Ziele setzen statt Methode bestimmen

Da das Management eine sehr gute Vorstellung haben muss, was denn das Unternehmen an Wertschöpfung leisten soll, ist darin auch die Zielvorgabe gesetzt. „Am Ende reden wir nicht über Agilität, sondern über Wertschöpfung[…]“[9] Als logische Konsequenz ist Zurückhaltung angesagt, was das Wie angeht. Denn wenn ich Mitarbeiter unmündig behandle, werden alle die, die sich nicht als unmündig empfinden, früher oder später das Unternehmen verlassen, und dem Unternehmen die kreative Schaffenskraft entziehen, die besonders in der Software dringend benötigt wird.

Das Top-Management sollte, statt bestimmte Methoden zu verordnen, also begründete Zielvorgaben machen. Rein intern motivierte Zielvorgaben, die nicht auf externen Erfordernissen gründen, werden von der Organisation nicht goutiert und tendenziell unterlaufen.

Die Methode und die Art und Weise, wie das Ergebnis erreicht wird, findet die findigen Köpfe in der Organisation schon heraus. Scrum und andere agile Frameworks und Methoden sind ja mittlerweile hinlänglich bekannt und dank Anwendungsratgebern[10] auch eigentlich verstanden. Sobald also Anforderungen bestehen, die eindeutig genug sind, so wird die Organisation entsprechende Veränderungen an der Arbeitsweise vornehmen. Diejenigen Menschen in der Organisation mit der informellen Macht, Methoden vorzuschlagen und auch einzuführen, werden mit großer Wahrscheinlichkeit auf eine gute Lösung kommen.

Wenn Sie dieses Vertrauen nicht aufbringen können, dann haben Sie ein ganz anderes Problem, denn dann arbeiten nicht die richtigen Leute im Unternehmen.

Mögliche Ziele

Das schöne an Zielvorgaben ist ja, dass der Weg dahin offen bleibt, auch wenn ganz viele Teams und Organisationen auf den gleichen, oder zumindest ähnliche Lösungswege kommen werden.

Statt nun also die Einführung von Scrum, SAFe, LeSS oder ähnlichem von höchster Stelle zu fordern, geben Sie als Marschziel vor, was Sie als Effekt von agilem Arbeiten erwarten würden und was tatsächlich Relevanz für ihr Unternehmen hat.

Damit verbunden ist auch, die Ziele relativ einfach und konkret zu halten, so dass alle wissen, um was es geht, und die Art und Weise der Lösung zu delegieren.[11] [12]

Es folgen zwei Beispiele. Diese haben weder den Anspruch, vollständig zu sein, noch allgemeingültig. Doch hoffentlich sind sie hilfreich und regen zum Nachdenken an.

Lieferfrequenz

Wir liefern unsere Software alle zwei Wochen, immer am selben Wochentag, in Form eines vollständig qualitätsgeprüften Release an unsere Kunden aus. Diese Lieferfrequenz gilt ab in zwei Monaten. Die ersten vier Releases können noch interne Releases sein.

Haben Sie jetzt bereits eine Lieferfrequenz von vier, drei oder zwei Wochen, so setzen Sie als Ziel eine Lieferfrequenz von einmal pro Woche, zwei oder drei Mal pro Woche, oder gleich jeden Tag.

Die Lieferfrequenz muss sich freilich durch einen Kundennutzen begründen lassen. Hoffentlich erzielen Sie ja mit Ihrer Software ohnehin einen Kundennutzen, und jedes neue Feature hoffentlich auch. Bekommen Sie also ein neues Feature früher in die Hände der Kunden, haben diese auch früher einen Nutzen davon, entweder, weil sie die Funktionalität produktiv einsetzen können, oder Ihre Software selbst wiederum integrieren mit anderer Software. Auch deren Möglichkeit, schneller und vor allem früher herauszufinden, ob und wo noch Integrationsprobleme mit deren eigener Umgebung bestehen, ist selbst auch wieder ein Kundennutzen.

Die Lieferfrequenz als Zielvorgabe hat einen wunderbaren Vorteil für die eigene Organisation: Alle relevanten Bereiche der ausführenden Softwareentwicklung, also Herunterbrechen der Kundenanforderungen auf Softwareanforderungen und Aufteilung auf Teams, Konfigurationsverwaltung, Integration, Softwaretest, Verifikation, Release-Packaging, erfordern damit ein Umdenken, weil sehr wahrscheinlich die bestehenden Strukturen diesen deutlich höher frequenten Turnus nicht erfüllen können.[13]

Sie geben mit der Frequenz also einen Änderungsimpuls, weil ein weiter wie bislang, nur mit mehr Dampf nicht mehr zieht. Deswegen darf die Frequenzänderung auch nicht nur graduell sein, also nicht einfach etwa von 6 auf 5 Monaten. Die Änderung muss drastisch sein, aber freilich noch sinnig.

Mit der Frequenzänderung bekommen Sie die Notwendigkeit für Continuous Integration gleich frei Haus. Lediglich manuelles, sporadisches Testen ist dann nicht mehr möglich. Die Frequenzänderung wird früher oder später ganz viele unnötige manuelle Schritte eliminieren, und von den verbleibenden Arbeitsschritte wird die Organisation ganz viele automatisieren müssen. Denn, und auch das müssen Sie klar machen, soll das Ganze ja im eingeschwungenen Zustand ohne Mehrbelastung von Mitarbeitern von statten gehen.

Durchlaufzeit von Anforderungen

Neue Kundenanforderungen werden zu 50% innerhalb von 10 Wochen in der fertigen Software geliefert, zu 25% innerhalb von sechs Monaten geliefert, und für 25% wird ein Zeitraum angegeben, in dem eine Realisierung zu erwarten ist. Wird eine Kundenanforderung abgelehnt, so geschieht dies binnen 2 Wochen nach Eingang.

Diese Ergebnisforderung hat ebenfalls den Aspekt der Lieferung in sich, geht jedoch noch ein Stück weiter, indem sie die gesamte Wertschöpfungskette (Value Stream) betrachtet. Software entsteht nunmal nicht allein durchs Programmieren und Ausliefern, sondern durch Anforderungen.

Besonders Organisationen, die sich schwer tun mit der Priorisierung von Anforderung, die mit unklaren Umfängen kämpfen, mit verspäteten Change Requests, mit davon galoppierenden Kosten, mit wuchernden Anforderungskatalogen in nicht so ganz klaren Zuständen, sie werden eine große positive Änderung verspüren, wenn das Ergebnis von Anforderungsarbeit klar gemacht wird: Anforderungen sind ja kein Selbstzweck, sondern münden entweder in Software, oder in eine Diskussion mit dem Kunden, dass und wieso eine Anforderung nicht umgesetzt wird.

Besonders der letzte Teil wird oft vernachlässigt. Je nach Art der Beauftragung kann es sein, dass Anforderungen, die nicht explizit abgelehnt werden, ab einem bestimmten Zeitpunkt automatisch als angenommen gelten und somit umgesetzt werden müssen. Genau deshalb muss auch das Zurückweisen von Anforderungen mit in die Ergebnisdefinition, und zwar auch mit einer zeitlichen Vorgabe. Auch der Kunde wird es schätzen, wenn schneller Rückmeldungen auf neue Anforderungen zurückkommen, selbst wenn diese abschlägig ausfallen sollten.

Damit nun nicht nur die Diskussionszeit oder Verarbeitungszeit von Anforderungen berücksichtigt wird, sondern auch die Zeit, bis eine Anforderung überhaupt erst erfasst ist, steht in der Forderung nach Eingang.

Die Prozentwerte können freilich abgewandelt werden, ich empfehle lediglich, eine geeignete Abstufung zu verwenden. Nicht alle Anforderungen können rasch umgesetzt werden, aber auch nicht alle Anforderungen setzen eine längere Änderung der Architektur voraus. Sinn ist ja auch hier wieder, dass die Zielsetzung so gewählt ist, dass einfach ein Stückchen schneller als jetzt nicht mehr reicht. Die Art und Weise, wie mit Kundenanforderungen verfahren wird, soll ja geändert werden, und das eben nicht durch Direktive von oben, sondern aus der Organisation heraus selbst.

Messen statt Mindset

Sie müssen messen. Und zwar externe Referenzen,[4] und wenn nicht direkt externe Referenzen wie etwa Umsatzerfolg, Produkterfolg usw., dann solche Messwerte, die so nah an der externen Referenz wie möglich liegen. Es ist ein hehres Ziel, die Agilität eine Organisation messen zu wollen, etwa mit Mitarbeiterumfragen oder ähnlichem, nur leider geht es am Kern vorbei und ist sogar schädlich.[14] [15] Denn die Frage ist ja nicht, wie sich Handwerkerïn oder Künstlerïn – das dürfen Sie sich aussuchen – mit dem Werkzeug fühlt, sondern welches Ergebnis sie damit erzielen, und welches Ergebnis am Markt sie mit diesem Werkzeug erzielen. Es ist schon klar, dass mit einem guten Werkzeug, das sich gut anfühlt, lieber gearbeitet wird und damit auch mehr Bindung entstehen kann. Sonst gäbe es keine schöneren oder weniger schönen Laptops. Aber ich kann, um wieder zurück zu kommen, nicht direkt auf das Mindset einwirken, weil das Mindset ein Ausdruck der Kultur und damit eine „nicht entscheidbare Entscheidungsprämisse“ ist.[16]

Indem Sie also stattdessen Messwerte erheben wie Lieferfrequenz oder Durchlaufzeit, sind Sie viel näher am tatsächlichen Ergebnis der Organisation und drücken dieser damit Ihr Vertrauen als Top-Führungskraft aus, den Weg zum Ziel besser einschätzen zu können als die Exekutivebene.[17] Für umfassende Problemlösung gilt nunmal das „Primat der Daten“[18] [19], wobei das freilich keine Quatschdaten sein dürfen. Vorgelagert zu Lieferfrequenz und Durchlaufzeit kann es viele weitere Messwerte geben, das müssen aber Daten zum Lernen sein, nicht Daten für Inspektionen (“distinguish[es] “data for the purpose of learning” from “data for the purpose of inspection.” […] Using data for inspection is so common that leaders are sometimes oblivious to any other model.”[18]).

Implikationen auf HR und Strukturänderungen

Die Implikationen für organisatorische Veränderung sind jedoch dennoch gravierend. Denn egal, ob Sie als oberste Führungskraft beispielsweise Scrum verordnen, oder ob Teams selbst auf Scrum oder ähnliches wechseln wollen: Die Teams werden auf der einen Seite Scrum Master benötigen, also laterale Führungskräfte mit viel Einfluss, aber wenig formaler Macht. Auf der anderen Seite werden Sie so manche disziplinarische Führungskraft nicht mehr in genau dieser Rolle benötigen. Das Personalwesen, also HR, kann und muss bei diesem Übergang eine helfende, tragende Rolle übernehmen, indem Angebote zum Übergang gemacht werden, materielle und immaterielle Ängste und Nöte sowohl ernst genommen als auch konstruktiv adressiert werden.[20]

Eine große Organisation, die ich bereits beraten durfte, hat, als sich ein umfassender Sog hin zu Scrum ganz klar abgezeichnet hat, alle disziplinarischen Teamleiter zu Scrum Mastern weitergebildet und umfunktioniert. Selbst im Angesicht des Risikos, dass ehemalige disziplinarische Führungskräfte möglicherweise auch in der lateralen Rolle versuchen, über direkte Anweisungen quasi an ihre Teamleitervergangenheit anzuknüpfen, finde ich diese Lösung sehr clever. Denn zum einen macht sie ernst mit der neuen Arbeitsweise, indem alte kleinhierarchische Teamstrukturen aufgelöst werden. Zum anderen nutzen ehemalige Teamleiter als Scrum Master auch den Umstand, dass Führungskräfte ja eben auch nach außen aus dem Team heraus führen können und damit die Impediments, also die organisatorischen, strukturellen Probleme, die die Teams vom Entwickeln abhalten, zu adressieren und lösen zu helfen.[21]

Dieser Abschnitt macht hoffentlich auch klar: Auch, wenn ich voll und ganz hinter dem Gedanken stehe, dass Organisationen von innen heraus den Wechsel des Entwicklungsparadigmas antreiben sollten, und dass dieser von außen lediglich durch eine Ergebnisforderung getriggert werden sollte, so bin ich auch der Ansicht, dass das Unternehmen jegliche Veränderung als Katalysator fördern sollte. Denn es ist auch ganz klar, dass sich viele Vorteile hauptsächlich dann ergeben, wenn alle Teile der Organisation mehr oder weniger das gleiche Paradigma umsetzen. Das bedeutet nicht, dass alle Verfahrensweisen genau gleich sein müssen, aber wenn sich abzeichnet, dass alle Lieferteams auf eine Spielart von Scrum gehen und gehen wollen, dann sollte die Gesamtorganisation dabei helfen, das tatsächlich möglich zu machen und eine entstehende Schattenorganisation zur dokumentierten Organisation zu machen.

Veränderung der Organisation braucht einen Grund und ist stetig

Agilität (engl. agility) war ja nur einer der Begriffe, den die Autoren des ursprünglichen Agilen Manifests [22] zur Wahl hatten. Anpassungsfähigkeit (engl. adaptability) war ein anderer, den ich rückblickend betrachtet für unmissverständlicher halte.

Ich muss also als obere Führungskraft, meiner Organisation, die ich gerne anpassungsfähig hätte, nicht ebendiese Anpassungsfähigkeit absprechen, indem ich bestimmte Änderungen von oben verordne, sondern ich kann genau diese Anpassungsfähigkeit – Agilität – fördern, in dem ich den Grund für eine Veränderung unmissverständlich klar und zur Vorgabe mache. Denn Agilität und Macht sind in einer Organisation ja nicht unabhängig voneinander.[23] Agilität mit den Mitteln starrer Macht einzufordern untergräbt das Ansinnen.

Versuchen Sie also gar nicht erst, Agilität durch das genaue Gegenteil einzuführen. Diesen Double Bind,[24] [25] diese kognitive Dissonanz, die Sie dadurch erzeugen, wird mit hoher Wahrscheinlichkeit einen Fehlschlag verursachen.

Führen Sie Agilität durch die Notwendigkeit zur Agilität ein, nicht durch die Methoden.

Tags

Scrum, SAFe, Agilität, Agile, Transformation, Change, Management, Change Management, Leadership, Unternehmensführung, Selbstverwirklichung, Zukunft der Arbeit.

Foto: Dr. Joachim Schlosser Fotografie