Folge 051 Budgetplanung

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,


Janina & Henry


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:


Cynefin

Transparenz

Anpassen

Teams

Backlog

StoryPoints

Planungsfehler



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


Facebook


Webseite


 


The post Folge 051 Budgetplanung appeared first on Znipcast - für
gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.