Was Agilität (nicht) bedeutet

Agilität – Die häufigsten Missverständnisse

Niklas Schlimm

Wikipedia sagt: „Der Begriff Missverständnis bezeichnet in der menschlichen Kommunikation den Unterschied zwischen dem, was auf der einen Seite der Sender gemeint und auf der anderen Seite der Empfänger verstanden hat. Der Empfänger versteht in diesem Fall etwas anderes, als der Sender gemeint hat.“ Im Folgenden geht es auch um Missverständnisse, und zwar rund um das Thema „Agilität“. Denn vor rund zehn Jahren wurde das Agile Manifesto gesendet und nicht jeder Empfänger hat alles richtig verstanden.

Unzählige Artikel, Bücher und Vorträge zu dem Thema ändern daran nichts, menschliche Kommunikation schlägt eben auch mal fehl. Aus vielen Gesprächen mit Entscheidungsträgern und Entwicklern habe ich mir die wichtigsten Missverständnisse notiert. Das heißt natürlich nicht, dass das die einzigen sind. Diese hier wiederholen sich aber hartnäckig:

  • „Agil bedeutet, ohne Dokumentation zu entwickeln“
  • „Agil bedeutet, nicht zu modellieren“
  • „In agilen Projekten lässt sich der Fortschritt nicht messen oder kontrollieren“
  • „In komplexen Großprojekten lässt sich nicht alle vier Wochen ein Produktionsrelease freigeben“
  • „Agil und ‚ingenieurmäßig‘ sind gegensätzliche Vorgehensweisen“
  • „Agil funktioniert nicht für komplexe Großprojekte“
  • „Die Anforderungen an die Entwickler in agilen Projekten sind höher“
  • „Um Agilität einzuführen, ist ein umfangreiches Veränderungs-Management notwendig“

Solche Missverständnisse erschweren den Einzug agiler Verfahren in die Unternehmenspraxis erheblich – Grund genug, sie hier in einer Artikelserie aufzugreifen. Wie gehen wir dabei vor? Es wird keine Definition erarbeitet, was Agile Software Entwicklung im Allgemeinen bedeutet. Dafür gibt es bereits sehr gute Quellen, in denen man sich schlau machen kann. Wer daran interessiert ist, kann sich z.B. hier einen Überblick verschaffen:

http://www.agilemanifesto.org

http://www.martinfowler.com/articles/newMethodology.html

Agilität erleben
Zum Thema Agilität kann man sich auch auf der JAX 2011 inspirieren lassen: Der Agile Day gibt Einblicke in die Erfahrungen von agilen Methodenberatern, agilen Kunden und agilen Entwicklern und zeigt auf, wie sich agile Vorgehensweisen gewinnbringend in Softwareentwicklungsprojekten umsetzen lassen. Auf dem Agile Day Interaktiv können agile Herausforderungen hautnah erlebt und in bewegten, interaktiven Sessions Lösungen erarbeitet werden. Die Agile ALM Days spannen den Bogen über den gesamten Lebenszyklus einer Software bis hinein in die Managementkultur eines Unternehmens. Alle Infos finden sich unter www.jax.de.

Stattdessen wollen wir im Folgenden direkt auf die oben aufgeführten Aussagen eingehen. Als Diskussionsgrundlage wird zunächst das Modell eines Regelkreises beschrieben, in dem ein agiles Projekt vereinfacht dargestellt wird. Danach wollen wir den ersten vier Missverständnissen zu Leibe rücken. In den nächsten Serienteilen werden dann die anderen Vorurteile mit einem jeweils eigenen Artikel gewürdigt.

[ header = Seite 2: Agile Softwareentwicklung als Regelkreis ]

Agile Softwareentwicklung als Regelkreis

Ein Regelkreis ist ein beliebtes Mittel in der Management-Kybernetik, das vor allem auch für die Entscheidungsträger im Management leicht nachvollziehbar ist. Und gerade das Management muss ja „abgeholt“ werden, damit agile Verfahren eine noch breitere Anwendung finden.

Abbildung 1: Neutraler Regelkreis

Abbildung 1 zeigt einen neutralen Regelkreis. Der Regelkreis besteht aus zwei Elementen: erstens aus dem Regler, der zweitens die Regelstrecke steuert. Regler und Regelstrecke sind in Form einer Rückkopplung miteinander verbunden. Diese Rückkopplung ermöglicht eine permanente, zyklische Interaktion und ist für das selbstregulierende Verhalten des Regelkreises verantwortlich. Output der Regelstrecke ist die Regelgröße, die den aktuellen Zustand der Regelstrecke meldet. Die Regelgröße wird laufend mit der Führungsgröße verglichen. Aus der Abweichung zwischen Regelgröße und Führungsgröße generiert der Regler die Stellgröße, mit der das Verhalten der Regelstrecke beeinflusst wird. Neben der Stellgröße wird das Verhalten der Regelstrecke durch Störgrößen beeinflusst.

Das Konzept des Regelkreises übertragen wir nun auf ein agiles (Scrum-)Projekt.

Abbildung 2: Regelkreis in einem Scrum-Projekt

Die Führungsgröße in einem agilen Projekt ist das Product Backlog, in dem alle (fachlichen und technischen) Anforderungen priorisiert aufgelistet werden. Das funktionsübergreifende Team (der Regler) analysiert das Backlog, vergleicht es mit dem aktuellen Entwicklungsstand der Anwendung (die Regelgröße) und bildet daraus das Sprint Backlog (die Stellgröße). Im Entwicklungsprozess wird die Anwendung programmiert, einziger relevanter Output der Regelstrecke ist die laufende Software. Als prominente Störgrößen, die auf die Regelstrecke wirken, können Änderungswünsche des Kunden oder Fehlinterpretationen der Entwickler genannt werden.

Aufbauend auf dem beschriebenen Modell möchte ich nun die ersten Aussagen kommentieren. Zunächst die Behauptung: „Agil bedeutet, ohne Dokumentation zu entwickeln“.

Falsch: Agil bedeutet, ohne Dokumentation zu entwickeln

Die Aussage, dass in agilen Projekten nichts dokumentiert wird, wird sehr häufig formuliert. Agil und „ohne Dokumentation“ gehören aber nicht zwangsläufig zusammen. In agilen Projekten ist die einzige relevante Regelgröße (Output des Entwicklungsprozesses) die laufende Software. Das ist in traditionellen Projekten oft anders. Dort wird ein erstelltes Dokument als messbares Ergebnis oder Meilenstein angesehen. Ein Dokument ist dann also eine Regelgröße, anhand der man den Zielerreichungsgrad des Projektes ablesen kann. Aber was wurde da wirklich gemessen? Kann der Kunde mit einem Dokument etwas anfangen?

Dokumente sind in agilen Projekten keine Meilensteine, weil sie dem Kunden keinen geschäftlichen Nutzen bringen und weil man in Wahrheit damit auch nicht den Fortschritt des Projektes messen kann. Nur die laufende Software ist relevant. Hier wird ultimativ klar, ob die Anforderungen des Kunden richtig umgesetzt worden sind. Deswegen stehen zum Beispiel Entwurfs- oder Analyse-Dokumente nicht im Mittelpunkt des Interesses, sondern dienen nur als Mittel zum Zweck. Wenn es aber hilft, die Anforderungen aus dem „Backlog“ umzusetzen, dann wird dokumentiert. Wenn es hilft, dem Endbenutzer die neuen Funktionen der Anwendung nahe zu bringen, dann wird auch dokumentiert.

Richtig: Wenn ein Entwickler in einem agilen Team aus Zeitgründen zwischen Kodieren und Dokumentieren auswählen muss – und er auch ohne Dokumentation zum Ziel kommt (laufende Software) -, dann entscheidet er sich für das Kodieren.

[ header = Seite 3: Agil bedeutet, nicht zu modellieren ]

Falsch: Agil bedeutet, nicht zu modellieren

Diese Aussage ist genauso falsch wie die Aussage zur Dokumentation. Selbst in Extreme Programming (XP), einer sehr informalen agilen Vorgehensweise, wird vorgeschlagen, komplexe und wichtige Teile des Systems zu modellieren – und zwar immer dann, wenn es hilft, sauber zu implementieren. Dazu wird aber eher Bleistift und Papier oder das Whiteboard vorgeschlagen, anstatt ein UML Tool.

Falsch: In agilen Projekten lässt sich der Fortschritt nicht messen oder kontrollieren

Diese Aussage kann man gut an dem oben eingeführten Regelkreis widerlegen. Der reale Fortschritt eines Projektes lässt sich tatsächlich nirgendwo besser ablesen als in einem agilen Projekt: nämlich durch die laufende Software. Schon ´mal in einem Projekt gearbeitet, das drei Wochen vor Ablieferung drei Monate Verzug anmelden musste? Oder schon ´mal drei Monate an etwas entwickelt, was der Kunde dann später völlig auf den Kopf gestellt hat? Vielleicht lag es daran, dass die falschen Regelgrößen gemessen wurden. Dokumente sind keine verlässlichen Regelgrößen, mit denen man den Fortschritt des Projektes bemessen könnte. Abgekürzt liegt das daran, dass man sich anhand eines Dokuments die beschriebene Anwendung nur (mehr oder weniger gut) vorstellen kann. In agilen Projekten gibt es deswegen nur eine universelle Regelgröße: die laufende Software. Daran kann man definitiv abmessen, ob die Anforderungen des Kunden, die im Backlog standen, wirklich abgearbeitet wurden.

Richtig: Es gibt wahrscheinlich keine bessere Fortschrittskontrolle (Regelgröße im Regelkreis) als laufende Software.

Kein Dokument kann ein laufendes System ersetzen, mit dem der Kunde die ersten Funktionen ausprobieren kann. So früh wie möglich und so schnell wie möglich sollte man deswegen dem Kunden die laufende Software zeigen. In agilen Projekten ist das ein wesentliches Kriterium. Wenn man jetzt noch die hoch priorisierten Anforderungen zuerst bearbeitet (die stehen im Backlog ganz oben!), dann bewegt man sich nahe am Maximum an Planbarkeit in einem Software-Projekt.

Falsch: In komplexen Großprojekten lässt sich nicht alle vier Wochen ein Release freigeben

Diese Aussage kann so ohne weiteres nicht nachvollzogen werden. Viele Kollegen haben schon komplexe Software mit agilen Vorgehensweisen entwickelt und konnten noch kürzere Releasezyklen erreichen. Die Vorgehensweise kann also nicht das Problem sein. Eine näher liegende Vermutung ist stattdessen, dass viele Organisationen „noch nicht so weit sind“. Gute Voraussetzungen für kurze Releasezyklen sind:

Funktionierende Continuous-Integration-(CI-)Umgebung

Wenn die Anwendung jeden Tag kompiliert, zusammengesetzt, getestet und qualitätsgesichert wird, dann hat man jederzeit einen schnellen Überblick. Man weiß jeden Tag, ob die Software lauffähig ist. CI ist im Sinne unseres Regelkreises die laufende automatische Überwachung des Outputs der Regelstrecke.

Ausgiebige Testautomatisierung (Unit Tests und GUI Tests)

Oft wird die gesamte Anwendung immer wieder von Hand durchgetestet. Dies erschwert die Durchführung von kurzen Releasezyklen. Stattdessen ist es ratsam, eine ausgewogene Abdeckung an automatisierten Tests zu erstellen, wodurch der Regressionstest automatisch abläuft.

Continuous Feedback in funktionsübergreifenden Teams

Wenn der Kunde im Team ist, dann hat er laufend Rückkopplung über den Stand der aktuellen Entwicklung. Die kontinuierliche Rückmeldung über die Qualität der erledigten Arbeitsergebnisse könnte man analog zu Continuous Integration auch als Continuous Feedback bezeichnen. Der Kunde ist so am Ende eines Entwicklungszyklus nicht plötzlich mit der Anwendung konfrontiert, sondern hat zusammen mit den Entwicklern kontinuierlich an der Erstellung und Bewertung gearbeitet.

Richtig: Die Länge der Releasezyklen hängt maßgeblich von einer zeitnahen und kontinuierlichen Rückmeldung über den Zustand der Regelgröße ‚laufende Software’ ab.

Zusammenfassung

Das waren die ersten vier Missverständnisse. Auf Basis des eingeführten Regelkreises haben wir die oben aufgelisteten Aussagen diskutiert. Der Regelkreis bietet sich als gute Diskussionsgrundlage an, weil das dargestellte Prinzip von Steuerung und Kontrolle besonders im Management gut nachvollziehbar ist. Und dort wird entschieden, ob Agile Verfahren im Unternehmensalltag weiter Einzug halten. Zusammengefasst ist das Ergebnis der ersten Diskussion in diesem Artikel:

  1. In agilen Teams wird dokumentiert, Dokumente sind aber generell weniger wichtig als laufende Software.
  2. Fortschrittskontrolle wird durch Agile Software-Entwicklung verbessert.
  3. Kurze Releasezyklen erfordern bestimmte Voraussetzungen, dazu gehören insbesondere Testautomatisierung sowie Continuous Integration und Feedback.

Soweit, so gut! In den nächsten Beiträgen werden wir weitere Missverständnisse diskutieren. Dabei widmen wir den einzelnen Falschaussagen einen jeweils eigenen Artikel, da die Themen inhaltlich etwas umfangreicher sind. Fortsetzung folgt!

Geschrieben von
Niklas Schlimm
Niklas Schlimm
Niklas Schlimm ist Leiter des Architekturteams der Provinzial Rheinland Versicherung AG. Er arbeitet als Architekt seit fünfzehn Jahren in EDV-Projekten im Java-Umfeld, meist mit Großrechneranbindung. In diesen Jahren war er in unterschiedlichen Beratungshäusern und Versicherungsunternehmen tätig. Die Provinzial Rheinland gehört zu den führenden deutschen Versicherungsunternehmen und ist Marktführer in ihrem Geschäftsgebiet.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.