Scrum. Entwickle Produkte, die Kunden lieben.

Mit Scrum entwickelst du Produkte, die Kunden lieben. Heute musst du mehr denn je einem sehr volatilen Markt trotzen können. Mit dem agilen Framework Scrum hast du die Chance, die Zukunft aktiv zu gestalten und auf Änderungen zu reagieren.

Sebastian Schneider Scrum Augsburg

Inhaltsverzeichnis

Was du hier findest

Auf meinen Seiten findest du feinst selektiert die wichtigsten Informationen, um mit dem agilen Framework Scrum Produkte zu erstellen, die deine Kunden lieben werden. Die folgenden Blöcke geben dir einen Überblick, danach findest du alle Details gleich auf dieser Seite.

Scrum Guide

Hier erfährst du alles, was du über die Grundlagen und die Theorie wissen musst.

Scrum Einführung

Du möchtest Scrum einführen? Dann schau dich am besten einmal in der Einführung um.

Scrum Skalierung

Scrum mit mehr als einem Team? Dann ist dieser Startpunkt für dich der richtige.

Scrum Toolbox

Alle möglichen Werkzeuge, die du in deiner Toolbox haben solltest, um erfolgreich Produkte zu entwickeln.

Scrum Coaching

Was genau ist Scrum Coaching und brauchst du das überhaupt? Alles Details über die Ausprägungen findest du hier.

Scrum Training

Scrum Training in moderner Art und Weise? Lerne wie du Scrum Wissen und Reflexion neu erleben kannst - nur hier!

Testimonials

Herr Schneider hat uns über einen längeren Zeitraum bei einer agilen Transformation unterstützt. Sein Wissen hat uns stark bereichert und wir haben stets seine Kompetenz geschätzt. Wir freuen uns auch in Zukunft wieder mit ihm zusammen arbeiten zu dürfen. Herzlichen Dank, Christoph Wagner (Translated by Google) Mr. Schneider supported us with an agile transformation over a longer period of time. His knowledge has greatly enriched us and we have always valued his competence. We look forward to working with him again in the future. Thank you very much, Christoph WagnerChristophSeptember 8, 2020
Ich schätze Herrn Schneider vor allem für seine Kreativität und schnelle Lösungsfindung. Sehr professionell, kundenorientiert und auf den Punkt. Das Coaching mit Herrn Schneider ebenso wie die hoch professionellen Scrum Kurse haben mich beruflich und persönlich sehr stark weitergebracht. Klare Empfehlung! Vielen Dank dafür! (Translated by Google) I particularly appreciate Mr. Schneider for his creativity and quick solution finding. Very professional, customer-oriented and to the point. The coaching with Mr. Schneider as well as the highly professional Scrum courses have brought me a lot forward professionally and personally. Clear recommendation! Thanks a lot for this!Christina B.June 26, 2020
Sehr kompetente Kollegen - ich schätze die undogmatische Herangehensweise und den Methodenmix (Translated by Google) Very competent colleagues - I appreciate the undogmatic approach and the method mixBirgit MallowFebruary 23, 2019
Sehr sympathisches Consulting zu den Themen Scrum, Lean und Agile, wie in meinem Fall. Kann ich nur weiterempfehlen.... (Translated by Google) Very nice consulting on Scrum, Lean and Agile, as in my case. I can only recommend....MarcO MathewsDecember 12, 2018
Die Einführung zum agilen Management sowie die Trainings zu Scrum waren äußerst informativ und exzellent aufgearbeitet. Der Inhalt wurde effektiv und nachhaltig vermittelt. (Translated by Google) The introduction to agile management as well as the trainings to Scrum were extremely informative and excellent. The content was communicated effectively and sustainably.Nadine ErnstNovember 21, 2018
Hervorragende Beratung, kann man uneingeschränkt weiterempfehlen. (Translated by Google) Excellent advice, you can unreservedly recommend.Jah TafariNovember 14, 2018

Was genau ist Scrum?

Ein Rahmenwerk, mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.


Jeff Sutherland

Ein Framework

Scrum ist ein einfaches - aber nicht leicht umzusetzendes - agiles Framework. Mit diesem agilen Framework kannst du physikalische Produkte, Software, Service, Prozesse und ähnliches entwickeln. Scrum hat drei sehr spannende Eigenschaften, die ich dir hier vorstellen möchte:

Leichtgewichtig

Iterativ

Inkrementell

Leichtgewichtig

Das Schöne an dem agilen Framework ist die Leichtgewichtigkeit. Das Framework besteht nur aus wenigen Seiten und enthält alles, was du brauchst, um deine wertvollen Produkte zu entwickeln.

Es besteht nicht aus vielen Seiten von Dokumentation, die du brauchst, bevor du überhaupt anfangen kannst.

Hinweis: Scrum setzt auf hohe Selbstorganisation in Teams, hat Anforderungen an die Organisation und kann nicht mal "ebenso eingeführt" werden. Alle Details findest du in der Scrum Einführung.

Iterativ

In Scrum sprechen wir von Sprints, die maximal einen Monat lang sind und sich dann wiederholen. Nach einem Sprint folgt immer der nächste. Das sind unsere Iterationen. Wir durchlaufen diese, solange wir auch Produkte entwickeln.

Hinweis: In Scrum sind die Iterationen - genannt Sprints - maximal ein Monat lang. Darunter können andere Längen verwendet werden und passen sich meist dem Umfeld an, in dem entwickelt wird.

Inkrementell

Inkrementelle Entwicklung bedeutet, dass wir ein Produkt erstellen und das immer Stück für Stück. Von Iteration zu Iteration erstellen wir jedesmal ein Inkrement und dieses wächst.

Hinweis: Ein Inkrement ist häufig nicht so leicht zu interpretieren. Es sollte immer so gestaltet sein, dass der Kunde etwas erleben und das Stakeholder Feedback maximiert werden kann.

Die Scrum Werte

Die Scrum Werte sind integraler Bestandteil von Scrum und gehören in jeder Implementierung berücksichtigt. Auf ihnen baut das agile Framework Scrum auf.

Fokus

Eine Konzentration auf die wichtigen Dinge ist essentiell und hilft.

Commitment

Das Beste versuchen, Zusagen einhalten und für Dinge einstehen, die man vertritt.

Mut

Neue Wege gehen, Entscheidungen treffen und visionär sein!

Respekt

Menschen zu respektieren und Ansichten zu teilen bietet Chancen zum Lernen.

Offenheit

Ideen, Ansichten und Techniken ändern sich, wir wollen diesen offen gegenüber sein.

Wann kann Scrum verwendet werden?

Scrum kannst du prinzipiell immer verwenden, es spielt seine Vorteile tatsächlich erst dann richtig aus, wenn du komplexe Rahmenbedingungen bei deiner Produktentwicklung vorfindest.

Welche Rahmenbedingungen gibt es?

Die folgenden Rahmenbedingungen stammen aus dem Stacey Landscape Diagram und dem Cynefin Framework. Beide Denkmodelle eignen sich, um eine erste Bestimmung der Rahmenbedingungen abzuleiten.

Einfach

Sense - Categorize - Respond

Wenn wir einfache Rahmenbedingungen vorliegen haben, dann ist das Leben recht einfach. Wir können eindeutige Wenn-Dann-Beziehung herstellen. Zudem finden wir für so ziemlich alles eine Best Practice.

Die Anforderungen und die Lösungstechnologie sind klar

Kompliziert

Sense - Analyze - Respond

Sind die Rahmenbedingungen nicht mehr ganz zu leicht zu verstehen, dann rücken wir vor in den komplizierten Bereich. Auch hier finden wir noch Good Practices, als einen Satz von Praktiken, die wir nutzen können.

Die Anforderungen und die Lösungstechnologie sind Bestimmbar

Komplex

Probe - Sense - Respond

Wenn wir uns im komplexen Bereich befinden, dann haben wir keine vorher klare Ursache-Wirkungsbeziehung und nutzen emergente Praktiken, um uns in diesem Bereich zu bewegen,

Die Anforderungen und die Lösungstechnologie Unterliegen einer Ungewissheit

Chaotisch

Act - Sense - Respond

Die Novel Practices bleiben uns noch im chaotischen Bereich über. Hier finden wir im System keine direkte Ursache-Wirkungsbeziehungen mehr und können folglich nur agieren und schauen, was passiert.

Die Anforderungen und die Lösungstechnologie sind nicht bestimmbar

Warum komplexe Rahmenbedingungen wichtig sind!

In der heutigen Zeit herrschen bei vielen Unternehmen komplexe Rahmenbedingungen: es ist nie genau klar, was (also die Anforderungen) ein Unternehmen wie (also die Lösungstechnologie) entwickeln muss.

Kunden wollen Produkte schneller, wollen sie anders oder schnell was neues und wir sind lange nicht mehr die einzigen, die Produkte entwickeln - die Konkurrenz schläft nicht. Während der Industrialisierung war dieser Druck noch nicht so stark. Diesen Sachverhalt hat Dr. Gerhard Wohland mit der Taylorwanne bildlich gut dargestellt.

In diesem post-tayloristischen, volatilen Umfeld hat Scrum seine Stärke.

Denn gerade durch die kurzen Sprints haben wir in Scrum eine gute Möglichkeit, schnell Feedback vom Markt einzuholen und darauf zu reagieren. Scrum findet schnell die Probleme und bringt sie an den Tag - lösen musst die sie allerdings immer noch selbst.

Basierend auf Prinzipien, einer fantastischen Transparenz und dem tatsächlichen Fortschritt hilft es dir mit allem, was du brauchst, um Produkte zu entwickeln, die Kunden lieben!

Was passiert bei den falschen Rahmenbedingungen?

Wenn dir die komplexen Rahmenbedingungen fehlen, kannst du nach wie vor Scrum anwenden, es wird allerdings sehr wahrscheinlich nicht so effektiv sein, wie unter den komplexen Rahmenbedingungen. Dieser Sachverhalt ist mir beim Scrum Coaching besonders wichtig und so habe ich dazu auch einiges in meiner Scrum Toolbox, um dir bei einem möglich Projekt zielgenau zu helfen, ob etwas für dich passt und wenn nein, was du sonst effektives tun kannst.

Der Ablauf von Scrum


Scrumablauf im Video

Der Ablauf von Scrum kann grob in die folgenden sechs Schritte unterteilt werden. Diese Schritte schauen wir uns dann später noch einmal im Detail an.

Die Vision

Die Vision oder auch die erste Idee ist der Startpunkt für ein Produkt in Scrum. Dabei haben wir im Kopf, dass Scrum keine Projekte kennt, sondern Produkte entwickelt.

Product Backlog

Das Product Backlog enthält alles, was wir brauchen, um ein Produkt zu entwickeln. Es hat alle Anforderungen und es gibt nur dieses eine Backlog.

Sprint Planung

In der Sprint Planung wird nur ein Sprint geplant, nämlich der nun folgende. Dazu haben wir Product Owner und Entwicklungsteam.

Daily Scrum

Das Daily Scrum ist ein wichtiges Event für das Entwicklungsteam. Hier kann es sich operativ synchronisieren und den nächsten Tag planen.

Sprint Review

Im Sprint Review kann das Entwicklungsteam zeigen, was es geleistet hat. Dabei binden wir Stakeholder in Scrum immer ein und stellen etwas Erlebbares in Form eines Produktinkrements vor.

Sprint Retrospektive

Die Sprint Retrospektive ist das letzte Event im Sprint. In diesem Termin werden Verbesserungen identifiziert, von denen auch eine im nächsten Sprint umgesetzt wird.

Die Rollen in Scrum

Die richtige Besetzung entscheidet über Erfolg und Misserfolg.

Das Entwicklungsteam

Das Entwicklungsteam in Scrum erstellt das Produkt, welches der Product Owner über das Product Backlog verwaltet. Die Umsetzung muss nicht technisch im Sinne des Produktes erfolgen, sondern bezieht sich allgemein auf die Umsetzung der Anforderungen (Product Backlog Items) aus dem Product Backlog. Es verwaltet selbstorganisiert die Arbeit, wie auch die Messung des Fortschritts. Dabei lässt sich über die einfache Faustregel sagen, das Entwicklungsteam kümmert sich um das "wie" des Produktes.

Scrum Product Owner

Der Product Owner

Der Product Owner ist die Person, die für das "was" und den wirtschaftlichen Erfolg des Produktes verantwortlich ist. Ihm obliegt die Sortierung des Product Backlogs, in dem alle Anforderungen an das Produkt zu finden sind. Während er sich immer auf das "was will der Kunde" konzentriert, überlässt er die konkreten Ausprägungen immer dem Entwicklungsteam. Er stimmt sich bestmöglich mit allen Stakeholdern ab, um alle Kundenwünsche und Blickwinkel zu berücksichtigen.


Scrum Master

Der Scrum Master

Der Scrum Master ist der Hüter des Prozesses und dafür verantwortlich, dass Scrum richtig gelebt und eingeführt wird. Seiner Arbeitsweise liegt eine dienende Führung zugrunde, die er über die Rahmenbedingungen und typisches Scrum Coaching sicherstellt. Er arbeitet im Gegensatz zu dem Product Owner und dem Entwicklungsteam nicht am Produkt mit und konzentriert sich auf das Framework Scrum und die Organisation, in der es eingeführt wird.


Die Basis von Scrum: Empirische Prozesskontrolle

Scrum basiert auf der empirischen Prozesskontrolle. Diese hat die drei Säulen von Transparenz, Inspektion und Adaption.

Transparenz

Nur wenn du in der Lage bist, deinen tatsächlichen Produkfortschritt zu kennen, dann bist du auch in der Lage realistische Maßnahmen zu treffen.

Inspektion

Liegt eine Transparenz über dein Produkt und dein Prozess vor, dann hast du die Chance diesen realistisch zu inspizieren und wertvolle Kenntnisse zu gewinnen.

Adaption

Durch das richtige Inspizieren des Produktes und Prozesses kannst du dann die richtigen Maßnahmen für eine Verbesserung einleiten, die dich dann weiterbringen.

Scrum im Beispiel

Das Produkt und die Vision

In Scrum gehen die Vision und das Produkt Hand in Hand. Obwohl die Vision im Scrum Guide keine große Aufmerksamkeit bekommt, ist sie nicht unwichtig. Die Frage stellt sich immer, wie kommt eine Organisation zu einem Produkt und der passenden Vision. Die kurze Antwort ist: wie bisher auch. Irgendwann entwickelt sich der Gedanke oder es wird aktiv ein Produkt gesucht, welches durch geeignete Maßnahmen gesucht wurde. Das kann mit Design Thinking geschehen, oder aber auch mit jeglichen anderen kleinen oder großen Techniken, wie Impact Mapping, Story Mapping, Brainstorming, die Befragung von Stakeholdern und vieles mehr. Wichtig ist nur: es ist kein Projekt! Die Definition eines Produktes ist ein spannender Aspekt, der dir spätestens in der Scrum Skalierung auffallen wird, denn es macht einen gewaltigen Unterschied, wie du dort mit den entsprechenden Produkten umgehst.

Vond er Vision zum Product Backlog

Eine Vision kannst du auf einem Canvas oder auch auf einem Flipchart festhalten. Da gibt es keine Vorschrift, aber viele Möglichkeiten, die du in deinem Werkzeugkoffer mitführen kannst, damit du bestens gerüstet bist. Eine einfache Vision habe ich dir hier einmal abgebildet.

Beispiel für die Vision

Wir entwickeln den innovativen Getränkeautomat für die Zukunft, der vor dem Getränkewunsch der Kunden schon weiß, was diese wollen und optimieren den gesamten Prozess von der Zubereitung bis zur Ausgabe - komplett, vernetzt & intelligent.

Product Backlog in Scrum

Die Erstellung des Product Backlogs

Ein Product Backlog zu erstellen ist eine kritische und zu Beginn sehr wichtige Tätigkeit. Scrum selbst braucht diese Vorbereitung nicht zwingend und es gibt auch keinen Sprint 0, in dem vorab etwas passiert. Es hilft (gerade in größeren Unternehmen) wenn du das Product Backlog zum Beispiel in einem initialen Product Backlog Refinement erstellst.

Im Product Backlog müssen keine User Stories verwendet werden und auch keine Story Points! Der Scrum Guide spricht hierbei nur von Product Backlog Items und von Schätzungen, lässt aber offen, wie genau das implementiert wird. Du kannst dir als agiles Schätzen so zurechtlegen, wie du es brauchst. Bedenke aber, dass es einen guten Grund hat, warum User Stories beliebt und Story Points häufig verwendet werden ;-)

Ein Backlog könnte so aussehen und würde dann basierend von unserer Vision dann abgeleitet werden:

Beispiel für das Backlog

In einem Product Backlog stehen die Wünsche des Kunden aus Anwendersicht. Ein paar exemplarische Werte, abgeleitet von der Vision.

Nummer

Beschreibung

Größe

Wert

1

Als Anbieter des Getränkeautomats möchte ich den Getränkewunsch des Kunden kennen, um das Getränk zubereiten zu lassen

8

20

2

Als Kunde eines Getränkeautomats möchte ich umgehend mein Getränk erhalten, wenn ich mit dem Gerät nähere, um keine Wartezeiten erleiden zu müssen

3

10

3

...

5

30

...

...

3

5

Das Refinement

Das Refinement ist kein typisches Event wie der Rest, sondern eine entwicklungsbegleitende Tätigkeit. Hier arbeiten der Product Owner und das Entwicklungsteam Hand in Hand um Product Backlog Items auf dem Product Backlog soweit zu verfeinern, dass diese Product Backlog Items als fertig für die Sprint Planung gelten. Dabei geht es immer um das gemeinsame Verständnis von Product Backlog Items. Dazu können Tätigkeiten wie das Schneiden, das Schätzen oder das (neue) Beschreiben von Product Backlog Items Thema sein. Am häufigsten ist das Problem, dass die Teams oder die Unternehmen zu wenig Zeit für diese Tätigkeit einplanen. Dadurch gelangen dann unfertige Einträge in den Sprint wodurch der Frust steigt und die Transparenz am Ende leidet.

Refinement in Scrum

Beispiel Refinement 1: Schneiden von PBIs

Wenn ein Eintrag zu groß ist (vgl. INVEST), dann muss er geschnitten werden, damit er in einen Sprint passt. Schneiden hat oft die dumme Eigenschaft, dass es dann nicht unbedingt mehr kundenorientiert ist. Deshalb sollte sich immer überlegt werden, wie die konkrete Funktionalität für den Kunden erhalte bleiben kann.

Im Refinement ist eine Tätigkeit das Schätzen der Product Backlog Einträge. Auch hier sagt der Scrum Guide nicht, wie du das konkret tun solltest, eine gängige Technik, gerade für User Stories, ist das Planning Poker. Dort wird mit einer (angepassten) Fibonacci-Reihe und einer Referenz geschätzt.

Beispiel Refinement 2: Schätzen von PBIs

Der Product Owner stellt ein Product Backlog Item vor und das Team schätzt diesen Eintrag. Meisten nutzen die Teams gerne Planning Poker. Bei diesem Poker bekommt jedes Mitglied einen Satz an Karten mit den Zahlen 1,2,3,5,8,13,... und dann entweder 20,40,100 oder auch 21,34,55,89. Also die angepasste oder echte Fibinacci Reihe. Im Grunde ist es 

Sprint Planung

Sprint Planung

In der Sprint Planung, die meistens in eine Sprint Planung 1 und eine Sprint Planung 2 aufgeteilt wird, stellt der Product Owner die wichtigstens Einträge aus dem Product Backlog vor. Dabei legt er den Fokus auf das "Was". Das Entwicklungsteam entscheidet zuerst, wie viele dieser Einträge es glaubt zu schaffen. In einem nächsten Schritt geht es dann darum, diese noch genauer zu planen. Dabei wir das "wie" genau bestimmt.

Beispiel Sprint Planung 1: Was wollen wir machen und wie viel?

Im Sprint Planning (Teil 1) stellt der Product Owner die Backlog Items nur kurz vor, diese sollten bereits alle durch das Refinement kennen. Hat unser Entwicklungsteam eine Velocity von 15, dann ist es wahrscheinlich, dass sie aus dem obigen Beispiel, mindestens die 8 und die 5 als Product Backlog Items ziehen und vielleicht auch noch das dritte Element. Die Entscheidung obliegt dem Entwicklungsteam, hier schiebt niemand nach - kein Product Owner und kein Management. Das Scrum Muster "Yesterday's Weather" hilft beim Schätzen.

Beispiel Sprint Planung 2: Wie wollen wir es umsetzen?

Im Sprint Planning (Teil 2) überlegt sich das Entwicklungsteam, wie es aus den konkreten Product Backlog Items dann konkrete Aufgaben erstellt. Pro Product Backlog Item können so oft 3-8 sogenannter Tasks erstellt werden. Diese sind für das Entwicklungsteam und können alles das umfassen, was das Entwicklungsteam braucht, um sich zu koordinieren.

Daily Scrum

Im Daily Scrum kann das Entwicklungsteam oftmals schon ohne den Scrum Master alleine die nächsten 24 Stunden für sich planen. Dabei geht es darum, sich im Team zu synchronisieren, so das jedem aus dem Entwicklungsteam klar ist, woran die anderen Kollegen arbeiten und wie der Stand bezüglich des Sprint Ziels ist. Zu Beginn hilft es, wenn der Scrum Master das Entwicklungsteam befähigt, das Event optimal zu gestalten.

Daily Scrum

Beispiel Daily Scrum: Abstimmung

Hier könnten Sie Entwicklungsteammitglieder gemeinsam sich an den drei Fragen orientieren. Was habe ich gestern für das Sprint Ziel getan, was tue ich heute für das Sprint Ziel und wo sehe ich Probleme. Dabei wird parallel das Sprint Backlog aktualisiert, in dem entsprechenden Tasks entsprechend umgehängt werden.

Sprint Review

Sprint Review

Im Sprint Review darf das Entwicklungsteam endlich zeigen, was es alles geschafft hat. Alle fertige Arbeit, die der Definition of Scrum entspricht, mündet in einem sogenannten Produktinkrement. Du erinnerst dich bitte noch mal an die inkrementelle Eigenschaft von Scrum. Unser Produkt wird also von mal zu mal weiterentwickelt und genau das ist etwas, was dann im Sprint Review auch gezeigt wird.

Du kannst sagen, dieses Event ist eher "informell", es soll kein Statusmeeting sein, sondern wir wollen alle lernen, wie es um das Produkt steht. Feedback von den entsprechenden Stakeholdern, dem Management und Kunden kann direkt durch den Product Owner eingesammelt werden und mündet dann im Product Backlog.

Am Ende kann der Product Owner dann ebenso noch einen Ausblick auf den Markt geben. Ebenso ist es ein guter Punkt, noch mal auf das große Bild, die Vision hinzuweisen und sonst wichtige Details aus wirtschaftlicher Sicht mitgeben.

Beispiel Sprint Review

In dem Sprint Review soll das Entwicklungsteam zeigen, was es gemacht hat. Und das so, dass es das Stakeholder Feedback maximiert. In unserem Beispiel könnten mehrere Einträge zum Beispiel in einer Art "Prozess" dargestellt werden. Das Entwicklungsteam baut "Stationen" auf, bei denen Stakeholder und Kunden vorbeigehen können. Dabei lohnt es sich, zum Beispiel Teile der Software (bei uns z.B. eine Funktionalität auf der App) und dann Teile des Prozesses (Geräteautomat) als "Stub" zu nutzen, wenn sie noch nicht fertig sind. Dazu helfen Story Maps. Der Kunde weiß meistens erst was er (nicht) will, wenn er es sieht.

Sprint Retrospektive

Die Sprint Retrospektive ist das letzte Event in deinem Sprint. Hier geht es darum, in möglichst kurzen Zeitabschnitten über deinen Prozess zu reflektieren. Wie war die Zusammenarbeit im Team? Was gab es für Probleme, die beseitigt werden sollten? Dieser Fragen werden in einer Retrospektive beantwortet und sehr oft sollte der Scrum Master hier die Führung übernehmen. Es ist praktisch "sein Meeting" in dem er sicherstellen kann, das Scrum richtig durchgeführt wird und so Angebote für die Verbesserungen mit Hilfe des ganzen Scrum Teams anleiten kann.

Sprint Retrospektive

Beispiel Sprint Retrospektive

In der Sprint Retrospektive reflektiert das Scrum Team, wie der letzte Sprint verlaufen ist und was im nächsten verbessert werden kann. Dabei kann eine einfach "+" / "delta" Liste zum Beispiel verwendet werden. So könnte das Team sagen, die Zusammenarbeit und die Eihaltung der Timeboxen hat sehr gut geklappt. Weniger gut war das Refinement, da einige PBI nicht richtig verstanden wurden. Dann wird sich eine Maßnahme dazu überlegt. Diese könnte hier heißen "wir refinen im Pair in spontanen Sessions kritische PBI". Diese Verbesserungsmaßnahme findet sich dann am besten gleich im Sprint Backlog des Entwicklungsteams.

Zeiten, die du investieren musst

Wenn du Scrum erfolgreich nutzen möchtest, dann kannst du dich an den folgenden Zeiten für einen einmonatigen Sprint orientieren. Wenn du der Meinung bist, einem Meeting Overhead gegenüberzustehen, dann hast du garantiert deine Probleme an anderer Stelle!

Für die Events

8h
Sprint Planning
4h
Sprint Review
3h
Sprint Retrospektive
2,7h
Daily Scrum

Für die Transformation mit Scrum selbst

Persönlich ist dieser Wert nur sehr schwer festzulegen. Ich denke aber, dass ein Zeitraum von einem bis drei Jahren ein gutes Scrum Team hervorbringen kann. Bedenke immer, es geht dabei um Empirie und um langfristiges Lernen. Das kannst du nur machen, wenn du es erlebst und das einen entsprechenden Zeitraum.

Schau dir gleich an, was es noch mehr zu Scrum gibt!

Tools und Werkzeuge 

Tools und Werkzeuge für Scrum solltest du immer differenzieren. Es gibt zum einen wertvolle Werkzeuge, die du immer in deiner Scrum Toolbox haben solltest. Das sind meistens mehr Werkzeuge im Sinne von Techniken oder Praktiken. Dann gibt es natürlich auch noch jede Menge remote Werkzeuge.

Excel

Nach wie vor werden noch viele Backlogs in Excel gehalten, die spaltenweise Sortierung und Funktionen der Tabellenkalkulation eignen sich recht gut.

Google Sheets

Google Sheets hilft durch eine gute Funktionalität im Teilen und bietet für das Backlog ähnliche gute Features an wie Mircosoft Excel.

Trello

Mittlerweile Teil der Atlassian Familie besticht Trello mit Einfachheit und guter Integration. Reife Teams finden mit Trello einen guten Punkt für den Start.

Jira

Reicht Trello nicht mehr, übernimmt Jira, ebenfalls von Atlassian. Gute Integration mit Confluence und bildet typische agile Strukturen ab.

Confluence

Das Wiki aus dem Hause Atlassian. Bietet gute Funktionalitäten und Integration mit anderen Atlassian Produkten.

Mentimeter

Die ein oder andere Abstimmung schnell benötigt? Mentimeter bietet die Möglichkeit dieses ansehnlich zu tun.

Miro

Ein digitales Whiteboard, welches Teams immer unterstützt wenn es darum geht virtuelle und remote zusammen zuarbeiten.

Concept Board

Ein digitales Whiteboard aus Deutschland mit Servern ebenso in Deutschland. Gute Möglichkeiten zur Zusammenarbeit.

Mural

Und noch ein gute Whiteboard, welches sich eignet über digitale Grenzen zu arbeiten.

Slack

Die Abstimmung im Team schnell über den ein oder anderen Chat erledigen? Slack machts!

Zoom

Saubere und stabile Bildübertragung, immer hilfreich, wenn Teams nicht zusammen sitzen.

Microsoft Teams

Aus meiner Sicht deutlich besser als Skype früher, im Video nicht ganz so gut wie Zoom.

Was es noch zu beachten gibt

Scrum und Projektmanagement

Scrum wird viel als Projektmanagement bezeichnet. Solange wir im Hinterkopf haben, dass es bei Scrum nicht um Projekte geht und der Begriff Projektmanagement genutzt wird, um dabei im Gespräch zu bleiben - alles gut. Im Grunde hat nur das Projekt in dem Kontext nichts verloren und impliziert eine alte und neue Welt, die so nicht zusammen passt.

Scrum und Methode

Eine Methode lässt den Anschein erblicken, man kann Scrum einfach von A bis Z durchgehen. Das ist nicht der Fall! Scrum ist ein agiles Framework und das ist etwas anderes als eine Methode. Auch wenn der Begriff der Methode nicht so hart gesehen wird, sehe ich ihn in der Praxis als sehr kritisch an.

Scrum und Softwareentwicklung

Scrum funktioniert super bei der Entwicklung von Software, aber auch außerhalb kann man prima damit Produkte entwickeln. Du musst dich dabei immer Fragen, wie du die Events, Artefakte und Rollen interpretierst. Egal ob Hardware oder Prozesse - es geht, nur 1:1 kopieren funktioniert in der Regel nicht.

Was ist mit dem Management?

Das Management existiert meistens in Unternehmen so oder so. Im Zuge einer Transformation oder Scrum Skalierung wandelt sich die Rolle allerdings stark. Es geht weg von der Verwaltung von Aufgaben und Kontrolle hin zur Verbesserung des Wertstroms und dem Lehren von wertvollen Fähigkeiten für die Organisation.

Scrum und schnell

Ein weit verbreiteter Irrglauben ist es, dass Scrum automatisch schnell bedeutet. Schnell kann eine gute Scrum Implementierung sein, ja. Der Fokus von Scrum liegt aber in dem Kundennutzen. Ein gutes Scrum ist sehr wahrscheinlich auch lean und schnell.

Über Mich.

Coach, Geschäftsführer und wibas und kegon Netzwerkpartner

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. Mit seiner systemischen, impuls- und experimentbasierten Art hilft er über den Tellerrand der Unternehmen zu schauen.

>