Ein Vortrag von Jutta Eckstein, it Consulting, zum Thema „Agiles Projektmanagement“ stand gestern auf dem Programm. Ihre Enleitung war treffend und widerspiegelt wohl auch die Erwartungshaltung von uns und unseren Kollegen „Agilität ist wie Teenage Sex – Alle reden darüber, doch keiner weiss, wer es wirklich praktisch macht.“
Die Grundrinzipien und Leitlinen sind schnell umrissen (siehe auch hier) und mit gesundem Menschenverstand gut nachzuvollziehen:
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiaion
- Responding to Change over Following and Plan
Verglichen mit klassischem Projektmanagement mit vorab abgestimmten Scope, Zeit und Geld gibt es also den entscheidenen Vorteil, dass sich ändernde oder unausgesprochene (vielleicht auch unaussprechbare) Anforderungen einbezogen und beachtet werden können. Eigentlich ja schön, für Kunden wie auch für den Hersteller. Doch im praktischen Einsatz scheint das gar nicht so einfach zu sein:
- Kann Agilität bei der Vertragsbeziehung von zwei Partnern funktionieren, die sich gar nicht kennen? Ist nicht eine Vertrauensbeziehung notwendig, um den sich aendernden Scope eines Projektes mit allen Konsequenzen gegenseitig zu akzeptieren?
- Funktioniert agiles Projektmanagement in Ausschreibungsprojekten, wo ich aufgrund eines definierten Kriterienkatalogs (defined scope) eine Zeit- und Kostenschätzuung abgegeben habe?
- Wenn die Projektleistung „NUR“ ein Konzept oder eine Studie ist, wie komme ich zu Projektergebnissen, wenn doch die Anforderungen sich sehr dynamisch aendern und wandeln?
- Welche menschlichen / persönlichen Eigenschaften muss ich von den Teammitgliedern fordern, um in einer agilen Umgebung abrechenbare und wertvolle Ergebnisse zu erzielen? Kann das jeder?
- Agiles Vorgehen heisst nicht nur in kurzen Intervallen zeigbare Ergebnisse zu produzieren, sondern auch diese Ergebnisse schnell zu bewerten und freizugeben – ein Umstand der viele Kunden scheinbar überfordert, denn der allgemeine Kommunikationsaufwand steigt und es müssen kurzfristig, schnell Entscheidungen getroffen werden.
Doch werfen wir auch auf die Vertragssituation einen Blick mit gesundem Menschenverstand: Wenn es noch keine klaren Vorstellung über gewünschte Features und Scope gibt, dann ist doch ein Festpreisvertrag immer problematisch, egal ob agil oder per Wasserfall vorgegangen wird. Im agilen Vorgehen wird nur viel eher transparent, wenn es viele ungeklärte Punkte gibt. Ähnlich können die meisten anderen Bedenken bei genauerem Hinsehen zum grossen Teil entkräftet werden. Also keine keine Ausreden mehr: „Bei uns funktioniert das so nicht!“. Wie schon in Teil 3 unserer Wissensmanagement Präsentation angesprochen: Kultur (Agilität) ist ein Ziel, keine Vorraussetzung.
Agiles Projektmanagement und agile Softwareentwicklung bleiben ein spannnendes Thema und noch viele Fragen zum Praxiseinsatz sind offen. Auch im naechsten Meeting unserer lokalen PMI Gruppe steht das Thema auf der Agenda und die zahlreichen Anmeldungen bisher versprechen auch hier eine interessante Diskussion.
Wir haben im vergangenen Jahr ein Projekt mit einem unserer großen Kunden durchgeführt und uns dabei komplett auf agiles Vorgehen eingelassen, weil die Anforderungen von vorherein unklar waren und die Kompetenz auf Seiten des Auftraggebers nicht so weit ging, dass man sich hätte über die präzise Funktionalität im Vorfeld einigen können. Es ging um die digitale Abbildung eines Prozesses mit einer größtmöglichen Fehlerfreiheit. Wir haben ein paar Dinge gelernt in diesem Projekt:
1. Der Kunden muss sich auf den Dienstleister verlassen können. Uns hat es geholfen, dass wir eine langjährige Kundenbeziehung haben und in Zufriedenheitsbefragungen immer nahe 100 liegen. Das schafft Vertrauen, und das ist unbedingt notwendig.
2. Wir haben einen Festpreis vereinbart. In der Regel strebt man bei agilen Projekten ja eine Vergütung nach Aufwand an. Ich glaube, ein Festpreis ist auch möglich, wenn man die Prozesse im Projekt transparent hält und dem Kunden Einblick gibt in die Tätigkeiten und Aufwände. Interessanter Weise interessierte sich der Kunde viel mehr für den Verlauf des Projekts als in vergleichbaren Projekten, wo auf Basis starren Plans nach festen Anforderungen gearbeitet wird und allenfalls Meilensteine interessant sind.
Auch hier ist der grundlegende Faktor das Vertrauen. Wenn wir dem Kunden sagen: „Wenn Du dieses Feature willst, dann wird das 30% des Budgets kosten“, dann überlegen wir gemeinsam nach Alternativen oder bewerten Funktionalitäten im Blick auf Nutzen, Aufwand etc.
3. Der Kunde lernt unser Geschäft als Dienstleister verstehen und entwickelt eine Kompetenz im Blick auf budgetangemessene Realisierungsmöglichkeiten. Damit steigt auf Kundenseite die Akzeptanz unsere Empfehlungen und Entscheidungen.
Am Ende des Tages haben wir vielleicht nicht alles realisiert, was möglich gewesen oder spezifiziert geworden wäre. Aber wir haben ein besseres System realisiert, weil wir es exakt auf die Bedürfnisse zugeschnitten haben. Die gewünschte Fehlerfreiheit lässt sich m.E. in einem agilen Projekt per se viel besser erreichen.
Und jetzt bin ich gespannt auf das im April anstehende Audit zur ReZertifizierung unserer Qualitätsstandards. Da werde ich das Projekt nämlich einbringen – und hoffentlich feststellen, das unsere Firma an manchen Stellen ebenso weit ist wie unser Kunde.
Eigentlich ist das garnicht so weit von dem entfernt wie die Projekte bisher laufen, lediglich die Sichtweise ist eine andere. Während die herkömmliche Projektvorgehensweise Änderungen als change requests erachtet (ein für alle Beteiligten negativ behafteter Terminus), macht agiles Vorgehen die sich ständig verändernde Projektumwelt zum zentralen Bestandteil. Es ist entwicklungsorientierter, da wir es bei Individualsoftware nie mit im voraus vollständig abgrenzbaren Anforderungen zu tun haben. Und menschlicher, da wir mit den immer auftretenden Unsicherheiten natürlicher umgehen können. @Markus: sauber, wie Du das mit einem vom Kunden durch Budgetzwänge oft gewünschten Festpreis vereinbarst und dabei den Kunden noch mehr involvierst.