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!"

Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps
Team
bgloger-redakteur
April 8, 2013

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4