.st0{fill:#FFFFFF;}

Scrum Einführung

Was ist Scrum? Schwieriger kann die Framework Frage nicht sein

 Juli 27, 2022

von  Sebastian Schneider

Wer schnell eine Antwort auf die Frage "was ist Scrum" sucht, der findet meistens Antworten, die damit beginnen, es gebe eine Scrum Methode. Neben dieser und weiterer Antworten, die das Verständnis von Scrum nicht unbedingt fördern, ist das Internet leider voll. Ich möchte dazu gerne andere Perspektiven teilen und gebe dir den umfassenden Einblick in meine Sichtweise. Zudem ist es mir aber auch wichtig, das "richtige" Bild zu teilen, da ich finde, viel mehr Menschen sollten das agile Framework verstehen und das Beste draus machen. Also, starten wir direkt rein!


Inhaltsverzeichnis

Überarbeitung

Der Artikel wird gerade überarbeitet und enthält schon die meisten Änderungen, einige Tests, Abbildungen und weiterführenden Informationen folgen bald.

Der schnelle Überblick: Scrum einfach erklärt

Wenn du nur wenig Zeit hast, lies diesen Absatz. Wenn du mehr Zeit hast, beginne hier und arbeite dich dann weiter durch.

Was ist Scrum? Scrum wird als agiles Framework bezeichnet. Es erlaubt dir mit wenig Regeln, teamorientiert komplexe Produkte zu entwickeln. Dabei kann Scrum in den unterschiedlichsten Branchen und Situationen angewendet werden. Dieses Rahmenwerk gibt dir einen groben Rahmen an die Hand, in dem entwickelt wird. Du übernimmst die Ableitung deines konkreten Prozesses auf Basis dieser "Vorlage". Du kannst diese Vorlage auch als nicht fertige Struktur ansehen oder als Skelett, an welches du noch "Fleisch" bringen musst. Und genau dieses "Fleisch" ist dann deine Interpretation und von da ab, dein Prozess.

Es gibt eine Rolle den Product Owner (stell dir vor, dass ist jemand der die Anforderungen an die Arbeit verantwortet und Entscheidungen treffen darf), der für eine sortierte Liste an Arbeit (die nennen wir einfach Product Backlog, also "Produktrückstand", nämlich da ist alles drin, was eben noch nicht im Produkt enthalten ist) verantwortlich ist. Der Product Owner arbeitet gemeinsam mit Entwicklern (das sind die, die wissen wie es konkret umzusetzen ist) zusammen im Team, die seine Anforderungen in konkrete Ergebnisse umsetzen. Diese Umsetzung erfolgt immer in festen Sprints (ein Sprint ist nichts anderes als ein fester, wiederkehrender Zeitabschnitt, z.B. 2 Wochen). Am Ende dieses Sprints steht ein Ergebnis und dieses nennen wir Inkrement. Da ist alles eingeflossen, was innerhalb des Sprints fertig geworden ist. Und das Inkrement ist die Summe aller fertiggestellter Arbeit, die getestet ist und die auch so gezeigt werden kann, dass sich Product Owner und Kunden davon direkt überzeugen können. Das tun sie in der Regel im Sprint Review, so nennen wir diese Zusammenkunft.

Der Scrum Ablauf - Mein Ablaufdiagramm

Wenn du nicht viel lesen willst (was ich dir trotzdem empfehlen würde) dann kannst du hier mit meinem Image Map immer zu einer beliebigen Stelle abspringen, wo ich einzelne Aspekte genauer beschreibe. Auf dem Bild klickst du einfach auf die Dinge, die dich interessieren und findest dahinter dann weitere Artikel, die dir tiefere Einblicke geben.

Etwas Theorie vorab: Scrum Definition

Wenn wir von der Scrum Theorie sprechen, verstehen wir meistens den Scrum Guide darunter. Dieses Dokument wurde von den Scrum Gründern Jeff Sutherland und Ken Schwaber erstellt und mittlerweile von der Community gepflegt. Es lohnt sich das Dokument einmal ganz zu lesen. Auch wenn du danach nie Scrum komplett begriffen haben wirst, ist es der erste und richtige Schritt sich mit dem agilen Framework zu befassen.

Scrum Theorie

Transparenz, Inspektion und Adaption sind wichtig Grundpfeiler auf denen Scrum steht. Wir wollen durch die Transparenz immer verstehen, wie unser aktueller Stand der Arbeit ist. Nur dann können wir diese Arbeit auch inspizieren (ohne Verschwendung) und geeignete Adaptionen darauf vornehmen. Scrum stützt sich auf Empirie. Das ist nichts anderes als gemachte Erfahrungen, welche wir durch ein adaptives Vorgehen erreichen können. Dazu brauchen wir immer die genannten drei Pfeiler.

Scrum Definition

Die Scrum Methode ist ein Framework und eben keine Methode 🙂 Du kannst auch sagen, Scrum ist ein Rahmenwerk oder deine Vorlage für gute Prozesse (und nein, Scrum selbst ist auch kein Prozess). Konkret heißt es für die Definition auf deutsch: Scrum ist ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Werte zu schaffen.

Wo liegt der Ursprung?

Ursprünge von Scrum finden sich bereits 1986 in dem Paper The New New Product Development Game der beiden Japaner Takeuchi und Nonaka, in dem Grundzüge von dem betrachtet wurden, was heute inhärent in Scrum enthalten ist. Niemand hat sich zu dem Zeitpunkt bereits gefragt: was ist Scrum? Das überraschende aus heutiger Sicht ist mit Sicherheit, dass es in diesem Paper nicht um Softwareentwicklung ging! Die erste Software, die mit Scrum erstellt wurde, erblickte 1993 das Licht der Welt. 1995 formalisierte Jeff Sutherland die Erkenntnisse auf der OOPSLA'95. 2001 entstand das agile Manifest, das praktisch die Grundlage von allen agilen Methoden & Rahmenwerken bildet. In diesem Manifest befinden sich vier Wertepaare und zwölf Prinzipien, die in der eigenen Organisation interpretiert und verstanden wollen werden. Ein Jahr später erschien das erste Buch zu Scrum. Im Jahre 2013 erschien der erste Scrum Guide, der bis heute gepflegt wird. Während früher der Fokus teilweise stark auf der Software lag, ist heute längst bewiesen, das Scrum in vielen Bereichen - auch Hardware oder dem Marketing - funktioniert und Vorteile bringt.

Scrum Werte

Scrum basiert auf fünf Werten. Diese Werte lauten Mut, Commitment, Fokus, Respekt und Offenheit. Die fünf Scrum Werte gehören natürlich dazu, wenn es um die Frage geht, was Scrum ist! Denn diese Scrum Werte sind praktisch gesehen die Basis auf der Scrum aufbaut. Diese Werte sind mittlerweile im Scrum Guide vorhanden, auch wenn diese schon seid dem Buch von Jeff Sutherland und Mike Beedle 2002 existierten. Die agilen Prinzipien mit den Werten gehören zur Grundausstattung.

  • Mut
  • Commitment
  • Fokus
  • Respekt
  • Offenheit

Wann ist Scrum sinnvoll?

Im klassischen Projektmanagement (sofern man das so sagen kann), arbeiten wir mit einem vorbestimmten Prozess. Wir analysieren, was zu tun ist, stellen einen Plan auf und arbeiten diesen ab. In Scrum nutzen wir eine empirische Prozesskontrolle, was bedeutet, wir konzentrieren uns auf die Erfahrungen und arbeiten uns Stück für Stück nach vorne. Und immer, wenn genau das gewollt und sinnvoll ist, lohnt sich auch Scrum. Um das herauszufinden, kannst du dir auch gerne mein Video zum Stacey Landscape Diagram ansehen, eine Möglichkeit herauszufinden, ob das für dich sinnvoll sein kann oder nicht.

Wann ist Scrum sinnvoll?

Die Uni Leipzig hat dazu ein schönes Statement geschrieben, was ich mir hier einmal herauspicken möchte:

Das Wort „Methode“ stammt aus dem Altgriechischen und bedeutet so viel wie „nachgehen“ oder „verfolgen“. Allgemeinsprachlich ist eine Methode ein planmäßiges Verfahren, um ein bestimmtes Ziel zu erreichen.

Uni Leipzig

Ich mag die Sichtweise der beschriebenen Methode auf planmäßiges Vorgehen nicht. Denn das kann ich im einfachen oder komplexen Bereich anwenden, nicht aber im komplexen. Das kann man gerne als Wortspielerei bezeichnen, meistens ist die Umsetzung bei Teams oder Menschen, die mit den Begriffen nicht richtig umgehen auch signifikant anders, als bei der anderen Gruppe der Menschen 🙂

Während früher der Scrum Fokus auf der Software lag, ist heute längst bewiesen, das Scrum in vielen Bereichen - auch Hardware oder dem Marketing - funktioniert und Vorteile bringt.

Die komplette Einführung zu Scrum

Im Folgenden gehen wir nun auf zwei größere Abschnitte genauer ein. Starten werden wir mit einer kompletten Übersicht, was alles komplett in Scrum enthalten ist, schauen was der Guide hergibt und tauchen dazu auch etwas mehr in jedes Element ab. Damit hast du dann alles, was für dich kommend von der Theorie wichtig und sinnvoll ist an einer Stelle.

In dem zweiten längeren Abschnitt gehen wir einmal auf komplett alles ein, was du für dein Verständnis vom Ablauf brauchst. Wir schauen welche Elemente von Scrum existieren, was innerhalb eines Sprints passiert, welche Kompetenz bei den Teammitgliedern existieren muss - kurz welche Rahmenbedingungen für dich wichtig sind. Dazu hatte ich dir oben schon mein Bild von Scrum gezeigt. Um den großen Zusammenhang zu sehen, ist das Bild immer ein guter Helfer. Da die folgenden Elemente von Scrum immer alle ineinander spielen ist ein einfacher Start und Ende schwer. Orientiere dich deshalb immer an dem Bild, dann begreifst du auch die nachfolgenden drei Rollen, die drei Artefakte in Scrum und fünf Events.

Somit bist du zum einen sehr gut gerüstet, um inhaltlich alles zu verstehen und auf der anderen Seite auch, wie ein kompletter Ablauf aussehen kann.

Die Artefakte in Scrum

Was ist Scrum - Artefakte in Scrum

Artefakt: Product Backlog

Das Product Backlog enthält die Anforderungen an das Produkt. Der Product Owner sorgt dafür, dass dieses Product Backlog immer transparent und für alle sichtbar ist. Die Einträge im Product Backlog stellen die einzigen Einträge einer langen Liste an Anforderungen für das Produkt dar. Ebenso repräsentieren sie nur den aktuellen Stand des Wissen, es ist keine fixierte und abgeschlossene Liste. Alle neuen Anforderungen werden ebenso im Backlog festgehalten. Zudem ist es relativ priorisiert.

Für die Aktualität dieses Artefaktes sorgt das Product Backlog Refinement. Es verbessert kontinuierlich den Inhalt des Backlogs. Der Product Owner und Entwicklungsteam (besser: Entwickler!) übernehmen diese Aufgabe.

Artefakt: Sprint Backlog

Das Sprint Backlog enthält das, was sich das Team für den aktuellen Sprint vorgenommen hat. Es stellt damit eine Teilmenge des Product Backlogs (oft auch "selected Backlog") dar und führt zu einem Inkrement. Nicht alle Aufgaben im Sprint Backlog müssen zwingend abgeschlossen sein, damit die Erreichung des Sprint-Ziels sichergestellt ist. Es befinden sich sehr konkrete Aufgaben in einem Sprint Backlog. Ebenso muss ein Sprint Backlog nicht komplett durchgeplant sein. Auch wenn viele Entwickler das tun (was nicht schlimm sein muss) wollen wir auch bewusst die Empirie akzeptieren und wenn wir einen Plan für die ersten Schritte haben und dann weitere Anpassungen vornehmen, um das Sprint Ziel zu erreichen, ist auch das ein legitimer Weg.

Artefakt: Inkrement

Das Ergebnis des Sprints resultiert in einem Inkrement. Das ist die gesamte fertige Arbeit, die als eine Art "Paket" zur Verfügung steht. Das Inkrement muss dabei nutzbar sein. Am Ende des Sprints muss es spätestens vorliegen. Es zeigt den Stakeholdern und dem Product Owner den Fortschritt des zu entwickelnden Produktes, das live erlebt werden kann.

Events und Meetings in Scrum (incl. Sprint)

Event: Sprint

Der Sprint stellt den zeitlichen Rahmen und den Herzschlag von Scrum dar, in dem alles andere abläuft. Dieser hat eine feste Länge und immer einen definierten Start- und Endpunkt. Grundsätzlich wird ein Sprint in der Länge nicht verändert. Zwar kann sich auch hier durch Inspektion und Adaption ergeben, dass eine gewählte Sprintlänge sich nicht mehr als passend erweist, wenn die Sprintlänge allerdings von Sprint zu Sprint sich ändert, existiert ein Problem. Iterativ bedeutet sich immer wiederholend.

Event: Sprint Planning

In der Sprint Planung wird festgelegt, was in dem kommenden Sprint umgesetzt werden soll. Dabei wird das Planning in drei Teile aufgeteilt: Im ersten geht geht es darum zu klären, warum der Sprint wichtig ist. Im Zweiten geht es darum, was gemacht werden soll und im dritten dann wie es gemacht werden soll. Früher hatte man hier nur zwischen Teil 1 und Teil 2 unterschieden. Diese Teile müssen keine verschiedenen Meetings sein. In der Tat ist es sehr oft so, dass nur eine Sprint Planung durchgeführt wird, in der alle Teile behandelt werden.

Event: Daily Scrum

Das Daily Scrum dient den Entwicklern als ein kurzes operatives Snychronisierungsmeeting in dem jedes Teammitglied die anderen Teammitglieder (oft mit drei kurzen Fragen, aber nicht zwingend nötig) auf den aktuellen Stand bringt. Dazu besprechen die Entwickler meist, was seit dem letzten Daily Scrum passiert ist. Der Scrum Master sammelt hier erste mögliche Hindernisse (Impediments) ein, die als Störung von außen auftauchen könn

Event: Sprint Review

Was ist Scrum? Sprint Review

Im Sprint Review wird auf das Erreichte im Sprint zurückgeblickt und alles was funktioniert und fertig wurde vorgestellt. Wichtig dabei ist die Definition of Done. Sie regelt, wann ein Eintrag aus dem Backlog als fertig gilt. Wichtig ist es dabei, dass du hier wirklich etwas vorstellen lässt und Menschen (Stakeholder, Kunden, ...) damit in Interaktion gehen können. Deshalb sprechen wir auch so oft von erlebbar oder läuffähig. Wenn du damit deine Schwierigkeiten hast, kannst du dich auch immer noch mal mit der Frage nähern: wie muss es gestaltet sein, damit wir am meisten über das Produkt lernen können und gutes Feedback bekommen?

Event: Sprint Retrospektive

Die Retrospektive schaut auf die gemachten Erfahrungen, also die Empirie. Dabei fokussieren wir uns auf den letzten Sprint. Im Fokus liegt die Zusammenarbeit, Prozesse, Tools und menschliche Interaktionen. Das Produkt betrachten wir fokussiert im Sprint Review, in der Retrospektive schauen wir auf den Prozess. Dafür gibt es mittlerweile eine Vielzahl an Techniken, bestimmte Vorgehen und jeder hat so seine Lieblinge. Ich persönlich habe mich auch mal an einer Retrospektive versucht (siehe SeHMaR), die kannst du gerne mal ausprobieren, wenn du magst. Prüfe hier bitte immer unbedingt, was deinen Teilnehmer wirklich gut tut und welche Methoden für sie auch wirklich funktionieren.

Entwicklungsbegleitende Tätigkeit: Backlog Refinement

Im Backlog Refinement werden die Anforderungen aus dem Backlog verfeinert. Dabei werden diese geschnitten, geschätzt und mit Akzeptanzkriterien versehen. Am Ende des Tages müssen sowohl der Product Owner als auch die Entwickler den Inhalt verstanden haben. Es muss also klar sein, was in diesem Product Backlog Items enthalten ist und was nicht. Wichtig ist dabei, es geht um das Verständnis und wichtige Rahmenbedingungen. Ersteres findet durch Diskussion statt und beschreibt zunächst das "was". Wir schreiben hier keine fertigen Spezifikationen, sondern versuchen möglichst einfach aber treffen das Verständnis zu beschreiben. Je nach Branche und Domäne können solche Einträge genauere Details benötigen. Wenn du so etwas brauchst und willst, dann ist die Folge oft, dass du hier etwas mehr Zeit spendieren musst. Dabei kannst du dich auch immer fragen, ob die investierte Zeit das Ziel auch wirklich trifft oder ob du beginnst in Refinements doch wieder fertige Spezifikationen zu schreiben. Diese müssen nicht schlecht sein, verstehe mich nicht falsch. Nur wenn du in der Lage bist, Dokumente als fertige, umfassende Spezifikationen zu schreiben und diese dann auch noch genauso umgesetzt werden können, ist die Frage, ob dir Scrum hier dann wirklich gut helfen kann. Oder anders ausgedrückt, bist du wirklich in einem komplexen Bereich unterwegs?

Die drei Rollen

Alle drei Scrum Rollen sind Teil des Scrum Teams. Das ganze Scrum Team nimmt sich dem zu entwickelnden Produkt an und das Team fokussiert sich darauf. Innerhalb des Teams gibt es keine Hierarchien. Der Product Owner und Scrum Master arbeiten eng zusammen wie auch der Scrum Master und Entwicklungsteam. Die Bezeichnung "innerhalb des Entwicklungsteams" wurde früher einmal verwendet, um das "Scrum Team" (also alle) vom "Entwicklungsteam" (also nur die Entwickler) zu unterscheiden. Das versucht man heute zu vermeiden, um Klarheit zu schaffen und das Team arbeitet eigenständig.

Rolle: Entwickler

Die Entwickler sind interdisziplinär, cross-funtkional oder nach T-shaped, M-shaped und ähnlichen Begriffen aufgestellt. Doch was heißt das genau? Intedisziplinarität und cross-funktionalität bedeutet grob gesprochen: du musst alle Fähigkeiten in deinem Team haben, die du benötigst, um dein Produkt zu entwickeln. "Jeder muss alles können" ist auch so ein Relikt aus alten Zeiten. Ja, es ist schön, wenn du so etwas tatsächlich hast und wir versuchen auch immer durch Events das Wissen auf mehrere Schultern auszulagern, aber so etwas erreichen wir in der Realität dann oft doch nicht!

Rolle: Scrum Master

Die Prozessverantwortung wird an den Scrum Master übergeben. Das bedeutet nicht, dass sonst keine Rolle am Prozess mitarbeiten darf, es bedeutet aber, dass eine gewisse Gewaltenteilung in Scrum anstrebst. Ich vergleiche den Scrum Master gerne als Hüter des Prozesses. Er ist derjenige, der sicherstellt, dass alle Scrum so benutzen können, wie es vorgesehen ist. Er kann die Events moderieren, beim Verständnis in der Organisation helfen und Teams coachen. Als Scrum Master durchlebst du auch unterschiedliche Reifegrade und solltest eine gute Haltung entwicklen. Wir sprechen hier auch öfters vom Servant Leader.

Rolle: Product Owner

Der Product Owner bringt die fachlichen Anforderungen ("was") mit in das Team. Er ist derjenige der wirtschaftlich für das Produkt verantwortlich ist. Er stimmt sich mit den Stakeholdern ab und kennt das Produkt. Er stellt sicher, dass das Product Backlog für alle zugänglich ist. Zudem entscheidet er, ob die Einträge aus dem Backlog am Ende eines Sprints fertiggestellt wurden. Auch wenn das meistens nicht das typische Daumen hoch oder Daumen runter ist. Bei einem guten und eingespielten Team bezieht sich das oft mehr auf das Feedback selbst als eine formale Abnahme.

Agile Praktiken: sinnvoll aber nicht immer Teil von Scrum

Auch immer wieder gerne falsch wiedergegeben: die folgenden Dinge sind entweder gar nicht oder nur sehr spärlich im Scrum Guide beschrieben. Für ersteren Fall bedeutet das, sie gehören auch nicht dazu. Für den zweiten Fall findest du hier nun ein paar weitere wertvolle Definitionen und Hinweise, die dir weiterhelfen können.

User Stories

Die User Stories sind ein bestimmtes Format, deine Product Backlog Einträge zu beschreiben. Sie sind keine Pflicht und stammen aus dem Extreme Programming. Sie passen aber gut in den Kontext. Du kannst sie auch als agile Praktik ansehen, denn sie passen recht gut in Scrum. Hier kannst du auch gut erkennen, dass Scrum in solchen Dingen dir freie Hand lässt, denn du wirst nicht (wie oft bei methodischen Vorgehen) auf etwas bestimmtes festgelegt.

Planning Poker

Mit Planning Poker tauchst du in den Bereich des agilen Schätzen hinein. Es ist eine agile Praktik, die dir hilft die Product Backlog Einträge zu schätzen. Das machst du in der Regel mit der sogenannte Fibonacci-Folge und einem Set an Karten. Eine Schätzung brauchst du meistens in irgendeiner Art und Weise. Es gibt auch die Gegenbewegung von #noestimates.

ScrumBan

Kanban ist prozessagnostisch, nutzt also vorhandene Prozesse. So kann ein Scrum Team auch den eigenen Prozess nutzen und diesen mit Kanban verbessern. Was hier oft passiert ist, dass Teams sich einzelne Elemente aus Kanban heraus picken und so zum Beispiel das Sprint Backlog mit expliziten WIP Limits oder ähnlichem versuchen zu verbessern. Weitere Details findest du dazu meinem Artikel über ScrumBan.

Die Vision

Die Vision wird immer gerne als Nordstern verstanden: Sie leuchtet dir den Weg, ist knackig und kurz beschrieben ohne zu genau zu werden. Somit hast du immer genug Flexibilität in deiner Art und Weise dein Ziel wirklich zu finden. In komplexen Umgebungen ersetzen sie auch das klare Ziel, auf das mit einem Plan hingearbeitet wird.

Continuous Integration

Wenn du Software entwickelst gehört es sowieso dazu, in anderen Domänen solltest du es für dich auch interpretieren. Worum geht's hier? Du hast schon gelesen, dass Scrum in kurzen Sprints immer wieder Inkremente erzeugt. Jetzt wollen wir kontinuierlich und laufend erkennen, ob sich vorgenommene Änderungen auch wie gewünscht verhalten. Dazu integrieren wir laufend und stellen schnell fest, ob etwas funktioniert oder nicht. Wir wollen also unsere Lernschleife deutlich verkürzen.

Definition of Ready

Über die Definition of Ready wird oft gestritten. Für die einen ist sie viel zu formal und behindert die Zusammenarbeit, für die anderen ist sie nützlich. Zum Rahmenwerk gehört sie auf jeden Fall nicht. Beschreiben tut die DoR dennoch folgendes: Ab wann sind die Einträge im Product Backlog so reif, dass diese in die Sprint Planung gelangen dürfen. Gerade größere Unternehmen beginnen hier gerne lange Checkliste zu erstellen und verstecken sich hinter Text und Regeln, statt in die wertvolle Kommunikation zu gehen. Das Problem liegt dann natürlich meist wo ganz anders, aber das führt zu weit an dieser Stelle.

Impediment List

Manche Teams führen eine eigene Liste mit den Hindernissen, die auftreten. Diese werden dann oft in extra Listen gepflegt. Darüber kann man unterschiedlicher Meinung sein und ich persönlich schaue mir gerne so etwas in der Realität an. Wird es vom Team wirklich genutzt? Findet es Verwendung in Retrospektiven? Kennt jeder dieses Inhalt der Listen? Oft stauen sich solche Listen an, werden von wenigen gepflegt und von noch weniger benutzt.

Story Map

Mit einem Story Map kannst du zum Beispiel deine User Stories (aber auch andere Dinge wie Features) übersichtlich darstellen und eine weitere Dimension in deinem Backlog darstellen. Ein Story Map kann sehr gut auch für Stakeholder benutzt werden und die Geschichte des Produktes zu erzählen. Es ist ein klasse Werkzeug um ein großes Bild von deinem Produkt oder deinem Vorhaben zu bekommen.

Burndown Charts

Eine Möglichkeit die noch zu verbleibende Arbeit in einem Sprint darzustellen. Auch verwendbar als Burnup Charts oder auch als Release Charts. Sie zeigen einfach und fokussiert, wie es um die verbleibende Arbeit steht und die Entwickler erstellen diese Charts selbst und eigenständig, am besten regelmäßig und täglich am Ende des Arbeitstages. Und das gemeinsam zu tun, kann auch wiederum das "wir" Gefühl stärken.

Team Canvas

Eine agile Praktik, die dir helfen kann Regeln festzulegen und für alle klar uns zugänglich darzustellen. So kann so ein Canvas Termine, Gruppennormen, Namen, Rituale und Vereinbarungen enthalten. Es sorgt vor allem für Klarheit und kann in der internen sowie auch externen Kommunikation genutzt werden.

Magic Prioritization

Einige Techniken für das Priorisieren funktionieren schneller, andere langsamer. Die einen sind genauer, die anderen weniger. Oft ist eine Priorisierung nie richtig, wenn sie aber ausreichend genau und ausreichend richtig ist, hilft das den Unternehmen in der Regel schon sehr. Wenn du das dann noch oft durchführst, dann sind Abweichungen oder Fehler in der Priorisierung nebensächlich, denn sie werden dann schnell ausgebügelt.

Weitere Ideen

Alles, was dem agilen und leichtgewichten Gedanken entgegenkommt und sich als hilfreich erwiesen hat, kann in diesen Bereich fallen.

Ein kompletter Durchlauf durch Scrum

Lass uns nun noch einmal schauen, wie es aussehen könnte, wenn du Scrum aufsetzt. Ich mache hier bewusst ein mögliches Beispiel, es gibt viele andere Möglichkeiten. Ich denke an dem Ablauf kannst du am besten verstehen, was gerade bei dir passieren könnte und welche Schritte nötig sind. Ich lasse hier auch einige meiner Erfahrungen natürlich einfließen und nur weil ich damit gute Erfahrungen gemacht habe, musst du es nicht unbedingt auch tun.

Es geht los: Rahmenbedingungen setzen

Ist Scrum akzeptiert? Funktioniert Scrum? Diese und viele weitere Fragen werden dich erreichen, wenn du und ihr damit starten wollt. Deswegen ist es wichtig zum einen zu verstehen, was du mit diesem Rahmenwerk alles anstellen kannst, zum anderen (und nicht weniger wichtig) musst du dein warum kennen. Es fällt Menschen immer leichter, wenn sie Gründe kennen, wenn sie wissen wo es hingehen soll und warum. Auch wenn dieser Punkt in der Praxis wohl der interessanteste ist, wollen wir diesen für unser Beispiel nicht überstrapazieren. So stehst du hier natürlich vor einem Change und nicht jeder in deiner Organisation wird dich gleich mit offenen Armen empfangen und schreien, juhu!

Wo ist das Ziel? Vision und Produkt Ziel erarbeiten

Meistens startet alles mit einer richtig guten Idee. Wir sprechen hier von einer Vision. Diese Vision sollte einfach, knapp gehalten sein und bei allen deinen Teilnehmern das richtige Verständnis generieren. Nicht zwingend, aber oft gibt es eine Diskussion zwischen (zukünftigen) Stakeholdern und der Person, die später die Rolle Product Owner übernehmen wird. Diese ersten Ideen entwickeln unterscheiden sich oft noch nicht von anderen Vorgehen. Auch wenn es durchaus einige agile Praktiken und selbst weitere Methoden, Strukturen und Rahmen gibt, hier aktiver zu werden. So kannst du hier Design Thinking nennen und auch Lean Start-Up. Das Produkt Ziel wurde auch im letzten Update vom Scrum Guide noch mal deutlich herausgestellt.

Unausweichlich: Wer entwickelt die gute Idee?

Auch wenn die gute Idee steht, brauchst du natürlich Menschen, die diese Idee auch zum Leben erwecken. Hier kommen die Entwickler ins Spiel und natürlich das ganze Scrum Team. Wir brauchen Menschen, die gemeinsam alle Fähigkeiten mitbringen, die wir für das Produkt brauchen. Das ist ein ganz entscheidender Erfolgsfaktor für Scrum. Denn wir gehen davon aus, dass die Teams autark alle Aufgaben, die erledigt werden müssen, auch selbstständig lösen können.

Teamfindung ist leider oft sehr einfach in Unternehmen gehalten. Sprich, es ist keine Findung, sondern Menschen werden durch Führungskräfte irgendwie zusammengestellt. Das muss nicht immer schief gehen, bedenke aber immer, wer sind die Menschen, die am besten Wissen, wie das Produkt zu entwickeln ist?

Oft sinnvoll: der erste Teamworkshop

Das Team muss sich kennen und das Produkt zusammen entwickeln, Also ist es natürlich auch höchste Zeit, dass sich alle Menschen Zeit nehmen, sich und das Produkt auch kennenzulernen. Ich lege jetzt hier nicht den Fokus auf das Teambuilding sondern mehr auf das Produkt. Der Product Owner stellt am besten noch mit Kundenvertreter die Vision vor. Oft gibt es schon so etwas wie ein Produkt Ziel. Wenn nicht ist es auch hier an der Zeit, dieses gemeinsam zu entwickeln. Sind beide Dinge klar, dann hilft oft ein erstes, großes Refinement in dem alle gemeinsam den Rahmen abstecken. Hier eignet es sich aus meiner Sicht ungemein mit einem Story Map oder Impact Map zu arbeiten. Wann ist Arbeit als fertig anzusehen? Entwickelt gemeinsam eure Definition of Done.

Wichtig: Sprint aufsetzen

Es gibt keinen Sprint 0 und mit zu viel Planung vorab erreichst du keine Empirie. Also kommt schnell ins Tun und das klappt meistens wenn schnell klar ist, wie der Sprint aussieht. Dazu unterstützt der Scrum Master und vermittelt, um eine gute Sprintlänge zu ermitteln. Sie darf laut Scrum Guide nicht länger als ein Monat sein. In der Praxis sehe ich oft zwei oder drei Wochen. Die Länge hängt auch davon maßgeblich ab, welches Produkt du entwickelst und auch in welcher Domäne du arbeitest.

Jetzt Disziplin wahren!

Aufsetzen, erste Erfolge sind immer gut und auch wichtig. Doch wenn du einmal begonnen hast ist es wichtig, dass aus dem "Sprint" kein Wettrennen und auspowern folgt, sondern eine gleichmäßige Geschwindigkeit, mit der das Scrum Team arbeiten kann. Wenn du startest ist es hilfreich sich erstmal an den ganzen Events zu orientieren und den "Hof sauber" zu halten. Während ihr dort schon einiges an Erfahrungen machen könnt, dürft ihr natürlich nicht vergessen gut und richtig zu reflektieren. Denn der nächste Sprint steht schon bald bevor! Die Anwender eures Produktes werden es euch hoch ansehen, wenn ihr kontinuierlich, erlebbar liefert.

KVP: immer dran bleiben, perfekt bist du nie!

Auch wenn das alles klappt, bist du nicht einfach fertig. Es gibt immer bessere Wege zu entwickeln. Es gibt bessere Wege sich gemeinsam zu Koordinieren. Es gibt auch bessere Wege für das Produkt, für Techniken und ähnliches. Arbeitet gemeinsam und mit dem Scrum Master zusammen an guten und sich verbessernden Prozessen!

Weitere Informationen

Was Scrum nicht ist

  • Eine Methode zum Austauschen. Es hat oft den Anschein, dass Menschen und Unternehmen Scrum als Plug & Play für das Projektmanagement, jetzt also agiles Projektmanagment ansehen. Das funktioniert nicht. Scrum anzuwenden bedeutet sich mit Veränderungen im Unternehmen zu beschäftigen. Es geht nicht darum eine Änderung einer Methode vorzunehmen und alles funktioniert so wie bisher auch. Scrum ist mal nicht ebenso gemacht. Natürlich lässt sich ein Buch zu Scrum am Wochenende durchlesen, aber die korrekte, effektive und effiziente Anwendung dauert Jahre.
  • Ein Werkzeug, was überall funktioniert. Scrum funktioniert überall dort gut, wo Sie komplexe Produkte entwickeln wollen oder müssen. Wenn Sie zum Beispiel das Gegenteil (einfache oder komplizierte Produkte, vgl Stacey Diagram) entwickeln, können Sie natürlich auch Scrum machen, werden aber nicht die Vorteile erzielen, wie wenn Sie komplexe Produkte entwickeln. Ebenso ist Scrum sehr auf das Team und die Transparenz ausgelegt und ständige Verbesserung. Haben Sie diese Grundlagen nicht, wird Scrum nicht wie angedacht funktionieren.
  • Planung und Dokumentation wird nicht mehr benötigt. Ein Klassiker, der sich zum Glück schon weit wieder verflüchtigt hat, trotzdem aber noch vorkommt und das vor allem indirekt in vielen Fragen mitschwingt. Scrum ist ein sehr disziplinierter Ansatz und hat eine sehr genaue Planung und Scrum selbst sagt über die Dokumentation erst einmal gar nichts aus. Der Wert aus dem agilen Manifest "Working Software over comprehensive Documentation" hat scheinbar zu dieser irren Annahme geführt. Er wird gerne so interpretiert, dass nur Software ohne Dokumentation zu erstellen ist

Kostenloser Scrum Kurs

Ich habe meinen kostenlosen Scrum Kurs überarbeitet. Wenn du möchtest, komm doch gerne mit dazu. Ich freue mich auf dich!

Test für dein Scrum machen

Ich habe dir einen kleinen Test vorbereitet. Wenn du Lust hast, mache ihn doch mal und prüfe deinen Fortschritt in Scrum! (kommt umgehend hier noch hin)

Scrum Master Class Membership

Wenn du dein Scrum Team nun in deiner Organisation aufsetzen möchtest und das gleich von Beginn an mit einer professionellen Unterstützung, die dich keine krassen Beratungstagessätze kosten lässt, dann schaue dir mein Scrum Master Class Membership an. Dort arbeiten wir gemeinsam bis dein Team auch wirklich steht und funktioniert.

Weitere Fragen und Antworten

Fragen sind gut, um sich mit einem Thema zu befassen. Deswegen findest du hier noch eine Anzahl an Fragen mit meinen Antworten in der Kurzform. Schau mal, ob da auch etwas wertvolles für dich enthalten ist.

Was ist agiles arbeiten?

Ein Vorgehen zu wählen, welches sich auf Basis des agilen Manifestes stützt: iterativ, inkrementell und leichtgewichtig.

Wie arbeitet man in Sprints?

Sprints sind nichts anderes als Zeitabschnitte. Diese haben einen Start und ein Ende. Sie beginnen mit der Sprint Planung und enden mit der Sprint Retrospektive. Der Scrum Master hilft dir gerne beim Koordinieren und Aushandeln mit allen Beteiligten.

Welche Rollen gibt es in Scrum?

Den Product Owner, den Scrum Master und die Entwickler.

Wie startet man ein Scrum Projekt?

Ich mag hier wieder beide Begriffe nicht gerne zusammen. Oben im Text haben ich dir eine grobe Outline skizziert. Versuche dich an dieser entlang zu hangeln. Grundsätzlich haben Projekte Eigenschaften, die wir nicht im agilen Kontext nicht bevorzugen.

Was passiert in einem Sprint?

Die Umsetzung von Product Backlog Items in ein Inkrement.

Wann ist der Sprint beendet?

Wenn die Timebox dafür abgelaufen ist.

Was spricht gegen Scrum?

Stelle dir die Frage, welche Vorteile für dich entstehen können und schaue, ob das für dich erfüllbar ist. Gegen Scrum spricht oft etwas, wie wenn du deinen Kunden gar nicht kennst, du in keinem komplexen Bereich tätig bist oder auch keine iterative und inkrementelle Entwicklung benötigst.

Welche Vorteile bietet Scrum?

Zum Beispiel schnelles Lernen und richtig guter Kundennutzen 🙂

Kann man Teile von Scrum weglassen?

Nein. Alles was im Scrum Guide enthalten ist, ist das Minimum, um Scrum so auszuführen, damit es noch funktioniert. Du kannst innerhalb bestimmten Bereichen aber immer anpassen. Stelle es dir als deine Vorlage vor, die du konkret mit Leben füllen musst.

Ist agil gleich Scrum?

Nein. Agil bzw. Agilität bezeichnet einen breiten Strauß an Techniken, Methoden Frameworks und ähnliches Vorgehen. Du kannst agil sein ohne Scrum zu nutzen und du kannst es auch nutzen ohne agil zu sein 😉

Ist Scrum eine agile Methode?

Ich hoffe du hast mittlerweile verstanden, warum ich den Begriff agile Methode nicht mag. Wenn du dir die Perspektiven anderer anhörst, dann wirst du diese Frage als bejahend vorfinden.

Ist Scrum eine Abkürzung?

Nein. Scrum ist eine Analogie zum Rugby und bezeichnet eine Formation höchster Konzentration.

Wann wird Scrum angewendet?

Wenn du in einem komplexen Bereich tätig bist, das Handlungsmuster probe-sense-respond benötigst.

Ist Scrum Lean?

Nicht primär auf Lean optimiert, aber jede gute Implementierung ist in der Regel auch in gewissen Bereichen Lean.

Was ist der Unterschied zwischen Scrum und Kanban?

Da gibt es einige. Kanban hat mehr den Fokus auf dem Fluss, Durchlaufzeiten und Vorhersagbarkeit. Scrum fokussiert mehr auf den Kundenwert und stellt den Rest hinten an.

Fazit

Die Suche nach "Scrum Methode einfach erklärt" führt wie die Suche nach "was ist Scrum" zu sehr qualitativ unterschiedlichen Ergebnissen. "Scrum ist eine agile Methode" hört man oft, ich finde den Ausdruck nicht passend, ebenso wie "Methoden wie Scrum". Auch wenn Menschen es agiles Projektmanagement nennen, neige ich dazu mehr nachzufragen, was gemeint ist. Begriffe haben sich schnell etabliert, ob sagen Menschen etwas anderes, meinen aber das gleiche. Oft sagen sie das gleiche, meinen aber wiederum etwas anderes. Es sind wie so oft die Perspektiven. Ich habe mir abgewöhnt Perspektiven zu beurteilen, sondern gehe stattdessen lieber in die Diskussion und erforsche, was an der andere meint und wie seine Sichtweise ist.

In der Praxis ist Scrum häufig nicht so einfach oder leicht, wie es dich hier vielleicht liest. Ist Scrum erst etabliert, dann hast du einen guten Startpunkt, von dem du aus kommend, deine Produkte und Prozesse oft mit höherer Motivation erledigen kannst, als zuvor.

Scrum definiert wenig. Scrum schreibt wenig vor. Dadurch lässt es viel Spielraum. Ken Schwaber und Jeff Sutherland wussten was sie damals taten und bis heute finde ich dieses Arbeitsergebnis wirklich klasse. Viele Dank!

Sebastian Schneider

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hole dir auch den kostenlosen Online Scrum Kurs

>