Ist Agilität gleich Chaos?
Mittlerweile wollen viele Organisationen agil werden. Der Wandel zu einer agilen Organisation ist jedoch ein großer Schritt und gelingt nur mit großen Veränderungen in der Organisationsstruktur und Arbeitsweise. Im folgenden Artikel möchte ich den Begriff „agil“ vom heutigen Standpunkt aus erläutern und Ihnen zeigen, dass eine agile Arbeitsweise Chaos vorbeugt und nicht verursacht.
Was bedeutet agil?
Nun aber erstmal zur Grundfrage: Was bedeutet eigentlich „agil“? Das Wort „agil“ und auch die Agilität gibt es schließlich nicht erst seit 2001, als das agile Manifest der Softwareentwicklung niedergeschrieben wurde. Im Duden steht „von großer Beweglichkeit zeugend; regsam und wendig“. Im Videospiel Pokemon gibt es die Attacke Agilität schon seit der 1. Generation, die im Februar 1996 in Japan erschienen ist. Die Attacke steigert die Initiative eines Pokemons stark und sorgt so dafür, dass es in diesem rundenbasierten Spiel zuerst angreifen darf. Ausgehend von Duden und Nerdtum wird also „agil“ mit Beweglichkeit und Geschwindigkeit assoziiert. Oft wird „agil“ aber auch mit ständiger Veränderung oder sogar erlaubten Regelverstoß assoziiert.
Es entstehen nun Bilder, dass nun jede:r für sich selbst verantwortlich ist und machen kann, was er:sie will. Derartige Verhaltensweisen sorgen aber eher für Chaos und haben nicht viel mit einer agilen Organisation gemeinsam. Agilität steht nämlich nicht für ständige Veränderung, sondern ist vielmehr die Antwort auf eine Umwelt, die sich ständig verändert. Die sich ständig veränderte Welt wird auch gerne VUCA-Welt genannt. VUCA steht hier für Volatility, Uncertainty, Complexity und Ambiguity. Im Deutschen kannst du aber auch VUKA sagen, was dann Volatilität, Unsicherheit, Komplexität und Ambiguität bedeutet. Letztlich sagt der Begriff aus, dass die Welt schneller, unvorhersehbarer, unsicherer und komplexer wird. Also keine guten Zeiten für schwerfällige Unternehmensstrukturen.
Das agile Manifest
Den Ursprung der Agilität bildet sicherlich das agile Manifest der Softwareentwicklung. 2001 haben sich hierzu 17 renommierte Softwareentwickler getroffen und mit dem agilen Manifest den Meilenstein der agilen Bewegung gelegt. Ich möchte es Ihnen natürlich nicht vorenthalten, und es ist dazu noch ziemlich kompakt:
Manifest für agile Softwareentwicklung
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Quelle: https://agilemanifesto.org/iso/de/manifesto.html
Wir bewegen uns auf der rechten Seite des agilen Manifests, um das auf der linken Seite zu erreichen.
Innerhalb des klassischen Qualitätsmanagements und auch in den klassischen Managementdisziplinen wird oft genau das Rechte getan, um das Linke zu bewirken.
Wir beschreiben die Interaktionen in Prozessen, die wir mit Werkzeugen analysieren und modellieren.
Wir erstellen umfangreiche Dokumentationen, um die Funktion und Sicherheit von Produkten sicherzustellen.
Wir setzen Verträge auf, um die Zusammenarbeit mit dem Kunden ins kleinste Detail zu beschreiben.
Wir setzen ausführliche Pläne mit Deadlines auf, um auch auf Unvorhergesehenes reagieren zu können.
Wenn dann etwas schief läuft, suchen Unternehmen oft auf der rechten Seite nach Defiziten. Wenn ein Plan nicht aufgegangen ist, dann war er einfach nicht gut genug, und das Unternehmen schmiedet für das nächste Mal einen besseren Plan mit ähnlichen Problemen. All diese Ansätze sind nicht komplett verkehrt und haben auch ihre Berechtigung. Die Verfasser des Manifests der agilen Softwareentwicklung haben aber folgendes gemerkt: Es funktioniert oft nicht, und wir müssen den Fokus anders legen. Im Folgenden gehe ich nun auf die linke Seite ein und stelle sie in den Kontext zur rechten.
Einen interessanten Artikel zum Umgang mit falschen Deadlines finden Sie hier.
Was das agile Manifest uns lehrt
Wertschöpfung wird von Menschen erbracht
Die tatsächlichen Interaktionen der Individuen sind viel wichtiger für die Organisation als eine Dokumentation, in der die Organisation sich selbst beschreibt. Oft ist die Prozessdokumentation veraltet und bildet nicht mehr die Realität ab. Produktqualität und Wertschöpfung entstehen aber in der Wirklichkeit und nicht auf dem Papier. Beides erschaffen nämlich Menschen. Die individuellen Interessen, Emotionen und Interaktionen lassen sich nicht in Arbeitsanweisungen beschreiben, und Konflikte lassen sich nicht auf Papier austragen. Der Versuch, einen Konflikt per E-Mail zu klären, geht zudem oft nach hinten los. Hierzu braucht es tatsächliche Interaktionen und Gespräche.
Der „professionelle“ und distanzierte Umgang mit der Arbeit, wo Gefühle keine Rolle spielen sollen, funktioniert nicht, und zum Glück hat sich hier auch in vielen Unternehmen die Erwartungshaltung geändert. Schließlich sind wir Menschen und Menschen haben Gefühle. Die Gefühle sind zudem nicht immer gleich und schon gar nicht planbar. Hier müsst Sie Agilität mitbringen, um mit diesen Schwankungen umgehen zu können. Da der Erfolg einer Organisation von gutem Teamwork abhängig ist, sollten Sie dies immer berücksichtigen.
Kunden wollen erstmal funktionierende Produkte
Ein Produkt, das nicht funktioniert, aber eine umfangreiche und detaillierte Dokumentation hat, ist schlichtweg nicht zu gebrauchen. Das gilt besonders für Software, wo kleine Bugs das ganze Produkt unbrauchbar machen können. Den Kunden Ihres Unternehmens wird es herzlich egal sein, ob die Dokumentation für ein defektes Produkt umfangreich oder minimalistisch ist. Zuerst muss die Produktqualität stimmen, dann kommt die Dokumentation.
Kunden wissen oft nicht, was sie wollen und brauchen
Die Kunden Ihres Unternehmens in den Fokus zu stellen, ist bereits alte Qualitätsmanagement-Philosophie. Allerdings ist hier von Zusammenarbeit mit dem Kunden die Rede. Da auch Ihre Kunden Individuen sind, sollte mit diesen regelmäßig interagiert werden. Ebenso wie es im agilen Manifest steht.
Der alte Lasten- und Pflichtenheftansatz funktioniert in der Realität oft nicht, da davon ausgegangen wird, dass Ihr Kunde zu Projektbeginn schon weiß, was er braucht. Das kann zur Folge haben, dass Sie und Ihr Kunde sich länger nicht sehen und am Ende ein Produkt vorliegt, das zwar dem Pflichtenheft entspricht, aber nicht den Kundenwünschen. Meist fehlen dem Produkt dann Funktionen, die Ihren Kunden begeistert hätten. Stattdessen sind dann Funktionen vorhanden, die Ihr Kunde doch nicht braucht. Stichwort Funktionen, die Ihre Kunden nicht brauchen. Wann haben Sie eigentlich das letzte Mal den VBA-Editor in Word benutzt?
Begrüße auch das Unvorhergesehene
Sie handeln klüger, wenn Sie auf eine sich verändernde Umwelt agil reagieren, statt stringent einem Plan zu folgen, der nicht mehr funktioniert. Das leuchtet schnell ein. Gerade bei Neuentwicklungen lässt sich schwer einschätzen, auf welche Schwierigkeiten Ihr Unternehmen während der Entwicklung stoßen wird oder welche Ergebnisse spätere Tests liefern werden.
Im Kontext des dritten Wertes „Zusammenarbeit mit dem Kunden“ bekommen Veränderungen noch weiteres Gewicht. Bekommen Sie nämlich regelmäßig Feedback von Ihrem Kunden und berücksichtigen dies auch in der Entwicklung, so wird am Ende ein besseres Produkt vorliegen. Die Änderungen aus den Kundenwünschen werden nicht drastisch sein, aber das Endergebnis wird ein anderes sein, als wenn Sie nach den Anfangsvorgaben gearbeitet hätten. Die regelmäßigen kleinen Veränderungen sorgen also dafür, dass Sie am Ende genau das liefern, was Ihr Kunde will, und Sie ihn dadurch begeistern.
Aus dem agilen Manifest und der damit verbundenen Agilität lässt sich also Vieles lernen und mitnehmen. Es enthält viel Wissen auf kleinem Raum. Chaos verursacht es aber keineswegs. Sie finden das agile Manifest in jeder Sprache auf der offiziellen Seite: https://agilemanifesto.org
SCRUM – Agiles Framework mit festen Regeln
SCRUM ist wohl das populärste Beispiel für agiles Arbeiten und agiles Projektmanagement. Ich möchte hier nicht auf das gesamte Framework eingehen, aber SCRUM eignet sich als gutes Beispiel, warum agiles Arbeiten gar nicht so flexibel oder chaotisch ist, wie manche denken. In SCRUM setzen die Teams sehr viel Timeboxing ein. Es gibt bestimmte Aktionen, die nur eine bestimmte Zeit dauern dürfen. Zudem hat SCRUM feste Bestandteile, die immer vorhanden sein müssen. Ein Bestandteil von SCRUM ist zum Beispiel der Daily SCRUM. Dieser findet, wie der Name schon sagt, täglich statt und darf maximal 15 Minuten dauern. Die Arbeit erledigen die Teams in Sprints. Vor jedem Sprint findet ein Sprint Planning statt, und nach jedem Sprint gibt es zunächst ein Sprint Review und dann die Sprint Retrospective. Auch diese Events sind abhängig von der Sprintlänge timeboxed.
All die genannten Bestandteile müssen in SCRUM enthalten sein und finden in einer festen Reihenfolge statt, ansonsten ist es kein SCRUM. Ebenfalls gibt es klare Rollenverteilungen in SCRUM. Eine davon ist der SCRUM Master. Eine der Hauptaufgaben des SCRUM Masters ist darauf zu achten, dass die SCRUM Regeln eingehalten werden. Sie sehen also anhand dieser wenigen Beispiele, dass dieses populäre agile Framework wenig mit Chaos und Regelverstoß zu tun hat. Ich werde in weiteren Artikeln noch mehr auf SCRUM eingehen.
Buchempfehlung für SCRUM und Agilität
Das Framework ist aber kein Geheimnis, und es gibt zahlreiche Informationen auf https://www.scrum.org/. Wenn Sie ein Buch über SCRUM und Agilität lesen möchten, so kann ich Ihnen das Buch „Scrum: The Art of Doing Twice the Work in Half the Time“ von Jeff Sutherland empfehlen. Es ist von einem der beiden Erfinder von SCRUM und sehr unterhaltsam geschrieben. Beim Lesen musste ich mehr als einmal lachen, weil er die Realität so humorvoll auf den Punkt gebracht hat. Eine klare Empfehlung für Menschen, die sich mehr mit der Agilität auseinandersetzen wollen.
Stehen Agilität und agil nun für Chaos?
Nachdem Sie die letzten Zeilen gelesen haben, sollte die Antwort klar sein: Nein. Wenn eine Organisation chaotisch ist, dann liegt das nicht daran, dass agil gearbeitet wird, sondern es schlichtweg chaotisch zugeht und es an Organisation fehlt. Beim agilen Manifest geht es um Werte und nicht um Arbeitsweisen. Die Arbeitsweisen lassen sich aber auf Basis dieser Werte herleiten. Daraus entstehen dann tolle Frameworks wie SCRUM oder Methoden wie Design Thinking.
