Projektreporting in agilen Projekten

Einleitung

Bei software architects leben und atmen wir agile Entwicklung. In den ersten Tagen unseres Unternehmens, als wir die ersten Stückchen unseres Flagship-Produkts time cockpit bauten, starteten wir mit Scrum. Mit der Zeit sind wir zu Kanban gewechselt, aber die agilen Prinzipien sind seit vielen Jahren unsere ständigen Begleiter.

Neben der Entwicklung von time cockpit lizensieren wir auch unsere Basistechnologie genannt Cockpit Framework (kurz CoFX) an andere ISVs und helfen diesen, cloud-basierende SaaS-Lösungen zu bauen. Natürlich arbeiten wir auch bei solchen Projekten agil. Aber eine Sache unterscheidet sich: das Projekt-Berichtswesen. Wenn auch die meisten unserer Kunden die Ideen agiler Entwicklung verstehen, zwingen die Tatsachen der realen Geschäftswelt sie in Budgets, Meilensteinen, Projektplänen etc. zu denken.

Über die Jahre haben wir eine solide Praxis für das Berichtswesen in agilen Projekten entwickelt. Es versucht, die (scheinbare) Lücke zwischen klassischem Projekt-Management mit starren Voraus-Projektplänen und den sich ständig verändernden Umgebungen in agilen Projekten zu überbrücken. In diesem Artikel möchten wir unsere wichtigsten Erfahrungen teilen. Zusatzlich beschreiben wir die KPIs, auf die sich unsere Projektberichte stützen.

Die Kernfrage: Sind wir auf dem richtigen Weg?

„Sind wir auf dem richtigen Weg?“ Das ist die Kernfrage, die unsere Kunden bei unserem regelmäßigen – normalerweise monatlichen – Projektbericht beantwortet haben möchten. Wir brechen diese Frage herunter auf zwei Aspeke: 

1. Wie geht es uns in Sachen Budget? 
2. Werden wir zeitgerecht fertig?

Diese Fragen sind nicht spezifisch für agile Software-Projekte. Sie spielen eine wichtige Rolle seitdem projektorientierte Arbeit existiert. Daher mussten wir nicht einen komplett neuen Bericht und KPI Framework erfinden. Wir konnten auf etwas aufbauen, das bereits da war: Earned Value Management (EVM) (siehe auch Earned Value Analysis für mehr Informationen in deutsch).

Standardisierung und praktischer Gebrauch von EVM

EVM ist im ANSI/EIA-748 Standard definiert [1]. Dieser Standard spielt vor allem für Lieferanten der US Regierung und dem US Department of Defense (DoD) eine wichtige Rolle. Die National Defense Industrial Association (NDIA) hat einen zusätzlichen Leitfaden publiziert [2] wie die US Regierung EVM in ihren Projekten einsetzen muss. Ein EVM-Einführungsguide ist auch vom US DoD verfügbar [3]. Diese Dokumente können hilfreich sein, wenn Sie ein tieferes Verständnis von EVM und seiner praktische Einführung wollen.

Im deutschsprachigem Europa gibt es einen ähnlichen Standard DIN 69901. Er definiert den Begriff Fertigstellungswert, der dem Betriff Earned Value von EVM entspricht.

Earned Value Management (EVM)

Die Basisidee von EVM ist, dass man das Projektbudget durch Beenden der terminiserten Arbeiten „verdienen“ muss. Am Beginn des Projektes ist der Earned Value EV 0 weil Sie noch nichts fertiggestellt haben. Am Ende des Projektes haben Sie das gesamte Budget at Completion (BAC) verdient, vorausgesetzt dass Sie alle geplanten Arbeiten abgeschlossen haben.

Die folgende Grafik illustriert die Beziehung zwischen Earned Value, Planned Value und Actual Cost. Am Meilenstein t1 – das könnte z. B. ein Sprint-Meeting oder eine Monatsbericht sein – hat das Team mehr Arbeit als geplant fertiggestellt (EV > PV, Schedule Variance SV > 0). Das Team ist daher dem Zeitplan voraus. Am Meilenstein t2 ist die Situation anders. Es hätte bei t2 mehr Arbeit fertig sein sollen (EV < PV, SV < 0). Zusätzlich hat das Team mehr Geld verbraucht als bis t2 geplant war (AC > EV, CV < 0).

Lassen Sie mich die Basics von EVM mittels eines einfachen Beispiels erklären. Denken Sie an die Zeit zurück, als Sie noch ein kleines Kind waren und Ihre Eltern haben Ihnen 10 EUR für’s Rasenmähen versprochen. Aus Erfahrung wissen Sie, dass diese Arbeit zwei Stunden dauern wird. Ihr Stundensatz wäre daher 5 EUR.

• EVM würde die 10 EUR Budget at Completion (BAC) nennen.
• Sie planen, etwas zu trinken nachdem die erste Hälfte des Rasens gemäht ist. EVM würde das einen Meilenstein (Milestone) nennen.
• Der Planned Value (PV) um den Meilenstein zu erreichen wäre PV = 10$ * 50% = 5 EUR.
• Ihr Zeitplan (Schedule) laut EVM wäre, den Meilenstein nach 1 Stunde zu erreichen und die Arbeit nach 2 Sunden zu beenden.

Ausgestattet mit diesem Wissen holen Sie Sich den Rasenmäher und fangen an. Nach 1,5 Stunden haben Sie 50% des Rasens gemäht. In diesem extrem vereinfachten Beispiel könnte EVM Ihnen helfen, um die oben gestellte Frage zu beantworten: Bin ich auf dem richtigen Weg?

Laut EVM würden Sie den Earned Value (EV) kalkulieren, wenn Sie Ihren Meilenstein erreicht haben:

• EV = 50% (completed work) * 10 EUR (Budget) = 5 EUR

Nun können Sie EV mit den Actual Cost (AC) vergleichen und bekommen die Cost Variance (CV):

• AC = 1,5 Stunden (Zeit, um den Meilenstein zu erreichen) * 5 EUR (Std. Satz) = 7,50 EUR
• CV = EV - AC = 5 EUR - 7,50 EUR = -2,50 EUR

Ein negativer Wert bei CV zeigt an, dass Sie beim Budget nicht auf dem richtigen Weg sind. Ihr Ziel müsste ein CV >= 0 sein.

Sie können ebenso einen Richtwert erhalten, ob Sie zeitgerecht fertig werden. Dafür können Sie die Schedule Variance (SV) nach 1 Stunde Arbeit kalkulieren:

• SV = 0 EUR (EV nach 1 Stunde, weil Sie keinen Meilenstein erreicht haben) - 5 EUR (Planned Value PV nach 1 Std.) = -5 EUR

Auch hier ist der negative Wert ein Hinweis darauf, dass Sie nicht im Zeitplan sind. Ein Manager müsste hier tiefer graben, das Grundproblem finden und entsprechende Maßnahmen setzen. 

Vorausplanung für EVM in agilen Projekten?

Auf den ersten Blick sieht EVM für jemanden, der die Prinzipien agiler Entwicklung schätzt, fürchterlich altmodisch aus. Um EVM’s KPIs kalkulieren zu können braucht man ein Gesamtbudget, einen Meilenstein-Plan, Arbeitsbeschreibungen mit Kostenschätzungen, Zeitpläne usw. All dies setzt Planung im Vorhinein voraus. Aber bedeutet agil nicht das Vermeiden von großen Plänen?

Agile bedeutet nicht, dass Vorausplanung unerwünscht oder sogar unmöglich ist. In seinem Buch The Scrum Field Guide [4] beschreibt der Autor Mitch Lacey, wie Release-Planung in Scrum funktioniert. Der Ausgangspunkt ist der Product Backlog. Wann immer wir ein Projekt mit einem Kunden starten, beginnen wir mit Scoping-Workshops in denen wir die wichtigsten Anforderungen ausarbeiten (auch bekannt als Epic Stories). Sie machen das anfänglichen Product-Backlog aus.

Ein Buch, das wir in dieser Projekt-Phase sehr weiterempfehlen ist Stephen Withall’s Software Requirement Patterns (Best Practices) [5].

Als Nächstes setzen wir mit dem Kunden den ersten Release-Umfang fest. Das Product-Backlog für das erste Release gibt uns alles, was wir für den Start mit EVM brauchen. Es macht nichts, ob Sie relative (z. B. Story Points, T-Shirt sizes) oder absolute Zahlen (z. B. Personentage, Arbeitsstunden, Euro) wählen, um den Aufwand für die Gegenstände im Product Backlog zu schätzen. Sie können immer den EV kalkulieren und ihn mit dem PV vergleichen.

Nutzen Sie Bereiche anstelle von Einzelwert-Schätzungen

Regelmäßige Leser unseres Blogs wissen, dass wir auf Bereichsschätzungen Vertrauen, wenn es um Aufwandsschätzungen geht. Das beeinflusst die Art wie wir den PV handhaben, wie die folgende Illustration veranschaulicht. Unsere Kunden erhalten immer Schätzungen in Form von Unter- und Obergrenzen. In vielen Fällen gilt die Obergrenze gleichzeitig als Obergrenze für die Projektkosten.

Praktisches Beispiel

Wie sieht das in der Praxis aus? Gehen wir von einem ziemlich einfachen Projekt aus:

1. DasProduct Backlog besteht aus 5 Arbeitsbereichen (= Epic Stories).
2. Für jeden Backlog-Bereich haben wir eine Schätzung in Personentagen (Unter- und Obergrenze).
3. Die Projektmitarbeiter zeichnen ihre Arbeitszeit pro Arbeitsbereich auf.
4. Annahmen (Vereinfachungen):
   1. Lineares Ressourcen Investment (wenn der Plan weniger Ressourcen am Beginn und mehr Ressourcen am Ende annehmen würde, wäre es komplexer).
   2. Nur direkte Kosten, indirekte Kosten werden bei der Berechnung nicht berücksichtigt.
   3. Nur Personalkosten, keine Materialkosten.

Die folgende Tabelle zeigt, wie ein simpler Projekt-Bericht aussehen könnte. Er startet mit der Aufwandsschätzung, den aktuellen Kosten und einer Schätzung nach Beendigung pro Arbeitsbereich. Basierend auf diesen KPIs lassen sich EV, PV, CV, und SV kalkulieren. Wie Sie in der Tabelle sehen können ist das Projekt im Zeitplan (SV > 0). Was das Budget angeht ist das Projekt nicht ganz perfekt da CV < 0 ist verglichen mit der Untergrenze aber noch > 0 im Vergleich zur Obergrenze. Das wäre für uns ein klarer Hinweis, dass die Kosten und das Budget bei diesem Projekt genau im Auge behalten werden müssen.

Aufwandserfassung in time cockpit

Den Aufwand jeden Monat zu analysieren ist wichtig aber nach unserer Erfahrung nicht ausreichend. Daher überwachen wir den Aufwand kontinuierlich indem wir entsprechende time cockpit Listen verwenden. Sie zeigen uns den geschätzten Aufwand pro Arbeitsbereich (Untergrenze, da wir immer versuchen diese einzuhalten) und vergleichen ihn mit dem aktuellen Aufwand. Die folgende Abbildung zeigt so eine time cockpit Liste. Sie stammt aus einem eher kleinen Projekt direkt aus unserem Produktiv-System (zum Vergrößern bitte klicken).

Wo ist die Agilität?

Wie oben erwähnt, kann EVM definitiv bei agilen Projekten eingesetzt werden. Allerdings existiert ein gewisses Risiko Agilität zu verlieren. Es ist wichtig, dass alle Projektmanager verstehen, dass der Plan der den EVM Kalkulationen zugrunde liegt, nicht unveränderlich ist. Er muss während des Projektes dem Gelernten angepasst werden. Wenn sich das Product-Backlog ändert, müssen auch EVM Kalkulationen entsprechend geändert werden.

Nach unserer Erfahrung ist das Geheimnis des Erfolges sicherzustellen, dass die Budgetverantwortlichen den agilen Ansatz verstehen. Sie müssen lernen, dass agile Projekte keinen eingefrorenen Plan haben, der sich nicht mehr ändern darf. Wir haben gesehen, dass EVM-basierende Berichte in einem Scrum-Projekt z. B. Product Ownern hilft, Budget-Probleme in einem frühen Projekt-Stadium zu erkennen.

Heute setzen viele Teams EVM in agilen Projekten ein und schreiben über ihre Erfahrungen. Wenn Sie tiefer in dieses Thema eintauchen wollen, kann ich Ihnen folgende Artikel empfehlen: Earned Value for Agile Development und AgileEVM – Earned Value Management in Scrum Projects.

Lessons Learned

Über die Jahre mussten wir einige Lektionen in Sachen Projektbericht auf die harte Tour lernen. Hier sind die Top-Learnings, die wir mit Ihnen teilen wollen:

1. Eine gute Projektberichts-Praxis ist wichtig und viele Teams kämpfen damit [6].
   EVM ist eine gute Erweiterung für z. B. Scrum da es hilft, Budget-Probleme in einem frühen Projektstadium aufzudecken.
2. Agiles Projektmanagement eliminiert nicht den Bedarf von Vorausplanung. Trotzdem sollten Sie den Aufwand für Vorausplanung genau managen und jede Planungsarbeit, die nicht absolut notwendig ist für das Anfangsbudget und die Scoping-Phase, verschieben.
3. Vergewissern Sie sich, dass alle Projektmanager (inkl. Budget-Verantwortliche) die Idee der agilen Entwicklung verstehen.
4. Die Qualität des EVM-basierenden Berichts hängt größtenteils von der Schätzung des Fertigstellungsgrades ab. Daher ist eine solide Done-Done-Checkliste ausschlaggebend für EVM. Sonst werden Sie unerfreuliche Überraschungen am Ende des Projektes erleben.
5. Mit der Cloud wechseln EDV-Kosten von indirekten zu direkten Kosten. Herkömmlich werden die Kosten für Entwicklung oder Servertests nicht als Projektkosten kalkuliert. Die variable Kostennatur der Cloud ermöglicht es Ihnen, EDV-Kosten leicht spezifischen Projekten zuzuordnen. Bei größeren Projekten kann das ein beachtenswerter Kostenblock sein.
6. Vergessen Sie nicht, aufgeteilte Aufwände zu kalkulieren und auszuwerten (z. B. allgemeine Koordinationskosten, Sprint Meetings, usw.).
7. Kalkulieren Sie nicht zu akribisch. Meistens reicht es aus, KPIs nur auf Projekt-Level zu kalkulieren. Wenn das Ergebnis anzeigt, dass es ein Problem gibt, können Sie in die Details gehen.
8. Scrum Burn Charts sind EVM ein bisschen ähnlich. Burn-Charts auf Sprint-Level sind aber nicht genug. EVM, wie in diesem Artikel beschrieben, hilft dem Product Owner die Kosten und den Zeitplan über Sprintgrenzen hinweg zu managen.

Quellenverzeichnis

[1] Electronic Industries Alliance EIA, ANSI/EIA-748-1998: Earned Value Management Systems, http://www.srs.gov/general/EFCOG/02GovtReferences/03NDIAANSI/ANSIEIA748.pdf, 1998

[2] National Defense Industrial Association (NDIA) Program Management Systems Committee (PMSC), ANSI/EIA-748-A Standard for Earned Value Management Systems Intent Guide, http://www.srs.gov/general/EFCOG/02GovtReferences/03NDIAANSI/NDIAIntentGuide.pdf, 2005

[3] US Department of Defense, Earned Value Management Implementation Guide, http://guidebook.dcma.mil/79/EVMIG.doc

[4] Lacey M, The Scrum Field Guide – Practical Advice for Your First Year, Chapter 11. Release Planning, Addison-Wesley, ISBN 0-321-55415-9

[5] Withall S., Software Requirements Patterns (Best Practices), Microsoft Press, ISBN 0-735-62398-8

[6] Pfister E. et al, Key Performance Indicators, in The Swiss Project Management Review Magazine, 6/2010, page 19ff, http://www.pmi-switzerland.ch/pm@ch/201008/PM@CH-Edition6_Summer-2010.pdf