Category Archives for "Scrum Grundlagen"

Wie Sie den Meeting Overhead in Scrum reduzieren!

Meeting Overhead in Scrum

"Wie können wir in Scrum den Meeting Overhead reduzieren?". Wenn ich diese Frage im Scrum-Umfeld bei Kunden höre, bildet sich bei mir schon eine Liste an möglichen Problemen in der Umsetzung des agilen Projektmanagement Framework Scrum.

Kommen Sie aus einer größeren Organisation und sind der Meinung, Overhead von Meetings in Scrum reduzieren zu müssen? Dann helfe ich Ihnen, wie Sie die Scrum Events richtig durchführen. Ich glaube fest daran, dass alle Scrum Events ausreichen, um komplexe Produkte zu entwickeln.

Sie sind der Agilist und der Meinung, das es keinen Overhead von Meetings in Scrum gibt, dann haben Sie ins Schwarze getroffen 🙂 Ich gehe auf das Symptom des Problems im Folgenden genau ein.

Mit "Meeting Overhead" wird folgender Sachverhalt bezeichnet: das Team das Gefühl, nur noch in Meetings zu sitzen und nicht mehr zum Arbeiten zu kommen. Diese Situation des "Meeting Overheads" findet sich nicht nur im agilen Projektmanagement Framework Scrum, sondern ist ein häufiges Problem von Teams und Individuen in Organisationen.

Aus meiner Erfahrung finden sich häufig drei Grundursachen bei Scrum. Ein "Meeting Overhead" entsteht immer dann, wenn...

  • ... Scrum "nebenbei" eingeführt wird und die Teams und Teammitglieder in mehreren Projekten arbeiten. Sie nehmen also mehr als eine Rolle in einem Projekt ein und sind dann überproportional mit Meetings belegt.
  • ... die Umsetzung der Scrum Events nicht richtig gelungen ist. Es werden mehr Meetings benötigt und diese dauern länger als gedacht. Damit sind die Meetings gefühlt und stundentechnisch einfach mehr, als nötig.
  • ... ein typischer "Roll-out" von Scrum in der ganzen Organisation durchgeführt wird. Es gibt keine Zeit für Experimente und alle müssen sich von einem Zeitpunkt x schnell umstellen.

Wieviel Meetings haben wir in Scrum?

Scrum als agiles Projektmanagement hat fünf Events. Davon sind vier typischerweise Meetings. Nehmen wir noch das Backlog Refinement als Meeting dazu, dann haben wir schon alles, was wir brauchen. Diese Meetings brauchen Sie, um Ihr Projekt verwalten und komplexe Produkte entwickeln zu können. Dabei sind alle Aktivitäten zur Verwaltung Ihrer Scrum Implementierung enthalten. Mehr hinsichtlich der Anzahl gibt es nicht. Eventuell haben Sie noch eigene Meetings, die Sie im konkreten Fall für Ihre Implementierung benötigen, aber grundsätzlich ist das alles.

Das Verhältnis von Events zu Entwicklungszeit

In diesem Abschnitt möchte ich mich dem "Meeting Overhead" einmal von den Fakten her nähern. Ich schaue mir die Vorgaben für die Events aus dem Scrum Guide an und setze diese Werte zu unterschiedlichen Sprintlängen in Beziehung.

Während es das agile Manifest mit

3. agiles Prinzip aus dem agilen Manifest

"Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne."

Quelle: Agiles Manifest, http://agilemanifesto.org

noch recht locker sieht, nimmt es der Scrum Guide mit

Scrum Guide

"Das Herz von Scrum ist der Sprint, eine Time Box von maximal einem Monat, innerhalb dessen ein fertiges ("Done"), nutzbares und potenziell auslieferbares ProduktInkrement hergestellt wird."

Quelle: Scrum Guide, www.scrumguides.org

schon etwas genauer. Er gibt aber nur die Obergrenze für die Dauer eines Sprints, nämlich ein Monat, an. In der Praxis haben sich neben der Maximallänge von einem Monat noch die Sprints von zwei und drei Wochen etabliert. Auch der Sprint mit der Länge von einer Woche findet ab und zu bei besonders innovativen und komplexen Produkten Anwendung. 

Meetings in Abhängigkeit der Sprintlänge

Nun werfen wir einen Blick auf die Länge der vorhandenen Events in Scrum, inklusive dem Backlog Refinement. Dabei stelle ich die Zeiten gegenüber, die in der Regel (und durch bloßes rechnen) Sinn ergeben. In der Praxis variieren diese Zeit teils sehr stark, abhängig von unterschiedlichen Rahmenbedingen. Das können zum Beispiel sein:

  • Was für ein Produkt wird konkret entwickelt
  • Wie reif ist das Team und welche Erfahrung hat das Team
  • Wie optimiert ist der bisherige Prozess
  • Wie gut sind Backlog Items vorbereitet
  • ...

Es hilft dennoch sehr, mit diesen Zeiten und Rahmenbedingungen zu starten. Dann werden Sie auch keinen Meeting Overhead in Scrum erleben!

Besonderheit Backlog Refinement

Das Backlog Refinement ist kein Event und hat keine Timebox wie die anderen Events. Das liegt daran, dass das Backlog Refinement eine aufwandsbezogene Tätigkeit ist. Das wird schnell klar, wenn wir überlegen, dass es schwieriger ist, mit 10 Entwicklern Stories zu verfeinern, als es mit 5 der Fall ist. Deswegen bezieht sich der Aufwand auf die Kapazität des Entwicklungsteams

Was bedeutet nun die Kapazität des Entwicklungsteams? Die Kapazität eines Teams ist die Zeit, die es in den Sprints real auch verbringt. Wenn wir zwei Wochensprints machen und dabei 10 Tage Kapazität von 10 Entwicklern haben, ergibt das eine Kapazität des Entwicklungsteams von 100. 10 Tage (10%) entfallen damit auf das genannte Refinement.

Dabei wird vom Scrum Guide offen gelassen, wer was wie macht. Deswegen entscheidet auch das Scrum Team darüber. Ein Beispiel:

  • Der Product Owner könnte von diesen 10 Tagen zum Beispiel eine gewisse Zeit für die Abstimmung mit dem Kunden sein (ohne Entwicklungsteam) und das Verfeinern und Aufnehmen von Backlog Items verwenden. Nehmen wir an, dies sind 3 Tage.
  • Der Rest könnten zusammen mit dem Entwicklungsteam für Schätzworkshops, Refinements, etc. verwendet werden. Dafür benötigt der Product Owner selbst noch zur Vor- und Nachbereitung 2 Tage und das Entwicklungsteam die restlichen 5 Tage für ein Meeting von einem halben Tag (10 Entwickler spendieren je einen halben Tag = 5 Tage).

Was auf den ersten Blick hoch erscheint, hilft Ihnen massiv bei der interativen und inkrementellen Entwicklung! Gerade wenn Sie Probleme in der Erstellung eines Inkrements haben, sollten Sie genauer auf Ihr Backlog Refinement schauen!

Die Sprints und die Zeiten im Überblick

Wenn Sie frisch mit Scrum starten, nutzen Sie bitte immer die aus dem Scrum Guide abgeleiteten Zeiten, so entgehen Sie dem Meeting Overhead in Scrum. Besonders wenn Sie merken, dass Sie deutlich mehr Zeit benötigen, als angegeben, ist es Zeit für eine Retrospektive bei Ihnen.

Sprint
Länge
1 Woche

Sprint Planning

2 Stunden

Daily Scrum

15 min

Sprint Review

1 Stunden

Sprint Retrospektive

0,75 Stunden

Backlog Refinement

4 Stunden
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
2 Wochen

Sprint Planning

4 Stunden

Daily Scrum

15 min

Sprint Review

2 Stunden

Sprint Retrospektive

1,5 Stunden

Backlog Refinement

8 Stunden * Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
3 Wochen

Sprint Planning

6 Stunden

Daily Scrum

15 min

Sprint Review

3 Stunden

Sprint Retrospektive

2,25 Stunden

Backlog Refinement

12 Stunden * Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
4 Wochen

Sprint Planning

8 Stunden

Daily Scrum

15 min

Sprint Review

4 Stunden

Sprint Retrospektive

3 Stunden

Backlog Refinement

16 Stunden *Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Aus meiner Sicht hilft es, sich gleich zu Beginn eine Übersicht zu erstellen, wann welche Meetings stattfinden und diese Information muss dann in das (oder die) Team(s) gebracht werden, ebenso in die Organisation. Im folgenden sehen Sie beispielhaft so einen Sprint Meeting Plan (ohne Backlog Refinement).

Meeting Overhead? Der Sprint Plan für 4 Wochen Sprints

Was Sie weiter für den Meeting Overhead und die Sprints beachten müssen!

Es gibt neben den konkreten Zeiten für die Sprints noch weitere Dinge, die Sie in Betracht ziehen sollten. Dazu gehört es sich in der Organisation auf die Suche nach Synchronisationswegen zu machen. Kann Ihr Team alleine alles entscheiden, benötigt es keine Abstimmungen, keine Zulieferungen oder ähnliches? Dann ist es einfach, oft gibt es aber irgendein Ereignis, auf das Sie sich synchronisieren müssen.

Ihre Sprintlänge und auch der genaue Startpunkt muss dann überprüft und ggf. auch angepasst werden. Im folgenden Bild sehen Sie eine vereinfachte Darstellung für eine angepasste Sprint Planung auf den Wochentag Donnerstag. In dem Beispiel könnten andere Takte dazu führen, dass die Sprint Planung am Donnerstag beginnen muss.

Kein Meeting Overhead mit getacktetem Meetingplan in der Organisation

Large-Scale Scrum: Scrum erfolgreich skalieren mit LeSS
Preis: nicht verfügbar
Zuletzt aktualisiert am 24.11.2017

Wir brauchen eine Anpassung!

Seien Sie bitte mit Anpassung immer vorsichtig. Scrum funktioniert nur als Ganzes. Auch wenn Sie aus dem Scrum Guide lediglich Teile nutzen können, ist das Ergebnis dann kein Scrum. Anpassungen sind im zeitlichen Rahmen aber immer wieder mal nötig. Das hängt zum Beispiel von dem entwickelten Produkt ab, wie gut das Team zusammenarbeitet und ähnlichem.

Ich starte gerne mit den Vorgaben, die der Scrum Guide bereitstellt. Orientieren Sie sich bitte auch an den oben genannten Werte und Zeiten. Stellen Sie dann fest, dass Sie andere Bedarfe an die Zeiten haben, dann nutzen Sie Ihre Retrospektive und beleuchten Sie Ihren Prozess und Ihre Anforderungen genau. Scrum basiert auf der empirischen Prozesskontrolle, Sie machen also Erfahrungen und adaptieren auf Basis dieser gemacht Erfahrungen!

Fazit: Meeting Overhead in Scrum gibt es nicht!

Wie so oft gilt auch hier:  Scrum ist einfach aber nicht leicht. Es ist eben kein Problem den Scrum Guide am Wochenende durchzulesen. Es gehören aber unter Umständen aber Jahre dazu, diese Anwendung zu perfektionieren. Sie müssen Scrum richtig anwenden und werden dann auch keinen Meeting Overhead spüren. Denken Sie bitte daran, dass Sie einen Meeting Overhead wahrnehmen, dass Sie sehr wahrscheinlich  Anpassungen an Scrum vorgenommen haben, die nicht optimal sind. Das liegt häufig an der Parallelität von Scrum zu bestehenden Initiativen und an Teilzeitteams.

Agil und Lean übertrieben einfach

Agil und Lean - übersichtlich und einfach

Manchmal vereinfache ich gerne Dinge. Agil und Lean jemanden zu erklären, der sich noch gar nicht damit auskennt erfordert oft so eine Vereinfachung. In diesem Artikel stelle ich Ihnen einmal meine einfach übertriebene Art und Weise vor.

Agil: Kundenwert und Flexibilität

Das wichtigste für mich im Bereich von Agil ist das Inkrement. Durch das Inkrement sind Sie in der Lage wirkliche Agilität zu leben. Wenn ich wählen müsste, wäre das Inkrement genau das, was für mich den Ausschlag gibt, ob Sie Agilität vorfinden können.

Das Inkrement zahlt maßgeblich auf die Flexibilität und den Kundenmehrwert ein.​ Beide Variablen sind die, an denen z.B. Scrum das System optimiert. 

Lean: kurze Durchlaufzeit

Schauen wir uns nun ebenso übertrieben einfach einmal an, was Lean ist, dann können wir sagen, dass eine besonders kurze Durchlaufzeit maßgeblich auf alles von Lean einzahlt. Auch hier spielen weitere Faktoren mit hinein. Wenn Sie es aber schaffen eine kurze Durchlaufzeit zu erreichen, dann haben Sie vieles von Lean erreicht zu haben.

Das Scrum nicht agil sein muss und das alles agile gleich Scrum ist, lasse ich an der Stelle einmal bewusst außen vor. Ebenso können Sie natürlich auch schnelle Durchlaufzeiten erreichen ohne sich mit Lean je beschäftigt zu haben. In der Regel werden Sie aber genau diese beiden Ausprägungen vorfinden, wenn sich die Ergebnisse (Inkrement, schnelle Durchlaufzeit) in der Realität finden lassen.

Agil und Lean - einfache Schlüsselkonzepte

Lernen ist ein inhärent wichtiger Bestandteil

Egal welche Wünsche ein Kunde hat, egal was wir in ein Backlog schreiben. Wenn wir es nicht schaffen aus einem Inkrement zu lernen und uns weiterzuentwickeln, dann haben wir nichts gewonnen. Wir können dann Verbesserungen eben nicht übernehmen.

Und das geht wiederum nur, wenn das Inkrement vorhanden ist. Wenn Sie kein Inkrement erzeugen, dann sollten Sie alles daran setzen, genau damit zu starten.

Reflektieren Sie einmal ihre agil und lean Implementierungen gegen diese Aussage. Ich bin mir sicher, dass Sie dort genau solche Ausprägungen finden werden.

YouTube ScrumKurs24

ScrumKurs24 jetzt mit YouTube Kanal!

ScrumKurs24 und YouTube

Der ScrumKurs24 ist jetzt mit einem eigenen YouTube Kanal vertreten. In diesem YouTube Kanal wird es in unregelmäßigen Abständen kleine Videos zu Scrum geben. Diese Video behandeln immer genau einen Aspekt aus Scrum oder dem Umfeld von Scrum.

Ziel und Zweck

Zum einen bin ich ein Fan von Videos im Ausbildungsbereich. Zum anderen denke ich, dass es eine gute Möglichkeit darstellt, Wissen über einen visuellen Kanal mit aufzunehmen. Ich möchte so die Möglichkeit geben, neben den hier existierenden Artikeln auch bewegte Informationen rund um Scrum darzustellen. Sie können sich den Kanal abonnieren und ganz kostenlos ansehen.

Fokus

Fokus ist nicht nur ein Scrum-Wert, sondern stand auch Pate für meine YouTube Videos: keines dieser Videos ist länger als 2:30min! So ist es möglich, den passenden Bereich herauszugreifen und in sehr kurzer Zeit das Wichtigste sich anschauen zu können.

Erklärstil

Die Videos sind alle im sogenannten “Erklärstil” oder auch “Explainer-Video” erstellt. Dabei sehen Sie praktisch, wie sich ein Whiteboard füllt und können der Hand folgende, die das schreibt. Diese Art der Produktion lässt den Aufwand in Grenzen halten, im Gegensatz zu Videos bei denen ich zum Beispiel selbst vor der Kamera stehen würde.

Nun wünsche ich aber viel Spaß mit meinem neuen YouTube Kanal! Schreiben Sie mir doch einfach, welche Videos Sie gerne noch sehen würden!

Nutzen Sie das Sprint Ziel richtig!

Das Sprint Ziel in Scrum

Scrum Entwicklungsteam Sprint ZielDas Sprint Ziel definiert den Nutzen, den ein Produktinkrement am Ende des Sprint erreicht. Das Sprint Ziel wird allerdings so definiert, dass es nicht die Summe der umzusetzenden User Stories ist. Ein Sprint Ziel schreibt den Nutzen des Produktinkrements in einer abstrakten Form, so ist es möglich das Sprint Ziel zu erreichen, auch wenn z.B. eine User Story getauscht wurde oder nicht umgesetzt wurden konnte.

Das Entwicklungsteam und der Product Owner definieren

Das Entwicklungsteam und der Product Onwer definieren gemeinsam das Sprint Ziel. Dabei gehen die Teams in der Regel so vor, dass der Product Owner ein solches Ziel als Vorschlag mit in das Team bringt. Dann wird mit dem Entwicklungsteam darüber diskutiert und im besten Falle gleich übernommen. Es kann auch vorkommen, dass das Entwicklungsteam kleine Anmerkungen hat oder das Sprint als utopisch ansieht – dann muss in die Verhandlung mit dem Product Owner gegangen werden. Das Sprint Ziel wird während des Sprints nicht verändert.

Das Sprint Ziel am Sprint Board

Sprint BacklogDas Sprint Ziel wird immer zum Sprint Backlog gehängt. Das hilft zum einen sehr im Sinne der Visualisierung – das Team schaut zwangsläufig immer jeden Tag (zu Beispiel im Daily Scrum) auf dieses Ziel und wird erinnert. Ach wenn dieser Aspekt oft als “lächerlich” oder “überflüssig” angesehen wird, ist es in meinen Augen sehr entscheidend.

Zudem kann das Team so auch viel besser die drei Fragen im Daily Scrum auf dieses Sprint Ziel beziehen.

Sprint Ziel kann nicht erreicht werden

Scrum Sprint PlanningEs kann durchaus auch vorkommen, dass ein Sprint Ziel einmal nicht erreicht wird. Das sollte immer die Ausnahme bleiben und ebenso in der Retrospektive ausführlich untersucht werden. Nehmen wir an das Scrum Entwicklungsteam hat sich komplett verschätzt und das Ziel des laufenden Sprints ist jetzt schon nicht mehr erreichbar. Dann kann und sollte der Sprint durch den Product Owner abgebrochen werden. Auch der Product Owner kann durch eine Änderung der Anforderungen und andere wirtschaftliche Entscheidungen sich dazu genötigt sehen, das Sprint Ziel einzustellen, da es nicht mehr zu erreichen ist.

Der Sprint wird in diesem Falle abgebrochen. Es ist besser den aktuellen Sprint abzubrechen, als ihn zu Ende zu führen, obwohl wir wissen, dass das Ziel nicht mehr erreicht werden kann.

Beispiele

Wenn Sie Ziele zum ersten Mal aufstellen wollen, suchen Sie in der Regel eine Vorlage, ein Beispiel – kurz: wie machen es denn eigentlich andere? So ein Ziel könnte lauten: Ersten haptischen Prototypen für das neue Navigationsgerät erstellen, die Loginfunktionalität des Portals etablieren oder auch den Umgang mit Scrum lernen. Sie sehen schon, dass das Ziel ganz unterschiedlich sein kann. Nur eines sollte es eben nicht sein: eine einfache Wiederholung von Anforderungen / Product Backlog Einträgen.

Sie können sich nun bestimmt auch vorstellen, dass das im Sprint definierte Ziel als eine kleine Vision für den Sprint gilt. Es ist konkret genug eine Richtung festzulegen, aber noch so abstrakt, dass Sie sich für oder gegen Eigenschaften des Produktes entscheiden können.

Es ist nun vollkommend ausreichend, wenn Sie dieses Ziel am Sprint Backlog des Team festhalten. So kann jedes einzelne Teammitglied aus dem Entwicklungsteam tagtäglich seine Arbeit gegen eben dieses Ziel reflektieren!

4

Scrum Werte als Grundlage

Scrum Werte

Die Scrum Werte existieren schon lange, nämlich seit dem ersten Buch von Ken Schwaber und Mike Beedle Agile Software Development with Scrum. Dort wurde fünf Werte definiert: Mut, Commitment, Fokus, Offenheit und Respekt. Diese Scrum Werte stellen die Basis für den Umgang mit Scrum dar. Die Werte erlauben eine gute Reflexionsmöglichkeit und nach wie vor finden sich bei nicht ganz rundlaufenden Scrum Implementierungen die Probleme tatsächlich in diesen Scrum Werten begraben. Zeit, sich diesen Werten einmal genauer zu nähern und diese zu analysieren.

Was sind Werte?

Schauen wir uns kur an, was Werte eigentlich sind, um dann diese Definition mit unseren Scrum Werten in Beziehung zu setzen. Wikipedia schreibt dazu:

Wertvorstellungen oder kurz Werte bezeichnen im allgemeinen Sprachgebrauch als erstrebenswert oder moralisch gut betrachtete Eigenschaften bzw. Qualitäten, die Objekten, Ideen, praktischen bzw. sittlichen Idealen, Sachverhalten, Handlungsmustern, Charaktereigenschaften beigelegt werden.

Wikipedia

Ich finde die Aussage “[…]erstrebenswerte oder moralisch gut betrachtete Eigenschaft[…]” in diesem Zusammenhang sehr treffend. Ich denke das diese Werte anzustreben sind, denn nur wenn sich innerhalb des Teams oder oder der Organisation diese Scrum Werte richtig etabliert haben, ist auch die Scrum Implementierung erfolgreich. Wir müssen im Scrum Umfeld diese Werte also erstreben, damit wir eine gute Basis für eine gute Scrum Implementierung haben.

Bei diesen Scrum Werten müssen wir zusätzlich noch etwas im Kopf haben, das Unterschiedliche Kulturen Werte sehr unterschiedlich interpretieren können. In Asien wird ein Wert Commitment anders interpretiert, als wir das in Europa kennen. Bei sämtlichen Betrachtungen dieser Werte, darf man das nicht außer Acht lassen.

Commitment

Scrum Werte - CommitmentDen Scrum Wert Commitment zu übersetzen finde ich immer etwas schwierig. Ich orientiere mich dabei gerne an einer Verpflichtung. Sehr oft findet sich das Wort Commitment im Deutschen ebenso, die Bedeutung schwankt aber durchaus in Extremen.

Das Team in Scrum verpflichtet sich auf eine zu entwickelnde Funktionalität und Arbeitsumfang in einem Sprint. Es committed sich damit praktisch auf das, was es zusagt. Das ist ganz elementar. Das ist einer der Scrum Werte, der in Teams dann zum Beispiel nicht umgesetzt ist, wenn Teams immer wieder die zugesagten Product Backlog Items (PBI) in den nächsten Sprint schieben.

Der Volksmund sagt gerne auch “wenn ich etwas sage, dann mache ich es auch!” – auch das ist letztendlich genau das, was mit diesem Commitment auch gemeint ist. Natürlich kann es immer mal passieren, dass diese Selbstverpflichtung nicht erreicht wird, dann sollte in der Retrospektive ein genauer Blick auf diesen Sachverhalt geworfen werden.

Fokus

Produktinkrement in ScrumFokus ist ein Wert, den heute – gerade in der digitalen Zeit – immer weniger Menschen wirklich besitzen. Es ist nicht leicht, sich auf eine Sache zu konzentrieren, diese abzuschließen und sich nicht zu verzetteln. Große Aufgaben werden zerkleinert und in Stücke bearbeitet, die es erlauben den Fokus auf genau diesen auch zu behalten. Wenn wir Aufgaben haben, die klar und klein sind, dann können wir den Fokus recht gut behalten und diese auch abschließend umsetzen.

In Scrum gibt es mit Meetings wie dem Daily Scrum auch eine gute Möglichkeit den Fokus auf der täglichen Arbeit zu behalten. Diese Visualisierungen in Scrum führen ebenso dazu, klar herauszustellen woran gerade gearbeitet wird und wo somit der Fokus im Projekt liegt.

Offenheit

Daily Scrum KommunikationOffenheit finde ich ebenso einen nicht ganz einfachen Werte der Scrum Werte. Offenheit muss immer im Verhältnis gesehen werden, denn sich komplett zu offenbaren will wahrscheinlich niemand und alles transparent zu machen auch nicht. Deshalb kommt es bei Offenheit auch und gerade auf das Verhältnis an.

Jeder einzelne im Scrum Team sollte offen und neugierig gegenüber neuen Techniken und Praktiken sein. Ebenso muss ich Konflikte offen und ehrlich auch ansprechen können und wollen.

Ein Stück weiter, dann sind wir bei der Transparenz, die sich auf den Arbeitsfortschritt und die Artefakte in Scrum bezieht.

Respekt

Scrum ZertifizierungenRespekt finde ich nicht nur in Scrum wichtig, sondern ist für mich ein ganz grundlegender Wert. Wenn wir mit anderen zusammenarbeiten, dann haben wir alle unterschiedliche Meinungen und Sichtweisen. Das ist wichtig und ganz elementar – gerade in Scrum.

Wir brauchen für den Wert Respekt einen Umgang miteinander, der es erlaubt mit unterschiedlichen Meinungen umgehen zu können und auch Stärken und Schwächen angemessen zu behandeln.

Mut

Scrum Werte - MutMut ist wichtig wenn wir neue Wege gehen wollen, wenn wir in unbeständigen Märkten unterwegs sind und komplexe Produkte entwickeln wollen. Ohne Mut verlassen wir keine alten, eingetretenen Wege und entdecken auch wenig neues. Doch nicht nur in Hinsicht auf das zu entwickelnde Produkt braucht es Mut, sondern auch für die eigene Organisation. Wer aus klassischen Organisationen mit starken Hierarchien kommt, muss mehr Mut beweisen, wenn er andere Wege gehen will. Innerhalb einer Organisation Neues zu versuchen bedarf ebenso mehr Mut – neue (höher in der Hierarchie angesiedelte ) Menschen müssen befragt und überzeugt werden und gerade die “Extra Mile” muss mehr und mehr gegangen werden.

 

 

13

Was ist Scrum? (und was ist es eben nicht!)

Was ist Scrum? Darum geht es!

was ist scrum

Was ist Scrum? Scrum wird als agiles Projektmanagement Framework bezeichnet. Scrum erlaubt es mit wenig Regeln und Artefakten komplexe Produkte zu entwickeln. Dabei kann Scrum in den unterschiedlichsten Branchen und Situationen angewendet werden. Dieses Framework gibt Ihnen einen groben Rahmen an die Hand, in dem entwickelt wird. Den eigentlichen Prozess aus dem Framework ableiten, das müssen Sie selbst.

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 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 auf der OOPSLA’95 den Scrum Prozess und stellte ihn vor.

2001 entstand das agile Manifest, das praktisch die Grundlage von allen agilen Methoden 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.

agiles manifest

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.

Doch was ist Scrum genau?

Scrum Werte

Die fünf Scrum Werte gehören sicherlich dazu, wenn es um die Frage geht, was Scrum ist! Denn diese Scrum Werte sind praktisch gesehen die Basis auf der Scrum aufbaut. Die Scrum Werte sind ebenso im letzten Update des Scrum Guide eingezogen, auch wenn diese schon seid dem Buch von Jeff Sutherland und Mike Beedle 2002 existierten.

  • Mut
  • Commitment
  • Fokus
  • Respekt
  • Offenheit

Das Framework

Scrum kennt drei Rollen: den Scrum Master, den Product Owner und das Entwicklungsteam. Dazu kommen drei Artefakte, nämlich das Product Backlog, das Sprint Backlog und das Inkrement. Mit fünf Events ist dann das Framework komplett, das wären der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive.

Das ist letztendlich auch das, was Scrum ausmacht. Mehr braucht es erstmal nicht, um komplexe Produkte zu entwickeln. Aber dieses Framework bildet auch nur den Rahmen. Scrum macht zum Beispiel keine Angaben darüber, wie Software zu entwickeln ist, welche Teststrategien Sie fahren sollten oder gar Angaben über Tools. Alles das ist Ihre Aufgabe, wenn Sie Scrum implementieren!

Die Rollen

Die eben angesprochenen Rollen sind im folgenden etwas genauer, aber dennoch abstrakt dargestellt. Auf die einzelnen Rollen gehe ich in separaten Artikeln ein, für das Verständnis soll es zunächst auf dieser Ebene ausreichen.

Scrum Master

Der Scrum Master

Der Scrum Master ist der Hüter des Prozesses. Er ist derjenige, der sicherstellt, dass alle Scrum so benutzen können, wie es vorgesehen ist. Er moderiert Meetings und hilft beim Coaching des Teams.

Scrum Product Owner

Der 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.

Scrum Entwicklungsteam

Das Entwicklungsteam

Das Entwicklungsteam setzt das Produkt um (“wie”). Es besteht aus Mitgliedern, die in Summe alle Fähigkeiten haben, das gewünschte Produkt auch umzusetzen.

Die Artefakte

Scrum Product Backlog

Das Product Backlog

Das Product Backlog ist die einzige Liste an Anforderungen (also so eine Art Wunschzettel) was das Produkt enthalten soll. Diese stellt den aktuellen Kenntnisstand dar und ist niemals abgeschlossen, sondern bewusst lebendig.

Sprint Backlog

Das 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 dar und führt zu einem Inkrement.

Produktinkrement in Scrum

Das Inkrement

Das Produkt(Inkrement) wird am Ende eines Sprints immer vorgeführt und zeigt den Stakeholdern und dem Product Owner eine funktionierendes Inkrement des zu entwickelnden Produktes, das live erlebt werden kann.

Die Events

Die Events sind die vier existierende Meeting und der Sprint. Das Backlog Refinement wird im Scrum Guide nicht als einzelnes Meeting aufgeführt. Meine Erfahrungen zeigen, es macht sehr wohl Sinn das als solches wie die anderen Meetings zu etablieren. Deshalb führe ich es hier mit den Events auf und Sie finden sechs, statt fünf Events hier.

Sprint Scrum

Der Sprint

Der Sprint stellt den zeitlichen Rahmen zur Verfügung, in dem Scrum durchgeführt wird. 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.

Scrum Sprint Planning

Das Sprint Planning

In der Sprint Planung wird festgelegt, was in dem kommenden Sprint umgesetzt wird. Dabei wird das Planning in zwei Teile aufgeteilt: einem ersten Teil der beschreibt, “was” umgesetzt werden soll und einem zweiten Teil der beschreibt, “wie” etwas umgesetzt werden soll.

Daily Scrum Kommunikation

Das Daily Scrum

Das Daily Scrum dient der Entwicklung für ein kurzes Statusmeeting in dem jedes Teammitglied die anderen Teammitglieder mit drei kurzen Fragen auf den aktuellen Stand bringt. Der Scrum Master sammelt hier erste mögliche Hindernisse (Impediments) ein.

Sprint Review

Das Sprint Review

Im Sprint Review wird auf das Erreichte im im Sprint zurückgeblickt und alles was funktioniert und fertig wurde vorgestellt. Wichtig dabei ist die Definition of Ready. Sie regelt, wann ein Eintrag aus dem Backlog als fertig gilt.

Retrospektive

Die Sprint Retrospektive

In der Sprint Retrospektive wird der aktuelle Sprint hinsichtlich Zusammenarbeit, Infrastruktur, … (grob: der Prozess) betrachtet und Verbesserungen abgeleitet. Eine Verbesserung wird im nächsten Sprint angegangen und versucht umzusetzen.

Backlog Refinement Toolbox

Das Backlog Refinement

Im Backlog Refinement werden die Anforderungen aus dem Backlog verfeinert. Dabei werden diese geschnitten, geschätzt und mit Akzeptanzkriterien versehen.

Was gibt es sonst noch in Scrum?

Scrum Vision

Die (Produkt) Vision

Die Vision wird zusammen mit dem Kunden erarbeitet und skizziert ganz grob, wo das Vorhaben hingehen soll. Dabei gibt es unterschiedliche Möglichkeiten eine solche Vision zu visualisieren. Oft wird ein klassisches Flipchart mit vier Sätzen gebildet, oft aber auch eine Art Canvas mit einer Struktur genutzt. Wichtig ist, aus der Vision wird das Product Backlog abgeleitet.

Impediment list

Impediment List

Die Impediment List – eine Liste mit allen Hindernissen – wird vom Scrum Master gepflegt und abgearbeitet. Diese Hindernisse behindern das Team an einer optimalen Arbeitsweise. Folglich können die Hindernisse auch unterschiedlicher Natur sein.

DoR DoD

Definition of Done

Die Definition of Done beschreibt wann ein Eintrag als erledigt gilt. Dabei kann es durchaus auf verschiedenen Ebenen mehrerer solcher DoD’s geben. Sie wird vom Team und Product Owner zusammen definiert und festgeschrieben.

DoR DoD

Definition of Ready

Die Definition of Ready beschreibt, wann ein Eintrag aus dem Backlog fertig für die Planung ist. Das wird zwischen dem Product Owner und dem Team definiert und festgelegt.

Was ist Scrum und was eben nicht?

Bis jetzt haben wir nun einen ersten Eindruck davon, was ist Scrum. Wichtig ist es aber auch ein Augenmerk darauf zu legen, was Scrum eben nicht ist. Hier zeige ich gerne mal meine favorisierten Aussagen, die natürlich etwas plakativ und überspitzt dargestellt werden, aber vom Grundsatz so vorgekommen sind.

Scrum ist ein Plug & Play für das Projektmanagement

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.

Scrum ist ein Silverbullet und ermöglicht phänomenale Einsparungen

Scrum funktioniert überall dort gut, wo Sie komplexe Produkte entwickeln wollen oder müssen. Wenn Sie zum Beispiel das Gegenteil (einfache oder komplizierte Produkte) 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 benötigen wir nicht mehr in Scrum

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.

Was ist Scrum für Sie?

Wie sehen Sie das Thema Scrm für sich? Was wäre, wenn ich Ihnen die Frage stellen würde, “was ist Scrum?” – wie lautet dann Ihre Antwort? Gerne in den Kommentaren!