Budgetierung in der agilen Softwareentwicklung – wie geht das?
Bei der agilen Arbeitsweise dreht sich alles um Innovation. Dies gilt insbesondere in der Softwareentwicklung. Innovation bedeutet Veränderung, und zwar oft eine ganze Menge – einschließlich Änderungen an einem bestehenden Softwareprojekt. Um ein solches zu managen, sind flexible und gleichzeitig zielgerichtete Ansätze erforderlich. Dazu gehört auch ‒ was vielleicht für einige überraschend ist ‒ der Ansatz des Budgetmanagements: Agile Budgetierung ist eine Methode zur Verwaltung der Investitionen in ein Projekt, die auf Veränderungen reagiert – dazu gehören neue Benutzer- und Geschäftsanforderungen oder abgeänderte Umstände. Es handelt sich also um ein Budgetmanagement, das sich bei Bedarf mit dem Projekt mitbewegen kann.
Wasserfall vs. agiles Budgetmanagement
Arbeitet ein Unternehmen mit dem Wasserfallmodell für die Verwaltung von Projektbudgets, handelt es sich dabei um einen recht klassischen und meist starren Ansatz. Die Planung wird von oben nach unten abgearbeitet, wobei es oftmals auch nur eine:n einzige:n leitende:n Entscheidungsträger:in gibt. Ausgaben werden streng kontrolliert, basierend auf einem detaillierten Business Case, der zu Beginn des Projekts über die angemessene Investitionshöhe entscheidet ‒ größtenteils, bevor die eigentliche Entwicklungsarbeit begonnen hat. Ausgaben werden im voraus geplant und eingeschätzt ‒ dies ist ein ganz wesentlicher Bestandteil des Wasserfallkonzepts bei der Softwareentwicklung. Im Verlauf des unbeständigen, unsicheren und komplexen Verlaufes eines Projekts zeigt sich hier aber häufig sehr schnell, dass dieser Ansatz kaum funktioniert: Denn währenddessen wird Ihr Team immer mehr an Wissen dazugewinnen und die endgültige Form Ihres digitalen Produkts mehrmals bestimmen und ändern.
Bei der agilen Methode passiert beim Ablauf so gut wie alles häufig und flexibel ‒ Planungen, Überprüfungen und Retrospektiven, Kommunikation, Produktwiederholungen. Deshalb ist es wichtig, dass auch das Budgetmanagement bei diesem Tempo mithalten kann und sich genauso agil gestaltet, wie die anderen Abläufe. Sie sollten bei der Planung daher offen für neue Umstände sein, denn die agile Projektbudgetierung gibt Ihnen die Freiheit, je nach Situation umzuschwenken, wenn die Situation es erfordert.
Ein agiles digitales Produktentwicklungsprojekt arbeitet in Sprints. Diese bezeichnen den festgelegten Zeitraum, in dem Mitarbeiter:innen bestimmte Arbeiten abschließen und zur Überprüfung bereitstellen müssen. Es handelt sich dabei um kurze Zeiträume (ein bis zwei Wochen), in denen priorisierte Aktivitäten aus dem Projekt-Backlog (Rückstand) in Angriff genommen werden. Funktionen und Mechanismen eines Produkts werden überprüft und zum Testen und für Rückmeldungen produziert. Dies hat logischerweise auch Einfluss auf bevorstehende Sprints, da die Arbeit weitestgehend darauf abgestimmt wird. Daher ist es nicht überraschend, dass auch das agile Budgetmanagement in Sprints erfolgt oder, genauer gesagt, dass ein Zyklus des flexiblen Budgetmanagements auf den Sprint-Zeitplan des Projekts abgestimmt wird.
Der Budgetplanungsprozess
Ein grundlegender agiler Budgetplanungsprozess könnte beispielsweise wie folgt aussehen:
- Grobe Schätzungen auf der Grundlage der Kundenanforderungen: Dies ist eine erste grobe Einschätzung der Kosten für das gesamte Projekt. Sie basiert auf Informationen der Kund:innen oder Produkteigentümer:innen über die Erwartungen und Anforderungen an das digitale Produkt: dessen Zielnutzer:innen und Zweck, die Frage oder das Problem, das es lösen soll. Diese Schätzung wird dann im Rahmen eines Product-Discovery-Workshops mit detaillierteren Informationen weiter verfeinert.
- Der Product-Discovery-Workshop: Er dient als offizieller Startschuss für ein Projekt. Die Idee besteht darin, das gesamte Entwicklungsteam (einschließlich Entwickler:innen, Qualitätssicherungsspezialist:innen und Designer:innen) mit einem Scrum Master und dem Product Owner als Vertreter:in des Kunden zusammenzubringen, um die Geschäftsidee und die Details des möglichen Produkts wirklich zu ergründen. So soll der erforderliche Arbeitsaufwand genau bestimmt werden und das natürlich immer unter Berücksichtigung des Budgets. Im Produktfindungs-Workshop bespricht das Team folgende Punkte:
- die Geschäftsidee und den Grund für das Produkt,
- Benutzergeschichten,
- den Reifegrad des Produkts,
- mögliche Lösungen,
- Technologie-Entscheidungen und
- Projektrisiken.
- Auf Los geht's los: Auf der Grundlage der oben genannten Informationen kann das Projektteam nun das Backlog der durchzuführenden Projektaktivitäten erstellen, einschließlich der Priorisierung dieser Aktivitäten im Hinblick auf die Bedürfnisse der Benutzer:innen und die Unternehmensziele. Für den ersten Sprint werden die prioritären Aktivitäten ausgewählt. Das spezifische Budget für den Sprint wird anhand der Kosten für die Ressourcen berechnet, die für die erfolgreiche Durchführung des Sprints erforderlich sind. Für das Gesamtprojekt kann ein Budget auf der Grundlage der Größe des Teams, der Anzahl und Länge der erforderlichen Sprints, etwaiger zusätzlicher Kosten (einschließlich Kapitalkosten) und eines Zuschlags von 20 bis 50 Prozent je nach Erfahrung des Teams und dem Grad der Sicherheit der aktuellen Informationen aufgestellt werden. Natürlich kann sich dieses Budget im Laufe des Projekts noch ändern.
- Ein Produkt liefern: Während das Team sich vor jedem Sprint zu einer Sprintplanungssitzung trifft, führt es nach jedem Sprint eine Sprint-Review und eine Sprint-Retrospektive durch. Dieser Planungs- und Bewertungsprozess umfasst auch die Überprüfung und Überwachung des Budgets. Jeder Sprint ist zeitlich festgelegt. Ein engagiertes Entwicklungsteam hat feste Kosten für die Personalressourcen. Dies macht nicht nur die Berechnung eines Sprint-Budgets einfacher, sondern auch die Überprüfung der Auswirkungen der Änderungen an einem Produkt oder den Projektprioritäten.
Vereinfacht gesagt, wird die agile Budgetierung, die Prognose sowie die Ausgaben regelmäßig und häufig überprüft und bei Bedarf angepasst, um die Projektziele zu erreichen.
Die Vorteile der agilen Budgetierung in Scrum
Die Verwendung eines agilen Budgets verknüpft die finanziellen Entscheidungen eng mit den Gegebenheiten des Projekts, was wiederum erhebliche Vorteile mit sich bringt. Durch die Budgetierung in Sprints wird die Aufgabe des Budgetmanagements eng an die Struktur und den Zeitplan des Projekts selbst angelehnt. Da es sich bei den Sprints um genau definierte Zeiträume handelt, lässt sich das Projektbudget auch leicht in vierteljährliche oder jährliche Zeiträume übersetzen, wenn sie in den größeren Kontext eines organisatorischen Finanzmanagements gestellt werden müssen. Weil die detaillierte Budgetierung immer nur einige Wochen im Voraus erfolgt, ist der Prozess sehr flexibel. Sollte sich ein Faktor oder ein Umstand ändern (z. B. der Ausbruch einer unvorhersehbaren Pandemie) bedeutet das, dass ein Entwicklungsteam von nun an verstreut ist und von zu Hause aus arbeitet. Dies hat schlussendlich keine Auswirkungen auf das restliche Jahresbudget. Der Verlauf oder die Ausgaben des Projekts werden in der nächsten Runde von Überprüfungen und Retrospektiven einfach neu angepasst.
In einer VUCA-Welt ist Agilität für diese Art von Projekten unverzichtbar.
Die agile Budgetverwaltung ist dezentralisiert und nicht auf eine:n einzelne:n Budgetverantwortliche:n konzentriert, was eine breitere Perspektive und einen größeren Input in den Budgetverwaltungsprozess ermöglicht und diesen im Idealfall effektiver macht.
Fazit
Dass agile Ansätze am besten für die Entwicklung digitaler Produkte funktionieren, ist deutlich. Dementsprechend ist auch agiles Budgetmanagement unerlässlich. Die Flexibilität, die durch die Verknüpfung des Budgetmanagements mit dem Sprint-Zyklus eines Projekts gewonnen wird, stellt sicher, dass die Ausgaben schnell auf sich ändernde Umstände und Faktoren reagieren können. In einer VUCA-Welt ist Agilität für diese Art von Projekten unverzichtbar. Betrachtet man die Alternative, hängt die Agilität vom Budgetmanagement ab ‒ ein festes Budget (im Wasserfallstil) würde einen Großteil der Flexibilität des Projekts zunichtemachen oder sogar verhindern und damit die allgemeinen Vorteile eines agilen Ansatzes untergraben.
