Agil mit festen Budgets entwicklen!

Unser Vorgehen ist agil. Wir entwicklen seit geraumer Zeit agil Software; so lange, dass wir mittlerweile sagen, dass wir post-agil vorgehen, um uns von den teilweise doch sehr ideologisch vorgetragenen Grundfesten mancher Berater im agilen Umfeld zu distanzieren. Dazu lohnt sich auch der Blog-Artikel (https://conventic.com/was-ist-post-agilitaet-context-over-convention) vom Marcelo Emmerich. Unser Unternehmen ist von der Basis her organisatorisch gesehen ebenfalls agil; und das ganz bewusst, weil wir glauben, nur so recht komplexe Aufgabenstellungen umsetzen zu können (… wer in größeren Firmen schon versucht hat, größere Projekte umzusetzen, weiß vielleicht in welche Richtung das gehen kann / soll). Wir wollen pragmatisch und zielorientiert vorgehen und eben nicht dogmatisch oder ideologisch geprägt. Bei einigen Beratern hat man das Gefühl, Agilität sei eine Religion. Das treibt dann in Projekten so seine Stilblüten.

Dazu nur ein Beispiel:

Wir beraten in einer Kundensituation und betreiben die Entwicklungsinfrastruktur. Dort ist/war auch eine „Agile Beratung“ vor Ort, um die Entwicklungsmannschaft zu agilisieren. Im Einsatz ist ein JIRA. am Ende der Beratung der Kollegen gibt es wieder ein echtes analoges scrum board mit Zetteln an der Wand… Meine Frage an den Projektleiter, wie er jetzt Abhängigkeiten zwischen den einzelnen Tickets sieht und wie er in den Tickets nach Stichworten sucht oder rein quantitativ misst, wieviel pro Zeiteinheit gearbeitet wurde beantwortet dieser mit Schulterzucken…

Wir sind da eher Agnostiker. Was dem Projekt hilft ist gut. Und Kunden haben eben manchmal Anforderungen, die nicht zu 100% den hohen Ansatz des scrums widerspiegeln. So z.B. feste Budgets und damit einhergehend trotzdem eine Vorstellung oder besser: Erwartung, was in dieses Budget alles reinpassen muss. Erfahrungsgemäß sei hier gesagt, dass das Erwartungsmanagement an der Stelle nicht wirklich überschätzt werden kann und dass nachgelagerte Verhandlungspartner, wie bspw. der Einkauf, alles andere sind als Fachleute in Sachen Agilität. Im günstigsten Fall hat die Fachseite hier schon etwas Vorarbeit geleistet und man hat einen Auftrag in Sachen T&M, kann also schön am Monatsende abrechnen.

FIX ABER DENNOCH AGIL?

Was aber, wenn der Einkauf im Grunde ein Gewerk will, das Projekt aber trotzdem einigermaßen agil stattfinden soll?

Aufgrund der Tatsache, dass sich der Scope gemäß scrum gewollt ändert und man flexibel darauf reagieren kann, ergibt sich das Problem, dass es im Grunde keine referenzierbare Gesamtzahl für den Aufwand im Vorfeld gibt.

Somit lässt sich auch nicht der aktuelle Stand im Bezug auf das fertige Produkt benennen. Gäbe es die komplette Abschätzung und wäre der Gesamtaufwand vorab bekannt, wäre es per Definition kein agiles Projekt!

VORGEHEN

Dem nähern wir uns nähern, in dem wir versuchen, den agilen Entwicklungsprozess zu verstehen indem wir ihn messen. Wir erheben möglichst nah am scrum-Prozess Werte und interpolieren diese sinnvoll. Und wichtig: wir nutzen die scrum-Institution der Sprint-Retrospektive mit allen Stakeholdern explizit und aktiv.

Unser Modell geht von der initialen Entwicklungsgeschwindigkeit des DEV-Teams mit Blick auf das Backlog aus und versucht, eine Prognose zu wagen, was am Ende des Projekts alles umgesetzt werden kann. Das gute daran: Je länger das Projekt läuft, um so genauer werden die Prognosen. Dazu bedarf es allerdings einiger Änderungen des üblichen Vorgehens: Die umfassendste: das gesamte Backlog, also die einzelnen Tickets sollten vor Beginn der Entwicklung oder zumindest zu Anfang in Bezug auf den Aufwand abgeschätzt werden. Dabei geht es noch nicht um außerordentliche Genauigkeit, sondern darum, die Grundgesamtheit des Aufwands zu erfassen. Um entsprechende Puffer zu haben, schadet es auch nichts, an der Stelle etwas großzügiger zu schätzen. Da zu Beginn des Projekts üblicherweise das gesamte Backlog noch nicht existent ist, ist an der Stelle schon mal klar, dass die interploierten Ergebnisse zu Beginn noch nicht so belastbar sind. Macht aber noch nichts, das Projekt dauert ja noch was an. An der Stelle geht es eher noch darum, das Team und seine Geschwindigkeit initial zu messen und zu sehen, dass alle relevanten Parameter erfasst werden. Warmlaufen sozusagen. Im weiteren Projektverlauf wollen und müssen wir genauer werden. Erstens sind dann weitere Stories im Backlog, die auch wieder direkt abgeschätzt werden müssen und zweitens kommen jetzt auch noch Bugs dazu, die ebenfalls immer direkt in Bezug auf ihren Aufwand abzuschätzen sind. Der Aufwand der kommt nun zum Gesamtaufwand hinzu. Die Bug-Rate sollte ebenso wie die Velocity in den ersten Sprints „eingestellt“ werden und in den kommenden Sprints als Indikator für die Qualität genutzt werden.

SPRINTBEWERTUNG

Formal muss in der Umsetzung das Sprint Review stärkeres Gewicht erhalten, da an der Stelle auch Vereinbarungen mit den Stakeholdern getroffen werden. Es wird wie folgt vorgegangen:

Bei Sprint-Retrospektive sind alle Stakeholder in Form eines definierten Stakeholder-Gremiums vertreten.
Zusammen mit Project Owner entscheiden die Stakeholder ob und wie umfänglich eine Anforderung umgesetzt wurde.
Ggf. zur Fertigstellung einer Anforderung oder zur endgültigen Korrektur eines Bugs benötigte Aufwende des aktuellen Sprints werden jeweils im Rückblick bewertet, also auch wie groß die ggf. notwendige Nacharbeit ist.
Der aktuelle Stand kann dann gegen die bisher in Summe abgeschätzten Anforderungen verglichen werden

Das kommt weitestgehend bekannt vor. Interessant ist hier aber, dass es zum kontinuierlichen Abgleich der alten Aufwandsabschätzung mit der neuen kommt. Und nur teilweise umgesetzte Anforderungen haben einen Restwert, der ebenfalls in den Gesamtaufwand mit eingerechnet wurde. Ziel ist es nun, bei der Retrospektive den vergangenen Sprint zu bewerten und zwar so, dass er mit allen anderen Sprints vergleichbar ist. Wie sieht das aus?

Im Grund recht einfach: Die Planung des Sprints, entweder in Story Points (so wie im Beispiel) oder auch gerne in echtem Zeitaufwand (bei einer Einheit bleiben), ergibt sich aus der Abschätzung der umzusetzenden Anforderungen + dem Aufwand der zu fixenden Bugs. Dazu können auch noch DevOps-Themen und andere bspw. technische Bereiche kommen.

Die Gesamtsumme der initialen Planung (oben) wird nun mit der Bewertung (unten) verglichen und eine Differenz gebildet, den wir hier mal Folgeaufwand nennen wollen, um ihn vom ursprünglich geplanten Aufwand zu differenzieren. Der Folgeaufwand ist nun ein Parameter der weiteren Betrachtungen und ein Qualitätsindex unserer Arbeit.

Ist der Folgeaufwand hoch, haben wir schlecht geschätzt oder schlecht gearbeitet oder beides. Auf jeden Fall müssen wir a) Forensik betreiben, warum das so schlecht ist und b) die Schätzung für den nächsten Sprint entsprechend anpassen.

Nebenbei bemerkt: Wenn wir mehr umgesetzt haben als geplant, ist das zwar schon mal gut für das Projekt, die Schätzung für den nächsten Sprint muss aber dennoch angepasst werden. Es geht ja darum, möglichst genau vorab sagen zu können, was am Ende alles umgesetzt werden kann.

MITTELWERTBILDUNG UND INTERPOLATION

Wie geht es nun weiter? Wir nehmen die vorhandenen Daten und verfahren wie folgt:

Agilität bleibt im Vordergrund; es erfolgt kein direkter Eingriff ins Projekt; es wird nur beobachtet respektive gemessen.
Die üblichen Codemetriken wie Velocity, Burndown, Zyklomatische Komplexität, durchschnittliche Aufwand / User Story, durchschn. Bug-Behebungszeit, Prozentsatz Bugs und Reopens, Regressionen, … werden natürlich erhoben und für forensische und qualitätssichernde Zwecke genutzt.
Für eine Abschätzung der Projektdynamik werden jeweils die Veränderungen der 3 letzten Sprints für eine Mittelwertbildung betrachtet.
Dieser Mittelwert wird jeweils auf die Anzahl der noch zur Verfügung stehenden Sprints interpoliert.
Statistische Ausreiser werden so in der mittelfristigen Planung egalisiert, fallen aber im Dashboard als mögliches Problem trotzdem auf.
Der interpolierte Aufwand fällt höher aus, da er durchschnittliche Höhe der Änderungen mit einbezieht, diese aber gegen Ende weniger werden (Das ergibt noch zusätzliche Puffer).

Mit etwas Erfahrung und Gefühl für das Vorgehen lassen sich so pseudo-agile Projekte tatsächlich weitestgehend agil umsetzen, wenn alle Beteiligten verstehen, dass das Verfahren mit der Zeit erst genauer wird.