Was ist Scrum?

EINLEITUNG

Scrum ist ein agiles Vorgehensmodell, das sich insbesondere für die Produktentwicklung eignet. Der Schwerpunkt liegt darin, Entwicklungs-Teams so zu befähigen, dass sie in der Lage sind, dynamisch und flexibel auf neue Situationen zu reagieren. Beispiele hierfür sind: Neue Kundenanforderungen im laufenden Projekt, die Berücksichtigung technischer Innovationen/Weiterentwicklungen, aber auch eine möglicherweise veränderte Marktsituation (zum Beispiel ein Wettbewerber, der mit einem ähnlichen Produkt den Markt adressiert).

Durch kleine Teams, die in Absprache mit Stakeholdern Produktziele formulieren, jedoch in deren Umsetzung selbstbestimmt bleiben, werden fortlaufend kleine Product Increments released. Das ermöglicht zeitnahes Feedback und ein empirisches, inkrementelles und iteratives Vorgehen.

,,Scrum ist leichtgewichtig, einfach zu verstehen, schwierig zu meistern.‘‘ (Schwaber & Sutherland, 2016, S.3)

Ausgangspunkt für Scrum bietet der Scrum Guide von Ken Schwaber und Jeff Sutherland.
In diesem wird die agile Methode explizit als ein Rahmenwerk und nicht als starre Vorlage definiert, welches stetig an die individuellen Bedürfnisse und (Produkt) Kontexte durch das Scrum Team angepasst werden kann.

Scrum beschreibt in seiner Theorie 1 Scrum Team, 5 Events und 3 Artefakte.

Das von uns designte Plakat basiert primär auf der neuesten Version (2020) des Scrum Guides und bietet dir einen fundierten Überblick zum Framework. Zusätzlich haben wir verschiedene „Good Practices“ formuliert, die aus unserer direkten Kundenerfahrung resultieren und wertvolle Tipps geben.

Die Vorteile von Scrum

NUTZE Was am besten ist

Scrum integriert Produktionsprozess und empirischen Lernprozess, wobei mehrere Ebenen von Feedback-Zyklen innerhalb des Projektteams und mit der Projektumgebung verbunden werden. Die Identifikation und Priorisierung von Verbesserungsmöglichkeiten sind Prozessbestandteil. Etwaige Innovationspotenziale können so sicher erkannt und direkt umgesetzt werden.

FLEXIBILITÄT

Scrum ermöglicht es, zeitnah neue Technologien einbinden und auf Veränderungen im Projekt weitgehend verzögerungsfrei reagieren zu können. Dies führt zu gesteigerter Flexibilität, da neue Anforderungen kontinuierlich eingebracht werden können. Die Auswirkung der Umsetzung von Change Requests wird unmittelbar transparent. Scrum verbindet damit eine positive Veränderungskultur und verbesserte Serviceorientierung.

INNOVATIONSFÄHIG­KEIT

Scrum integriert Produktionsprozess und empirischen Lernprozess, wobei mehrere Ebenen von Feedback-Zyklen innerhalb des Projektteams und mit der Projektumgebung verbunden werden. Die Identifikation und Priorisierung von Verbesserungsmöglichkeiten sind Prozessbestandteil. Etwaige Innovationspotenziale können so sicher erkannt und direkt umgesetzt werden.

LEISTUNGSQUA­LITÄT

Scrum-Coaching bietet situationsgerechte Lösungen, die sich in vergleichbaren Projekten bewährt haben. Entwicklungspraktiken wie z.B. Continuous Integration, Test Driven Development oder Pair Programming stellen eine hohe Produktqualität und eine stete gegenseitige Kontrolle der Entwickler sicher. Scrum bietet so den Rahmen für eine kontinuierliche und organische Verbesserung der Leistungsqualität. 

PROAKTIVE KOMMUNIKATION

Informationen zum Projektfortschritt stehen grundsätzlich jedem Projektbeteiligten offen. Nach jedem Sprint werden Abschlusspräsentationen und Planungsmeetings mit allen Projektbeteiligten durchgeführt. Damit wird zu jedem Zeitpunkt die höchstmögliche Transparenz über den Projektfortschritt erreicht. Scrum bietet so entscheidende Rahmenbedingungen für eine hohe Selbstregulierung des Projektteams.

PLANUNG

Speziell bei großen Softwareprojekten besteht die Herausforderung in der Einpassung von agilen Vorgehensweisen in bestehende klassische Umgebungen. Dies gelingt bei der Integration in ein V-Modell XT oder vergleichbares PM-Framework durch Tailoring und vor allem durch klare Definitionen zu Systemgrenzen und –schnittstellen. Das Resultat ist eine hohe Tranzparenz und Klarheit im Projekt.

MOTIVATION UND ERFOLG

Die Durchführung von Projekten in agilen Vorgehensweisen erhöht die Zufriedenheit von Kunden und Projektmitarbeitern. Die Transparenz, die explizite Festlegung von erreichbaren Zwischenzielen und die Übergabe von Verantwortung an die Projektmitarbeiter führen zu erhöhter Identifikation mit dem Projekt. Die teamzentrierte Arbeit und der direkte Kontakt zu Kunden werden zu wesentlichen Motivationsfaktoren.

DAS SCRUM PLAKAT

Der Scrum-Überblick für deine Wand – oder deinen Bildschirm.
Alles Wichtige an einem Ort.

Mit dem Scrum Plakat bieten wir dir eine übersichtliche Visualisierung des gesamten Prozesses mit detaillierten Beschreibungen aller wichtigen Elemente.

Unser Add-on: Good Practices für den operativen Einsatz von Scrum.
Direkte Kundenerfahrung von uns für dich.

TEAM, Events, Artefakte & Werte

Wie FUNKTIONIERT SCRUM?

Scrum Team

Developer

Umsetzungsexperten

Product Owner

Value Maximizer

Scrum Master

True Leader

Events

Bis zu 120 Min pro Sprint Woche

Sprint planning

Findet am Anfang
eines jeden Sprints Statt

Bis zu 4 Wochen

Sprint

MAximal 4 Wochen

Bis zu 15 Min pro Event

Daily Scrum

Tägliches Event
mit festen Rahmenbedingungen

Bis zu 60 Min pro Sprint Woche

Sprint Review

Vorletztes Event
des Sprints

Bis zu 45 Min pro Sprint Woche

Sprint Retrospective

Schließt den sprint ab

ARTEFAKTE

Product Backlog

,,Das, was wir umsetzen‘‘

Sprint Backlog

,,Wie wir es umsetzen‘‘

Increment

,,Konkreter Schritt in Richtung des Product Goals‘‘

WERTE

Commitment

Das Scrum Team

C

Mut

Das Scrum Team

M

FoKus

Das Scrum Team

F

Offenheit

Das Scrum Team

O

Respekt

Das Scrum Team

R

GOOD PRACTICES

WIE LÄSST SICH SCRUM OPTIMIEREN?

„Fail fast.“ – Autor unbekannt

Wir empfehlen automatisierte Tests, da sie es ermöglichen, Fehler im Code und der Funktionalität schnell zu erkennen und auszubessern. Getestet werden nicht nur Neuentwicklungen, sondern auch Auswirkungen auf das gesamte Produkt. Dabei ist der Kosten-/Nutzen-Faktor zu betrachten: Da eine Testautomatisierung aufwändig sein kann, konzentriert man sich auf die wichtigen Funktionen, die entscheidend für die Nutzung des Produktes sind (risikobasiert).
Automatisierte Tests ersetzen manuelle Tests nicht vollständig. Wir empfehlen, automatisierte Tests möglichst früh in der Entwicklung zu berücksichtigen und Akzeptanzkriterien als Grundlage zu nutzen

„You build it you run it.” – Werner Vogels

Wir leben DevOps, da sich das Team ganzheitlich um die Anwendung kümmert und komplexe Software-Übergabeprozesse nicht mehr notwendig sind. So liegt die Verantwortung bei den Experten, die sie entwickelt haben.
Von der Entwicklung, über die Integration der Komponenten, zum Go-Live und weiter zur Überwachung der laufenden Anwendung – alles liegt in der Verantwortung des Teams.

„The most powerful tool we have as developers is automation.” – Scott Hanselman

Wir nutzen Continuous Integration, um sicherzustellen, dass unser Code nach jedem Commit noch lauffähig ist und unsere Qualitätskriterien (z.B. Testabdeckung) weiterhin erfüllt sind. Eine automatisierte Pipeline hilft uns dabei.
Continuous Delivery ist der automatisierte Schritt des Deployments der Anwendung in die Produktion, sobald alle notwendigen Qualitätskriterien erfüllt sind.

,,Ein Backlog ist nie komplett und nie vollständig‘‘ – Tim Buchner

Wir empfehlen regelmäßige Refinement Events, wenn das Team es noch nicht gewohnt ist, sich ausreichend mit der Weiterentwicklung des Backlogs zu beschäftigen. Es stellt ein gemeinsames Zeitfenster dar, in dem sich das Scrum Team mit dem Backlog auseinandersetzen kann. Dieses kann um Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.
Ein solches Event ist auch dann sinnvoll, wenn man Stakeholder außerhalb des Teams in das Refinement mit einbeziehen möchte.

,,Denken heißt vergleichen‘‘ – Walther Rathenau

Wir nutzen Referenz Product Backlog Einträge, um für die Schätzung des Aufwands neuer Einträge eine gesunde Basis zu schaffen. Dadurch fällt es Teams deutlich leichter, neue Anforderungen in Relation zu diesen einzuschätzen.
Wichtig ist es immer wieder zu überprüfen, ob bisherige Referenz Product Backlog Einträge noch als solche sinnvoll sind; andere technologische Schwerpunkte oder ein tieferes Verständnis des Produktes und der verwendeten Technologien können Komplexitäten verändern.

„Keep it simple and get rid of the big cards.” – Autor unbekannt

Wir benutzen Planning Poker für die Schätzung unserer Product Backlog Einträge, um Meinungen und Expertisen einzelner Teammitglieder besser zur Geltung zu bringen.
Während eines Refinement Events werden Diskussionen durch sehr unterschiedliche Schätzungen angestoßen und voneinander unabhängige Gedankengänge im Team zugelassen.

,,Wer zu schnell geht, kommt oft nicht mit‘‘ – Anke Maggauer-Kirsche

Wir empfehlen, dass Teams ihre Velocity messen, um in zukünftigen Sprints besser abschätzen zu können, wieviel Komplexität sie in einem Sprint schaffen können.
Velocity beschreibt die Menge der erledigten Arbeit, die ein Team in einem Sprint geschafft hat (kann z.B. mit Story Points gemessen werden). Hier werden nur die Product Backlog Einträge herangezogen, die gemäß der „Definition of Done“ geschlossen wurden.
Auf keinen Fall darf Velocity zur Bewertung oder zum Vergleich von Teams herangezogen werden.
Schwankungen sind hierbei völlig normal. Nach einer bestimmten Zeit sollte sich ein gewisses Gefühl im Team entwickeln.

„Hör nicht auf, wenn es wehtut. Hör auf, wenn du fertig bist.” – Autor unbekannt

Wir nutzen eine „Definition of Ready”, um sicherzustellen, dass auch in den Product Backlog Einträgen alle Aspekte beachtet wurden, die zur Umsetzung notwendig sind. Vergleichbar mit einer „Definition of Done” werden Kriterien festgelegt, die erfüllt sein müssen, bevor das Product Backlog Eintrag in den Sprint Backlog übernommen wird. Ein paar Beispiele, die enthalten sein können:

  • Geschätzt
  • Klein genug, um in einem Sprint erledigt zu werden
  • Möglichst keine Abhängigkeiten zu anderen Backlog-Einträgen (technisch wie fachlich)
  • Von allen Teammitgliedern verstanden
  • Sicherheitsrelevante Aspekte beachtet

„You’ll never walk alone.” – Richard Rodgers

Wir empfehlen beim Daily Scrum die Methode „Walk the Board“, wenn mehr als eine Story gleichzeitig aktiv bearbeitet wird. Jeder Sprint Backlog Eintrag wird durchgegangen und der aktuelle Stand sowie eventuell aufgetretene Impediments besprochen.
Es ist sinnvoll, sich auf eine festgelegte Reihenfolge zu einigen. Zum Beispiel nach Priorisierung im Sprint Backlog oder am weitesten fortgeschritten in der Umsetzung (von rechts nach links). Dadurch wird ein häufiger Kontextwechsel vermieden.

,,Erfolg ist eine Treppe, keine Tür‘‘ – Dottie Walters

Wir empfehlen, den Fortschritt des Teams während eines Sprints mit einem Burndown Chart zu visualisieren. Dabei wird jeden Tag die geleistete Arbeit in Relation mit dem Zeitverlauf des Sprints gesetzt, beginnend mit der voraussichtlichen Gesamtarbeitsmenge. Dies bietet einen schnellen Überblick auf die noch zu leistende Arbeit und hilft zu erkennen, ob Impediments das Team blockieren und wie gut die Arbeitspakete aufgeteilt sind.
Der Graph wird jeden Tag aktualisiert und ähnelt im Idealfall einer Rutsche oder einer Treppe (bei Jira).

Das Ganze ist mehr als die Summe seiner Teile.“  – Aristoteles.

Für uns ist Mob Programming zu einem wichtigen Bestandteil des Entwickleralltags geworden. Wir finden es klasse, wenn mehrere Entwickler gemeinsam an einem Problem arbeiten können.
Nicht nur die Qualität des Codes wird (bereits während seiner Erstellung) gesichert, auch Wissensinseln innerhalb des Teams werden vermieden.

„Es hört doch jeder nur, was er versteht.“ – J.W. Goethe

Wir nutzen Behaviour Driven Development in Verbindung mit einer „ubiquitous language“, also einer allgegenwärtigen, für alle verständlichen und auf der Fachdomäne basierenden Sprache, um Verständnisprobleme zwischen Fachexperten, Developern und anderen Stakeholdern zu minimieren und ein gemeinsames Verständnis von der Anwendung zu entwickeln.
Da die Tests während oder besser noch vor der Entwicklung des Codes erstellt werden und das Verhalten der Anwendung in einer semi-formalen Syntax (z.B. gherkin) beschreiben, ist allen Beteiligten von Anfang an klar, wie die Anwendung nach der Implementierung eines neuen Features funktionieren soll.

DAS SCRUM-PLAKAT

ZUM DOWNLOAD
Din A1

Das vollständige Plakat mit allen drei Schalen. Von dieser Version gibt es natürlich auch wieder gedruckte Exemplare im Format DIN A1.

Din A2

Schale 1+2 zusammen. Diese Version enthält bereits eine vollständige Beschreibung von Scrum. Wir haben sie auf eine Größe von DIN A2 (entspricht 4 DIN A4-Seiten) entworfen. Allerdings kann man auch bei einem Ausdruck auf A3 alles noch recht gut erkennen. 

Din A4

Nur Schale 1 mit dem Scrum-Prozess alleine. Sie passt bequem auf eine DIN A4-Seite bzw. eine einzelne (Powerpoint-) Folie. Sie eignet sich z.B. für Vorträge zum Thema Scrum.

DAS SCRUM-PLAKAT

Kostenlos ALS POSTER
Din A1
kostenlos bestellen

Das vollständige Plakat mit allen drei Schalen. Von dieser Version gibt es natürlich auch wieder gedruckte Exemplare im Format DIN A1. Diese Plakate kannst du gedruckt auf DIN A1 ganz einfach und formlos kostenlos bei uns bestellen.

Nachdem unser > SCRUM-Plakat so großen Anklang gefunden hat, haben wir uns entschieden auch ein Plakat zu KANBAN in IT-Prozessen zu machen. Das Plakat steht als Download zur Verfügung oder kann bei uns als Poster kostenlos > bestellt werden.

Das KANBAN-Plakat zum Download >>> DIN A1

Über Anregungen freuen wir uns jederzeit!