Projektcontrolling gestaltet sich bei agilen Projekten wegen der selbstorganisierenden Teams etwas anders als bei „normalen“ Projekten – besonders, weil es hier normalerweise keinen Projektleiter und keinen Projektcontroller gibt. Aber auch hier umfasst das Projektcontrolling planen, überwachen und steuern. In diesem Artikel erhalten Sie eine Übersicht, wie in agilen Projekten das Projektcontrolling ausgeführt und agile Projekte geplant werden. Im nächsten Artikel zeige ich Ihnen dann, wie agile Projekte überwacht und gesteuert werden.
Projektcontrolling ist bei agilen Projekten kein Thema
Sie wundern sich vielleicht, warum Projektcontrolling bei agilen Projekten kein Thema ist. Auch der bekannte Scrum Guide kennt diesen Begriff nicht. Ich kann Ihnen aber jetzt schon sagen, auch bei agilen Projekten wird ein Projektcontrolling gemacht – nur etwas anders.
Die Begriffe Projektcontrolling, Planen, Überwachen und Steuern tönen für viele “Agilisten” und “Scrumer” vielleicht sehr schräg, altbacken oder sind für sie einfach unpassend – obwohl agile Team sehr ähnliche Aktivitäten ausführen, diese aber einfach anders benannt sind. Dieser Artikel will nicht den Begriff Projektcontrolling bei agilen Projekten einführen. Er soll Ihnen zeigen, wie Projektcontrolling in agilen Projekten gemacht wird – und das dieses hier viel wirkungsvoller gemacht wird als in traditionellen Projekten.
Falls Sie sich mit agilem Projektmanagement und Scrum noch nicht so gut auskennen, dann können Sie sich hier zuerst einen Überblick verschaffen.
Übersicht Agiles Projektmanagement
Wie Sie in meinen Büchern über Projektcontrolling detailliert nachlesen können, umfasst das Projektcontrolling folgende drei Hauptaktivitäten: Planen, Überwachen und Steuern. Diese Aktivitäten werden auch in agilen Projekten ausgeführt, nur etwas anders und aus meiner Sicht einiges effizienter. In diesem Beitrag zeige ich Ihnen wie das mit Scrum funktioniert.
Die Herausforderung beim Controlling agiler Projekte
Bei agilen Projekten will man den „administrativen“ Projektaufwand möglichst gering halten, deshalb hört man oft den Spruch: „Je mehr du nach Plan arbeitest, umso mehr bekommst du das, was du geplant hast, aber nicht das, was der Kunde braucht“, oder „vergiss Planung … wir sind “agile” … wir lösen die zukünftigen Probleme morgen.” Darum wird bei einem agilen Projekt meist nur der nächste kurze Zeitabschnitt (Iteration/Sprint/Timebox) von 1-4 Wochen detailliert geplant. Was in den folgenden 4 Wochen folgt wird nur sehr grob geplant, alles danach kann man im Mission-Statement finden. Das sind natürlich nicht die besten Voraussetzungen für ein traditionelles Projektcontrolling, da ja Projektcontrolling vermutlich auch unter den oben genannten „administrativen Aufwand“ fällt.
So schlimm wie dies im ersten Augenblick aussieht ist es in der Praxis nicht, denn auch bei agilen Projekten lebt man nicht so einfach in den Tag hinein, wie man oft meinen könnte. Der Kunde weiß was er ungefähr als Projektresultat wünscht (Projektumfang) und dafür zu zahlen bereit ist (Kosten), und wann er das Resultat haben will (Zeit). Das sind die Parameter, mit denen sich das Projektcontrolling hauptsächlich beschäftigt.
Sie werden sich vermutlich immer noch fragen: “Wer macht hier das Projektcontrolling und was für Instrumente/Methoden werden dafür verwendet. Lesen Sie weiter und erfahren Sie wie agile Projekte geplant werden.
Planung agiler Projekte
Ziele, Anforderungen
In der traditionellen Softwareentwicklung werden alle Anforderungen bei Projektbeginn möglichst vollständig erfasst und präzise beschrieben. Erst dann wird eine detaillierte Projektplanung erstellt. In Scrum erfolgen Anforderungsbeschreibung, Planung und Umsetzung zeitnah und überlappend. Hier dazu ein Beitrag: Anforderungsmanagement bei agilen Projekten
Der Product Owner repräsentiert die Bedürfnisse des Kunden, der Anwender und anderer Interessenvertreter. Wie viele Anforderungen der Product Owner für den nächsten Sprint aufbereitet hängt von der Entwicklungsgeschwindigkeit (Velocity) des Teams ab. Das zentrale Mittel um Anforderungen zu erfassen und zu managen ist das Product Backlog. Das Product Backlog verändert sich über die ganze Projektlaufzeit: Bestehende Anforderungen werden umgesetzt, neue Anforderungen werden aufgenommen, existierende Anforderungen geändert, verfeinert oder entfallen und die Priorität der Anforderungen kann sich ändern. Die Aufwände aller Product Backlog Einträge werden vom Development-Team geschätzt.
Die drei Planungsebenen in Scrum
Die Projektplanung bei agilen Projekten basiert auf dem „Rolling Wave Planning“. Das heißt, es wird hier auf drei Zeitebenen geplant und nur das Naheliegende wird detailliert geplant. Die Projektplanung wird auf folgenden Ebenen ausgeführt:
- Releaseplanung – (Mittelfristplanung)
- Sprint-Planung (Iterationsplanung)
- Daily Scrum – Arbeitstag-Planung
Die Releaseplanung – die Mittelfristplanung
Der Product Owner erstellt den Releaseplan und aktualisiert diesen vor jedem Sprint. Der Releaseplan bietet eine Übersicht zum Zeit- und Kostenrahmen, und zu Terminen für Zwischenergebnisse. Er zeigt grob, in welcher Reihenfolge die Anforderungen umgesetzt werden und die erwartete Anzahl Sprints. Zuerst wird nur grob geplant. Im Laufe des Projektes wird der Releaseplan regelmäßig vom Product Owner weiter detailliert, damit er das Projekt sinnvoll überwachen und steuern kann. Dabei wird speziell auch auf Risiken eingegangen.
Die Sprint-Planung
Zu Beginn jedes Sprints trifft sich das ganze Scrum-Team zum Sprint Planning Meeting. Dieses dauert maximal einen Tag (bei einem 4 Wochen-Sprint) und dient dazu, das “Arbeitspaket” (Sprint Backlog) für das Development-Team für den kommenden Sprint zu definieren. Der Product Owner präsentiert dem Team die Product Backlog Items mit der höchsten Priorität und benennt sein Sprint-Ziel, mit dem das Development-Team einverstanden sein muss. Gemeinsam bestimmen beide Seiten, welchen Teil des Product Backlogs das Team im kommenden Sprint in ein auslieferbares Produkte-Inkrement umsetzen kann. Dies entspricht dann dem Sprint Backlog. Das Development-Team plant den Sprint, indem es dann die betreffenden Anforderungen in Aktivitäten herunterbricht.
Daily Scrum – Arbeitstag-Planung und Überwachung
Das 15-minütige Daily Scrum Meeting ist ein Statusmeeting, an dem der Sprintfortschritt festgestellt wird, die Teammitglieder sich abstimmen und gegenseitig informieren und die nächsten 24 Stunden geplant werden. Bei diesem Stand-Up-Meeting stehen die Teilnehmer am besten in einem Halbkreis um das Taskboard, auf dem das Sprint Backlog mit den Anforderungen und Aktivitäten und deren Abarbeitungsfortschritt dargestellt ist.
Der Scrum Master nimmt am Daily Scrum teil, notiert sich Impediments (Hindernisse) auf seiner Impediment-Liste und greift, wenn notwendig, moderierend ein. Auch der Product Owner nimmt nach Möglichkeit am Daily Scrum teil, um auf dem neuesten Stand zu bleiben und bei Bedarf Fragen zu beantworten. Nur die Development-Team-Mitglieder sprechen und berichten einander jeweils Folgendes:
- Was habe ich gestern erreicht, dass dem Development-Team hilft das Sprint-Ziel zu erreichen?
- Was werde ich heute erledigen, dass dem Development-Team hilft das Sprint-Ziel zu erreichen?
- Sehe ich irgendwelche Hindernisse, die mich oder das Development-Team abhalten das Sprint-Ziel zu erreichen?
Darauf müssen Sie bei der Planung agiler Projekte speziell achten:
Planen Sie nur so viel wie nötig. Jeder Auftraggeber hat seine Vorstellungen was er ungefähr erhalten will, was es kosten und bis wann die Software betriebsbereit sein soll. Dies ist die Ausgangslage für die erste Planung – natürlich mit dem Wissen, dass sich viele Parameter während der Projektdauer ändern werden. Die Devise lautet hier: Nur soviel planen wie nötig, nicht soviel wie möglich, denn es kommt meistens anders als man denkt. Bei Projektbeginn sollten jedoch mindestens der erste Sprint detailliert geplant sein.
Kürzere Sprints sind besser. Die zeitliche Planung besteht aus immer gleichlangen Zeitabschnitten (Sprints) von 1-4 Wochen. Halten Sie die Sprints so kurz wie möglich. Dies erleichtert die Überwachung und so werden auch häufiger neue Funktionalitäten geliefert.
Ein Releaseplan für den Überblick. Ein übergeordneter Releaseplan zeigt, besonders bei größeren Projekten, wann größere Funktionalitäten ausgeliefert werden und wie viele Sprints dafür notwendig sind. Er ist auch „Cost-Baseline“ für den Auftraggeber und ein gutes Hilfsmittel für die Steuerung des Projektes.
Nur das Nahe detailliert planen. Es wird nur der aktuelle Sprint detailliert geplant. Für die weiteren Sprints besteht nur eine Grobplanung. Dies entspricht dem bekannten Prinzip des „Rolling Wave Planning“.
Gantt-Charts nur als Überblick. Gantt-Charts haben bei agilen Projekten nicht den gleichen Stellenwert wie bei der traditionellen Projektplanung. Ein High-Level Gantt-Chart kann hilfreich sein, um den Überblick zu behalten und um wichtige Abhängigkeiten zu erkennen – mehr ist jedoch nicht sinnvoll. Für die Detailplanung sind Sprint-Task-Listen, bzw. das Task Board das beste Werkzeug.
Das Development-Team plant. Das Development-Team organisiert sich selbst. Es plant die Sprints und ordnet sich selbst die Aufgaben zu. Das Team kennt die Abhängigkeiten der Arbeiten am besten und kann sein Wissen voll einbringen.
Anforderungsbasiertes Planungsvorgehen. Planen Sie Anforderungen (User Stories) innerhalb der Sprints, nicht Aufgaben wie z.B. Design, Test. In Sprint 4 für ein Online E-Commerce System könnten z.B. die Anforderung stehen: „Implement Search for Books“, „Implement Search for DVDs“, „Implement Process Credit Card Payment“. Die Detailplanung können dann die Teammitglieder im Sprint Planning 2 oder während des Sprints selbständig ausführen.
Risiken früh behandeln. Ist mit einer Anforderung ein Risiko verbunden, so wird diese Anforderung hochpriorisiert und baldmöglichst umgesetzt. So können Unsicherheiten und offene Punkte früh im Projekt behandelt werden, bevor ein Brandherd daraus wird.
Kostenplanung
Kostenplanung ist schon bei traditionellen Projekten oft ein unbeliebtes Kapitel, bei agilen Projekten wird diese gerne ausgeblendet. Wenn es dann noch um Fixpreis-Verträge bei agilen Projekten geht, dann ist der Widerstand groß und das Verständnis klein. Viele Product Owner behaupten, dass es bei agilen Projekten nicht möglich ist eine vernünftig genaue Kostenplanung zu machen. Ich bin mir jedoch sicher, dass es dem internen oder externen Auftraggeber nicht egal ist, was das Projekt kostet und was er dafür bekommt.
Wenn es um Fixpreis-Verträge geht müssen vor der Auftragsvergabe die Anforderungen nahezu vollständig spezifiziert sein und während des Projektablaufs möglichst stabil bleiben. Dieses Szenario widerspricht im Kern der Idee agiler Vorgehensweise. Mit diesem Problem haben aber auch viele traditionelle Projekte zu kämpfen und überschreiten ihr Budget teilweise massiv.
Folgende Tipps kann ich Ihnen zur Kostenplanung bei agilen Projekten geben:
- Wenn ein Fix-Preis verlangt wird, vereinbaren Sie einen solchen jeweils nur für einzelne Meilensteine oder Releases.
- Machen Sie mit erfahrenen Kollegen tiefere Vorabklärungen (Agile Modeling, Architecture Envisioning), um ein tieferes Verständnis für die Anforderungen zu erhalten.
- Geben Sie Ihrem Auftraggeber nach der Auftragsklärung und der ersten Grobplanung (basierend auf den groben Anforderungen) nur eine grobe Bereichsschätzung ab, z.B. €700‘000 … €1‘200‘000.
- Bei relativ detailliert definierten Fix-Preis-Verträgen ist eingespielter Change Request Management und Claimmanagment-Prozess unumgänglich.
Hier erfahren Sie mehr, wie Sie Verträge bei agilen Projekten wirkungsvoll anwenden.
Wer ist für die Planung verantwortlich?
Für die Anforderungen, das Product Backlog und die Releaseplanung ist der Product Owner verantwortlich. Auch für den ersten Teil des Sprint Planning (wenn es um das WAS geht). Für den zweiten Teil des Sprint Planning (wenn es um das WIE geht) ist das Development-Team verantwortlich und auch für die Tagesplanung im Sprint.
Vom Scrum Master haben Sie bis jetzt nicht viel gelesen. Seine Rolle ist aber nicht unwichtig, denn er unterstützt das Scrum-Team bei der Planung, coacht und schult das Team, wo nötig und moderiert die Planungsmeetings.
Als Repetition nochmals die wichtigsten Punkte:
- Der Product Owner bestimmt die Projekt- und die Sprintziele, sowie die umzusetzenden Anforderungen
- Das Development-Team bestimmt, wieviele Anforderungen es im Sprint umsetzen kann und macht die Sprint-Detailplanung
- Es wird nur der aktuelle Sprint im Detail geplant. Die weiteren Sprints und Releases sind nur sehr grob geplant (Rolling Wave Planning)
- Das Development-Team überwacht seinen Arbeitsfortschritt im Daily Scrum selber und behandelt Störungen umgehend
Dies war der erste Teil des Beitrages “Projektcontrolling bei agilen Projekten” mit der Projektplanung. Der zweite Teil mit der Überwachung und Steuerung folgt bald.
Was haben Sie für Erfahrungen mit der Planung bei agilen Projekten gemacht? Stimmen Sie mit meinen Aussagen überein oder haben Sie eine andere Ansicht oder Ergänzungen? Teilen Sie Ihre Erfahrung mit einem Kommentar den Lesern mit, damit wir alle eine weitere Sicht kennenlernen. Danke!
Hier gibt es noch mehr Wissen
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte noch erfolgreicher machen? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Beitrag auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn in Ihrem Netzwerk. Vielen Dank!
