Eine interne IT ist für dieses Szenario prädestiniert: Als Ausrede für irgendwelche nicht erledigten Dinge, planerisches Chaos oder einfach Kopflosigkeit hört man: „Wir sind doch jetzt agil, da kann jeder machen, was er möchte.“. Kommt Ihnen das bekannt vor? Dabei hat Professor Doktor Gunther Dueck in diesem Vortrag auf der re:publica 2016 schon damals sehr schön erklärt, was agil eigentlich bedeutet 😉
(02:45 Min. Gesamtlänge)
Das agile Manifest ist unter Idealbedingungen entstanden
Wer sich mit dem Thema Agilität beschäftigt, weiß, dass es eben eines genau nicht ist: Chaos. Dennoch gelingt es regelmäßig, unter dem Deckmantel der Agilität in etablierten Organisationen Chaos zu stiften. Ein Grund hierfür findet sich zunächst in der organisatorischen Ebene, in der dieses Thema umgesetzt oder „implementiert“ wird. Und diese Ebene ist – in den meisten Fällen – bei den operativen Teams selbst. Selbstverständlich angeordnet „von oben“. Im Grunde eine gute Idee, möchte man meinen. Denn Agilität stellt vor allen Dingen den Kundennutzen wieder in den Mittelpunkt. Und dieser Kundennutzen wird an der Basis selbst erzeugt. Echte Agilität ist allerdings ein gesamtorganisatorischer Transformationsprozess (der im Übrigen niemals endet). Da sich die wenigsten an dieses „große Rad“ herantrauen, probieren sie das erst einmal aus.
Ein Teil des „Dilemmas“ steckt zudem im agilen Manifest selbst. Dieses wurde von freien und nahezu unabhängigen Softwareentwicklern geschrieben. Menschen, die für ein Produkt brennen. Menschen, die für sich selbst stets den besten und optimalen Weg finden wollen, ihre Arbeit zu erledigen. Menschen, die permanent darüber nachdenken, wie sie Dinge besser, effektiver oder effizienter erledigen können. Es waren Softwareentwickler, die ihre bis zu diesem Zeitpunkt angewandten Methoden kritisch – und mit Recht – hinterfragten. Und sie entwickelten gemeinsam Vorschläge, wie sie es besser machen könnten: basierend auf Werten, Prinzipien und Leitsätzen. Zwei dieser genialen Softwareentwickler, Jeff Sutherland und Ken Schwaber, haben schließlich ein sehr praktisches Rahmenwerk entwickelt: das Scrum Framework. Dieses diente fortan als Basis, Nachschlagewerk und Referenz. Wie praktisch! Denn dort sind klare Handlungsanweisungen, Methoden, Events und Artefakte beschrieben.
Die Rahmenbedingungen sind in klassischen Organisationen anders
Schauen wir nun aber in die betriebliche oder unternehmerische Realität, sind die Rahmenbedingungen gleichwohl völlig andere, als sie unsere Softwareentwickler damals selbst vorfanden. Zwar haben auch klassisch organisierte Unternehmen verstanden, dass Wasserfall- oder V-Modelle zur Erstellung neuer Software nicht die besten Ideen sind. Diese Erkenntnis reduziert sich aber allein auf den Entstehungsprozess der Software.
Solche Modelle sind nichts weiter als Methodiken. So wie Scrum auch „nur“ eine Methode ist. Methoden haben den unschlagbaren Vorteil, vor allem in Veränderungsprozessen der Anker schlechthin zu sein. Neue Methoden vermitteln den Anschein, dass allein ein verändertes Tun den gesamten Veränderungsprozess vorantreibt (Doing agile vs. being agile).
Mit der Erkenntnis ausgestattet, die IT agiler zu machen, wird dann zur Erledigung der Arbeit „Top-Down“ angeordnet und auf Scrum umgestellt. Methodisch, selbstverständlich. Damit startet dann meist ein einzelnes IT-Team, denn man will erst einmal schauen, wie das so funktioniert. Bestenfalls haben sich die Mitarbeitenden bereits mit dem Thema auseinandergesetzt. Oder sie wurden und werden aktuell geschult und dürfen das jetzt einfach mal auf Teamebene umsetzen: „Wir machen jetzt Scrum und sind agil.“
Leider funktioniert dieser Ansatz nur bedingt gut. Aufgrund der organisatorischen Schranken kommen die Mitarbeitenden nämlich tatsächlich über einen einfachen Methodenwandel nicht hinaus. Wer möchte sich bitte schön von der internen, meist eher konservativ wahrgenommenen IT vorschreiben lassen, wie Projekte abzulaufen haben?
Zudem basiert das über allem schwebende Prinzip des Inspect & Adapt auf einer sehr wichtigen, ja erfolgskritischen Rahmenbedingung: der Freiwilligkeit. Zum „Agil-tun“ lassen sich die Menschen auf methodischer Ebene anweisen. Agile zu sein ist eine innere Einstellung, eine Haltung. Und diese verändert sich nur, wenn die Akteure es freiwillig möchten.
Organisationen hochregulierter Branchen haben eine weitere Herausforderung: ihre eigene DNA
Es geht also vor allen Dingen darum, den richtigen Rahmen für die agile Umsetzung bereitzustellen. Insbesondere in Unternehmen, die einer sehr starken Regulatorik unterliegen, ist Prozesskonformität (bis hin zur Zertifizierung) in die DNA der Organisation übergegangen (zum Blogartikel Innovationsbremse Regulatorik). Dies basiert auf einer exakten Planbarkeit von Input und Output eines definierten Prozesses. Methodisch werden Dinge präzise und bis in das kleinste Detail beschrieben und gehen dann in den nächsten Prozessschritt über. Dort ist alles haarklein dokumentiert und damit auch prozesskonform.
Diese Prozesskonformität ist über die Jahre in das Denken und Handeln der Akteure in den Organisationen übergegangen. Definierter Input, definierter Output. Und genau deshalb wurden noch vor einigen Jahren die Fachverantwortlichen damit gequält, Fach- und Feinkonzepte zu schreiben (die dann keiner gelesen hat), und im Anschluss eine sehr lange Zeit damit beschäftigt, den vor irgendwann einmal beschriebenen Output herzustellen. Für einen zertifizierten, strukturierten und stabilen Prozess klappt das wunderbar. Handelt es sich um instabile Rahmenbedingungen und vielleicht noch dynamische Technologien, wird genau dies sehr schwierig.
Die Fachverantwortlichen entledigen sich ihrer Arbeit
Da nun das Schreiben von Fach- und Feinkonzepten, insbesondere bei agilen Vorgehensweisen wegfällt, entledigen sich die Fachkollegen oftmals nun sehr gern dieser Schreibarbeit („Wir machen das jetzt agil“). Dies ist methodeninhärent auch in Ordnung. Die erweiterte, oftmals damit einhergehende Hoffnung ist allerdings, dass die hauptsächliche Arbeit nun auf der Entwicklungsebene stattfindet. Das aber ist eine grundlegend falsche Annahme. Denn auch Fach- und Feinkonzepte hatten etwas Gutes: Der betriebswirtschaftliche Prozess musste einmal mehr durchdacht und zumindest beschrieben werden.
Wenn das in heutigen, agilen Vorgehensweisen nicht mehr getan wird und sich die Fachbereiche ihrer Arbeit entledigen, ist die IT mit der Umsetzung auf verlorenem Posten. Zwar sind in der Entwicklung nach agilen Werten und Prinzipien Änderungen willkommen, diese betreffen in ihrer Ursprungsform und nach den Gedanken ihrer Väter aber evolutionäre, explorative Prozesse – ob und wie mein Kunde eine neue Funktionalität annimmt oder ob meine Hypothesen stimmen. Dies impliziert einen Hunger nach Feedback und einer grundlegenden Haltung, Änderungen an meinen eignen Annahmen zu machen. Macht jedoch ein Fachkollege schlichtweg seine Hausaufgaben nicht, ist das nicht nur einfach ärgerlich. Es führt letztendlich zu Frust und zu genau jenem angesprochenen Chaos. Diese Fachverantwortlichkeit und dieses Ownershipment muss daher konsequent eingefordert und gelebt werden. Gerade in diesen Bereichen sind die Beteiligten umfangreich zu befähigen.
Das Märchen vom internen Kunden
Das zentrale Element im Agilen sind nicht Geschwindigkeit, iteratives Vorgehen, ein fluides Backlog oder ein Daily am Morgen. Dies sind alles nur Methoden oder Werkzeuge. Sie allein machen Agilität nicht aus. Das zentrale Element im Agilen ist der Kunde. Größtmögliche Kundenzentrierung ist die oberste Prämisse. All die dort aufgeschriebenen Dinge dienen einem einzigen, höheren Zweck: Den Nutzen für unseren Kunden permanent zu maximieren. All die agilen Methoden, ob Scrum, Kanban, Design Sprints und wie sie alle heißen, zielen genau darauf ab: Nutzenmaximierung unter volatilen, unsicheren und komplexen Rahmenbedingungen.
Die innerbetriebliche Realität jedoch ist: Mein Kunde ist in Wirklichkeit mein Kollege. Das ist und wird nie eine echte Kunden-Dienstleister-Beziehung. So sehr man sich das Konzept des „internen Kunden“ auch wünscht. Der echte Kunde braucht und hat ein vitales, ökonomisches Interesse, eine echte innere Triebfeder, an dem, was er tut und erreichen will. Und ein echter Dienstleister hat ein ebenso vitales und ökonomisches Interesse, seinem Kunden einen Nutzen zu stiften und ihn glücklich zu machen. Damit spreche ich nicht ab, dass dies tatsächlich innerbetrieblich auch einmal vorkommt – es ist allerdings nicht der Regelfall. Hier werden die Aufgaben oftmals noch immer Top-Down verteilt. Die Mitarbeitenden erledigen diese Dinge, weil es Ihre Aufgabe ist, und nicht, weil sie davon im Innersten und intrinsisch davon überzeugt sind.
Three Key-Take-Aways
- Das agile Manifest ist unter Idealbedingungen einer Kunden-Dienstleister-Beziehung entstanden, die betriebliche Realität ist anders.
- Eine in der Unternehmens-DNA fest verankerte Prozesskonformität steht einer agilen Organisation entgegen.
- Einer Kultur des Agile-Cherry-Picking sollte in jedem Fall vorgebeugt werden.
Weiterführende Links
- Zum Blog von Andreas Diehl über das Agile Manifest https://digitaleneuordnung.de/blog/agiles-manifest/
- Scrum Framework https://www.scrum.org/resources/scrum-guide
- Zum Blog von Andreas Diehl über VUKA https://digitaleneuordnung.de/blog/vuca-welt/
