Dennis Willkomm - Roadmap durch die VUCA-Welt

Abb. 12:

Das Agile Manifest (eigene Darstellung nach http://agilemanifesto.org)5

Den Ursprung aus dem Bereich der Softwareentwicklung sieht man sehr deutlich im zweiten Wertepaar, welches funktionierende Softwareüber eine umfassende Dokumentation stellt. Hier kann Software ohne viel Fantasie durch ein begeisterndes Produkt, eine zufriedenstellende Dienstleistung oder was auch immer man liefern möchte, ersetzt werden. Den Autoren war dabei wichtig, darauf hinzuweisen, dass das Endprodukt im Fokus stehen sollte, nicht Dokumentation für interne Prozesse. Zwar kann man dadurch bei einem Fehlschlag sehr schön seinen Kopf aus der Schlinge ziehen (vielleicht kennen Sie auch das geflügelte Wort „Wer schreibt, der bleibt“), aber dem Kunden nutzt dies nur sehr wenig. In einer gesunden Kultur sollte immer der Kundennutzen im Mittelpunkt stehen, nicht der Selbstschutz.

Das wird auch aus dem dritten Wertepaar ersichtlich, das die Zusammenarbeit mit dem Kundenüber die Vertragsverhandlungen stellt. Natürlich braucht man im Geschäftsleben Verträge, aber viel wichtiger ist es, den Kunden von einer wertschätzenden Partnerschaft zu überzeugen und ihn in den Entwicklungsprozess zu integrieren. Durch eine enge Zusammenarbeit kann man sehr schnell feststellen, ob man auf dem richtigen Weg ist. Kurskorrekturen können sofort vorgenommen werden und am Ende entsteht so hoffentlich ein Produkt, mit dem der Kunde glücklich ist. Das Abarbeiten ausführlicher Pflichtenhefte führt nicht unbedingt dazu, dass am Ende auch ein Produkt entsteht, das der Kunde so haben wollte.

Zuletzt betonen die Autoren noch, dass das Reagieren auf Veränderungdeutlich wichtiger ist, als einem vorher festgelegten Plan zu folgen. Den Unterzeichnern war klar, dass man schnell auf Veränderungen in der Umwelt reagieren müsse, um erfolgreich zu sein. Um es auch noch mal in aller Deutlichkeit zu sagen: Auch in der agilen Welt spielen Pläne eine große Rolle. Allerdings hat nicht mehr, um die Zukunft vorherzusagen, sondern vielmehr um Transparenz herzustellen.

Lassen Sie uns auf den nächsten Seiten einen Blick auf die agilen Prinzipien werfen. Diese werden oftmals übersehen, dabei bilden sie das Rückgrat des agilen Arbeitens.

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Zum einen spiegelt sich hier die starke Fokussierung auf den Kunden wider. Alles, was getan wird, sollte das Ziel haben, den Kunden zufrieden zu stellen. Aber auch über die Art und Weise, wie dies erreicht wird, kann man hier etwas finden, nämlich durch frühe und kontinuierliche Lieferung. So sollte schon sehr frühzeitig und in regelmäßigen Abständen etwas an den Kunden übergeben werden. Im Fall von Software ist dies relativ einfach, denn man kann ja einfach Funktionen nachliefern. Das ist heute oft gelebte Realität. Es gibt viele Apps, die schon sehr früh erscheinen und dann nach und nach neue Funktionalitäten nachliefern. So können viele Menschen die App schon nutzen mit den Funktionalitäten, die vorhanden sind.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden! Anforderungsänderungen sind in der Regel ärgerlich. Denn in den allermeisten Fällen hat man schon Zeit investiert, um sie umzusetzen, oder sich zumindest Gedanken darüber gemacht, wie eine Umsetzung aussehen könnte. Aus Kundensicht wäre eine Änderung aber sehr vorteilhaft. Sei es, weil sich die Voraussetzungen verändert haben, oder dass der Kunde durch einen Zwischenstand neue Erkenntnisse gewonnen hat. In einer von Vertrauen geprägten Beziehung sollte man davon ausgehen, dass das Gegenüber gute Gründe für einen Änderungswunsch hat. Und aus diesem Grund sollte man auch diese Anforderungsänderungen willkommen heißen und als Chance sehen, ein noch besseres Endprodukt herauszubringen.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne! Hier wird noch etwas konkreter was es heißt, regelmäßig zu liefern, denn man sollte sich auf wenige Wochen oder Monate beziehen. In Zeiten formuliert, wo Software teilweise Veröffentlichungszyklen von Jahren hatte, ist dies eine sehr forsche Forderung. Aber nur, wenn man dieses Prinzip befolgt, wird man auch schnell auf Veränderungen reagieren können. Mit kurzen Zyklen kann man sehr schnell Hypothesen testen und bei Problemen eine Richtungsänderung vornehmen. Je länger eine Entwicklungsphase ohne Feedbackzyklus ist, desto teurer wird eine potenzielle Fehlentscheidung ausfallen.

Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten! Um kurze Zyklen und kontinuierliche Lieferung zu gewährleisten, braucht man ein anderes Konstrukt als ein auf dem Wasserfallmodell basierendes. Es benötigt interdisziplinär aufgestellte Teams, in denen unterschiedliche Perspektiven und Expertisen zusammenkommen. Diese sollten eng auf täglicher Basis miteinander arbeiten. So entsteht tiefes Verständnis für die Domäne des anderen und es kommt zu echter Kollaboration.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen! Hier werden sich eher die Organisationsgestalter angesprochen fühlen. Es geht darum, den interdisziplinären Teams einen geeigneten Rahmen zur Verfügung zu stellen, in dem sie sich entfalten können. Teams benötigen Freiheiten, selbst Entscheidungen treffen zu dürfen. Das setzt Vertrauen voraus, denn bisher wurden die meisten Entscheidungen traditionell an anderen Positionen in der Unternehmenshierarchie getroffen. Auch die Motivation spielt eine große Rolle. Was Menschen motiviert und welche grundlegenden Motive dabei eine Rolle spielen, werden wir uns noch im Detail ansehen.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Hier werden wahrscheinlich einige effizienzgetriebene Manager schlucken, denn mündliche Kommunikation mit Rückfragen und Diskussionen ist vieles, aber aus ihrer Sicht nur selten effizient. Aber was wäre die Alternative? Der klassische Weg über eine Vielzahl von Dokumenten und geschriebenen Worten vielleicht. Aber im Falle eines eng zusammenarbeitenden Teams sieht das vielleicht schon wieder anders aus. Bei schriftlicher Kommunikation besteht immer die Gefahr, dass etwas fehlinterpretiert wird, was dann im Nachgang mit deutlich höheren Kosten für Korrekturen verbunden ist.