Agil arbeiten oder agil sein

Es begab sich zu der Zeit, fast 18 Jahre ist es her, da gingen die Gebote aus, dass alle Softwarewelten verbessert würden. Und so machten sich siebzehn erfahrene und prominente Softwerker auf, die Welt der Softwareentwicklung zu verbessern. Sie  gaben uns das agile Manifest mit zwölf goldenen Prinzipien. Auf dass hochwertigere, qualitativ bessere, an den Kunden orientierte Software entstehe. Das Richtige zu tun und das Falsch zu lassen. Viele Softwareentwickler nahmen einige der Punkte dankbar an. Der Interpretationsspielraum ließ durchaus die Deutung zu, eine Methodik zu haben, die Entwickler von einigen lästigen Dingen entlastete, bspw. Dokumentation.

Seit damals hat sich Einiges getan. Die Verwendung agiler Techniken ist nach Abflauen des ersten Hypes auf eine Weise vorangeschritten, die viele Unternehmensführungen veranlasste, die Anwendung von Agilität als Marketing-Instrument zu nutzen: “Wir sind agil” erst als Unique Selling Factor und in Zeiten breiter Adoption heute als “Wir sind es auch”.

Die Welt ist also, was Softwareprodukte angeht, endlich ein großes Stück besser geworden. Sollte man meinen. Tatsächlich hält sich das Gerücht hartnäckig, nach agilen Prinzipien zu arbeiten, wäre gleich bedeutend mit “agil sein”. Nein, das ist es nicht. Es ist keine Frage von Sein oder Nichtsein. Es geht um die Verinnerlichung von Mindsets, die in mehr oder weniger Köpfen verankert sind oder auch nicht. Tatsächlich gibt es aus gutem Grund keine Definition von irgendeiner messbaren Art an Agilität, die einem Unternehmen erlauben würde, sich agil zu nennen. Es würde auch nicht funktionieren, denn des gibt nämlich noch die Sache mit der Evolution.

Die Evolution

In den letzten 18 Jahren hat die Softwarewelt große Sprünge gemacht. Die Komplexität von Software und der umgebenden Ökosysteme ist gewaltig gestiegen. Die Ansprüche an Software und ihre Schnittstellen sind gewachsen. Wir entwickeln nicht mehr nur Webshops mit Datenbank und Frontend, wir entwickeln komplexe Embedded Systems in Luftfahrt, Medizin oder Automotive mit Anbindung an Backends, Cloud, verteilte UIs und lassen diese mit anderen Systemen kommunizieren. In der Folge kommt es zu einer Explosion der Zahl der Stakeholder und zahlreiche Projekte kommen mit irgendeiner Art von gesetzlicher Regulatorik und unzähligen regulatorischen Anforderungen in Berührung. Safety, Security, DSGVO usw.

Software ist mittlerweile überall und übernimmt Aufgaben, die vorher elektronisch und mechanisch gelöst wurden. Viele Softwareprodukte sind abhängig von paralleler Hardwareentwicklung. Sie kennen das, der Spaß beginnt erst dann richtig, wenn die Software versucht, sich auf einer Hardware zu integrieren, die sich noch im Prototypenstadium befindet und man der Geschäftsleitung erklären muss, warum die Softwareentwickler nicht für das nächste Projekt zur Verfügung stehen, obwohl sie eigentlich fertig sein sollten. Nur ist eben die Integration erst in drei Monaten abgeschlossen. Wahrscheinlich. Hoffentlich. Vielleicht.

Das reale, agile Leben

Und an diesem Punkt stellen wir fest: So einfach ist das mit der Agilität bei weitem nicht. Die agile Entwicklung ging bei ihrem Start von einem Modell aus, das 2001 noch aktuell war: Softwareentwicklung ist ein in sich geschlossener Prozess, der am Ende Eines liefert: Software.

Im Laufe der Evolution hat sich das Ganze verwässert. Wir sehen heute Teams, die agile Prinzipien adoptiert haben: Test Driven Development, Daily Standups, Retrospektiven und mehr. Diese bilden allerdings innerhalb ihres Corporate Eco-Systems eigene Inseln der glückseligen Agilität in einem Meer konservativer Strukturen und Prozesse. An den Stellen, an denen äußere traditionell strukturierte Einflüsse nach innen schwappen, kommt es zu Konflikten und das Gebilde fällt in sich zusammen. Selbst dann, wenn innerhalb der Teams ein vollständig agiles Mindset vorherrschen würde.

Agilität braucht einen klaren Rahmen, dessen Grenzen und Schnittstellen nach außen klar gezogen werden müssen. Und dann haben Scrum Master und Product Owner gemeinsam die undankbare Aufgabe, diesen Rahmen nach innen und außen zu vertreten. Die Teams wollen (zu Recht) Story Points, das Management (zu Recht) Zeit und Kosten. Der Kunde will nicht alle zwei Wochen zum Sprint-Review antanzen, die Testinfrastruktur ist kompliziert und teuer, und die QA ist deswegen nicht auf kurze Zyklen ausgelegt. Regulatory will bedient werden und Deliverables an jedem Sprintende sind umfangreich, wenn man der Prämisse folgt, dass zu Runnable Software auch mehr gehören kann als nur Code. Eigentlich sollte nach jedem Sprint ein Gesamtpaket vorhanden sein. Ein halber Tag für Retrospektive? “Wer bezahlt das von welchem Budget?” – fragt das Controlling und der ehemalige Projektleiter vermisst bereits seine Gantt-Charts, in denen doch alles so schön sequentiell sauber geordnet war.

Die gesamte Situation wird ultimativ durch den Gedanken verstärkt, die agile Transformation ließe sich durch ein simples Rollen-Mapping implementieren. Auf einmal hat der zum Product Owner gekürte Produktmanager einen noch volleren Terminkalender als früher, da er mit dem Team und allen anderen reden muss. Kommunikation ist zwar gemeinhin das A&O, für einige Beteiligte scheint es dennoch ein eher neues Konstrukt zu sein, denn plötzlich stellen Teams und Teammitglieder Fragen und erwarten sogar zügige Antworten. Frechheit. Diese unverschämten Lümmels. Früher hat man sie einfach arbeiten lassen und nach drei  Monaten das Ergebnis erhalten.

Das agile Leben kann ganz schön anstrengend sein!

Die Agilität in den Köpfen

Der agile Gedanke, so richtig er auch ist, so sinnvoll er auch konzipiert wurde, ist im Begriff, seinen guten Ruf zu verlieren, da sich der ursprüngliche Payoff nicht auszahlt. Das liegt nicht am Gedanken selbst, sondern an der Vielzahl schwacher bis hin zu fehlerhafter Implementierungen und dem Versäumnis, der gestiegenen Komplexität Rechnung zu tragen.

Nur wenige Unternehmen haben es geschafft, die Betrachtung auf eine ganzheitliche Weise durchzuführen. Die Adoption auf eine breite Ebene zu stellen, damit der Payoff auch tatsächlich kommt. Und zwar von oben nach unten. Das Mindset in die Köpfe der Mitarbeiter zu bringen und, ganz wichtig, es dort zu halten. Und das ist ein konstanter Prozess des Coachings und der Nachjustierung. Das ist eine der wesentlichen Erkenntnisse, die ich in den letzten 25 Jahren gewonnen habe. Frühzeitig zu erkennen, wo es nicht passt. Die Mitarbeiter und Kollegen mitzunehmen. Den Blick von außen zuzulassen und vor allem, sich nicht auf die eigene Erkenntnis zu verlassen, alles richtig zu machen.

Komplexe Herausforderungen erfordern komplexe und originelle Lösungen. Auch wenn Teams sich selbst organisieren, die Integration in ein größeres agiles Ökosystem gibt ihnen die Möglichkeit, aus ihrer Isolation heraus zu kommen und wieder Teil eines Ganzen zu werden, während das Unternehmen davon profitiert, auf vielen Ebenen schlanker und effizienter agieren zu können. Dass Unternehmen niemals agil sein können, ist hierbei keine schlechte Nachricht. Vielmehr können sie im großen Maßstab von der Nutzung agiler Prinzipien – zugeschnitten auf ihr Unternehmen – profitieren, in dem sie eine einheitliche agile Kultur entwickeln, mehr interdisziplinären Zusammenhalt durch Stakeholdermanagement schaffen und die Identifikation mit den Produkten stärken.

Dies anzupacken und die agilen Prinzipien in dieses Jahrzehnt zu bringen, wird sich dann für die Unternehmen auszahlen, wenn wir das Mindset dort implementieren, wo es hin soll: In die Köpfe aller Beteiligten.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Oliver Fels hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.