Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Der Sprint – ein Zeitplan für Macher

Wer beim Sprinten ins Stolpern kommt, wird meist von etwas abgelenkt. Das gilt zumindest in den Sprints, die im Büro stattfinden. Den Sprint in Scrum gibt es aus vielen Gründen: Er dient der Synchronisation, stellt eine Grenze gegen Überlast dar (WIP-Limit) und sorgt für störungsfreies Arbeiten.

Synchronisation

Der Sprint dient der Synchronisation für die Priorisierung und Lieferung. Hierbei besteht die gleiche Kadenz für Priorisierung und Lieferung. Die gleiche Kadenz heißt, es wird zu Anfang des Sprints festgelegt, was in die freien Slots kommt, die im nächsten Sprint frei sind und es wird festgelegt, wann das Scrum-Team die nächsten Ergebnisse liefert. Sobald man in Scrum das Sprinten startet, legt man den Rahmen, die Kadenz automatisch fest. Man legt Synchronisationspunkte fest und die damit verbundenen Transaktionskosten.

Die Transaktionskosten der Koordination minimiert man bei einer regelmäßigen Priorisierung. Es ist klar, wann wer zusammenkommen muss und jeder kennt den Rhythmus.

Transaktionskosten für die Lieferung hängen von mehreren Faktoren ab: Wie aufwendig sind Koordination und Integration, wie hoch ist der Grad der Automatisierung und wie schnell kann, wie schnell muss man Geschäftswert für den Endnutzer bereitstellen.

Die Automatisierung hat heutzutage noch viel mit Professionalisierung der Software-Entwicklung zu tun. Unternehmen, bei denen bisher wenig automatisiert ist, haben meist hohe Transaktionskosten. Solche Kosten sind oftmals auf manuelle Qualitätssicherung und hohe Koordinationskosten für Integration und Releases zurückzuführen. Meist führen gerade solche langen Lieferzeiten jedoch zu einem Teufelskreis: Da die Transaktionskosten hoch sind, meiden Unternehmen kurze Zyklen. Lange Zyklen beinhalten immer ein höheres Risiko an Fehlern. Kombiniert man nun lange Zyklen mit der Angst vor Fehlern in der Praxis, stellen sich nochmals höhere Transaktionskosten durch ausgeprägte Testphasen ein. Da man zum einen mehr testet, zum anderen fehlerhafte Funktionen länger in der Praxis hat, verlängert sich der Zeitraum des fehlenden Geschäftswerts. Derweil sitzt der Kunde noch mit Praxisfehlern auf der langen Bank. Wartet der Kunde auf der Bank, dann führt das häufig zu Mitnahmeeffekten durch Wettbewerber.

WIP-Limit

„Limit work in progress“ – so richtig wichtig, leider oft so richtig wenig verstanden. Überlast in Unternehmen führt nicht nur dazu, dass alles lange dauert und keiner mehr Lust hat. Es führt vor allem dazu, dass fast nichts mehr geht. Menschen betankt man nicht wie Maschinen, die dann bis auf eine gewisse Grundwartung mit einer geringen Fehlerquote arbeiten. Wann geht fast nichts mehr? Wenn alles aufeinander wartet und gemeinsame Synchronisationspunkte zu selten oder unkoordiniert stattfinden. Dann ergeben sich Abhängigkeiten, die nur noch so ungefähr aus der Vogelperspektive erfasst werden können. Wenn die Vogelperspektive hier helfen würde, dann wäre das schön, meiner Erfahrung nach zählen allerdings vor allem die Details.

Im Sprint limitiert das Entwicklungsteam die eigene Auslastung. Das Entwicklungsteam zieht sich die eigene Auslastung, manchmal auch die eigene Überlastung. Dadurch entsteht für den Zeitraum des Sprints ein limitiertes System, ähnlich einem Währungssystem, es entsteht eine Knappheit. Mit dieser Knappheit kann man arbeiten. Indem ich ausweise, dass im nächsten Zeitraum nicht mehr geht, zeige ich deutlich auf, was geliefert wird. Meine Lieferung rückt in den Fokus.

Des Weiteren kann bei Blockaden nicht auf etwas weniger Wichtiges ausgewichen werden, sondern es muss genau an dem gearbeitet werden, was wichtig ist. Trifft man auf Blockaden, so sind sie zu lösen. Ist das System nicht limitiert, so wäre die natürliche Reaktion, sich mit etwas anderem zu beschäftigten. Das führt in vielen Organisationen dazu, dass Blockaden selten oder nie gelöst werden und man sich mit ihnen abfindet. In einem knappen System geht das nicht. Es muss etwas getan werden, der Fokus auf den Wert bleibt erhalten und man reduziert deutlich die Parallelität und damit den Auslöser für das heutzutage vielmals gescheiterte Multiprojektmanagement.

Wichtig ist, die so erzeugte Knappheit im System aufrechtzuerhalten: Wird das System ständig gestört z. B. durch Incidents, dann werden schnell die Vorteile eines solchen Systems obsolet (stabile Transaktionskosten für Priorisierung, Lieferung, konsequentes Auflösen von Hindernissen, etc.).

Störungsfreies Arbeiten

Wer kennt es nicht: Manager hetzen stundenweise von Termin zu Termin. Stimmen sich ab, tauschen sich aus und tragen all die neuen Erkenntnisse überall dorthin, wo sie aktuell noch gar nicht sein müssten – ins Entwicklungsteam. Auf der anderen Seite sitzen im Entwicklungsteam Menschen, die Zeit benötigen, sich in ihre Arbeit zu vertiefen.

Ich beschreibe Software-Entwicklung meist so: Du sitzt da vor deinem PC und über dir schwebt ein stetig wachsendes Konstrukt von Beziehungen, Abläufen und Strukturen. Es ist wie ein kleines Wolkenschloss, dass mit jeder Zeile Code, die du liest, wächst. Immer mehr Gedankenblasen steigen vor dir auf bis dann… ja dann klingelt das Telefon, es kommt jemand herein, spricht dich an und du siehst weit am Horizont die letzte Gedankenblase zerplatzen und dein Wolkenschloss ist vom Winde verweht. Um ein solches Konstrukt zu erzeugen benötigt es Zeit, es ist aufwendig und anstrengend.

Wenn wir die Zeitpläne eines Managers mit dem eines Entwicklungsteams vergleichen, dann sehen wir kleine Zeiteinheiten über den Tag verteilt beim Manager und große Zeiteinheiten beim Entwickler. Jetzt würde manch einer sagen, dass es jede Menge Entwickler gibt, die auch einen zerstückelten Zeitplan mit sich herumtragen. Hier stelle ich die Frage: „Wie viel wird von demjenigen dann noch entwickelt und wie viel managt er schon?“

Paul Graham nannte 2009 die unterschiedlichen Zeitpläne „Maker’s schedule, manager’s schedule„. Er bringt dort zum Ausdruck, dass diese beiden Zeitpläne konträr zueinander stehen und so wenig wie möglich aufeinandertreffen sollten, damit die Produktivität der Macher (Entwickler) möglichst wenig beeinträchtigt wird. Im Umkehrschluss schlägt er vor, dass beide Zeitpläne voneinander entkoppelt werden sollten. Spannenderweise findet dieses Prinzip sich im Agilen im Allgemeinen und bei Scrum im Speziellen wieder. In Scrum entkoppeln die Sprints die beiden unterschiedlichen Zeitpläne voneinander. Im Sprint sorgt der ScrumMaster für störungsfreies Arbeiten und gibt seinem Entwicklungsteam den Freiraum und die Zeit, möglichst autonom und produktiv zu arbeiten. Zum anderen entkoppeln die Rollen Product Owner und ScrumMaster die Zeitpläne. Das geschieht dadurch, dass beide für das Scrum-Team zwischen den Zeitplänen vermitteln, indem sie selbst als Puffer und Filter agieren. Ein weiterer Vorteil ist, dass sich das Entwicklungsteam gegenüber Störungen ausgehend von den beiden Rollen auch durchsetzen kann, da weder ScrumMaster noch Product Owner disziplinarische Vorgesetzte des Teams sind.

Zieleinlauf

Der Sprint isoliert die hektische Welt des Managements vom Zeitplan eines Entwicklers. Entwickler können sich so fokussieren und gedankenintensive Arbeit leichter abschließen. Der Sprint fördert stabile Bedingungen, die zu niedrigeren und stabilen Transaktionskosten führen und ermöglicht Professionalisierung aufgrund von kleinen Lieferungen. Als knappes System führt der Sprint dazu, dass Blockaden gelöst werden müssen und zukünftig nicht auch anderen Arbeiten im Weg stehen. „Wenn Sie mich fragen: Ich mag ihn, den Sprint!“

  • Rolf

    Hi Sven

    Warum dann nicht gleich die Entkopplung mittels Kanban-Elementen weiter treiben? Transaktionskosten der kompletten Sprintplanung sparen? Keine commitments mehr auf Sprint Backlogs, sondern nur noch auf Durchsatzraten?

    Gruß,
    Rolf

    • Sven Winkler

      Hi Rolf,

      durchaus eine Möglichkeit, keine Frage. Wenn ich im Team arbeite möchte ich allerdings nicht auf ein gutes Sprint Planning verzichten. Muss halt gut sein und Wert liefern ;-) welchen Wert ich meine kannst Du hier nachlesen:

      SP1 http://borisgloger.com/2013/01/18/willkommen-zum-candle-light-dinner-sprint-planning-1/

      SP2 http://borisgloger.com/2013/01/21/bastelecke-sprint-planning-2/

      Ob man Liefer- und Planungs-/Priorisierungskadenz trennt oder in einem Rutsch (Sprint) macht, liegt beim Anwendungsfall.

      Seinen Durchsatz bzw. seine Geschwindigkeit sollte man in jedem Fall kennen.
      Mit welchen Elementen möchtest Du denn weiter entkoppeln – angenommen ich möchte mein SP1+2 behalten?

      Grüßle, Sven

      • Rolf

        Hi Sven,

        na, wasch mich aber mach mir den Pelz nicht nass! ;-)

        Bei SP1 und SP2 sehe ich in dieser Form eher schwarz, das würde ja dem Sinn des Ganzen eher zuwiderlaufen. Am ehesten dürfte noch, in Anlehnung an das Backlog Grooming,eine Art „Domain Grooming“ mit kurzem zeitlichen Horizont das SP1 ablösen und das SP2 einer Pull-Herunterbrech-Session (besserer Begriff händeringend gesucht…).

        Warum würdest Du auch bei extrem kurzen Kadenzen für die Priorisierung noch auf SP1 und SP nicht verzichten wollen? Was müsste denn da geplant bzw. im *festen* Takt heruntergebrochen werden? Wenn sich alles einspielt, gäbe es ja nicht mal mehr eine Priorisierungskadenz – sogar die User Storys könnten per Pull ad hoc vom PO geholt werden.

        Grüßle,
        Rolf

      • Sven Winkler

        Hi Rolf,

        vielleicht zum gemeinsamen Verständnis. Ein SP1 und SP2 ist für mich nicht da, damit ich ein Commitment schreibe und Aufgaben festklopfe, sondern um Anforderungen festzuhalten und letzte Entscheidungen einzuholen, sowie um im SP2 einen Grundstein für Design mit Schnittstellen für die gemeinsame Zusammenarbeit in den nächsten Wochen zu legen, welches dann im Sprint verfeinert wird. Also die Suche nach dem: Wo fangen wir wie an und bei welchen Punkten müssen wir unsere Ideen testen (Verhalten und Struktur) und über was müssen alle Bescheid wissen.

        „Warum würdest Du auch bei extrem kurzen Kadenzen..“ ehm, da hab ich wohl verpasst, was du im Kopf hattest ;-) biste jetzt „On demand“ mit einer minimalen Eingangs-Queue und heftigen Limits? Hülfe, hol mich ab ;-)

        Grüßle, Sven :-)

      • Rolf

        Ja, so heftig, in etwa. Allerdings habe ich das Nachdenken darüber bisher nur selten einem Kunden nahe gelegt – dass für jemand ein 2-Wochen-Sprint noch zu lang fürs effektive Steuern ist, kommt doch eher selten vor. Kann aber dann durchaus hilfreich sein, nur so etwas wie „3 freie slots“ statt eines Sprint Backlogs zu haben und „on demand“ beim PO Nachschub an User Storys zu ziehen.

        Die Lieferkadenz ist dann aber auch eher „ständig“, allenfalls eine „Review-Kadenz“ von 2-3 Wochen ergibt dann noch Sinn, wenn man Stakeholder zusammentrommeln muss, die nicht so oft wie der PO Zeit haben.

        Deine Anmerkung zu SP1 und SP2 finde ich sehr interessant. Für mich dient das SP1 schon dem Abstecken des Sprint Backlogs, auch wenn dafür letzte Klärungen nötig sind (die finde ich aber besser im Backlog Grooming aufgehoben). Wenn ich keine 2-wöchige Planungskadenz mehr habe und User Storys sehr zeitnah vor der Umsetzung gezogen werden, müsste ich so ein Meeting eher durch eine fachlich geprägte Session ersetzen, in der sich das Scrum Team in die Lage versetzt, diese Storys zu verstehen und umsetzen zu können.

        Das SP2 wurde ja im Scrum Guide mittlerweile an den Framework-Gedanken angepasst, man spricht nur noch vom „Plan“, der für die Umsetzung zumindest der ersten „Items“ aus dem Product Backlog erstellt werden sollte. Damit das Entwicklungsteam „erklären“ (bemerkenswertes Wort hier!)könne, wie es denn die Items umzusetzen gedenke. Auch hier lässt sich das nicht mehr so umsetzen, wenn die Planungskadenz auf praktisch einen Tag schrumpft. Deshalb wäre dann ein SP2 durch ein ad-hoc-Meeting zum Herunterbrechen der gerade gezogenen Story zu ersetzen.

        Allerdings hat das Ganze dann nur noch zu Teilen mit Scrum zu tun und sollte auch nicht mehr so genannt werden. Ehrlich gesagt habe ich aber nur wenig Kunden, die solche „G-Forces“ (Kent Beck) schon zu spüren bekommen. Meistens sind es eher POs, die sich ein Sprint Backlog aus „Flexibilitätsgründen“ auf Kosten des Teams und des Gesamtdurchsatzes „sparen“ möchten.