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

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

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:
=&0=&: 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.

=&1=&: 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.

=&2=& 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.

=&3=&: 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

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

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

Anja und ich haben vor einer Weile wieder das agiLE Meetup in Leipzig besucht. Diesmal gab es ein Fokusthema, “Product Ownership”, und so behandelte eine Session des Open Space auf dem Meetup die Frage, welche Schätzverfahren die Teilnehmer in ihren Teams einsetzen und ob denn überhaupt geschätzt wird. Das Thema wird auch im Management 3.0, in der #noestimates-Initiative, in Scrum 3.0 und in Kanban angesprochen, was ich in diesem Doppel-Artikel etwas genauer unter die Lupe nehme.

Schätzmethoden

Die meisten agilen Teams starten mit Scrum und viele Teams adaptieren schnell ein Schätzverfahren – etwa mit Story Points nach Fibonacci-Zahlen in Planning-Poker-Runden.

Betrachtet man nun über die Zeit viele Teams, so findet man Abwandlungen und Vereinfachungen davon. Insbesondere am Anfang tun sich viele Teams, die aus einer klassischen Projektmanagementwelt kommen, schwer mit abstrakten Größen wie Story Points. Sie schätzen daher gern in Zeitangaben mit Stunden oder Tagen – oder sie haben eine Umrechnung in Story-Punkte. Gerade wenn ein Team noch keinen leicht von der Hand gehenden Schätzprozess hat, lohnt sich auch der Einsatz von Referenz-Stories, die eine Art Skala für Schätzungen vorgeben.

Anderen Teams sind die Story-Punkte zu granular – sie brauchen viel Zeit zum Schätzen, ziehen aber gar nicht so viel nützliche Informationen daraus. Diese Teams legen sich dann z.B. auf nur wenige mögliche Größenkategorien fest – “alles größer als 8 ist zu groß”. Oder aber sie gehen zu einfacheren Systeme über und schätzen in T-Shirt-Größen mit S, M, L.

Foto: Rolf Irion

 

Mit Planning Poker werden die einzuschätzenden User Stories zwar so besprochen, dass jeder ihren Sinn und Kern verstanden hat, jedoch spricht man jede Story durch – und das kann recht viel Zeit in Anspruch nehmen. Viel schneller kann hier Magic Estimation sein, denn hier bespricht man nur die Stories, die noch Klärung benötigen. Ich habe Teams gesehen, die damit in 45 Minuten satte 50 Tickets geschätzt haben (ok, hier waren nicht nur User Stories sondern auch Verbesserungen und Defekte dabei).

Auf dem Meetup in Leipzig brachte ein Teilnehmer eine mir noch unbekannte Technik mit:

3-Punkte-Schätzung nach DeMarco

Remote Daily Stand-Ups

Remote Daily Stand-Ups

Remote Daily Stand-Ups meint täglich stattfindende Planung im Team, bei der ein oder mehrere Teammitglieder nicht am gleichen Standort sind wie der Rest des Teams. In diesem Artikel möchte ich meine Erfahrung mit solchen Teams beschreiben und ein paar Tipps geben, wie man die auftretenden Schwierigkeiten meistern kann.

Daily Scrum Meetings – oder auch einfach Stand-Ups – stellen viele Teams vor eine Herausforderung. Gerade in der Aufbauphase des Teams tun sich so einige Teams schwer einen sinnvollen Inhalt und ein funktionierendes Format festzulegen. Geht der Impuls damit überhaupt anzufangen nun auch noch von einem “Externen” – etwa Vorgesetzten oder auch Coach bzw. Scrum Master aus, so ist die Akzeptanz und Disziplin im Team meist sehr dünn. Ist dieser “Externe” einmal nicht da, schon fällt das Daily aus.

Boards & Buddies

Als eine sehr starke Hilfe habe ich die Visualisierung und Interaktion des Teams mit seinem Team-Board beobachtet. Das klappt am besten, wenn das Team ein analoges Board z.B. an einem Whiteboard im Einsatz hat. Im Stand-Up aktualisiert jedes Teammitglied verbal (es beschreibt die Aufgaben kurz) und haptisch (die Karte am Board wird geschoben, ggf. einfach auch anfassen) seinen Arbeitsstand. Damit löst sich das Team von ganz allein von einem Reporting-Charakter. Es eröffnet auch das Experimentieren andere Abläufe im Stand-Up: etwa anstatt dass jedes Teammitglied der Reihe nach etwas sagt, geht das Team die Karten am Board durch und nur diejenigen sagen etwas dazu, die daran arbeiten.

Schwieriger wird es, wenn einige Teammitglieder nicht am gleichen Standort sind. Generell gibt es hier mehrere Varianten, wie ein Team in diesem Fall mit seinem Team-Board umgeht. Ein analoges Board kann auch hier funktionieren, ist aber viel aufwendiger. Denn damit die entfernten Teammitglieder auch damit arbeiten könnten, bräuchten sie eine Kopie des Boards, die immer aktuell ist. Damit ist Aufwand und viel Disziplin verbunden – etwa über ein “Buddy-System” von 2 Leuten, die für das aktuell-halten des Boards an beiden Standorten verantwortlich sind. Selbst der Gedanke, dies zu einfachen und einfach das entfernte Teammitglied live zuschauen zu lassen, wenn das Team im Stand-Up sein Board aktualisiert, funktioniert leider eher schlecht. Denn selbst in einem 1080p Video-Bild aus dem Teamraum mit Abfilmen des Teamboards lassen sich kaum Details erkennen. Zudem braucht das entfernte Teammitglied trotzdem einen “Buddy” um seinen eigenen Arbeitsstand am Board aktuell zu visualisieren.

Die meisten Teams nervt in dieser Konstellation mit entfernten Teammitglieder sehr schnell das analoge Teamboard und sie wechseln zu einer digitalen Lösung. Braucht man keinen großen Detailgrad der Tickets mit Feldern und Filtern und ist nicht an Prozesse wie etwa Code-Repositories, Deployments oder auch andere Teams gebunden so kann man sehr simple Tools wie etwa Trello nutzen. Diese haben den Vorteil, dass sie einfach zu lernen, aufzusetzen und zu bedienen sind. Gerade bei Scrum-Teams in einer skalierten Scrum-Umgebung mit mehreren Teams am selben Produkt stößt man hier aber schnell an Grenzen. Alle Scrum-Teams, die ich bisher unterstützt habe, setzten daher auf komplexere Tools wie etwa JIRA.

JIRA bietet Scrum und Kanban-Boards, die sich in einem Stand-Up sehr leicht auf einen großen TV darstellen lassen. Um das an- und abstecken der Technik nicht jeden Tag aufs Neue machen zu müssen empfiehlt sich ein extra Mini-PC am TV – etwa ein Barebone-PC, Mac mini oder aber auch ein AppleTV oder Chromecast mit Streaming von einem der Teammitglieder. Das Board kann man dann z.B. über das Screen-Sharing der Videokonferenz-Software mit dem anderen Standort teilen. Die meisten Lösungen bekommen das heute problemlos hin, sei es nun Skype, Hangouts, GoToMeeting oder Appear.in – das sind zumindest die, mit denen ich ganz gute Erfahrung gemacht habe.

Akustik mit Spinne

Viel wichtiger als Videokonferenz-Software, Webcam oder Qualität des Videobildes ist aber der Ton. Ein Team Stand-Up kann man sehr leicht mit Tonproblemen extrem nervig und langatmig gestalten oder es sogar ganz töten. Man kann in bessere Akustik nun aber auch sehr viel Geld reinstecken – komplette Setups für Videokonferenzsysteme in Meeting-Räumen sind schnell bei 10000€ pro Raum. Ein passabler Kompromiss sind meiner Erfahrung nach Meeting-”Spinnen”. Die Jabra Speak Freisprecheinrichtungen sind sehr preiswert, haben aber den Nachteil, dass die Reichweite des Mikrofons nur recht gering ist und dass sie nur ein gerichtetes Mikrofon in der kreisrunden Plastikoberfläche haben. Mit den Jabras gibt es auch recht preiswerte Lösungen in Verbindung mit Barebone-PC und Webcam wie etwas Googles Chromebox for Meetings, oder auch Microsofts Skype for Business. Noch besser sind die “Chat” Mikrofone von ClearOne. Ich habe bisher mit den Chat 150 und Chat 170 gearbeitet. Allerdings kosten diese auch gleich mal das dreifache der Jabras. Die Chat-Mikrofone haben allerdings eine bessere Reichweite und Mikrofone an drei Seiten.

In Team Stand-Ups hat man nun aber sehr selten einen Tisch in der Mitte des Teams stehen, auf dem man ein Tischmikrofon stellen könnte. Platziert man es auf einem der Schreibtische oder direkt am TV sind die Teammitglieder, die sehr nah am TV stehen gut zu verstehen, die aus dem Hintergrund aber gar nicht. Hier kann man aber etwas kreativ werden: man besorge sich ein Stativ und eine Befestigungsplatte bzw. eine Halterung für Tablets sowie ein langes USB-Kabel. Das Mikrofon damit auf dem Stativ befestigt und schon kann man es in die Mitte des Teams im Stand-Up stellen. Oder man geht noch einen Schritt weiter und sieht einen “Sprechbereich” für die Teammitglieder vor – etwa eine geklebte Linie auf dem Boden. In Kombination mit einem Speaker-Token wie einem kleinen Ball oder Rugby-Ball stellt sich jeder, wenn er an der Reihe ist genau an die Linie. Diese ist genau am Mikrofon und jeder ist ausgezeichnet zu verstehen.

Headsets für Alle