Scrum

1. Einleitung
Scrum zählt zu den bekanntesten agilen Ansätzen. Auch wenn die Grundgedanken aus der Entwicklung mechatronischer Produkte stammen, war Scrum, wie es heute bekannt ist, zunächst darauf ausgerichtet, Software zu entwickeln. Ausgangspunkt für die Entwicklung von Scrum in den 1980er und 1990er Jahren war, dass eine Software-Entwicklung nicht von Anfang bis Ende präzise durchgeplant werden konnte.

Scrum – modernes Projektmanagement

Deshalb erfolgt die Produktentwicklung bei Scrum iterativ in Feedback-Schleifen von wenigen Wochen, den sogenannten Sprints. Bei jedem Sprint soll eine verwendbare Produktversion entstehen, das Inkrement – auch wenn dieses nur einen minimal zusätzlichen Funktionsumfang hat. Dieser iterativ-inkrementelle Ansatz erlaubt es dem Projektteam, auf Änderungen oder Probleme zu reagieren und Feedback von den Stakeholdern anhand eines funktionieren Produkts zu erhalten anstatt anhand von Dokumenten. Der Erfolg von Scrum bei der Software-Entwicklung führte dazu, dass mittlerweile auch andere Vorhaben mit Scrum angegangen werden, z.B. Hardware-Entwicklungen, Organisationsentwicklungen oder die Bereitstellung von Dienstleistungen.

2. Scrum
Oft ist ein erfolgreiches Projektmanagement für kleine- bzw. mittelgroße Teams eine große Herausforderung. Hierbei wird eine zentrale Anlaufstelle für die Planung und Durchführung von vielen benötigt. Diese Anlaufstelle dient für einen detaillierten Überblick über Aufgaben und vereinfacht so die Zusammenarbeit im Team.
Scrum ist ein Framework für agile Produktentwicklung und Projektmanagement, seinen
Ursprung nach es in der Softwareentwicklung und war dort sehr beliebt, bis es schlussendlich auch nicht in Softwareprojekten genutzt wurde.

3. Was ist Scrum?
Der Begriff “Scrum” kommt auf dem Rugby und bedeutet grob übersetzt “angeordnetes Gedränge” Die Erfinder Jeff Sutherland und Ken Schwaber stellten diese Methode 1955 vor.
Scrum ist eins der bekanntesten agilen Ansätze. In den 1980-1990 wurden Projekte in der Informatik nicht präzise genug von Anfang bis Ende geplant. Hierdurch entstand der Bedarf an einem System, welches hierbei helfen sollte. Diese beeinträchtigt heutzutage maßgeblich das heutige Verständnis von agiler Arbeitsweise. Die Produktentwicklung findet in sogenannten Feedback-Schleifen statt welcher Sprints genannt werden. Deren Ziel es ist in verwendbare Produktversionen umgesetzt zu werden, diese nennt man Inkrements. Durch dieses System erlaubt man dem Projektteam auf Änderungen oder Probleme zu reagieren und diese abzuarbeiten. Der große Erfolg in der Informatik hatte zur Auswirkung das Scrum sich in weitere Umfelder ausbreite wie beispielsweise der Hardware-Entwicklung.

4. Definition
Zitat: “ Scrum ist ein Rahmenwerk für die Zusammenarbeit von Teams
basierend auf einer Definition von Rollen, Meetings und
Werkzeugen, die einem Team Struktur und einen klar
definierten Arbeitsprozess basierend auf agilen Prinzipien
geben.”

Es ist keine dogmatische Methode, sondern ein Framework und bietet Orientierungspunkte für die Zusammenarbeit und Kommunikation in Teams.
Scrum wird heute von scrum.org weiterentwickelt und wird im Scrum Guide dokumentiert (Letzte Änderung Ende 2020).
Scrum ermöglicht den Teams das automatische Lernen durch Erfahrungen und Fehler. Zusätzlich hilft es bei der Problembehebung diese selbst zu organisieren und einzuordnen. Hierbei werden Erfolge und Niederlagen selbstständig reflektiert und fördert somit das selbstständige Lernen.

Scrum wird trotz allem meistens in der Softwareentwicklung genutzt doch die Prinzipien und gewonnen Erkenntnisse treffen auf alle Arten des Teamworks zu, dies ist auch der Grund warum Scrum so beliebt ist.

Scrum wird oft als agiles Projektmanagement-Framework bezeichnet und umfängt Meetings, Tools und Rollen und unterstützt das Strukturieren und Managen von Teamarbeiten.

5. Nonaka und Takeuchi
Die japanischen Wissenschaftler Ikujirō Nonaka und Hirotaka Takeuchi sind eine der bedeutendsten Forscher auf dem Gebiet des Wissenschaftsmanagements, ihr Artikel “The New New Product Development Game” welches 1968 in der Harvard Business Review erschien gilt als erster Artikel über Scrum. Dieser Beitrag legte somit den Anfang, Projektmanagement und generelle Produktentwicklung auf eine komplett neue Art zu verstehen. Nonaka und Takeuchi waren beide schon immer die Zusammenarbeit sehr wichtig, da sie laut ihnen Synergien ans Licht bringen, welche im Grunde konzentrierte Energien zur gemeinsamen Erfüllung von Aufgaben sind, die zu verborgenen Wissen führen. Zugleich führt Zusammenarbeit zu neuen unentdeckten Ideen. In ihrem Artikel beschrieben Sie als erstes das auch Vorschläge aus dem Team aufgenommen werden sollte und nicht von Oben herab entschieden werden sollte. Ebenfalls wurde hier das erste Mal die Begriffe “Scrum” und “Sprint” genutzt.

6. Scrum Master
Der Scrum Master ist dafür verantwortlich, dass das Scrum als Rahmenwerk funktioniert, er arbeitet mit dem Entwicklungsteam zusammen gehört jedoch nicht dazu. Er ist der Aufpasser über das Scrum Projekt, er führt Regeln ein und überprüft die Einhaltung seiner eingeführten Regeln. Sobald Störungen oder Hindernisse auftreten, versucht er diese zu beheben, solche Hindernisse können, mangelnde Kommunikation oder Zusammenarbeit, persönliche Konflikte unter den Entwicklern oder eine Störung in der Zusammenarbeit mit dem Product Owner, oder Probleme von außen sein. Zu seinen Aufgaben zählen ebenfalls das Moderieren der Sprint Retrospektive und des Sprint Planning sowie die Kontrolle des Backlog Refinement. Im Gegensatz zu dem Entwicklerteam ist er eine dienende Führungskraft, er gibt einzelnen Mitgliedern keine Anweisung. Zu seinen Aufgaben gehört nicht Mitarbeiter zu beurteilen oder gar disziplinieren, er ist der Coach des Prozesses.

Er beseitigt die Hindernisse, die im Weg für einen reibungslosen Ablauf des Projektes liegen. Jedoch ist der Job am Anfang nicht so leicht, denn am Anfang ist der ein Vollzeitjob da er verantwortlich ist die Abläufe und das Zusammenwachsen des Teams zu planen und kontrollieren. Ebenfalls das Einlernen in die Rollen ist schon sehr aufwändig und erfordert viel Arbeit. Sein Ziel ist im Allgemeinen Teams auszubilden, jedoch sobald das System etabliert wurde, kann er seine Rolle als Change-Manager wahrnehmen und nachgehen.

7. Das Framework
Scrum benötigt die völlige Hingabe des gesamten Teams, um auf neue Denkansätze für den Kunden zu kommen und diese auszuarbeiten. Das Framework hilft bei der Bewältigung von schweren Aufgaben und hilft mit neuen Denkweisen und diese zu verfolgen und unterstützt bei der täglichen Kommunikation sowie der Bewältigung von täglichen Aufgaben aufgrund der Agile-Grundsätze. Scrum wird als heuristisches Framework bezeichnet da es auf kontinuierlichem Lernen und steigen Anpassen an ändernde Faktoren basiert.
Jedoch berücksichtigt das Framework das Teams nicht auf Anschlag alles wissen und sich nur durch Erfahrungen weiterentwickelt. Scrum wurde so aufgebaut, dass Teams neue Bedingungen bzw. Anforderungen selbst anpassen können.
Durch ständige Updates hilft es das Team dauerhaft zu verbessern und dass es selbstständig dazulernt.

8. Agiles Projektmanagements

Es gibt kein einheitliches Verständnis des agilen Projektmanagements. Es ist eigentlich ein Oberbegriff für verschiedene Vorgehensmodelle, beispielsweise Scrum oder Extreme Programming. Es bezeichnet die Vorgehensweise des Projektteams welches über hohe Toleranzen für Qualitäten, allgemeinen Umfang, Zeit und Kosten verfügt.

9. Drei Artefakte
Die drei Artefakte werden erstellt wie Tools zum Lösen von Problemen. Bei den Artefakten handelt es sich um
Product-Backlog
Sprint-Backlog
Inkrement

Hierbei werden die Ziele selbst bestimmt.

9.1. Product-Backlog
Das Product-Backlog ist hier die Hauptliste mit den zu erledigenden Aufgaben im Projekt, dieses wird von dem Product Owner oder dem Produktmanager verwaltet und gepflegt. Das Backlog ist eine dynamische Liste an Features, Anforderungen, Verbesserungen und Fehlerbehebungen und fließt in das Sprint-Backlog ein. Im Grunde ist so ein Dokument eine “To-do-Liste” des Teams auf welches fortlaufend zurückgegriffen wird und ständig neu priorisiert wird. Die Verwaltung darüber wird von dem Product Owner übernommen da, wenn Erkenntnisse gewonnen werden oder sich der Markt ändern sind womöglich manche Aufgabenelemente nicht mehr relevant oder Probleme auf andere Weise lösbar.

9.2. Sprint-Backlog
Das Sprint-Backlog ist die nächste Etappe der drei Artefakte, hier wird in Sprint Planning Meetings durch den Product Owner erklärt welche Product-Backlog Items die höchste Priorität genießen und was zuerst abgearbeitet werden soll.

Das Entwicklerteam legt hierbei fest wie viele User Stories in Springt jeweils bearbeitet werden sollten, der Product Owner kann hierbei Wünsche einbringen jedoch entscheidet das Entwicklerteam schlussendlich selbst welche Vorschläge übernommen werden und welche nicht möglich sind oder nicht zum Thema passen.

Diese Product-Backlog Items werden in diesem Stadium zu Aufgaben umformuliert und den jeweiligen Sprints zugeordnet. Alle Aufgaben zusammen werden zu Aktivitäten zusammengefasst, Aufgaben jedoch dürfen aufgrund der Effizienz nicht länger als ein Tag dauern, somit werden täglich Aufgaben abgeschlossen und Probleme fallen sofort auf und können in Angriff genommen werden. Je nach Status der Aufgabe werden diese physisch in Drei Spalten eingeteilt:
To Do
Doing
Done

Sollte eine Aufgabe länger als Ein Tag in Doing sein, liegen anscheinend Probleme in der Abarbeitung der Aufgaben, hierdurch entsteht ein Fluss im Arbeitszyklus dem sogenannten “Flow”. Ein Sprint-Backlog wird als “lebendes” Dokument bezeichnet da es dauerhaften Wandel durchmacht durch Bearbeiten bzw Ergänzen der Aufgaben.

9.3. Inkrement
Das Inkrement ist das dritte Artefakt. Dieser Begriff entspringt aus dem Latein und bedeutet “Zuwachs” beziehungsweise “vergrößern”. Dieser Schritt ist im Grunde ein potenzielles aus lieferbarem Produkt (eng. “potentially releasable”) welches am Ende eines Sprints nach dem “Done” Status entsteht. Die Aufgabe jeden Sprints ist somit ein “auslieferbares” Produkt zu erzeugen. Ein Inkrement ist kein Endprodukt, sie bauen aufeinander auf und vergrößern somit das Endprodukt immer weiter.

9.4. Ziele
Das Produkt soll nicht am Ende jedes Sprints ausgeliefert werden da es nur potenziell ist. Es umfasst alle Items aus dem Product Backlog und ist immer das letzte Produkt im aktuellen Release-Status. Sollten Hindernisse oder gar ein Abbruch voraus stehen so hat man nach jedem Sprint ein “fast” fertiges Produkt, welches vorgezeigt werden kann.

9.5. Zuständigkeit
Das Entwicklerteam ist für eine Übergabe an den Product Owner zuständig welcher daraufhin entscheidet, ob das Produkt Release fähig ist oder noch weitere Arbeit benötigt

10. Rollen in Scrum
Der Scrum Guide definiert hier drei Rollen:

  • Scrum Master
  • Product Owner
  • Entwicklungsteam

Alle drei Rollen zusammen ergeben das Scrum Team. Scrum Master und Product Owner werden mit einer Person besetzt. Das Entwicklungsteam sollte funktionsübergreifend zusammengesetzt werden, sodass es ohne Hilfe die Elemente des Product Backlogs bearbeiten kann. Als typische Größe des Entwicklungsteams gibt der Scrum Guide drei bis neun Personen an. Der Scrum Master ist für die Implementierung von Scrum und die Einhaltung der Regeln im Team zuständig. Er ist verantwortlich dafür, möglichst gute Bedingungen für das Team zu schaffen und unterstützt es bei der Selbstorganisation. Als Schnittstelle zur Organisation ist er dafür verantwortlich, das Team Umfeld zu verbessern, also die umgebende Organisation Schritt für Schritt zu verändern, damit das Scrum Team seiner Aufgabe besser nachkommen kann.

10.1. Product Owner
Der Product Owner verantwortet den wirtschaftlichen Erfolg des Produkts. Er ist verantwortlich für das das Product Backlog und somit für die Ausprägung des Produkts, Zeit, Kosten und über die Priorisierung qualitätsrelevanter Aspekte. Er steht in Kontakt mit den Stakeholdern und gibt regelmäßig Feedback an das Entwicklungsteam.

10.2. Entwicklungsteam
Das Entwicklungsteam entwickelt das Produkt und ist für die die technische Ausprägung und die Produktqualität verantwortlich. Es setzt die Anforderungen aus dem Product Backlog selbstständig um. Das Entwicklungsteam verantwortet dadurch das “Wie”.

10.3. Ereignisse (Events) in Scrum
Charakteristisch für Scrum sind die fünf vorgegebenen Ereignisse die Events, die den zeitlichen Rahmen für die Arbeit mit Scrum spannen. Das übergeordnete Event ist der Sprint, der die anderen vier Events umfasst:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint-Retrospektive

Alle Events haben fixierte Starttermine bzw. -zeiten und somit eine definierte maximale Dauer, die nicht überschritten werden soll. Sowohl im Sprint wie auch in den vier anderen Events kann sich das Scrum-Team selbst verbessern und lernen, was möglich ist und was nicht. Die harte Taktung verringert die Komplexität und schafft verlässliche Synchronisationspunkte mit Stakeholdern und der umgebenden Organisation.

11. Vor und Nachteile von Scrum
In den vergangenen Jahren gab es einen regelrechten Hype um Scrum als Methode im agilen Projektmanagement. So ist das Framework beispielsweise zwar für mittelgroße bis große bzw. komplexe Projekte geeignet, doch in kleinen Projekten kann die iterative Arbeitsweise in Sprints sogar zu unnötigen Zeitverlusten gegenüber klassischen Methoden führen. Hier ein kurzer Überblick über die zentralen Vorteile und Nachteile von Scrum.

11.1. Vorteile:

  • Wenige Regeln, leicht verständlich und schnell einführbar
  • Kurze Kommunikationswege
  • Hohe Flexibilität/Agilität durch adaptives Planen
  • Hohe Effektivität durch Selbstorganisation
  • Hohe Transparenz durch regelmäßige Meetings und Back Logs

11.2. Nachteile:

  • Kein Gesamtüberblick über die komplette Projektstrecke
  • Hoher Kommunikations- und Abstimmungsaufwand
  • Wenige konkrete Handlungsempfehlungen
  • Zeitverluste bei zu „defensiven“ Sprintplanungen
  • „Tunnelblick-Gefahr“ bei ausschließlicher Fokussierung auf Tasks

Am Ende lässt sich sagen, dass das Einführen von Scrum als Framework für agile Entwicklungsprozesse vorher genau überlegt werden muss.

Denn Scrum passt nicht immer und bei jedem, für das Unternehmen erfordert es genau dann zunächst einmal ein großes Umdenken, wenn dieses zuvor ausschließlich auf Top-down-Prozesse gesetzt hat. Man sollte sich als stets über die Vor- und Nachteile bewusst sein.

12. Alternatives Modell Kanban

12.1. Was ist Kanban
Kanban gilt heute als eins der einfachsten und schnellsten umsetzbaren Prozesse in der Modere, genau wie Scrum genießt Kanban eine große Beliebtheit. Dabei werden die Arbeitsschritte und Workflows in sogenannte unkomplizierte Schemen eingefügt. Dies Visualisiert die Aufgaben aller Beteiligten noch einmal. Bei Kanban geht es um die Grundpfeiler aller agilen Methoden, Effizienz und Transparenz.

12.2. Herkunft und Bedeutung
Entwickelt wurde Kanban von Taichi Ohno für den Autokonzern Toyota 1947, es sollte eine Kampfansage gegen die großen Lagerbestände werden, welche die Vorratshaltung teuer gestaltet. Ohno dachte sich daher ein Konzept für kurzfristige Dispositionen und Reduzierungen von Beständen aus. Kanban war geboren. Schlussendlich musste dieses System getestet werden, deswegen hat er sich an Supermarkteinkäufen orientiert, bei diesen entnimmt man Ware bestimmter Art in bestimmten Mengen aus dem Regal welche nachgefüllt werden. Aus diesem Grund gibt es in Kanban sogenannte Karten, welche den Abteilungen signalisiert welche Anzahl von welchem Produkt nachproduziert werden müssen. Der Begriff Kanban bedeutet daher in Japanischen einfach Karte oder Tafel. In Japan wurde Kanban zu einem schnellen Erfolg, weshalb sich das System in den 1970 Jahren bis nach Europa und die USA ausbreitete.

13. Fazit
Scrum ist ein ausgezeichnetes System, wenn man für seine Projekt ein System braucht, um alles zu organisieren. Der Scrum Master hat hierbei eine große Verantwortung, gerade zum Anfang muss er sich um sehr viel kümmern und seinen Job gut machen. Jedoch wenn die Vorarbeit richtig erledigt, wurde dann wird das Projekt vereinfacht und führt zu großen Erfolgen