Netzgeflüster: Scrum von Anfang an

In „Netzgeflüster“ geht es heute um ein sehr spezifisches Thema, das v.A. für Softwareentwickler interessant ist oder all jene, die in Projekten beschäftigt sind und entsprechend agile Methoden benutzen. Für alle anderen ist vielleicht der Ausschnitt aus dem Alltag eines Softwareentwicklers interessant. Denn es geht heute um eine Vorgehensweise der Softwareentwicklung und speziell wie man bei dieser Methodik beginnt. Es geht um das Vorgehensmodell SCRUM, einer Form der agilen Softwareentwicklung, die darauf abzielt, dass Meetingaufwände reduziert werden, das Team selbst organisiert arbeitet, die Flexibilität und Transparenz erhöht wird und dass es nicht erst nach langer Vorlaufs- und Entwicklungszeit ein vorzeigbares Produkt ausgeliefert wird, sondern kontinuierlich. SCRUM ist längst nicht mehr neu. In meinem Berufsumfeld ist SCRUM gang und gäbe, aber auch ich habe bisher nur in einem Projekt erlebt wie man mit SCRUM beginnt und konnte mich ansonsten in das gemachte Nest setzen. Was an dem Beginn und ersten Sprint so besonders ist? Der Grund ist, dass Sprints sehr stark abhängig von Schätzungen und dem in vorherigen Sprints erreichten sind. Wie startet man also ohne?

Die meisten von uns, die in der Softwareentwicklung beschäftigt sind und in einem agilen Umfeld arbeiten, haben bereits Retrospektiven, Refinements, Plannings beigewohnt und im Sprint-Verlauf allgemein Sicherheit gewonnen. Trotzdem gibt es Ausnahmesituationen, die selbst im strukturierten, agilen Vorgehen Unsicherheit auslösen und wie Corner Cases eines ansonsten klaren Ablaufs wirken. Am Anfang war der Anfang und die Frage: Wie fängt man eigentlich an? Wenn nichts da ist, Boards und Diagramme noch leer? Wir kennen das Schätzen und Schneiden innerhalb unseres Backlogs, das Verfeinern. Und dank unserer Velocity haben wir eine Maßgabe wie viel wir in den nächsten Sprint einplanen. Aber wie geht man vor, wenn es keinen vorhergehenden Sprint und keine Velocity gibt? Wir reden von einem Fabelwesen, dem man nicht oft beiwohnen darf: dem ersten Sprint.

Antipattern und agiler Mythos: Sprint 0

Aber ja, es gibt sie, die ersten Sprints. Nur der Mythos vom Sprint 0 sollte besser ein Mythos bleiben. Nach Lehrbuch ist kein Sprint 0 vorgesehen, trotzdem poppt er immer mal wieder auf. Inzwischen wird der Sprint 0 sogar oftmals als Anti-Pattern bezeichnet. Unter der Annahme, dass man in einem Sprint 0 vorbereitende Aufgaben erledigt, schleichen sich meistens die ersten Verfälschungen einer Schätzung ein. Was sind solche vorbereitenden Aufgaben? Erste Meetings aufsetzen und daran teilnehmen, eine Entwicklungsumgebung einrichten? Meetings und Setups oder sonstige technische Checks sind Aufgaben, die in jedem Sprint auftreten (können) und womit man immer rechnen darf. Jeder Sprint soll Mehrwert für den Kunden erzeugen. Tut es das nicht, dann ist es kein Sprint. Daher ist es laut Lehrbuch nicht richtig von Sprint 0 zu sprechen, wenn man in diesem rein administrative und planerische Aufgaben übernimmt, bei denen kein Deliverable für dein Kunden entsteht. Das ist dann kein Sprint. Gibt es Aufgaben für das Team: dann ist es ein regulärer Sprint, eben Sprint 1. Unser deliverable, unser Ergebnis, ist beispielsweise die funktionierende Entwicklungsumgebung, ein Teil der Dokumentation und wahrscheinlich erste kleine Tasks, die einen sichtbaren Mehrwert für den Kunden erzeugen. Wer seinen ersten Sprint aber gerne bei null anfangen möchte zu zählen, kann das tun, solange ein Deliverable entsteht. Wir Informatiker sind es ja gewöhnt bei null anzufangen zu zählen 😉 Trotzdem bleiben die Unsicherheiten: wieviel gehört in so einen ersten Sprint? Die Antwort kling fast zu einfach: das was nötig ist und das was möglich ist.

Der erste Sprint

Ohne eine Velocity oder die Erfahrung vorhergehender Sprints und was man sich zutrauen kann, muss man quasi zurück zu den Wurzeln und überlegen: was brauche ich um zu starten und wieviel Zeit kostet mich das? Ein Beispiel: Alle Entwickler setzen beispielsweise einen Tag lang ihre Entwicklungsumgebung auf, werden x Tage eingewiesen in das Programmiermodell und -vorgehen (Know your tools, Server, wie delivern, Definition of Done, Definition of Ready und wie läuft die Code Review ab? Was sind die Programmierrichtlinien und wie sieht die Qualitätssicherung und Test aus?) und je nach Länge des Sprints: welche ersten Aufgaben können zeitlich dann noch absolviert werden? Im ersten Sprint ist es valide nicht zuviel einzuplanen, sondern erstmal tief zu stapeln. Eine Story nachzunominieren und nach Start des Sprints noch nachträglich mit einzufügen ist zwar für „Scrum nach Lehrbuch“-Fans nicht valide, aber im ersten Sprint sicherlich verkraftbar.

Wer beim ersten Schätzen unsicher ist, kann sich bei erfahreneren Entwicklern Hilfe suchen und sehr transparent zu schätzen. Also „laut denken“. Hilfreich kann sein zusammenzutragen, wieviel unterschiedliche Technik dafür angefasst werden muss. Habe ich Änderungen in der Datenbank bzw. der Persistenz allgemein? Oder ist es nur Businesslogik? Muss ich nur Tests schreiben oder ein ganzes Test-Framework aufbauen (schließlich sind wir am Anfang). Falls erfahrene Entwickler nicht da sind oder die Schätzung zu unscharf wirkt, kann sogar erstmal eine ganz andere Schätzmethode mit weniger Kategorien verwendet werden wie T-Shirt-Sizes (Story-Größen S, M, L, XL). Generell gilt aber: was die Schätzgrößen bedeuten (also wie komplex beispielsweise 5 Story Points sind), bestimmt das Team. Dafür gibt es keine allgemeingültige Antwort, weswegen im ersten Sprint auch manchmal einfach das berühmte Bauchgefühl reicht. Bei soviel Unschärfe ist klar: in Sprint 1 kann man daneben liegen. Die Korrektur erfolgt mit der Erfahrung ab dem zweiten Sprint und hilft für die Zukunft.

Tipps für den zweiten Sprint

Die Story und ihre jeweile Schätzung des ersten Sprints sollte als Referenz herangezogen werden. Best Practice ist sich eine Liste sortiert nach Story Points anzulegen, die als Referenz-Storys dienen, sodass in Zukunft alle ein Gefühl dafür bekommen, was beispiels 5 Story Points bedeuten, wie komplex sie sind und wie solche Storys ungefähr aussehen. Lag man daneben und hat länger als erwartet gebraucht, war die Aufgabe also komplexer, dann kann das bei der Erstellung der Referenz berücksichtigt und korrigiert werden.

Zum weiterlesen:
Official Scrum Guide (scrum.org)
Your first agile sprint: A survival guide (TechBeacon)
Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (scrum.org Blog)

Arbeitet ihr in SCRUM-Teams? Wie seid ihr an den ersten Sprint herangegangen? Seid ihr auch der Ansicht, dass „Sprint 0“ Quatsch ist oder seid ihr Fans von dem Gedanken des „hardening sprints“? Und wo seht ihr vielleicht sogar die Probleme von SCRUM allgemein?

5 Antworten

  1. Was sagst du eigentlich zur Facebook-Affäre? Es ist zumindest eine Gelegenheit, das Thema Datenschutz allgemein anzusprechen.

    1. Avatar von Miss Booleana
      Miss Booleana

      Um ehrlich zu sein wundere ich mich, dass erst jetzt soviel darüber gesprochen wird. Ich dachte, dass das schon vor einer halben Ewigkeit ans Tageslicht gesickert wäre, dass Facebook nicht so gut auf Daten aufpasst wie alle gehofft haben. Deswegen finde ich das Tohuwabohu etwas albern… . V.A. weil die Berichterstattung etwas schwach und unspezifisch bleibt. Ich hoffe, dass Facebook bzw. Zuckerberg jetzt mal ordentlich eins vor den Latz geknallt wird, damit die Services ihre Verantwortung begreifen.
      Wenn die Berichte darüber das Bewusstsein der Menschen für Datenschutz nicht schärfen, dann kann man ihnen wohl leider aber auch nicht helfen.

  2. Spannende Einblicke für mich. Bei uns wird auch agil und via SCRUM gearbeitet, wie sehr nach dem Buch kann ich nicht ganz beurteilen. Werde deinen Artikel auf jeden Fall mal mit unseren Developern diskutieren. Danke für die spannende Diskussionsgrundlage 🙂

    1. Avatar von Miss Booleana
      Miss Booleana

      Ahaaaa ihr seid also auch agil? 😀 Cool!
      Ja, also die Regeln streng nach Buch sind sicherlich immer ein guter Leitfaden, aber manchmal muss man es eben auch auf das Projekt anpassen. Abgesehen davon steht da auch immer die Frage im Raum nach wessen Buch man zitiert 😉
      Und bitte gerne, freut mich insbesondere bei den Themen, wenn es mit Interesse angenommen wird 😀

  3. Danke für den Artikel. 🙂 Bei sowas sind andere Meinungen für mich besonders interessant. 🙂
    Ich habe 1-2 Jahre nach Scrum gearbeitet oder nach dem was bei uns damals darunter verstanden wurde. Ich habe mir nie die Mühe gemacht, mich wirklich tiefgreifend mit Scrum zu beschäftigen. Mein Ziel ist es ja irgendwann nochmal ein Buch darüber zu lesen. 😉

    Bzgl. Scrum habe ich gemischte Gefühle. Scrum ist eine Form des Managements und als solches immer ein notwendiges Übel, das auf das allernötigste reduziert werden sollte. Scrum hat viele Meetings und ist daher aus meiner Sicht kein schlanker Prozess. Ich denke, dass ein sehr gutes Team so gut wie kein Management braucht und somit viele der Scrum-Mechanismen nicht benötigt werden. Allerdings ist es auch so, dass Management-Fehler oft sehr teuer sind und daher kann es klug sein einen Sicherheits-Overhead zu haben. Tatsächlich war mein Arbeitsleben für mich als Entwickler am angenehmsten geregelt als ich Mitglied eines Scrum-Teams war. Ich konnte mich auf das Schreiben von Software konzentrieren und durch Gruppenschätzungen und Management war ich relativ gut davor geschützt mehr und mehr Arbeit aufgehalst zu bekommen.
    Bei jedem Software-Projekt an dem ich mitgearbeitet habe, war die Leistungsfähigkeit zwischen den Entwicklern allerdings sehr unterschiedlich.
    Sehr effizienzverbessernd für jedes Projekt ist es zudem die zu implementierenden Komponenten auf die einzelnen Teammitglieder zu verteilen, so dass sich möglichst wenige Leute in den Kontext einer Komponente einarbeiten müssen. Dieses Prinzip läuft natürlich dem Scrum-Prinzip entgegen, dass jeder Entwickler alles machen können muss. In der Konsequenz wurde bei der Schätzung immer schon berücksichtig, welcher Entwickler die Aufgabe machen wird. Trotzdem ist es eine Management-Regel die Entwicklungsleistung belohnt und daher insgesamt sehr vorteilhaft wirkt.

    Aufgrund dieser Art der Schätzung waren bei uns auch immer die Punkte nicht wirklich ein Maß für die erbrachte Arbeitsleistung. Nach meiner Erfahrung liegt der Hauptwert von Scrum darin verlässlicher Planen zu können und Probleme sichtbar zu machen. Daher ist es in meinen Augen auch bedeutungslos, wenn der erste Sprint nicht passt. Wichtig ist, dass der Prozess im Laufe der Zeit verlässliche Vorhersagen und stabile Software hervorbringt. Für die Arbeitsleistung ist das Erreichen von Meilensteinen viel wichtiger und aussagekräftiger.

    Ich denke, dass Scrum besonders in Bereichen gut eingesetzt werden kann bei dem bekanntes Terrain beschritten wird. Je größer der Forschungsanteil des Projekts ist, desto weniger wird Scrum funktionieren.
    Bei den meisten Projekten die ich gemacht habe, wurden zu Beginn des Projekts Meilensteine erstellt. Diese wurden dann in Stories und Tickets zerteilt, geschätzt und priorisiert. Angefangen hat man dann mit den Aufgaben bei denen man sicher war, dass sie mit hoher Sicherheit benötigt werden und sich nur noch wenig ändern werden. Das die Schätzungen anfangs nicht gut gepasst haben, war von geringer Bedeutung.

    Wichtiger als die Durchführung eines Prozesses ist denke ich immer ein effizientes Arbeiten zu ermöglichen. Wenn der Prozess dem zuwiderläuft, dann muss sich entweder der Prozess ändern oder die Umstände.

    Wie strikt nach Prozess wird denn bei Dir im Unternehmen Scrum durchgeführt? Könntet ihr ohne größeren Extra-Aufwand den aktuellen Entwicklungsstand einfach releasen? Bei uns kam da immer noch viel Abhängzeit + Testaufwand hinzu. Sind bei euch die Entwickler tatsächlich auf dem gleichen Leistungslevel?

Schreibe einen Kommentar zu Miss Booleana Antworten abbrechen

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