Dieser Artikel basiert auf meiner Session "Controlling in agilen Software-Projekten", die ich am 09.04.2016 auf den Drupal Business and Community Days in Heidelberg gehalten habe.

Controlling in agilen Software-Projekten: Session von Ralf Hendel auf den Drupal Business and Community Days in Heidelberg 2016
Controlling in agilen Software-Projekten: Session auf den Drupal Business and Community Days in Heidelberg 2016

Herausforderung

Aussagen über einen zukünftig zu erwarteten Projektverlauf stellen den Versuch dar, Prognosen über Ungewissheit abzugeben: Niemand kann verbindlich vorhersagen, was in der Zukunft tatächlich geschehen wird.

Je länger die Laufzeit von Projekten ist, desto mehr Umgebungsvariablen können sich während der Umsetzung ändern. Für wasserfallartige Projekte vergrößert dies die Möglichkeit zu Scheiterns enorm. bei klassischen Projekten bedeutet Controlling in erster Linie die Beantwortung kaufmännisch relevanter Fragen: mit Hilfe von Change-Management wird der Mehr- oder Minderaufwand sich ändernder Anforderungen erfasst.

In dieser Session möchte ich unsere Controlling-Verfahren vorstellen und welche Erkenntnisse wir daraus gewonnen haben.

Agiles Projekt-Management

Agile Projekte "begrüßen" idealerweise den Wandel. Jedoch ist ein Kunde auch bei agilen Projekten in aller Regel darauf angewiesen, ein Budget einplanen und zur Verfügung zu stellen. Die Frage lautet also, wie sich Budgetfragen unter Ungewissheit klären lassen.

Der agile Ansatz besteht darin, Projekte in kleinere Abschnitte aufzuteilen, deren Umsetzungsaufwand geschätzt wird und die sich in einzelnen Sprints umsetzen lassen. Mit dem Kunden wird eine Priorisierung der Themen erarbeitet, die iterativ – in der Regel in Sprints – umgesetzt werden.

Aus unseren Sprints gewinnen wir Erkenntnisse, die helfen, den weiteren Projektverlauf vorhersagbar zu machen.

Agil bedeutet nicht Beliebigkeit

In einer naiv verstandenen Vorstellung agilen Vorgehens stellt Agilität nur die Rechtfertigung von Beliebigkeit und Disziplinlosigkeit dar. Es ist angenehm, sich in nichts festlegen zu müssen. Früher oder später kommt jedoch für jedes Projekt der Tag der Wahrheit, an dem sich entscheidet, welche Anforderungen umgesetzt sind und zu welchem Preis. Dies ist geschieht meistens kurz vor oder zum Launch. Eine Kurskorrektur, sollte sie gewünscht sein, ist dann in aller Regel nicht mehr möglich.

Seit gut einem Jahr verfolgen wir bei comm-press den Ansatz, unsere Prozesse agiler Vorgehensweise verbindlicher festzulegen, um die Vorteile agilen Projektmanagements besser nutzen zu können.

Zu Beginn des Projekts ist es sinnvoll, ein Backlog mit Anforderungen zu erstellen und sämtliche Anforderungen grob zu schätzen. Je umfangreicher die Anforderungen zu Beginn geschätzt sind, desto früher lassen sich belastbare Aussagen über Umsetzungsdauer und zeitliche Abläufe gewinnen. Während des Projekts können weitere Anforderungen hinzukommen oder bestehende Anforderungen weiter präzisiert werden.

Schätzbare und nicht schätzbare Aufwände für Projektmanagement, Deployment, Bugfixing und Support
Schätzbare und nicht schätzbare Aufwände für Projektmanagement, Deployment, Bugfixing und Support

Schätzbare und nicht schätzbare Aufwände

Bei den gesamten Arbeiten innerhalb eines Projekts unterscheiden wir zwischen schätzbaren Tickets einerseits und anteiligen Aufwänden für Projektmanagement, Deployment, Bugfixing und Support andererseits.

Schätzbare Aufwände

Komplexe Anforderungen werden vor der Umsetzung so lange in kleinere Teile geschnitten, bis deren Umsetzung als Tickets schätzbar sind.

Nicht schätzbare – anteilige – Aufwände

Die nicht schätzbaren Aufwände entstehen in den Bereichen Projektmanagement, Deployment, Bugfixing und allgemeinen Support. Die aufgewändeten Zeiten für diese Bereiche werden ebenfalls erfasst.

  • Projektmanagement
    Vor einem Projekt lässt sich der Umfang des Projektmanagement nicht vorhersagen. Das Team muss den Kunden und das Projekt kennen lernen.
    Durch Unterstützung des Teams mit präzisen Informationen aber auch durch z.B. verzögerte Entscheidungen oder Abstimmungen mit mehreren Stakeholdern kann ein Kunde maßgeblichen Einfluss auf den Umfang eines Projekts nehmen.
    Eine Aussage über den zu erwartenden Umfang des Projekt-Managements lässt sich üblicherweise erst nach ein paar abgeschlossenen Sprints treffen.
  • Bug-Fixing
    Bugs werden üblicherweise nicht geschätzt. Arbeiten in diesem Bereich lassen sich schwerlich vorhersagen.
  • Deployment
    Aufwände für Deployment lassen sich üblicherweise nicht einzelnen Tickets zuweisen.
    Der Aufwand an Deployment hängt von verschiedenen Faktoren wie z.B. dem Umgang mit git, der Art des Projekts und der Team-Größe ab.
  • Support
    Ebenso zeigt sich erst im Laufe des Projekts, wie viel sonstiger Support der Kunde – z.B. in Form von Schulung – benötigen wird.

Eine Schätzung ist eine Schätzung ist eine Schätzung

Eine "gute" Schätzung darf nicht als Schätzung mit möglichst hoher Eintreffenswahrscheinlichkeit verstanden werden. Eine gute Schätzung ist eine Schätzung, bei der die einzelne komplexe Anforderungen so weit in einzelne Unteraufgaben geschnitten werden, bis sich diese überhaupt schätzen lassen. Wenn sich einzelne Anforderungen nicht schätzen lassen – sei es, weil externe APIs untersucht werden müssen oder das Team Neuland betritt – ist es sinnvoll, sogenannte "Spikes" einzurichten.

Spikes sind Recherche-Aufgaben, die mit einer Timebox versehen werden, um mit den daraus gewonnenen Erkenntnissen die entsprechenden Anforderungen schätzen zu können.

Zustände von Tickets

Während der Sprints durchlaufen die einzelnen Issues in aller Regel die Zustände "neu", "geschätzt", "zur Umsetzung freigegeben", "in Umsetzung befindlich", "Qualitätssicherung", "PO-Abnahme", "Stage-Deployment", "Kunden-Abnahme", "Live-Deployment".

Da ich mich in diesem Artikel nur auf das Controlling konzentrieren möchte, gehe ich auf die Bedeutung der einzelnen Prozessschritte nicht näher ein. Die Zustände sind nicht generell festgelegt: für andere Teams können andersartige Stati geeigneter sein als unsere.

Unsere Daten erheben wir derzeit in JIRA und mite
Unsere Daten erheben wir derzeit in JIRA und mite

Erhebung der Daten

Projekt-Management System – z.B. "JIRA"

Als Projekt-Management System setzen wir derzeit JIRA ein.

Im JIRA werden die Issues erfasst und durchlaufen die oben bezeichneten Statuszustände.

Zeiterfassungs-System – z.B. "Mite"

Unsere Zeiten erfassen wir in Mite. Mite ist ein sehr schlankes und gut bedienbares SaaS Tracking-System. Wir legen für jede Anforderung im JIRA ein eigenes Mite-Projekt an. Auf diese Weise können wir die Zeiten für jede Userstory einzeln erfassen und mit der Schätzung im JIRA vergleichen.

Auswertung der Daten

Auswertung der schätzbaren Tickets

Am Ende eines Sprints exportieren wir die Projektdaten aus dem Mite und die Storys inkl. ihrer Statuszustände aus dem JIRA. Mit – derzeit noch händischer – Datenaufbereitung und etwas Tabellen-Akrobatik fügen wir beide Informationen in einem gemeinsamen Tabellenblatt zusammen.

Das erste Datenblatt enthält das vollständige Backlog der Tickets mit den geschätzten und gemessenen Zeiten. In einer zusätzlichen Spalte errechnen wir das Verhältnis aus geschätzter und gemessener Zeit. Auf vier weiteren Datenblättern gruppieren und sortieren wir die Tickes nach folgenden Kriterien:

  • umgesetzt
    Hier laufen alle Tickets auf, die entweder abgeschlossen sind oder an denen mutmasslich nicht mehr viel zu arbeiten sein wird. Dies betrifft die Zustände "Qualitätssicherung", "PO-Abnahme", "Stage-Deployment", "Kunden-Abnahme", "Live-Deployment" und "umgesetzt".
    Die Sortierung erfolgt absteigend anhand des Verhältnisses aus geschätzter und gemessener Zeit. Auf diese Weise lassen sich relevante Issue mit Klärungs-Bedarf, bei denen die Umsetzung gravierend von der Schätzung abweicht, schnell identifizieren.
  • teilfertig
    Sämtliche Tickets im Zustand "in Umsetzung befindlich".
    Da nicht klar ist, inwieweit die Anforderungen der Issues zum gegenwärtigen Zeitpunkt umgesetzt sind, lassen sich hieraus keine belastbaren Prognosen ableiten. In einem gut organisierten Umsetzungsprozess ist die Zahl der gleichzeitig in Bearbeitung befindlichen Issues jedoch stets gering. In einer idealen Welt ist sie am Ende eines Sprints null.
  • nicht umgesetzt
    Sämtliche Issues in den Zuständen "neu", "geschätzt" oder "zur Umsetzung freigegeben".
    An diesen Tickets wurde in der Regel noch nicht gearbeitet. Es gibt keine empirischen Erkenntnisse.
  • descope
    Anforderungen, die zwar geschätzt, vom Kunden jedoch – vorläufig oder dauerhauf – depriorisiert wurden.
    An diesen Tickets wurde in der Regel ebenfalls noch nicht gearbeitet und es gibt kaum empirische Erkenntnisse.

Auswertung der anteiligen Aufwände

Die Summe der nicht schätzbaren Aufwände aus den Bereichen Projektmanagement, Deployment, Bugfixing und allgemeinem Support wird auf der "Auswertungs"-Übersicht ausgegeben und dort ins Verhältnis zu den insgesamt gemessenen Zeiten gesetzt.

Auf Basis des Verhältnisses der geschätzten zu den gemessenen Zeiten lässt sich der Aufwand des noch nicht umgesetzten Projekt-Anteils vorhersagen.
Auf Basis des Verhältnisses der geschätzten zu den gemessenen Zeiten lässt sich der Aufwand des noch nicht umgesetzten Projekt-Anteils vorhersagen.

Prognosen

Auf Grundlage der bisher geschätzten und gemessenen Zeiten sowie der gemessenen Zeiten für anteilige Aufwände lassen sich Vorhersagen über den noch nicht umgesetzten Projekt-Anteil treffen.

Hochrechnung der restlichen Aufwände

  • umgesetzt
    Das Verhältnis der geschätzten zu den gemessen Zeiten der bisher umgesetzten Arbeiten stellt eine der zentralen Erkenntnisse eines Projekts dar.
    Wir gehen davon aus, dass dieses Verhältnis auch für die Umsetzung der restlichen Arbeiten gelten wird und verwenden es für die weitere Hochrechnung.
    Über den Verlauf des gesamten Projekts kann sich das Verhältnis gravierend verschieben. Je fortgeschrittener ein Projekt ist, desto mehr wird sich dieser Quotient jedoch stabilisieren.
    Das Ergebnis – das ermittelte Verhältnis kann durchaus zwischen 90 bis 140% schwanken – ist nicht immer "gewünscht", hilft jedoch enorm bei der Vorhersage künftiger Arbeiten!
  • teilfertig
    Über die Fertigstellung der teilfertigen Arbeiten lässt sich nicht viel vorhersagen, da sich der Umsetzungsstand der einzelnen Tickets nicht bekannt ist.
    Zur Hochrechnung der Fertigstellung der teilfertigen verwenden wir die Schätzung abzgl. der gemessenen Zeiten und wenden darauf das Verhältnis der umgesetzten Arbeiten an.
  • nicht umgesetzt
    Zur Hochrechnung verwenden wir ebenfalls die Schätzung abzgl. etwaiger bereits geleisteten Zeiten und wenden darauf das Verhältnis der umgesetzten Arbeiten an.
  • descope
    Solange die Tickets nicht priorisiert sind, wird hierauf kein weiterer Aufwand anfallen.

Hochrechnung der anteiligen Aufwände

Die zweite zentrale Erkenntnis liefern die gemessenen Zeiten im Bereich Projektmanagements. Über die Dauer eines Projekts wachsen diese Aufwände kontinuierlich mit. Jedoch verhalten sie sich nicht linear zum Verlauf:

  • Durch die initiale Erstellung und Schätzung des Backlogs entsteht zu Beginn des Projekts ein höherer Anteil an Projekt-Management.
    Nach der Start- und vor der Schlussphase eines Projekts verhält sich der Aufwand an Projekt-Management üblicherweise recht konstant.
  • Der Aufwand für die Behebung von Bugs steigt in der Regel über die Dauer des Projekts: Zu Beginn gibt existiert schließlich noch gar nichts, was überhaupt buggy sein könnte.
  • Mitunter wird auf Kundenseite erst kurz vor dem Launch intensiv getestet. Fehler, die das Team nicht selbst feststellt, werden dann erst kurz vor oder nach dem Launch festgestellt.
  • Störungen im Projektverlauf führen mitunter kurzzeitig zu einer starken Zunahme der anteiligen Aufwände.

Um eine grundsätzliche Prognose zu ermöglichen, ignorieren wir diese Besonderheiten und gegen von einem linearen Anstieg der anteiligen Aufwände aus: Wir wenden das ermittelte Verhältnis der anteiligen Aufwände zu den Arbeiten insgesamt auf den Umfang der prognostizierten Tickets an.

Die Projekt-Velocity eignet sich zur Vorhersage des Launch-Zeitpunktes.
Die Projekt-Velocity eignet sich zur Vorhersage des Launch-Zeitpunktes.

Vorhersage des Launch-Zeitpunktes

Neben den kaufmännischen Fakten – wie viel Budget einem Projekt zur Verfügung steht bzw. welche Anforderungen sich innerhalb eines festes Budget umsetzen lassen – ist auch die Frage des Launch-Zeitpunktes wichtig.

Theoretisch lässt sich der Launchzeitpunkt sehr einfach ermitteln, indem die restlichen Aufwände auf die Anzahl der zur Verfügung stehenden Mitarbeiter verteilt werden. Praktisch ist dies jedoch schwierig, wenn es kein Projekt-Team gibt, sondern alle Projekte und das Tagesgeschäft von einem gemeinsamen Team betreut werden.

Ein alternativer Ansatz besteht darin, die Projekt-Velocity zu verwenden.

Velocity – Durchsatz je Sprint

In jedem Sprint setzt das Team eine bestimmte Menge an Tickets um. Aus der Menge der je Sprint umgesetzten Tickets lässt sich sehr schnell und zuverlässig die Restlaufzeit ermitteln. Als Maßeinheit verwenden wir die Schätzung.

Da wir davon ausgehen, dass sich die anteiligen Aufwände weiterhin proportional verhalten, können sie für die Ermittlung des Zeitpunktes außer Acht gelassen werden.

Die Velocity unterscheidet sich von Sprint zu Sprint. Je besser Projekt und Team organisiert sind, desto höher wird die Velocity. In Sprint-Retrospektiven kann das Team über sich selbst reflektieren und Methoden ausprobieren, die ihm helfen sollen, die Arbeit besser zu organisieren. Selbstverständlich lässt sich die Velocity nicht ins Endlose steigern. Nach einigen Sprints kann man jedoch die bisher gemessene Velocity prognostisch auch für den weiteren Verlauf annehmen.

Ein valides Controlling ermöglicht frühzeitig zu reagieren und Anforderungen umzupriorisieren.
Ein valides Controlling ermöglicht frühzeitig zu reagieren und Anforderungen umzupriorisieren.

Learnings

  • Durch ein verbessertes Controlling verlaufen Projekte nicht besser.
  • Ein verbessertes Controlling ermöglicht dem Dienstleister jedoch, den Kunden früher über den zu erwartenden Aufwand und den voraussichtlichen Launch-Zeitpunkt zu informieren.
    Auf diese Weise kann der Kunde auf schlechte Nachrichten früher reagieren und wird dies dem Dienstleister in aller Regel auch danken.
  • Der schlimmste Fall ist, wenn das Budget aufgebraucht und das Projekt nicht launchfähig ist. Zu diesem Zeitpunkt kann der Kunde nicht mehr depriorisieren. Er kann entweder Budget nachschießen, die Agentur schießt Manpower nach oder das Projekt scheitert.

Die Folien zur Präsentation befinden sich hier als PDF.