- Agilität (95)
- Allgemein (11)
- Ankündigungen (29)
- Buchtipp (13)
- Crystal (7)
- it-agile-blog-planet (9)
- Konferenzen (23)
- Kunden (5)
- Lean Software Development (1)
- Management (37)
- Planung (20)
- Politik (14)
- Praktiken (7)
- Refactoring (11)
- Scrum (15)
- Software Design (10)
- Surftipp (28)
- Testgetriebene Entwicklung (8)
- Werkzeuge (7)
- Zitate (8)
- 4.2.2012: Selbstorganisation bei it-agile
- 4.2.2012: Reanimation meines Blogs
- 21.1.2010: it-agile und Coldewey Consulting gehen zusammen
- 11.12.2009: Aufspalten einer User Story
- 6.11.2009: Vortrag auf der W-Jax zu langfristiger agiler Planung
- 2.10.2009: Alistair Cockburns Keynote "I come to bury Agile, not to praise it" als Video
- 22.9.2009: Apple und die Macht einer Vision
- 21.9.2009: Pair Programming in der New York Times
- 10.9.2009: Neue XING-Gruppe zu Lean Software Development
- 9.9.2009: CSM+Crystal Kurse mit Alistair Cockburn
- Februar 2012
- Januar 2010
- Dezember 2009
- November 2009
- Oktober 2009
- September 2009
- August 2009
- Juli 2009
- Juni 2009
- Mai 2009
- April 2009
- März 2009
- Februar 2009
- Januar 2009
- Dezember 2008
- November 2008
- Oktober 2008
- September 2008
- Juli 2008
- Juni 2008
- Mai 2008
- April 2008
- März 2008
- Februar 2008
- Januar 2008
- Dezember 2007
- November 2007
Ziele agiler Planung
Wenn agile Planung richtig durchgeführt wird, leistet sie einen wichtigen Beitrag, das Projekt zum Erfolg zu führen. Dabei ist Erfolg nicht als Einhaltung von Zeit, Umfang, Budget und Qualität definiert, sondern als Beitrag zur Maximierung des Geschäftsnutzens der Software. Das bedeutet, dass agile Planung sowohl die Effektivität der Softwareentwicklung fördern sollte, als auch deren Effizienz – und zwar in dieser Reihenfolge.
Zur Förderung der Effektivität werden mehrere Teilziele verfolgt:
- Das Team soll sich darauf fokussieren durch die Anwendung den geschäftlichen Mehrwert des Systems zu optimieren
- Das Planungsverfahren soll Änderungen unterstützen und nicht erschweren. Änderungen gelten im agilen Kontext als unvermeidlich und sind Teil des Lernprozesses aller Beteiligten
- Risiken sollen minimiert werden, also entweder frühzeitig ausgeschaltet oder durch entsprechende Sicherungen unschädlich gemacht werden. In diesem Sinne ist Risikomanagement integraler Bestandteil agiler Planung
Weitere Teilziele sollen die Effizienz der Entwicklungsarbeit optimieren:
- Voneinander abhängige Aktivitäten sollen koordiniert werden
- Die Planung soll realistische Voraussagen ermöglichen, damit sich andere Projektbeteiligte rechtzeitig darauf einstellen können. Zum Realismus zählt auch das explizite Eingeständnis, dass jede Voraussage nur mit einer gewissen Wahrscheinlichkeit eintritt. Eine Abschätzung für diese Wahrscheinlichkeit ist eine der „Königsdisziplinen“ agiler Planung
- Die Planung sollte eine Basis für realistische Statusbestimmungen liefern. Dafür muss klar definiert sein, wann eine Aufgabe abgeschlossen ist. Dieses Kriterium muss sich an dem Beitrag zum Projektergebnis orientieren, es muss eindeutig feststellbar sein und darf nicht interpretierbar sein. Der Fortschritt sollte sich an den ausgeräumten Risiken orientieren und der Status muss ausreichend Informationen enthalten, um schnelle Eskalationen zu ermöglichen
Interessant sind aber auch Ziele, die oft mit Plänen verbunden werden, die aber von agilen Planungsverfahren explizit nicht verfolgt werden:
- Es soll keine korrekte Vorhersage des Projektablaufs erstellt werden, weil das nicht möglich ist. Erfolg ist der geschaffene Mehrwert, nicht das Einhalten eines Plans
- Die Mitarbeiter- und Ressourcenbelegung soll nicht vorausgeplant werden, weil diese Pläne in einem nicht vorhersehbaren Umfeld sehr aufwändig und fragil sind und keinen Nutzen stiften
- Agile Planung ist kein Vehikel, um über „ambitionierte Pläne“ Druck auf das Team auszuüben. Hilfreicher Druck kommt in agilen Teams vom gemeinsam verfolgten Ziel. Übermäßiger Druck führt zu Qualitätseinbußen und damit kritischen Zeitverzögerungen. Die Grenze zwischen heilsamer Fokussierung und übermäßigem Druck liegt deutlich niedriger, als die meisten Manager glauben
- Agile Planung ist kein Vehikel, um Verantwortung weiter zu schieben, indem man unrealistische Zulieferungstermine aufstellt und dann den Verzug verantwortlich macht für eigene Verzögerungen. Da Planungen stets mit Wahrscheinlichkeiten versehen sind, versucht wird, Abhängigkeiten aufzulösen und die Teams für Risiken Rückfallstrategien aufbauen, taugen solche Spielchen nicht mehr, um die Verantwortung abzuwälzen
- Agile Planung erzählt Managern nicht, was sie gerne hören wollen, sondern bietet einen realistischen Blick auf das, was möglich ist. Das erfordert für viele Manager Umgewöhnung, erlaubt ihnen aber, früher zu reagieren und schädliche Auswirkungen zu begrenzen
Agile Planung ist damit ein wichtiges Instrument für das Team und das Management, die Wertschöpfung eines Projekts nicht so sehr trotz, sondern mit Hilfe vieler Änderungen zu optimieren. Wie Jim Highsmith schreibt: „Agile Projektmanager kümmern sich bevorzugt um Wertschöpfung, Teams und Anpassbarkeit. Diese sind für ein erfolgreiches Projekt wichtiger, als die Beschränkungen durch Zeit, Kosten und Anforderungen“ („Cutter Agile E-Mail Advisor“ am 13.11.2008, Cutter Consortium).
5.5.2009 bei 08:58
Jens, danke für diesen Beitrag - er bringt es genau auf den Punkt! Anschlussfrage dazu: Wo liegt für Dich die Abgrenzung zwischen “Die Planung soll realistische Voraussagen ermöglichen” und “Es soll keine korrekte Vorhersage des Projektablaufs erstellt werden”? In der Regel fordern Manager das zweite, wenn Du das erste versprichst. Wie gehst Du damit um?
Gruß,
Matthias
5.5.2009 bei 08:59
Jens, könntest Du bitte noch einen Link auf den Cutter Agile E-Mail Advisor einfügen?
6.5.2009 bei 13:30
Hallo Mattias,
ich denke, es gibt zum einen den wesentlichen Unterschied zwischen “Voraussagen über Projekt*ergebnisse*” und “Voraussagen über den Projekt*verlauf*”, zum anderen einen Unterschied zwischen “realistisch” und “korrekt”. Verfolge ich den Status eines Projekts, indem ich die Einhaltung des geplanten Ablaufs überwache, ist das etwas völlig anderes, als wenn ich den Projekterfolg am Nutzen tatsächlich gelieferter Ergebnisse messe.
Die Argumentation geht darüber, dass der geplante Verlauf keine Aussage über den wahren Projektstatus ermöglicht, höchstens über die Treffsicherheit der Planung. Mit der wird aber kein Geld verdient. Geld wird mit der lauffähigen, qualitativ hochwertigen Software verdient und da müssen entsprechend auch Planung und Monitoring ansetzen.
Viele Grüße
Jens
6.5.2009 bei 13:33
Zum Link: Die E-Mail Advisor sind ein Service für die Kunden von Cutter, man kann lediglich ein vierwöchiges Probeabo bestellen. Von daher kann ich leider keinen Link für diesen Advisor angeben.
Jim arbeitet aber derzeit an einem Buch zu agilen Organisationen, das noch heuer erscheinen soll, in dem er das sicher ausführlicher darstellt.