Im zweiten Teil des Doppel-Artikels schauen wir nun auf #Noestimates, Scrum 3.0 und Kanban. Diese bieten andere Ansätze, wie Teams sich selbst in Eigenregie messen können.

#Noestimates

“Noestimates” klingt erstmal recht reißerisch: Wir machen einfach keine Schätzungen mehr. Wie Vasco Duarte es in seinem Video aber gut erklärt: wir messen trotzdem noch etwas und planen mit Hilfe dieser Metriken.

In seinem Blog definiert Woody Zuill #noestimates als:

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with “No Estimates”.

Bei #noestimates zählt man etwa nur die Anzahl der geschafften Stories über die Zeit und spart sich die Estimation-Meetings. Vasco erläutert im Video einige mit Schätzungen verbundene Nachteile:

Waste: Das Managen eines Backlogs, das Schätzen der Backlog Items und vielleicht sogar die Überarbeitung dieser Schätzungen zu einem späteren Zeitpunkt sind Verschwendung.

Langzeit-Commitment: Die zu schätzenden Tickets repräsentieren einen Plan. Das Schätzen bedeutet also, sich zu einem Plan zu committen. Schätzt man nun ein Backlog durch, bedeutet dies ein Commitment zu einem Langzeit-Plan, was dem Gedanken von Agilität gänzlich widerspricht.

Fehlende Anpassung: Ein springender Punkt der Arbeit in Iterationen ist ja, Feedback für das Gelieferte zu erhalten. Dieses Feedback verändert oft den Scope – also die Backlog Items. Stories verändern sich also und werden meist eher größer. Und schon stimmen die Schätzungen nicht mehr.

Schlechtere Vorhersagbarkeit: Analysiert man die Daten der Sprints von Teams, kommt man schnell zur Schlussfolgerung, dass mit Story-Punkte die Vorhersagbarkeit nicht besser ist, als einfach nur die Anzahl der Stories zu zählen. Im Gegenteil: wie sich zeigt, steigt die Vorhersagbarkeit sogar, wenn man nur Daten des Story-Durchflusses verwendet – und es gibt damit auch weniger Overcommitment.

Die Verläufe über die Zeit von mehreren Teams aus mehreren Firmen werden im Video ausgewertet und es wird die Vorhersagbarkeit von Story Points der von einfach nur Stories zählen gegenübergestellt. Ein elementarer Aspekt dabei sind die Daten: nur anhand dieser kann man Schlussfolgerungen ziehen und experimentieren. Normalerweise hat die aber jedes Scrum Team. Sie verstecken sich meist nur – etwa in JIRA Sprint Reports – und man muss etwas Zeit investieren, um sie herauszuziehen.

Screenshot aus dem Video von Vasco Duartes Talk von der Øredev 2014

In ihrem Artikel “Putting #noestimates in action” bringt Albina Popova das “Warum” von #noestimates sehr gut auf den Punkt, finde ich: Wir fokussieren uns darauf, so schnell wie möglich den maximalen Wert zum Endkunden zu liefern und planen dabei kontinuierlich neu. Wir nutzen dabei den minimal nötigen Schätzprozess.

Sehr cool im Artikel finde ich den Wechsel der Diskussionsgrundlage über Stories. Vorher fragte man: wie groß bzw. komplex ist diese Story? Mit der Diskussion darüber erhielten alle im Team ein besseres Verständnis über den Umfang und die Risiken. Nachdem wir nun keine Größe mehr brauchen, schlägt Albina als ein Beispiel eine andere, viel bessere Frage vor: Was ist der Geschäftswert dieser Story?

Aber gehören denn Story Points und Velocity nicht elementar zu Scrum? Scrum hat sich über die Jahre sehr gewandelt und Boris Gloger gibt ihm derzeit eine Version “3.0”.

Scrum 3.0

In seinem Talk vom Meetup Leipzig im letzten Mai beschreibt Boris Gloger Scrum 1.0 als das Scrum basierend auf Ken Schwabers Buch: “Software Development with Scrum”. Boris zieht das Fazit: Scrum 1.0 hat nie funktioniert!

Um 2004 datiert Boris dann den Start von Scrum 2.0. Scrum 2.0 repräsentiert die Best Practices. Wir haben gelernt, die Grundideen von Scrum handhabbar zu machen, so dass Scrum funktioniert. Hier spielen sich auch die vielen Praktiken, Techniken und Verfeinerungen aus dem Teil 1 dieses Artikels ab.

Nun beschrieb der Scrum Guide bis 2011 als Teil des Sprint Planning 1 das Commitment des Entwicklungsteams auf ein Sprint Backlog. Dies hat sich verändert, nun ist die Rede von einer Vorhersage:

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal

Den Grund dafür lässt Boris in seinem Talk durchblicken: Commitment ist ein Wert von Scrum. Es bedeutet, dass ich überhaupt mitmachen will. Es bedeutet nicht ein Commitment auf den Sprintplan am Ende des Sprint Planning 1.

Foto: Rolf Irion, Scrum 3.0 – Talk von Boris Gloger auf dem agiLE Leipzig Meetup

Kein Commitment mehr auf mittels Schätzungen geplante Sprints und stattdessen eine Vorhersage. Dies bedingt Zahlen und Messungen, und das erinnert schon stark an #noestimates. Dieser Evolutionsschritt von Scrum ist einer der Bestandteile von Scrum 3.0. Hier stehen Weglassen und Einstampfen im Vordergrund. Dabei werden Dinge aber auch beibehalten. So etwa die Rollen (wenn auch mit geänderten Definition), das Liefern, der Fokus und den Wert Respekt – also die Leute ernst zu nehmen.

Scrum 3.0 verinnerlicht also den #noestimates-Ansatz und basiert Vorhersagen die auf Messung von Durchlaufzeiten. Das Team misst einfach die Zeit zwischen Erstellung der Arbeitskarte (“Entry date”) und der Live-Auslieferung (“Delivery date”). Es gibt keine Schätzungen mit Story Points mehr. Damit gibt es auch keine Planning-Poker und Magic-Estimation Runden. Der große Aufwand mit Estimation-Meetings ist verschwunden und das Backlog Refinement dient dem Verständnis und ggf. Aufbrechen von User Stories statt dem Schätzen.

Dabei spielen Größenunterschiede der Arbeitspakete eine geringere Rolle, als bisher. In Scrum 2.0 wurde in so vielen Teams Stunden um Stunden damit verbracht, Anforderungen in die richtige, möglichst kleine Größe zu zerteilen. Jedoch beeinflusst die Varianz in der Größe die durchschnittliche Durchlaufzeit viel weniger, als man vermutet.

Folgt man die Vorschläge von Boris noch weiter, werden Schätzungen noch weltfremder. In einem Team, das Daily Stand-Ups als Micro-Sprint-Reviews behandelt, bei denen man von PC zu PC geht und sich alles neue und geänderte seit dem Vortag anschaut, braucht man kein Team-Taskboard und keine Klebezettel mehr. Und ein Team, das sich auf genau eine Aufgabe konzentriert und mittels Mob-Programming an nur dieser einen arbeitet, braucht keine Backlogs (die Backlog-Größe wäre ja: 1) und gar keine Daily Stand-Ups (alle waren ja sowieso bei der Implementierung dabei) mehr.

Durchlaufzeiten zu Messen ist aber keine neue Innovation von #noestimates oder Scrum 3.0. In seinem Talk sieht Boris als starken Einfluss dafür: “Baam! Und da war KANBAN da.”

Kanban

Kanban ist bei vielen Software-Teams beliebt. Ein Grund ist die scheinbare Einfachheit verglichen mit Scrum. Aber Kanban richtig zu implementieren ist meiner Meinung nach schwieriger, da es mehr Freiräume und damit weniger Leitlinien gibt. Auch ist das Mindset etwas anders, denn ein elementares Konzept ist es, künstliche Limits gezielt einzubauen. Teams sind dann in der Evolution ihres Prozesses häufig am Feilen an diesen Work-In-Progress Limits – es gibt quasi keinen finalen Endzustand.

Anfang des Jahres habe ich ein Software-Team “neu gestartet”. Sie hatten vorher einen Kanban-Prozess, was für sie aber lediglich ein JIRA-Kanban-Board war. Ein Grund für Kanban war, dass für sie Scrum “zu viele Meetings hatte”. Nun gut, dachte ich mir. Dann machen wir aber auch richtig Kanban. Anhand des Buches “Kanban In Action” von Sunden und Hammarberg hangelten wir uns zusammen entlang zu einem funktionierenden Kanban-System.

Für mich lagen die Vorteile auf der Hand: das Team bewegt sich aus dem “arbeite irgendwie”-Modus bewusst zu einem Flow-System, in dem es selbst die Kontrolle hat. Die Akzeptanz und das Engagement sind dabei hoch, weil den Teammitgliedern kein Scrum-Prozess aufgezwungen wird. Schnell fingen wir dann an, auch Messungen vorzunehmen:

  • Der Work-In-Progress der einzelnen Prozessschritte am Board mittels Anzahl der Aufgaben (täglich im Stand-Up)
  • Der Startzeitpunkt, wenn eine Aufgabe in Entwicklung geht und der Endzeitpunkt, wenn eine Aufgabe zur Integration in der Master gemergt wird (Durchlaufzeit, täglich im Stand-Up)
  • Durchschnittliche Durchlaufzeit und Durchsatz (alle 2 Wochen in einem gemeinsamen Treffen für die Auswertung)

Beispiel einer Spektralanalyse der Durchlaufzeit aller Tickets einer 2-Wochen-Periode des Teams

Das Team ist nun an dem Punkt, an dem es experimentell Änderungen an seinen WIP-Limits vornimmt und an dem es es Vorhersagen basierend auf der Historie der Metriken machen kann. Außerdem erkennt es anhand der Durchlaufzeiten sehr gut Ausreißer. Das sind Aufgaben, die ungewöhnlich viel mehr Zeit gebraucht haben, als andere. Diese Art von Spektralanalyse mit dem Auftragen der Anzahl der Aufgaben zu ihren Durchlaufzeiten gibt dem Team auch einen sehr guten Ansatzpunkt für eine Retrospektive. Die Evolution des Teams habe ich vor kurzem in einem Talk auf dem Agile Meetup Dresden zusammengefasst.

(die Slides gibt es hier)

Die Durchlaufzeit, auch Cycle Time, ermöglicht also Vorhersagbarkeit: wann wird eine Aufgabe, die wir heute anfangen wahrscheinlich fertig sein? Der Durchsatz, auch Throughput, ermöglicht auf der anderen Seite eine Aussage wie etwa: wir haben zwei Wochen Zeit; wie viele dieser Aufgaben hier schaffen wir?

Denken wir zurück an den #noestimates-Artikel von Albina Popova erkennen wir das wieder:

Instead of looking at previous sprints velocity in story points, we were looking into previous sprints velocity in backlog items as a guide to define how many stories to take into upcoming sprint.

Verlässt man die eingetretenen Wege von Scrum mit seinen Schätzungen und startet mit den Metriken, die aus Kanban kommen, empfiehlt es sich, sich mit den Grundlagen, den Visualisierungen und der Datenerfassung in Kanban näher zu beschäftigen.

Fazit

Lange Zeit galt als gesetzte Regel für Scrum-Teams, dass sie in Story Points das Backlog zu schätzen und ihre Velocity zu steigern haben. Diese Starrheit ist zum Glück vorbei. Diese Herangehensweise passt gut auf Teams, die mit Scrum und Agilität gerade erst anfangen. Hat man dann das Handwerkszeug erlernt, stört aber es mehr und mehr. Die Erfahrung des Teams, dessen Abhängigkeiten nach außen – also die Struktur um das Team – und die Kultur der Umgebung ermöglichen über die Zeit alternative Ansätze. Es ist eine Art Team-Evolution: Weg von Manntagen, zu selbst planen, pokern, schätzen und schließlich hin zu Daten: messen statt schätzen. Im Interview mit InfoQ schreibt Vasco Duarte dazu:

When you apply that principle in a particular context you may still take estimates as a “stepping-stone” to the next stage of #NoEstimates.

Quellen

Schätzungen von Scrum über #Noestimates zu Kanban – Teil 2

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.