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

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.

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“.

Geschrieben von
Niklas Schlimm
Kommentare

Schreibe einen Kommentar

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