Da ist sie wieder. Die vermeintlich einfache Frage danach, was Agilität denn eigentlich ist. Sie begegnete mir in den vergangenen Jahren immer wieder und die Antworten fielen immer unterschiedlich aus. So einfach zu beantworten, wie es auf den ersten Blick scheinen mag, ist diese Frage wohl doch nicht. Nichtsdestotrotz möchte ich an dieser Stelle einen weiteren Versuch unternehmen.
Wo helfen uns agile Arbeitsweisen weiter?
Beginnen wir doch zunächst einmal mit der Frage, wo wir agile Arbeitsweisen einsetzen sollten und wo sie uns wirklich einen Mehrwert liefern, denn keine Methodik sollte zum Selbstzweck eingesetzt werden.
Ganz vereinfacht lässt sich sagen: Überall, wo komplexe Problemstellungen vorherrschen oder wir nicht genau vorhersagen können, wie die Lösung für ein Problem aussehen soll oder was der Kunde genau möchte, hilft uns Agilität weiter. Agilität macht also besonders Sinn im Kontext von Unsicherheit, die sich oft im Grad der Komplexität ausdrückt.
Ob unser avisiertes Produkt oder Projekt denn nun komplex ist, lässt sich gegebenenfalls anhand der Stacey-Matrix einschätzen. Das Diagramm von Professor und Wirtschaftstheoretiker Ralph Douglas Stacey ist ein schönes Denkmodell, um vorab über genau diese Fragestellung zu reflektieren.
Das Diagramm teilt sich auf in eine Achse für die Anforderungen, die unser geplantes Produkt beschreiben sowie die Lösungstechnologie, die zum Einsatz kommen soll.
Ist beides klar, sprich: Wer es also problemlos vermag, sich aus dem Meer an Technologien sofort für die richtige zu entscheiden und die Anforderungen seiner Kunden genau kennt und mit Sicherheit weiß, was der Markt verlangt und wie die Lösung aussehen soll, der ist durchaus im einfachen Umfeld unterwegs.
Dann gibt es nachfolgend den Bereich für komplizierte Dinge und den für die komplexen Aufgaben. Den Bereich für das Chaos, in dem sich hoffentlich niemand bewegt und der sofortiges Handeln nach sich ziehen sollte, möchte ich heute außen vor lassen.
Kompliziert vs. Komplex
Aber was ist der Unterschied zwischen kompliziert und komplex?
Hierzu ein einfaches Beispiel aus der Praxis: Ich kaufe mir einen Kleiderschrank bei einem schwedischen Möbelhaus. Viele Teile, viele Schrauben. Aber ich habe eine Anleitung, die ich konsultieren kann und die mir dann irgendwann hilft zu verstehen, wie der Schrank genau zusammengesetzt ist.
Habe ich einen solchen Schrank oder Elemente davon gar schon öfter zusammengesetzt, kann ich diese ggf. irgendwann einmal ohne Blick in die Anleitung zusammensetzen. Komplizierte Dinge können also nach sorgfältiger Analyse verstanden und Lösungen dazu notiert werden, damit sie beherrschbar werden.
Bei diesen komplizierten Dingen ist es oft noch sinnvoll und möglich, mit den klassischen Verfahren des Projektmanagements in die Zukunft zu planen, da der Lösungsweg (nach Analyse des Problems) bekannt ist.
Jetzt stelle man sich aber vor, man dreht mit einem Schraubenzieher eine Schraube an der linken Seite fest und irgendwo unten rechts löst sich ein Teil, ohne dass ein offensichtlicher Zusammenhang erkennbar ist. Herzlich willkommen in der Welt der Komplexität!
Hier ist eine vorausschauende Planung in die Zukunft nicht mehr mit ausreichender statischer Relevanz möglich, sondern wir benötigen ein empirisches Vorgehen, dass aus der Erfahrung und Beobachtung der nahen Vergangenheit Rückschlüsse auf die Zukunft zulässt. Diese bieten agile Vorgehensmodelle.
Komplexität als Nährboden für Agilität
Wir erleben heutzutage eine enorm hohe Geschwindigkeit der Veränderung, mit der wir uns täglich konfrontiert sehen. Noch während wir bereits getroffene Entscheidungen diskutieren, müssen wir sie ggf. schon wieder überdenken.
Das ist im Übrigen nicht allein ein Phänomen, mit dem wir uns in der Software-Entwicklung konfrontiert sehen. Man beobachte einfach das tägliche Geschehen in der Politik und der Wirtschaft und die vielen Abhängigkeiten und Auswirkungen von Entscheidungen, die dort getroffen werden.
Ob sich die Briten damals beispielsweise darüber bewusst waren, was sie mit dem Referendum über einen EU-Austritt auslösen würden? Oder die Monsanto-Übernahme des Bayer-Konzerns, eine wirtschaftlich sicherlich sinnvolle, ethisch aber fragwürdige Entscheidung, sieht man sich nun wütenden Aktionären und Sammelklagen gegenüberstehen. Oder die Diesel-Affäre, welche Industrielle, Umweltschützer, Politiker und Lobbyisten in ein kompliziertes Netz von Handlungen und Entscheidungen einspinnt.
Gerade in der heutigen Zeit der Digitalisierung erleben wir die Veränderung mehr und schneller als zuvor. Die Anforderungen der Verbraucher ändern sich ständig und neue Technologien schießen wie Pilze aus dem Boden.
Die Welt ist also, wie wir sehen, voller Komplexität. Das war sie so gesehen aber schon immer. Neu ist also die Herangehensweise, mit der wir dieser Komplexität entgegentreten.
Klassische Denkansätze helfen uns hier oftmals nicht mehr weiter, daher machen wir uns heute die Vorteile einer agilen Arbeitsweise zu Nutze.
Aber was ist Agilität denn nun eigentlich?
So weit, so gut. Nun wissen wir, wo uns Agilität konkret weiterhelfen kann. Aber was Agilität genau ist, haben wir noch immer nicht geklärt.
Ist es eine neue Art zu denken? Eine Entwicklungsmethodik? Eine Lebenseinstellung?
Hierzu einmal folgende Definition:
„Agilität ist ein Merkmal des Managements einer Organisation (Wirtschaftsunternehmen, Non-Profit-Organisation oder Behörde), flexibel und darüber hinaus proaktiv, antizipativ und initiativ zu agieren, um notwendige Veränderungen einzuführen.“¹
Für mich ist Agilität in allererster Linie eine Veränderung unserer Denkweisen und vor allem ein stark empirischer Prozess.
In eben erwähntem komplexen Umfeld stellen wir quasi mit jeder neuen Iteration Annahmen oder Behauptungen über die Bedürfnisse unserer Kunden an und versuchen diese durch Überführung in ein konkretes Produktinkrement in der Realität zu belegen.
Agilität bedeutet Veränderung!
Tatsächlich liegt der Kern aus meiner Sicht auf Veränderung.
Veränderung in bisher gewohnten Arbeitsweisen.
Veränderung unserer Produkte auf neue Herausforderungen in den Märkten und neue Bedürfnisse unserer Nutzer.
Und last but not least, Veränderungen in unserer Denkweise (das berühmt berüchtigte agile Mindset).
Denn gerade in der Zusammenarbeit eines agilen Softwareentwicklungs-Teams ändert sich einiges. So schaffen die Entwickler nun doch selbstorganisiert und eigenverantwortlich die Lösung für bestimmte Kundenanforderungen und -probleme. Die Verantwortlichkeit, wie eine bestimmte Lösung designed und umgesetzt wird, liegt also beim Team, innerhalb dessen idealerweise alle benötigten Kompetenzen mit Mitarbeitern besetzt sind.
Vor allem die Produkte müssen sich kontinuierlich anpassen und verändern, um proaktiv Änderungen im Markt zu adressieren. Dies funktioniert nur durch ständige Beobachtung des Marktes, enge Zusammenarbeit mit den Nutzern des Produktes oder Messungen und Tests.
Agilität stellt den Kunden in den Mittelpunkt
Agile Produktentwicklung ist somit komplett kundenzentrisch und richtet alles an seinen Nutzern als Dreh- und Angelpunkt aus.
User Stories sind hierbei ein probates und gern genutztes Werkzeug in der agilen Entwicklung, um neue Features konkret auf Bedürfnisse des Kunden auszurichten: Sie enthalten eine einfache textuelle Beschreibung darüber, welches konkrete Problem für welchen Benutzer gelöst wird und welchen Mehrwert es liefert.
Das heißt konkret, dass die Entwicklung stets in enger Abstimmung mit dem Kunden stattfindet, so werden beispielsweise regelmäßig die neuesten Anpassungen präsentiert und aktiv Feedback vom Kunden eingeholt. Anhand dieses Feedbacks können wir dann bestimmen, ob wir mit unserem Produkt auf Kurs sind oder ob Anpassungen notwendig sind.
Transparency, Inspect & Adapt
Wir versuchen hierdurch also die in der Planung getroffenen Annahmen zur Problemlösung zu belegen (hier sind wir wieder beim empirischen Prozess).
Eines der Kernprinzipien in einer agilen Produktentwicklung ist somit die kontinuierliche Überprüfung und Anpassung. Die agile Entwicklung eines Produktes geschieht stets in kleinen, übersichtlichen Zyklen (sogenannte Sprints, zumeist 2-3 Wochen), an deren Ende das Ergebnis betrachtet und Maßnahmen und Folgeaktivitäten abgeleitet werden.
Aber nicht nur das Produkt verbessert sich auf diese Weise kontinuierlich, sondern auch das Entwicklungsteam betrachtet seine Arbeitsweise in der vorhergehenden Iteration kritisch. In der sogenannten Retrospective blickt das Team zurück und identifiziert geeignete Maßnahmen, um sich zu verbessern und zukünftig noch effektiver zusammenzuarbeiten.
Scheitern ist keine Schande
Sind wir auf dem richtigen Weg oder benötigen wir Anpassung? Durch Einholen von Feedback der betroffenen Benutzer, respektive des Kunden oder Betrachten von Mess- und Testergebnissen am Ende der kurzen Iteration können wir relativ schnell feststellen, ob wir auf dem richtigen Weg sind oder gar in eine ganz andere Richtung steuern müssen.
Dabei kann es auch vorkommen, dass ein Ziel, welches man sich zu Beginn einer Iteration gesetzt hat, am Ende einfach in der Praxis nicht funktioniert. In diesem Fall wurde die in der Planung aufgestellte These in der Realität einfach nicht belegt.
Allerdings ziehen wir aus diesem vermeintlichen Fehlschlag am Ende wertvolle Erkenntnisse und lassen diese in den nächsten Sprint einfließen, um es dort einfach besser zu machen. In der Agilität betrachten wir Fehlschläge als Chancen und als aktive Möglichkeit, aus Fehlannahmen zu lernen.
Das agile Manifest
Insbesondere in der Software-Entwicklung haben agile Entwicklungspraktiken seit erster Schritte im Extreme Programming Ende der 90er enorm an Verbreitung gewonnen.
Als kleinsten gemeinsamen Nenner aller agilen Vorgehensmodelle lässt sich das agile Manifest betrachten. Im Frühling 2001 kamen hier 17 clevere und erfahrene Software-Entwickler zusammen und verabschiedeten eben dieses agile Manifest.
Es verankert Prinzipien und Leitlinien für die agile Software-Entwicklung. Vier wesentliche Leitsätze fassen die oben von mir bereits erwähnten Kernpunkte schön zusammen:
- Individuen und Interaktionen stehen über Prozessen und Werkzeugen.
- Funktionierende Software steht über einer umfassenden Dokumentation.
- Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung.
- Reagieren auf Veränderung steht über dem Befolgen eines Plans.
Hierbei sollte stets dazu gesagt sein, dass die Werte, die auf der rechten Seite stehen, durchaus wertgeschätzt werden, den Dingen auf der linken Seite aber wesentlich mehr Bedeutung zugemessen wird.
Weitere Leitsätze sind die zwölf agilen Prinzipien, die eine Umsetzungshilfe zum Leben der obigen Werte darstellen.²
Agile Produktentwicklung bei atrify
Bei atrify arbeiten wir bereits seit mehreren Jahren nach agilen Vorgehensmodellen, um unsere Produkte näher an den Bedürfnissen des Kunden auszurichten und herausragende und hilfreiche Lösungen für deren Geschäftsanforderungen anbieten zu können.
Wie genau wir dabei mit unseren Kunden zusammenarbeiten, wie wir Ideen für unsere Produkte generieren und Lösungen dafür bereitstellen, werde ich in meinem nächsten Beitrag detailliert beleuchten.
Quellen:
¹ Steven L. Goldman (Hrsg.): Agil im Wettbewerb: die Strategie der virtuellen Organisation zum Nutzen des Kunden. Springer, Berlin Heidelberg New York Barcelona Budapest Hongkong London Mailand Paris Santa Clara Singapur Tokio 1996, ISBN 3-540-60644-0.
² Beck, Kent / Beedle, Mike / Bennekum, Arie van u. a.: Manifest für Agile Softwareentwicklung (2001), http://agilemanifesto.org/iso/de/manifesto.html (07.06.2019)
