Budgetplanung
Ich krieg sehr oft von anderen Agilisten zu hören, dass eine Budgetplanung nicht möglich ist. Das ist Unsinn. Das funktioniert. Vor allem wenn Personal die höchsten Kosten sind. Das ist in Entwicklungsteams häufig der Fall. Aber auch Hardware lässt sich schätzen.
Budgetplanung geht im Agilen nicht?
Also, ich kriege oft zu hören, dass wir Agilisten nie irgendwelche Zahlen nennen können und vor allem keine Planung machen. Genau das bringen wir in der Budgetplanung sogar zusammen.
Prüf es nach, ich behaupte unsere Planung ist genauso ungenau wie jede andere Planung auch, wir beschäftigen uns nur weniger lange damit, kommen schneller ins Handeln und sie sieht etwas anders aus. Dafür wird die Planung ständig aktualisiert.
Wie viel Geld braucht Dein Projekt im nächsten Jahr?
Um diese Frage zu beantworten würde Janina sich die Kosten des vergangenen Jahrs anschauen. Diese lassen sich super auf das nächste Jahr extrapolieren.
Doch wie ist es mit einem Projekt, dass ich erst frisch übernommen habe? In dem Fall würde ich mich stark bemühen Erfahrungswerte zu bekommen. Vielleicht erst einmal ein Forecast für 3 Monate mit einem kleinen Team, welches bereits beginnt Pläne aufzustellen und erste Erfahrungen zu sammeln. Mit diesem Team lässt sich dann der restliche Forecast aufstellen. Das witzige ist jetzt, wenn ich dies erfahrenen Projektleitern erzähle, dann nicken sie und machen in klassischen Projekten genau das Gleiche.
Zukunft vorhersagen
Die Schwierigkeit bei agilen Projekten ist, dass wir nicht genau wissen was in der Zukunft auf uns zu kommt. Du erinnerst Dich sicher an den komplexen Bereichen im Cynefin Framework.
Gerade am Anfang sind es daher sehr sehr viele grobe Daumenwerte, die mit der Zeit immer genauer werden. Das schöne ist, wir machen es transparent. Zum einen, dass es ungenaue Daumenwerte sind und zum anderen während der Projektlaufzeit permanent, wie sich die geschätzten Werte zur Realität entwickeln. Transparenz ist hier das Stichwort.
Wenn alles neu ist
Wenn wirklich alles neu ist, Team, Projekt, Methode, Framework, Technologie, dann würde Janina erst einmal gar keine Finanzaussagen machen. Wir brauchen ein paar Wochen Erfahrung mit dem Team. Hier sind wir wieder bei den 6 Iterationen. Nimm Dir also mindestens 2 Monate Zeit dafür. Alle Aussagen, die Du vorher machst sind sonst viel zu grobe Annäherungen. Nach den 2 Monaten solltest Du schon gute Aussagen mit Deinem Team treffen können.
Eine weitere Möglichkeit ist Dir ein vergleichbares Projekt anzuschauen und davon zu extrapolieren. Hierbei nutzt Du das Potential von erfahrenen Experten. Dies liefert Dir vor allem für die ersten Monate gute Werte.
Nutze die ersten Iterationen um Backlog Einträge zu generieren, diese zu Schätzen und damit dann eine grobe Planung aufzustellen, was alles noch kommen könnte.
Nach 6 Iterationen wird eine Grundausstattung von IT-hardware, Arbeitsmitteln und Büroräumen auch vorhanden sein. Falls nicht, hast Du auch Erfahrungswerte und kannst die Preise dafür benennen, damit diese beschafft werden können.
Abarbeitungsquote
In der StoryPoints Folge haben wir uns über das Schätzen von Komplexität unterhalten. Denn darum geht es ja im komplexen Umfeld, die Komplexität zu bewältigen. Nun kann ich mir in den ersten Iterationen anschauen wie viel Komplexität mein Team pro Zeiteinheit bewältigt. Wir nennen das Velocity und erzählen später mehr dazu. Diese Velocity kann ich auf das geschätzte Backlog anwenden und aussagen, wann der aktuelle Stand des Backlos in etwa abgearbeitet sein wird. Nun kann ich einberechnen, was passiert, wenn ich das Team verkleinere oder vergrößere und wenn es effizienter wird. Nun lege ich noch einen Preis drüber und schon ist meine Budgetplanung fertig. Daraus kann ich jetzt natürlich noch Etappen machen. Wir nennen das unter anderem Release Burndown.
Die Grundannahme, die dahintersteckt und unseren Job so wichtigmacht, ist, dass alle Menschen im Team immer das beste tun, was sie können.
Wenn Du zu Beginn Deines Projektes bereits weißt, was alles zu tun ist und glaubst, dass Deine Teammitglieder nicht das Beste tun, was sie können, dann ist Agilität das falsche Tool für Dich. Kannst Du alles vorhersagen, bist Du mit klassischen Projektmanagementmethoden, wie PRINCE2 gut beraten und wenn Du glaubst es gibt nicht jeder sein bestes solltet ihr als Team erst einmal am Vertrauen arbeiten. Es kann natürlich auch sein, dass Deine Teamzusammensetzung nicht ideal ist. Auch daran kannst Du arbeiten.
Jahresplanung / Budgetplanung
Bleibt Dein Team stabil, so kannst Du mit der Abarbeitungsquote eine fiktive Zahl an das Jahr packen. „Unser Team schafft 670 StoryPoints pro Jahr“ Und dann jede Anforderung einpreisen und Aussagen darüber treffen wie viel davon pro Jahr möglich ist und was es kostet.
Prototypen erzeugen
Es ist wichtig während der kompletten Projektlaufzeit, und vor allem in den ersten Iterationen, Prototypen zu erzeugen. Über die Prototypen erzeugen wir die besten Erfahrungswerte zur Umsetzung der Theorie in die Praxis. Wir entdecken die ersten Planungsfehler und können uns mit unserem Kunden abstimmen ob es in die richtige Richtung geht. Dabei lernen wir gerade am Anfang viel und behalten dies vor allem bei um auch später immer wieder dazu zu lernen und unsere Budgetplanung anpassen zu können. Je früher wir eventuelle Fehler ausmerzen können, desto besser für alle und desto weniger Risikovorhalt benötigen wir in der Projektplanung. Diese Prototypen lassen sich oft auch schon verkaufen oder Studien damit durchführen. Dies schafft einen zusätzlichen Mehrwert für das Unternehmen. Better done than perfect.
Über die Prototypen kommen häufig auch erst die entscheidenden Fragen auf. In der Theorie übersehen wir Menschen häufig Dinge, die es für die Implementierung braucht. Beim Prototypen stellen wir das dann fest und schon können wir neue Backlogeinträge schreiben.
Produktentwicklung
Im Agilen haben wir eher Produktentwicklung statt Projektentwicklung. Ich nehme mir also mein Team und mache erst einmal eine grobe Themensammlung. Best Guess ins Backlog. Danach schaue ich mit dem Team gemeinsam was denn die relevanten Mindestanforderungen sind um das Produkt auf die Straße zu bringen. Also den ersten Minimalansatz als erste Version des Produktes herauszubringen. Darauf fokussiere ich mich dann erst einmal.
Die Planung abgeben
Mit Deinem Team brauchst Du nun nicht auf Anforderungsebene schätzen, sondern kannst dies auf Feature / Funktionsebene tun. Dafür nimmst Du alle Funktionen, die Du im Backlog hast und schätzt diese relativ zueinander in Iterationen. Nun kannst Du Deine Schätzung für das nächste Jahr abgeben und variabel Funktionen tauschen, falls neue hinzukommen. Einfach eine 5 Iterationsfunktion gegen eine 2er und 3er tauschen etc.
Sei also Transparent, wenn Du auf Änderungen reagierst. Beispielsweise, wenn sich Dein Umfeld ändert oder da Projekt neue Aufgaben hineinbekommt. Dies macht es anderen leicht Deine Änderungen am Plan nachzuvollziehen und warum sich einige Funktionen nach hinten verschieben.
Das Team stabil halten
Mein Anliegen ist es das Team möglichst stabil und effektiv zu halten. Damit sind die Budgetschätzungen meist die gleichen über Jahre. Lediglich am Umfang schrauben wir und wann der Zeitpunkt ist, wann wir fertig fertig sind. Liefern können wir jeder Zeit, da es sich nur um Updates (Inkremente) des Produktes handelt.
Im Dramadreieck des Projektleiters halte ich damit die Ressourcen stabil, und den Termin. Variiert wird hauptsächlich über den Umfang. Zudem kommt eine vierte Komponente hinzu, nämlich die Qualität, welche auch hochgehalten wird, da sie implizit ist. Dies ist eine wesentliche Änderung zum klassischen Projektmanagement, wo die Qualitätssicherung und die Tests häufig weggekürzt werden, wenn die Zeit knapp wird.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann bewirb dich gerne für unser True Leader Coaching: https://forms.gle/6EteZLp8JhuTE2Dg9 – Durch deine Bewerbung hast du die Chance auf einen der nächsten freien Plätze.
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
