Als die ersten Dilbert-Comics über Agilität veröffentlicht wurden, war klar, dass Agilität kein Hype mehr war, sondern langsam, aber sicher den Massenmarkt erreicht hatte. Doch wie in anderen Bereichen stellen auch die agilen Dilberts eine Mischung aus typischen Missverständnissen, falschen Erwartungen und merkwürdigen Interpretationen dar. Agilität ist ein Wertesystem, das im Agile Manifest definiert worden ist. Dieses Manifest basiert auf zwölf Prinzipien. Das heißt, agile Entwicklung ist mehr als nur eine spezielle Methode wie Extreme Programming oder Scrum. Der erste deklarierte Wert im Manifest betont sogar: "Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge", was selbstverständlich auch agile Prozesse einschließt. Folgerichtig muss das Team dafür sorgen, dass der eingesetzte Entwicklungsprozess die eigenen Bedürfnisse so gut wie möglich erfüllt. Dazu bieten die Prinzipien des Manifests eine gute Orientierungshilfe für die Modifizierung und Anpassung des Prozesses.

ActiF
Requirement-Management (RM) und Implementierung (IMP) sind ist voll abgedeckt, keine Unterstützung gibt es für Wartung (W) und Betrieb (B). Auch der Test (T) ist schwach ausgeprägt. Besser schneidet AcriF bei der Integration (INT), Projekt-Management (PM), Qualitäts-Management (QM) und Systemdesign (SD) ab.

Adaptive Software Development (ASD)
ASD schneidet nur im Qualitäts-Management (QM) sehr gut ab. Disziplinen wie Integration (INT), Wartung (W), und Betrieb (B) werden überhaupt nicht abgedeckt. Projekt- und Requirement-Management (PM/RM), Systemdesign (SD), Implementierung (IMP) und Test (T) sind schwach ausgeprägt.

Agile Enterprise
Agile Enterprise leistet vollständige Unterstützung in den Bereichen Projekt-Management (PM), Requirements-Management (RM), Implementierung (IMP) und Test (T). Nicht ganz so gut sieht es bei der Integration/Einführung (INT), dem Qualitäts-Management (QM) oder dem Systemdesign/technische Konzeption (SD) aus. Schwachpunkt ist die Wartung (W), für den Betrieb (B) kommt überhaupt keine Unterstützung.

Agile Model Driven Development
AMDD deckt unter den Disziplinen des Software Engineering die des Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Integration/Einführung (INT), Wartung (W) und Betrieb (B) sowie für Implementierung (IMP). Auf mittlerem Niveau bewegen sich das Qualitäts-Management (QM), Requirements-Management (RM) und das Systemdesign/technische Konzeption (SD) während für Projekt-Management (PM) nur wenig Unterstützung kommt.

Behavior Driven Development
Behavior Driven Development schneidet nur im Requirements-Management (RM) sehr gut ab, gefolgt vom Qualitäts-Management (QM). Keine Punkte gibt es im Bereich Wartung (W), Betrieb (B) und Projekt-Management (PM). Die Disziplinen Systemdesign (SD), Implementierung (IMP), Test (T) und Integration (INT) schwächeln.

Crystal
Crystal hat seine Stärke im Bereich Test (T), auch das Qualitäts-Management (QM) und die Implementierung (IMP) werden gut abgedeckt. Mittel bis schwach ausgeprägt sind dagegen Projekt-Management (PM), Requirement-Management (RM), Integration/Einführung (INT) und Wartung (W). Keine Unterstützung gibt es für Betrieb (B) und Systemdesign/technische Konzeption (SD).

Design Driven Development
D3 unterstützt nur wenige Disziplinen im Software Engineering. Am ehesten gilt dies noch für das Requirement-Management (RM), schwache Abdeckung gibt es auch in den Bereichen Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Qualitäts-Management (QM). Keine Unterstützung gibt es für Integration/Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).

Dynamic System Development Method
DSDM spiel seine Stärken in den Bereichen Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Integration/Einführung (INT) aus. Weniger gut werden die Aspekte der Wartung (W), des Betriebs (B) sowie des Projekt- (PM) und Qualitäts-Managements (QM) abgedeckt.

Eclipse Way Process
Aufgrund der Kombination unterschiedlicher Techniken im Eclipse Way Process ergeben sich zahlreiche Stärken. Disziplinen im Software Engineering, die vollständig abgedeckt werden, sind Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T). Nicht ganz so gut schneidet Integration/Einführung (INT) ab. Eine schwache Abdeckung gibt es für Wartung (W) und Qualtitäts-Management (QM), während Betrieb (B) überhaupt nicht unterstützt wird.

Evolutionary Process For Integrating Cots-Based Systems (Epic)
Epic hat seine besondere Stärke im Projekt-Management (PM). Recht gut abgedeckt werden auch Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Test (T) und Integration/Einführung (INT). Mittlere Abdeckung gibt es für den Bereich Implementierung (IMP), während Wartung (W) und Betrieb (B) überhaupt keine Unterstützung finden.

Evolutionary Project Management & Product Development (EVO)
Projekt-Management (PM) und Test (T) sind die Stärken des EVO-Vorgehens. Schwächer fallen Systemdesign/technische Konzeption (SD), Qualitäts-Management (QM), Requirements-Management (RM), Implementierung (IMP) und Integration/Einführung (INT) aus. Die Bereiche Wartung (W) und Betrieb (B) werden überhaupt nicht abgedeckt.

Extreme Programming
Extreme Programming (XP) deckt unter den Disziplinen des Software Engineering die Implementierung (IMP) und den Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Qualitäts-Management (QM) und Requirements-Management (RM). Mittlere Abdeckung erfährt das Systemdesign/technische Konzeption (SD) sowie die Integration/Einführung (INT), während Wartung (W) und Projekt-Management (PM) nur schwach ausgeprägt sind. Der Betrieb (B) ist nicht abgebildet.

Feature Driven Development
FDD deckt die Aspekte des Systemdesign/technische Konzeption (SD) vollständig ab. Nicht ganz so gut sieht es beim Projekt-Management (PM), Qualitäts-Management (QM), Requirements-Management (RM) und bei der Implementierung (IMP) aus. Wenig Abdeckung gibt es für Test (T) und Integration/Einführung (INT). Wartung (W) und Betrieb (B) werden überhaupt nicht unterstützt.

Iconix
Iconix deckt die Bereiche Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign (SD), Implementierung (IMP) und Test (T) vollständig ab. Recht gut ist die Methode auch, wenn es um die Integration (INT) und das Projekt-Management (PM) geht. Defizite gibt es bei der Wartung (W), der Betrieb (B) wird überhaupt nicht berücksichtigt.

Internet-Speed Development
Internet-Speed Development ist im Bereich Integration und Einführung (INT) hervorragend. Keine Abdeckung erfährt der Bereich Wartung (W) und Qualitäts-Management (QM). Mäßige bis gute Abdeckung erzielt die Methode bei Betrieb (B), Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T).

Lean Software Development
Lean Software Development zeigt seine Stärken vor allem in den Bereichen Qualitäts-Management (QM) und Test (T). Auch das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) sind gut abgedeckt. Vergleichsweise schwach ausgeprägt sind dagegen die Bereiche Requirements-Management (RM), Integration und Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).

Microsoft Solutions Framework (MSF)
Das Microsoft Solutions Framework for Agile Software Development deckt die Bereiche Projekt-Management (PM), Implementierung (IMP) und Test (T) gut ab. Mittlere Unterstützung gibt es für Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD)sowie Integration/Einführung (INT). Wartung (W) und Betrieb (B) erfahren dagegen keine Abdeckung.

Mobile-D
Gute bis mittlere Abdeckung bietet Mobile-D für die Software-Engineering-Disziplinen Test (T), Implementierung (IMP), Requirements-Management (RM), Qualitäts-Management (QM) und Projekt-Management (PM). Schwach ausgeprägt sind Systemdesign/technische Konzeption (SD) und Integration/Einführung (INT). Keine Unterstützung gibt es für Wartung (W) und Betrieb (B).

Rapid Application Development
RAD deckt die Belange der Implementierung (IMP) voll ab, gut ist die Methode in den Bereichen Test (T) und Integration/Einführung (INT). Mittlere bis schwache Abdeckung gibt es fürs Requirements-Management (RM), Qualitäts-Management (QM), Projekt-Management (PM) und für die Wartung (W). Systemdesign/technische Konzeption (SD) und Betrieb (B) sind nicht berücksichtigt.

Scrum
Scrum punktet in den Software-Engineering-Disziplinen Projekt-Management (PM) und Requirements-Management (RM). Gut abgedeckt sind auch das Qualitäts-Management (QM) und die Integration/Einführung (INT). Nur mäßige Unterstützung gibt es dagegen für Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Wartung (W). Der Betrieb (B) ist nicht abgedeckt.

Test Driven Development
Seine Stärken zeigt TDD naturgemäß im Bereich Test (T), aber auch bei der Implementierung (IMP). Gute bis mittlere Abdeckung gibt es für das Qualitäts-Management (QM) und die Integration/Einführung (INT), während Wartung (W) und Requirements-Management (RM) nur schwach ausgeprägt sind. Keine Unterstützung erfahren die Disziplinen Betrieb (B), Projekt-Management (PM) sowie Systemdesign und technische Konzeption (SD).

Unified Process
Unter den Disziplinen im Software Engineering deckt UP das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Test (T) und Integration/Einführung (INT). Schwach ausgeprägt sind dagegen die Wartung (W), das Projekt-Management (PM) und das Qualitäts-Management (QM). Den Betrieb (B) unterstützt die Methode nicht.

Agile Unified Process
Der Agile Unified Process (AUP) deckt die Disziplinen Projekt-Management (PM) und Implementierung (IMP) vollständig ab. Gute Unterstützung kommt auch für das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD), den Test (T) und die Integration/Einführung (INT). Schwach ist die Methode dagegen in den Bereichen Qualitäts-Management (QM) und Wartung (W), während der Betrieb (B) überhaupt nicht unterstützt wird.

Essential Unified Process
EssUP hat seine Stärken in den Software-Engineering-Disziplinen Projekt-Management (PM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP). Gut abgedeckt sind auch Test (T), Integration/Einführung (INT) und Requirements-Management (RM). Etwas schwächer ist die Methode beim Qualitäts-Management (QM) und bei der Wartung (W) - der Betrieb (B) wird überhaupt nicht unterstützt.

Open Unified Process
Der Open Unified Process deckt die Software-Engineering-Disziplinen Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP) vollständig ab. Auch die Bereiche Test (T) und Integration/Einführung (INT) werden gut unterstützt. Schwach ist OpenUP dagegen bei der Wartung (W), während der Betrieb (B) überhaupt nicht berücksichtigt wird.

Usability Driven Development
Usability Driven Development besitzt seine Stärken in den Bereichen Test (T) und Integration/Einführung (INT). Gut bis befriedigend ist die Methode auch beim Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), bei der Implementierung (IMP) und beim Projekt-Management (PM). Schwächen gibt es bei der Wartung (W), der Betrieb (B) wird nicht unterstützt.

Das agile Wertesystem

Der Kern des Manifests vergleicht mit vier Aussagen jeweils zwei Werte und argumentiert, obwohl jeder dieser Werte generell als wertvoll erachtet wird, dass der erste im Sinne von Agilität größeres Gewicht hat als der zweite.

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

Diese Aussage respektiert die Tatsache, dass die wichtigsten Kriterien für einen Projekterfolg oder -misserfolg die an dem Projekt beteiligten Menschen und die Art ihrer Zusammenarbeit sind. Prozesse und Werkzeuge werden zwar als wertvoll erachtet - ansonsten würden wir gar nicht über (agile) Prozesse diskutieren, und die agile Gemeinschaft hätte wohl nicht so viele Werkzeuge erfunden (Frameworks für Unit Tests, Integrations- und Konfigurationswerkzeuge etc.). Aber wenn die Projektmitglieder im Team nicht gut zusammenarbeiten, helfen die besten Prozesse und Werkzeuge auch nicht viel.

• Lauffähige Software ist wichtiger als umfangreiche Dokumentation.

Diese Aussage wird vermutlich am häufigsten missverstanden. Menschen, die mit der agilen Entwicklung nicht vertraut sind, verstehen sie oft dahingehend, dass es in agilen Projekten keine Dokumentation gibt. Aber in der gleichen Weise, wie Prozesse und Werkzeuge eine wichtige Rolle spielen, gilt dies auch für die Dokumentation. Allerdings drückt dieser Wertevergleich aus, dass lauffähige Software der kritische Erfolgsfaktor für die Entwicklung ist. Dokumentation kann zur Unterstützung oder zum besseren Verständnis der lauffähigen Software notwendig sein, aber sie kann und sollte nicht als Selbstzweck dienen.

• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

Obwohl ein Vertrag benötigt wird, unterstreicht diese Aussage, dass der Vertrag nie ein Ersatz für eine gute Beziehung zum Kunden sein kann. Um ein Produkt erfolgreich zu entwickeln, ist ein regelmäßiger Austausch mit dem Kunden unabdingbar.

• Auf Änderungen reagieren ist wichtiger, als einem Plan zu folgen.

Diese Aussage weist darauf hin, dass es wichtiger ist, mögliche Änderungen in Kauf zu nehmen, speziell in Form von Anforderungsänderungen, als stur einen Plan zu verfolgen, den man vor einiger Zeit entworfen hat. Wir akzeptieren, dass sowohl der Kunde als auch das Projektteam über die Zeit dazulernen werden, und wir wollen dieses Gelernte berücksichtigen, indem wir es in die weitere Entwicklung einfließen lassen. Wenn in dem fertigen Produkt all das umgesetzt wurde, was der Kunde und wir am Anfang geplant haben, nicht aber das, was wir später herausgefunden haben und was wirklich benötigt wird, dann ist das Produkt mit Sicherheit ein Fehlschlag.

Systemische Vorgehensweise

Agile Entwicklung verfolgt einen systemischen Ansatz, der durch einen Regelkreis unterstützt wird. Dieser Regelkreis besteht aus folgenden Schritten:

Planen: In diesem ersten Schritt planen wir die jeweils nächsten Aktivitäten. Dabei handelt es sich meist um eine kurzfristige Planung, indem beispielsweise die nächste Iteration geplant wird, aber es kann sich auch um eine langfristige Planung handeln, um zum Beispiel das nächste Release aufzusetzen.

Machen: In dem zweiten Schritt führen wir die Aktivitäten aus, die wir im ersten Schritt geplant haben.

Überprüfen: Der dritte Schritt dient der Überprüfung beziehungsweise Analyse des Ergebnisses. Hat alles wie geplant funktioniert? Gab es etwas, das besonders gut funktioniert hat, so dass es ratsam wäre, wenn wir uns dieses Vorgehen merken? Gab es etwas, das gar nicht funktioniert hat, weshalb man sich für die Zukunft ein anderes Vorgehen überlegen sollte?

Anpassen: Basierend auf dem Ergebnis des vorherigen Schrittes definieren wir, welche Änderungen wir vornehmen müssen, um besser voranzukommen. Als Resultat entscheiden wir über die notwendigen nächsten Aktionen.

Der letzte Schritt in diesem Regelkreis dient als Input für den ersten Schritt in der nächsten Runde. Folglich werden bei der nächsten Planung die Aktionen, die im letzten Schritt der letzten Runde beschlossen wurden, berücksichtigt.

Risiko reduzieren

Die grundlegende Idee eines agilen Projekts besteht darin, nicht nur am Projektende, sondern frühzeitig und regelmäßig ein lauffähiges System zu liefern. Zu diesem Zweck wird die Lebenszeit des Projekts in Entwicklungszyklen gegliedert. In einem größeren Zyklus, genannt Release, wird ein Feature-Bündel (englisch: Feature Pack) fertiggestellt. Der kleinere Zyklus dient der Organisation von kleineren Segmenten, aber auch der Lieferung von kleineren Funktionalitäten. Dieser kleinere Zyklus wird Iteration genannt. Beide, Release und Iteration, haben als Ergebnis die Lieferung eines Produkts beziehungsweise ein potenziell lieferbares Produkt.

Der größte Vorteil einer derartigen Vorgehensweise liegt darin, dass sich aufgrund einer hohen Sichtbarkeit und Transparenz das Risiko stark reduziert.

Dadurch, dass man immer ein lauffähiges System hat, regelmäßig Rückmeldungen vom Kunden und über Tests erhält und den Fortschritt, den man mit jedem Inkrement macht, nicht auf Papier, sondern anhand eines realen Systems sieht, erhält man einen realistischen aktuellen Projektstatus. Dieser ermöglicht es, Entscheidungen bezüglich weiterer Lieferungen und notwendiger Aktionen zu treffen. Wenn beispielsweise im schlechtesten Fall festgestellt wird, dass der Kunde mit dem System nicht zufrieden ist und es auch unmöglich ist, das System wieder in die richtige Richtung zu drehen, dann besteht immerhin noch die Möglichkeit, das Projekt gleich und damit frühzeitig zu stoppen und nicht erst, wenn das ganze Geld ausgegeben wurde.

Produktivität ist relativ

Manchmal hört man das Argument, dass durch den Einsatz einer agilen Vorgehensweise ein Entwicklungsteam wesentlich produktiver wird, als wenn es eine andere Vorgehensweise verfolgen würde. Das kann durchaus der Fall sein, muss aber nicht. Agile Entwicklung verlangt von einem Team, dass es häufig ein lauffähiges System liefert. Diese Häufigkeit wird über die Iterationen definiert, die eine Zeitspanne von einer bis vier Wochen umfassen. Das lauffähige System wird über die Benutzbarkeit durch den Kunden definiert. Das heißt: Dadurch, dass alle zwei Wochen ein lauffähiges benutzbares System zur Verfügung gestellt wird, maximiert ein agiles Team den Geschäftswert für den Kunden.

Folglich kann ein Kunde die Entscheidung treffen, mit dem System früher als geplant in Produktion zu gehen. Das bedeutet aber nicht zwangsläufig, dass das Projekt als Ganzes, also die Gesamtfunktionalität, früher fertig ist als mit einer anderen Vorgehensweise. Im Gegenteil: Die frühe Markteinführung einiger Funktionalitäten kann auch Mehraufwand verursachen, da man ab diesem Moment rückwärtskompatibel sein muss.

Verständnisprobleme

Agilität wird in der Praxis oft weniger als Wertesystem, sondern mehr als eine Sammlung von Praktiken wahrgenommen, nicht selten wird eine bestimmte Praxis mit Agilität verwechselt. Doch Vorsicht: Agilität ist mehr als eine solche Sammlung. Praktiken wie zum Beispiel Pair Programming oder testgetriebene Entwicklung, beide bekannt von Extreme Programming, sind hervorragende Hilfsmittel, um das agile Wertesystem zu bewahren. Allerdings haben diese Praktiken nicht die Macht, das Wertesystem zu etablieren. So kann man beispielsweise erfolgreich paarweise programmieren und weiterhin einen linearen Entwicklungsprozess (Wasserfall) einsetzen.

Agil gleich undiszipliniert?

Ein anderes Problem: Vielfach wird Agilität mit "undiszipliniert" gleichgesetzt. Dieses Verständnis setzt eine agile Vorgehensweise mit einem Ad-hoc-Vorgehen gleich, für das keinerlei Planung benötigt wird und bei dem jeder einfach nach seinen Vorstellungen arbeitet. Manchmal wird der Begriff agil auch als Entschuldigung für eine mangelnde Vorbereitung benutzt. Da ist dann schnell das Argument zur Hand, dass man doch agil sei und deswegen weder planen noch sich vorbereiten müsse. Allerdings entspricht das genaue Gegenteil der Wahrheit - Agilität bedarf einer Menge Planung.

Um es noch deutlicher zu machen: Verglichen mit einer linearen Vorgehensweise erfordert eine agile wesentlich mehr Planung. Der Grund liegt darin, dass bei der agilen Vorgehensweise anders als bei einer linearen das eigentliche Artefakt, also der Plan selbst, relativ unwichtig ist - essenziell ist die Aktivität, das Planen. (ph)