storz.net

21.08.2017
Your fortune today:
All your extbase are belong to us.

#RawEstimates + Lean + Agile bei sitegeist

#RawEstimatesMit Christian Dähn von it-agile sprach ich kürzlich über die „alte“ Geschichte: Was würdest du als Agile Coach mit auf eine Insel nehmen, wenn du nur eine Sache wählen dürftest. Die Antwort ist „die Retrospektive“, weil man aus der Retro alles andere entwickeln kann (inspect & adapt).

 

Sven Ditz brachte auf dem Firmen-Retreat der sitegeist eine hübsche Version aus Richtung Business: Wenn er nur eine Sache von all dem, was die sitegeist gelernt hat und macht, mitnehmen dürfte, wäre das #RawEstimates. Warum?

 

Was heißt #RawEstimates??

#RawEstimates ist eine für Kunden akzeptierbare Adaption von #noestimates. Seit langer Zeit geistert das Hashtag #noestimates, beziehungsweise die Ideen und Konzepte drum herum durch die Community. Schätzen ist Waste, Schätzen ist schwierig, schätzen ist sinnlos. Wir arbeiten bei der Techdivision intensiv an Schätzgüte und Vereinfachung der Schätzung, aber klar, immer wieder beschleicht einen das Gefühl: Wenn es schwierig ist und anfällig und wenig gut läuft, dieses Schätzen... Dann lassen wir es doch bleiben? Dazu kam es bei uns (TD) bisher noch nicht. In den letzten Wochen und Monaten habe ich mit Sven (Ditz) und Gina Steiner bei sitegeist super interessante Gespräche gehabt.

Nun ist #noestimates eine tolle Sache, aber deutlich schwieriger zu verkaufen als #RawEstimates. Beziehungsweise nicht weit weg von #RawEstimates, wenn man aus Issue Count und Lead Time eine Prognose macht (Kanban). Denn dann habe ich im Big Picture #RawEstimates, und zwar deshalb, weil die Vorhersagegüte bei großen Issues (Epics etc.) aus zwei Gründen schlechter ist:

Größere Unsicherheit bzgl. Scope und (u.a. dadurch) größere Streuung in der Lead Time. Also ganz einfach: #noestimates auf Issue-Niveau + Kanban = #RawEstimates auf Epic- Niveau (Beziehungsweise Feature-Niveau, Beziehungsweise egal, wie man die Aggregatsniveaus oberhalb von Workable Issues nennt).

 

Warum folgt aus #RawEstimates {alles}?

Erst mal: #RawEstimates heißt Customer Collaboration over any negotiation.

sitegeist arbeitet ohne Angebote und ohne Verträge. Die Ansage lautet ganz einfach: Wir haben in deinem Projekt n, z.B. 24 Module identifiziert. sitegeist nennt die {Dinge auf Aggregatsniveaus oberhalb von Workable Issues} Module. Beziehungsweise Gummi-Module, wozu wir noch kommen werden. Module klingen anfassbar, sind plastisch, es ist dabei nicht ein in sich geschlossenes Modul im technischen Sinne gemeint. sitegeist wollte aber, um Missverständnisse und Verwechslungen zu vermeiden, weg vom Wording „Epic“ oder „Aufgabe“ (Story Mapping) etc. Ich persönlich kann mit „Modul“ leben.

Diese 24 Module können wir für € 120k in 6 Monaten umsetzen. Wir wissen nicht, wie groß das einzelne Modul ist, darum bepreisen wir sie auch nicht einzeln, sondern geben nur ein #RawEstimate für alle 24 Module zusammen. Wir wissen vom Gefühl her, dass Modul X wahrscheinlich deutlich größer als Modul Y ist. Aber das wollen wir gar nicht diskutieren, sonst geraten wir in Diskussionen („Ist X jetzt 2 oder 3 Mal größer als Y? Und womöglich stellt sich hinterher auch heraus, das Y größer war als X...), die wir nicht wollen und die niemandem nutzen.

Deshalb nennen wir sie Gummi-Module. Stell dir die 120k als einen Kasten vor, in dem sich die 24 Module befinden. Eine detaillierte Beschreibung der Module erfolgt nicht. Die Module heißen z.B. „Hotelbewertungen automatisiert integrieren“ oder „Navigation“. Weitere Detailbeschreibungen zu den Modulen gibt es nicht. Ziehen wir eines davon größer als 1/24 (viele Änderungsrunden, erwiterter Scope, Gold Plating etc.), müssen wir im Blick behalten, dass andere dafür kleiner werden, weil sie sonst nicht mehr alle in den Kasten passen. Ganz einfach.

Letztlich nichts anderes als Dimensional Planning, aber ausgehend vom Budget und einer auf Erfahrung basierenden „gefühlsmäßigen“ Gesamtschätzung. Und ich kann aus eigenen Projekten bestätigen, dass diese „gefühlsmäßigen“ Gesamtschätzung erfahrener Devs und POs/PMs fast immer valider war als die pseudogenaue Hochrechnung von Einzelschätzungen. Die Validität kann sich durch das „Gummi“ in den Modulen natürlich automatisch einstellen. Sven Ditz hat also recht: Wozu dann das Ganze? Weglassen!

Damit der Kunde mit dem Argument „Risiko“ nicht landen kann, gibt es Review und Kostenaufstellung (also Scrum-like vorgehen). Natürlich haben die Kunden Angst davor, dass die Summe der Stunden zu hoch ist, denn selbst der Kostenumfang eines Sprints wird nicht zuvor festgelegt (!). Es gibt aber einen magischen Satz, und der lautet:

Wenn Ihnen das Ergebnis gar nicht gefällt, dann zahlen Sie einfach nichts.“

Die Antwort ist in der Regel ein verblüfftes „Ach, das geht...?“ Das Konzept ist noch schärfer als money for nothing and change for free und sorgt m.E. dafür, dass der Kunde sich vertrauensvoll auf Agile und #RawEstimates einlassen kann. 

Ist das „Nicht-Bezahlen“nicht ein zu großes Risiko für die Agentur?Hierzu meint Sven Ditz, er könne nach eineinhalb Jahren Praxiserfahrung sagen, dass das in der Regel sehr selten passiere. Auf jeden Fall war früher die Summe an nicht bezahlten Stunden aus Pauschalprojekten, die einfach viel aufwändiger waren als geschäzt, um ein großes Vielfaches höher!

 

Natürlich auch: Responding to change over following a plan

Änderungen? Kein Problem! Wir haben eine Box von 120k, wir haben 24 Gummi-Module, zieh eines größer = mach andere kleiner oder schmeiß sie raus usw. Das klassische „Change for free“ aus Scrum, wie oben erwähnt. Hier also nichts Neues.

Wichtig ist das konsequentes „Fahren auf Sichtweite“, i.e. Rolling Wave planning: Welche und wie viele Issues aus den einzelnen Modulen entstehen, legt man erst fest, wenn die Module anstehen .

 

Und selbstverständlich: Working software (product) over comprehensiv documentation

Denn wie überzeuge ich nach dem Projektstart Kunden weiterhin und immer wieder, dass das Konzept funktioniert? Indem ich liefere. Durchstiche statt Komponenten oder Layer. Liefern, schnell, mit reduziertem Scope, um Feedback zu bekommen, dann iterieren und/oder nächstes Inkrement. Hier nichts Neues. Aber mit dem Zwang: Ich muss es so machen, sonst springt mir der Kunde ab. Sven Ditz meint: Wenn ich das dem Kunden auch so klar verdeutliche, versteht er: Er kann sich bei dem RE.A.L.-Konzept viel sicherer sein, das die Agentur das gesamte Projekt über höchst effizient und engagiert arbeitet.

 

Wozu brauche ich Agile?

Agile ist ein Muss, denn ich kann nur schnell liefern und damit fortwährend überzeugen, indem ich inkrementell liefere und iteriere („Das Feature doch etwas aufgebohrt? Kein Problem!“). Aus Raw Estimates folgt zwangsweise Agile. Und ich kann nur schnell liefern und Änderungen akzeptieren, wenn ich agile Entwicklungspraktiken verwende (CI, automatisches Testen etc.). Ein „Jetzt nichts mehr anfassen, bitte“ gibt es nicht!

 

Wozu brauche ich Lean?

Man kann evtl. formulieren, dass Agile ohne Lean ohnehin keine gute Idee ist, aber ich will es konkreter machen: Die Konzentration auf das Budget (Raw Estimate findet in EUR statt) macht allen Beteiligten brutalst klar: Waste = Geldvernichtung. Das ist zwar eigentlich immer klar, aber ich habe schon oft erlebt, dass weder PO noch SM das im Scrum-Team so verankern, dass maximale Wertschöpfung bei Maximierung von „work not done“ die Prio Nr. 1 sind.

Und natürlich brauche ich Lean ohnehin, um alle Overheads, die ich habe, immer wieder zu prüfen und wenn möglich als Waste zu eliminieren.

Und ich brauche „Respect for people“, denn erst ein optimales Team mit einem optimal educated Kunden kann die hochanspruchsvolle Aufgabe „erfolgreiches Projekt“ meistern. (Das gilt ja eigentlich immer, auch ohne Raw Estimates, Lean und Agile, oder?) Und damit sind wir bei: Individuals and interactions over processes and tools.

Was ist daran neu?

An den Einzelbestandteilen: Gar nichts. Ich finde es aber dennoch bestechend. Weil der Kern bei #RawEstimates die Business Collaboration ist, die das alte Problem „Wie messe ich den gelieferten Wert?“ umdreht: „Wie viel willst Du für Feature/Epic/Modul X ausgeben?“ Das, was man sich als "Agilist" immer vom Kunden wünscht. Auch das ist nicht neu. Agile heißt schon immer „Wir bauen dir inkrementell/iterativ so viel Produkt, wie du Geld/Zeit hast, priorisiert nach Wert (und Risiko und COD usw.;)“ Aber Hand aufs Herz, ist das so einfach, wie es klingt? Nein. #RawEstimates als Denkmodell, als Kern und Basis der Zusammenarbeit macht es m.E. ein großes Stück einfacher.

 

 

Datum: Samstag, 04. Juli 2015

Kategorien: Agile

comments powered by Disqus