Jedes Projekt agiert auf Grundlage von Vereinbarungen zwischen den Beteiligten Organisationseinheiten bzw. Unternehmen, wobei diese mehr oder minder explizit und formalisiert sein können. Ob diese Vereinbarungen tatsächlich als schriftlicher und detaillierter Vertrag vorliegen oder nicht, ist unwesentlich. Professionelle Verträge sind immer ein wesentlicher Erfolgsfaktor, wenn allerdings ein Vertrag in Widerspruch zum tatsächlichen Vorgehen im Projekt steht, behindert dies die Projektarbeit ebenso schwerwiegend, wie ein guter Vertrag diese wesentlich erleichtert. Daher wird hier von einer Vertragsphilosophie gesprochen, die dem Handeln aller Beteiligten zugrunde liegen sollte, wenn ein Projekt mit sinnvoll eingesetzten agilen Elementen abgewickelt werden soll.
Klassische Vorgehensmodelle haben oft ihre Berechtigung
Zunächst muss festgehalten werden, dass für wesentliche Teile eines typischen IT-Projektes klassische Vertragsmodelle sinnvoll und notwendig sind, so z.B. für Planungsleistungen, Lizenzen, Infrastrukturleistungen etc. Ebenso gilt dies für die Schätzung des Gesamtaufwandes des Vorhabens (z.B. anhand eines Lastenheftes). Dies ist ja schon eine notwendige Grundlage für die Entscheidung, ob ein Projekt überhaupt gestartet werden soll.
Für jene Teile des Projektes, in denen die Entwicklung und/oder die Anpassung von Software erfolgt, gelten teilweise andere Regeln. So wird für die agil abzuwickelnden Teile des Vorhabens ein passendes Leistungsvolumen (Skills, Kapazitäten, Durchlaufzeit) eingekauft. Die Laufzeit des Entwicklungsprojektes wird in gleich lange Intervalle („Iterationen/Sprints“) aufgeteilt, wobei in jeder Iteration Software geliefert wird, die vom Kunden/Anwender getestet werden kann.
Ablaufsteuerung ist der zentrale Hebel für den Erfolg
Die Feinsteuerung erfolgt aufgrund einer Aufwandsbewertung der Features („Story Points“/Planaufwand). Die konkreten Iterationsinhalte werden zu Beginn nur grob geplant, nach jeder Iteration erfolgt eine Aktualisierung, die Inhalte der jeweils nächsten und meist auch übernächsten Iteration werden im Detail fixiert.
Ein Spezifikum agiler Projekte ist auch die unveränderliche Iterationsdauer („Time Boxing“), innerhalb einer Iteration nicht realisierte Features werden nicht durch Terminverschiebung nachgeliefert, sondern zurück in den „Backlog“ gestellt und in einer späteren Iteration eingeplant.
Auf Grundlage der tatsächlichen Iterationsergebnisse wird eine regelmäßige Hochrechnung durchgeführt, die je Iteration abgearbeiteten Features („User Stories“) werden in dem für agile Projekte typischen „Burn-Down-Chart“ dargestellt. Letztlich ist dies die allgemein bekannte Earned-Value‑Darstellung, wenn auch mit umgekehrten Vorzeichen: man zeigt, wie die noch zu leistende Arbeit reduziert wird („burned down“), während der Earned Value die bereits geleistete Arbeit abbildet.
Da am Ende jeder Iteration funktionierende Software geliefert werden muss, zeichnet sich die Fortschrittsmessung solcher Projekte durch eine höhere Aussagekraft und Robustheit gegenüber Fehleinschätzungen des Arbeitsfortschritts aus. Werden Abweichungen vom geplanten Fortschritt je Iteration („Velocity“) erkannt, bleibt auch solchen Projekten nicht erspart, darauf mit den üblichen Maßnahmen zu reagieren, die da sind:
– Projektabwicklung optimieren
– Features streichen/zurückstellen
– Kapazität erhöhen
– Zusätzliche Iterationen und Verschiebung des Endtermins.
Herausforderungen für die Vertragsgestaltung bei agilen Projekten
Als Auftraggeber von Projekten mit agilen Elementen ebenso wie als Projektmanager muss man darauf achten, die spezifischen Herausforderungen der mit agiler Methodik abgewickelten Projektteile zu erkennen und darauf adäquat zu reagieren. Wird in Projektaufträgen bzw. in Verträgen eine Philosophie der Projektsteuerung festgeschrieben, die das nicht richtig adressiert, gerät man entweder in einen vertragsfreien Raum oder man kollidiert ständig mit Vertragsbestimmungen, die nicht zum tatsächlichen Vorgehen passen.
Generell muss man feststellen, dass agile Softwareentwicklung im Kern auf einer Aufwandsverrechnung beruht, da ein fixer Werklohn mangels detaillierter Ergebnisbeschreibung nicht definiert werden kann. Die daraus resultierende Unschärfe wird allerdings nach meinen Erfahrungen von allen Beteiligten regelmäßig stark überschätzt: Jeder weiß aus eigener Erfahrung, dass Fixpreise durch Change Requests regelmäßig ausgehebelt werden. Daher erscheint mir eine Aufwandschätzung mit eingestandener Bandbreite sowie einer darauf aufsetzenden Projektsteuerung durch Burn-Down-Charts als die ehrlichere und de facto auch wirksamere Methode. Man muss allerdings der hier sichtbar gemachten Unsicherheit ins Auge blicken können, wozu nicht alle Auftraggeber bereit und in der Lage sind. Dies gilt umso mehr, wenn die Umsetzung nicht durch die unternehmenseigene IT-Abteilung erfolgt, sondern durch ein externes Unternehmen.
Agile Projekte erfordern mehr Projektmanagement-Skills
Eine zentrale Herausforderung ist also: professionelle Projektsteuerung ersetzt detaillierte Ergebnisdefinition. Dafür muss das Management der Unsicherheit ins Auge blicken, mehr dazu hier. Abweichungen werden allerdings viel früher erkannt als in klassischen Projekten. Sie können aber nicht an einem vertraglich fixierten detaillierten Pflichtenheft gemessen werden. Daher müssen geeignete Prozesse (auch vertraglich) definiert und gelebt werden.
Agile Projekte können daher nur gelingen, wenn es eine aktive und sachkundige Mitwirkungsleistungen des Kunden gibt, wobei dies im Falle einer externen Beauftragung nicht nur für die Anwenderbereiche („Business“) gilt, sondern auch für die IT-Abteilung des Auftraggebers. Dies erscheint gegenüber einem Wasserfallmodell als Mehraufwand. Ob man diese Ersparnis in späteren Projektphasen durch Nachbesserungen wieder verliert, sei dahingestellt. Ich wage die Behauptung, dass der tatsächliche Gesamtaufwand gut gemanagter agiler Projekte eher geringer, aber anders verteilt ist als bei Projekten nach einem Wasserfallmodell.
Ebenso gilt: Agiles Vorgehen erfordert vertrauensvolle Zusammenarbeit. Dafür müssen Bereitschaft und Fähigkeit zu interdisziplinärer Arbeit und social skills bei allen Beteiligten verfügbar sein. Vertrauen ist hier im doppelten Sinn zu verstehen, mehr dazu hier.
Sachlich gesehen, ist das Vertrauen in die Angemessenheit der Aufwände des Realisierungspartners ein entscheidender Erfolgsfaktor. Das Aushandeln des Verzichts auf Features, um das Budget und den Endtermin zu halten, funktioniert nur, wenn die vom Auftragnehmer geschätzten Realisierungsaufwände vom Auftraggeber als angemessen und nachvollziehbar gesehen werden. Regelmäßig als überhöht empfundene Aufwandschätzungen können durchaus auf Architekturmängel zurückzuführen und daher in Wirklichkeit korrekt sein. Sie sind also einer unzureichenden Projektvorbereitung geschuldet. Damit bleibt aber das Problem gleich, nur die Ursache liegt in der Vergangenheit.
Zusammenfassung
Wie überall, ist auch bei der Entscheidung für oder gegen eine agile Projektabwicklung jede Form von Fundamentalismus schädlich. Es geht um eine sinnvolle Kombination, um hybride Ansätze des Managements von IT-Projekten, die auf die gegebenen projektspezifischen Umstände Rücksicht nehmen. Umso mehr gilt daher: Auch agile Projekte müssen gut gemanagt werden! Es gibt keine Erfolgsgarantie!
Leichter ist es, Misserfolgsgarantien zu geben. Hier eine kompakte Anleitung, wie man Projekte zum Scheitern bringt.
Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).
Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.
Zum Abschluss noch eine Buchempfehlung:
