Scrum

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