Planbarkeit in IT-Projekten – so funktioniert’s auch agil

In der IT-Branche steht Agilität bei der Projektentwicklung im Vordergrund. Schließlich kann man der digitalen Welt mit all ihren Schwankungen, Veränderungen, Updates nur durch flexible Arbeitsweisen gerecht werden. Aber wie schafft man es, bei allen agilen Variablen den Fortschritt eines Projekts zu kontrollieren? Und wie kann man ein Projekt, das noch viele Fragezeichen hat, von Anfang an in puncto Aufwand realistisch einschätzen? Keine einfache Aufgabe – aber sie ist zu bewältigen. Und zwar mit Hilfe der so genannten empirischen Prozesskontrolle. Was das ist, wie es funktioniert und wie wir es bei Ambient Innovation umsetzen, verraten wir Ihnen hier.

Agiles Problem: Kein Preis pro Meilenstein

Im SCRUM-Prozess werden für jedes neue Projekt zunächst einzelne Meilensteine oder Features definiert, die zum Gesamtziel führen (dem vollendeten Projekt). Das hilft, den Überblick über den Gesamtprozess zu behalten und sich auch bei plötzlichen Kursänderungen, die agiles Arbeiten erfordern kann, nicht zu verirren.

Oft ist es aber so, dass zwar die Meilensteine selbst, nicht aber deren Preise (oder Aufwand) zu Anfang definiert werden können. Wenn wir ein solches Projekt angehen, laufen wir deshalb Gefahr, den finanziellen Rahmen falsch einzuschätzen. Fehlkalkulationen sorgen für Unzufriedenheit bei uns – und bei den Kund*innen, die schließlich ein Budget einzuhalten haben.

Um das zu vermeiden, müssen wir schon von Projektbeginn an clever kalkulieren, in welcher Zeit welcher Meilenstein zu erreichen ist. Das schaffen wir – auch ohne von Anfang an durchdefinierte Preise – durch empirische Prozesskontrolle, eine grundlegende Methode des agilen Controllings, die wir bei Ambient Innovation schon lange erfolgreich einsetzen. Diese setzt auf drei Grundprinzipien von SCRUM, die wir Ihnen im Folgenden näher erläutern.

Empirische Prozesskontrolle schafft Planbarkeit in IT-Projekten

Empirische Prozesskontrolle basiert auf Empirie, also Erfahrung. Im SCRUM heißt das: Mit jeder neugewonnen Erfahrung im Projektentwicklungsprozess können wir unsere Planung anpassen und realistischer kalkulieren. Diese Methode basiert also auf dauerhaftem Lernen der Projektmitglieder – und spiegelt damit einen Grundstein von Agilität wider.

Um dem gerecht zu werden, muss die empirische Prozesskontrolle in jeder Iteration eines Projekts erfolgen. Nur so kann garantiert werden, dass das bestmögliche Ergebnis für die Kund*in erzielt wird. Dabei basiert das Vorgehen auf drei Säulen, die im SCRUM eine große Rolle spielen: Transparenz, Überprüfung und Anpassung.

Transparenz: Offenheit schafft Erfolg

Ein Grundprinzip von SCRUM ist die Transparenz im Arbeitsprozess. Das heißt: Alle Mitarbeiter*innen sollten offen und für alle nachvollziehbar arbeiten. Das gilt auch für die Projektkontrolle. Je offener Ergebnisse, Teilergebnisse und Probleme kommuniziert werden, desto schneller kann zugunsten des Projektes reagiert werden. Vor dem Beginn der Projektarbeit müssen daher gemeinsame Standards festgelegt werden. Alle Mitarbeitenden müssen „eine Sprache“ sprechen und sich über die Herangehensweise einig sein.

Überprüfung: Kurswechsel jederzeit möglich

Wichtig ist auch, dass die Überprüfung von Arbeitsschritten und Ergebnissen regelmäßig erfolgt. Nur so können wir sichergehen, dass wir uns „auf Kurs“ befinden oder ggf. den Kurs ändern müssen. In den Überprüfungsablauf sollen alle am Projekt beteiligten Mitarbeiter*innen eingebunden werden – jedoch nur, solange sie dies nicht an ihrer eigenen Arbeit hindert. Zu häufige Überprüfungen können schließlich kontraproduktiv sein. Verantwortlich für die Überprüfung sind vor allem SCRUM Master und Product Owner.

Anpassung: Schnelle Umsetzung spart Umwege

Die Erkenntnisse der regelmäßigen Überprüfung münden in der Anpassung unserer Prozesse. Haben wir festgestellt, dass ein Element im Workflow optimiert werden muss, sollten wir dies so schnell wie möglich umsetzen. Um dies zu gewährleisten, erfolgen Überprüfung und Anpassung im SCRUM in mindestens vier regelmäßigen Meetings: Sprint-Planning, Daily-SCRUM, Sprint-Review und Sprint-Retrospektive. Wichtig ist das gemeinsame Diskutieren im Team, das die Anforderungen umsetzt.

Hier sollte der SCRUM Master vor allem eine moderierende Rolle einnehmen, um Blockaden und Meinungsverschiedenheit im Team konstruktiv zu begegnen. Fakt ist: Je aufwändiger ein Projekt, desto mehr Raum für Unstimmigkeiten gibt es. Diese sollten in jedem größeren Meeting angesprochen und nach Möglichkeit aus der Welt geschafft werden.

Die drei Säulen

Transparenz
Überprüfung und
Anpassung

orientieren sich am Lean-Thinking-Konzept, das der Verschwendung von Ressourcen im Business vorbeugen soll. Der Grundsatz lautet hier: Es geht bei effizientem Arbeiten nicht um das Erhöhen von Geschwindigkeit, sondern insbesondere um das Vermeiden von sinnlosen Tätigkeiten. An deren Stelle soll ein fokussiertes, sinnstiftendes Arbeiten treten – eine wichtige Grundvoraussetzung für Erfolg im Team. Dadurch werden nicht nur Produkte effizienter fertiggestellt, sondern auch der Lerneffekt im Team vorangetrieben. Und je schneller das Team lernt, umso größer ist sein Marktvorteil.

Klassische versus agile Prozesskontrolle – der Vergleich

In der IT-Branche ist agiles Arbeiten – und damit die empirische Prozesskontrolle – unumstritten die erste Methode der Wahl. Es gibt jedoch auch Branchen, die konventioneller arbeiten. Das Controlling basiert bei diesen auf unveränderlichen, festkalkulierten Zahlen und Fakten, die durch den gesamten Prozess führen. In seltenen Fällen mag dies funktionieren, zum Beispiel, wenn ein Kultprodukt immer wieder gleich hergestellt und vertrieben werden soll. In den meisten Fällen jedoch ist ein derart starres Vorgehen in der Realität kaum praktikabel. Es gibt zu viele Variablen, die einen Effekt auf die Projektentwicklung haben. Bedingungen und Anforderungen ändern sich laufend und können den Projekterfolg gefährden, wenn man sie unbeachtet lässt.

Wer sein Controlling ganz klassisch auf scheinbar fixen Elementen aufbaut, muss deshalb bei jeder Abweichung den Gesamtprozess neu überdenken. Das kostet enorm viel Zeit – und noch mehr Nerven. Bei der empirischen Prozesskontrolle nach SCRUM können dagegen einzelne Schrauben neu justiert werden, um den Gesamtapparat des Projektes wieder auf den richtigen Pfad zu bringen. Der Aufwand hält sich in Grenzen und das Ergebnis wird optimiert.

Agilität heißt damit für uns: Wir planen, so weit wir müssen und so kurz wir können. Das bedeutet natürlich nicht, dass es anfangs keinen groben Fahrplan geben darf. Es bedeutet nur, dass wir jederzeit bereit sind, von diesem Plan abzuweichen, wenn die Umstände dies notwendig machen. Dadurch sind die einzelnen Schritte in SCRUM zwar kleiner als bei klassisch vordefinierter Projektplanung. Aber sie sind umso wendiger – eben agil. Das heißt, sobald sich etwas ändert, müssen wir nur einen klitzekleinen Schritt zurückgehen, während konventionell arbeitende Unternehmen riesige Rückschritte machen müssen. Das verschafft uns einen Riesenvorteil – sowohl in der Projektentwicklung als auch in der Kontrolle.

Durch empirische Prozesskontrolle verbessert sich aber nicht nur das Produkt, das wir entwickeln sollen. Auch die Teams selbst profitieren von dem kontinuierlichen Lernprozess und die Zusammenarbeit wird mit jeder neuen Aufgabe produktiver.

Bedingungen sind bekannt/unveränderlich
Prozess kann in jedem Schritt von Anfang an geplant werden
Projektleitung läuft über „command und control“

Bedingungen können sich laufend ändern
Prozess kann nur in Teilschritten geplant werden
Projektleitung läuft über „inspect and adapt"

Agilität verschafft uns einen riesigen Vorteil. Sobald sich etwas ändert, müssen wir nur einen klitzekleinen Schritt zurückgehen.

Empirische Prozesskontrolle bei Ambient Innovation

Bei Ambient Innovation nutzen wir zur empirischen Prozesskontrolle ein Release-Burnup-Chart. Das ist ein Diagramm, mit dessen Hilfe wir unsere Projektfortschritte kontrollieren und visualisieren können. Product Owner und SCRUM Master sind gemeinsam dafür verantwortlich, dieses Diagramm aktuell zu halten. Auf der Y-Achse befinden sich dabei die Story Points, unsere Maßeinheit für den Arbeitsaufwand. Auf der X-Achse tragen wir die entsprechende Zeit in Sprints ein. Und so funktioniert’s:

Aufwandsschätzung: Wir ermitteln in jedem Projekt natürlich zuerst alle Anforderungen und geben eine erste Aufwandsschätzung.
Scope des Projektes: Auf der Y-Achse des Release-Burnup-Charts tragen wir den geschätzten Gesamt-Aufwand ein. Unsere Maßeinheit sind Story Points (mehr dazu unten).
Erreichte Story Points: Nach jedem Sprint überprüfen wir, wie viele Story Points wir geschafft haben. Diese tragen wir anschließend auf der X-Achse ein.
Geschwindigkeitsermittlung: Wir sehen nun, in welchem Verhältnis Zeit und abgearbeitete Story Points stehen. Dies ist unsere derzeitige Arbeitsgeschwindigkeit oder Velocity.
Projektion: Auf Basis der aktuellen Velocity können wir berechnen, wie viele Sprint wir vermutlich zur Fertigstellung des Projekts benötigen. Den geschätzten Wert projizieren wir auf unser Diagramm.
Anpassung: Diesen Überprüfungsprozess wiederholen wir in jedem Sprint. Dabei lassen wir stets neue Erkenntnisse einfließen: Haben sich Anforderungen geändert oder hat die Erfahrung gezeigt, dass die Aufwandsschätzung angepasst werden muss? Sind die Teams schneller oder langsamer geworden? Welche Faktoren spielen eine Rolle dabei? Und wie wirkt sich das auf die neue Gesamtgeschwindigkeit aus? Gemäß aller neuen Aspekte können wir nun die Anzahl an Story Points entweder erhöhen oder verringern und damit auch den geschätzten Aufwand oder Scope des Projekts angleichen. So können wir in jedem Sprint unsere Einschätzung anpassen, um realistisch zu bleiben.

Release-Burnup-Chart als: Hocheffizient und motivierend

Die empirische Kontrolle mittels Release-Burnup-Charts gehört für uns zu jedem Projekt dazu und hat sich als äußerst effizient erwiesen. Ein entscheidender Vorteil liegt auch darin, dass wir uns hier auf Ergebnisse konzentrieren, nicht auf Fehler oder den riesigen Berg an Aufgaben, der noch vor uns liegt. Das Release-Burnup-Chart legt den Fokus auf die Aufgaben, die geschafft wurden, und erhöht so nicht nur die Treffgenauigkeit unserer Schätzung, sondern auch die Motivation unserer Mitarbeiter*innen.

Mehr zum Release-Burnup-Chart und seiner Funktion erfahren Sie in diesem Video.

Ein Chamelion tarnt sich und passt sich der Umgebung an.

Anpassung is King. Somit können wir die Anzahl der Storypoints realistisch einschätzen.

Story Points als Maßeinheit zur empirischen Prozesskontrolle

Story Points sind Maßeinheiten, mit denen der Gesamtaufwand einer Implementierung realistisch geschätzt werden kann. Dabei weisen Teams jeder Aufgabe verschiedene Story Points zu. Die Anzahl bemisst sich nach Komplexität, Aufwand und Menge der nicht-definierten oder veränderlichen Variablen. Story Points bilden damit eine Alternative zur reinen Messung von Aufgaben in Arbeitsstunden. Und das hat folgende Gründe:

Arbeitsstunden berücksichtigen all die kleinen Dinge, die neben dem Projekt im Arbeitsalltag zu bewältigen sind, nicht (E-Mails etc.). Story Points dagegen haben diese ablenkenden Elemente auf dem Schirm und ermöglichen dadurch eine realistischere Einschätzung.
Story Points bemessen eine Aufgabe nicht nur nach zeitlichem Aufwand, sondern auch nach Schwierigkeitsgrad. Dadurch kann den beteiligten Entwickler*innen die Anerkennung zukommen, die sie verdienen.
Eine vorherige gemeinsame Definition jedes Story Points macht die Arbeitsteilung einfacher. Es muss weniger diskutiert und hin und her geschoben werden, weil Schwierigkeit und Aufwand von Arbeitsschritten vorher festgelegt wurden. Das spart nicht nur Zeit, sondern verhindert unnötige Diskrepanzen im Team.
Story Points verhindern „stupides Abarbeiten“ und Absitzen im Büro. Sie fußen nicht auf Arbeitsstunden, sondern auf bestmöglichen Ergebnissen.

Story Points helfen also enorm, sowohl den Arbeitsaufwand eines Projekts als auch die Priorisierung der einzelnen Teilaufgaben einzuschätzen.

Story Points realistisch einschätzen

Damit Story Points als Maßeinheit im SCRUM-Prozess funktionieren, muss ihnen vorab ein realistischer Wert zugewiesen werden. Die Story-Points-Schätzung sollte sich dabei an folgenden Punkten orientieren:

Schätzen soll das Team, das auch am Projekt beteiligt ist. Schließlich wissen die Leute, die sich mit dem Projekt beschäftigen, am besten, wie lange eine Aufgabe daran dauert.
Das Einbinden der Definition of Done. Damit ist eine gemeinsam definierte Checkliste gemeint, die vorgibt, wann ein Projekt bzw. eine User Story als erledigt zu betrachten ist. Solch eine Checkliste ist sinnvoll, weil die Meinungen zu Qualitätskriterien auch in einem Team stark auseinanderdriften können. Berücksichtigen Sie aber eine vorab festgelegte Definition of Done, macht das auch die Story-Point-Schätzung wesentlich einfacher.
Das Heranziehen der Fibonacci-Folge. Entwickler*innen nutzen diese berühmte Zahlenfolge für Schätzungen von Story Points, weil sie am besten die Relation zwischen Greifbarem/Konkretem und Unvorhersehbarem/Abstraktem widerspiegelt. Dabei werden die ersten beiden Zahlen addiert, was die dritte Zahl ergibt usw. Mit jeder größer werdenden Zahl wird auch der Abstand zwischen den Zahlen in der Folge immer größer. Klingt vielleicht kompliziert, ist aber in der Umsetzung ganz einfach zu verstehen. Die Fibonacci-Folge heißt nichts anderes als: Je komplexer ein Projekt, desto schwieriger die Schätzung.

Genau deshalb sind möglichst kleine Schritte im SCRUM so wichtig, um Teilerfolge zu messen und dem Gesamtziel auf geradestem Weg näherzukommen.

Damit diese Teilerfolge angemessen überprüft werden können, ist es natürlich notwendig, dass überhaupt erst Teilziele definiert werden. Moderne SCRUM-Anwender*innen arbeiten dabei mit mindestens drei Zielen:

Produktziel (für das Produkt-Backlog)
Sprintziel (für das Sprint-Backlog)
Definition of Done (für das Increment, siehe oben)

Controlling nach SCRUM – sofort effizienter arbeiten

Wir bei Ambient Innovation haben für uns längst die vielen Vorteile von SCRUM erkannt. Empirische Prozesskontrolle gehört für uns genauso dazu wie das Arbeiten in agilen Teams und das Einteilen in Sprints. In der digitalen Welt ändern sich die Dinge laufend, denn in vielen Projekten gibt es mehr Variablen als festgelegte Parameter oder Anforderungen. Das macht unsere Branche so anspruchsvoll, aber eben auch so aufregend und vielseitig. Durch empirische Prozesskontrolle werden wir dieser Vielseitigkeit gerecht und können unseren Kund*innen Ergebnisse liefern, die mit vordefinierten Prozesskontrollen nicht möglich wären.

Kurz gesagt: Wir sind überzeugte SCRUM-Fans! Sie auch? Oder haben Sie Einwände, Fragen, Kritikpunkte? Dann schreiben Sie uns, wir freuen uns auf Ihre Nachricht!