Was ist Scrum?
Stakeholder eines Unternehmens: Ich hätte das gerne bis morgen erledigt.
Entwickler: Da wir in Scrum arbeiten, können wir das nicht früher als im nächsten Sprint fertig kriegen, sorry. Und bitte kontaktiere dann noch unseren Product Owner, um deinem Wunsch nachzugehen.
Oftmals beginnt so die Reise: Scrum, Sprint, Product Owner mit einer Vielzahl anderer seltsam klingender Terminologien.
Stakeholder eines Unternehmens: Und warum wollen sie meine Aufgabe für morgen nicht fertig stellen
Product Owner: Nun, sie werden es einfach nicht tun. Sieh dir mal an, wie das alles funktioniert:
Scrum ist ein Framework - weder eine Methode noch eine Methodik.
Scrum wird als ein agiler Weg beschrieben, ein Projekt zu managen. Sein Hauptzweck ist es, komplexe adaptive Probleme anzugehen und produktiv Produkte von höchstmöglichem Wert und Standards zu liefern.
Wenn du den Scrum Guide, also den maßgeblichen Leitfaden für Scrum, beachtest, wirst du feststellen, dass er kein Wort über Softwareentwicklung verliert. Du kannst also sogar mit deinem Ehepartner reden und dich entscheiden, Scrum zu Hause einzuführen. Es geht um Werte, Ereignisse, Artefakte und Regeln, die Ereignisse miteinander verbinden. Egal, in welcher Abteilung du arbeitest oder was für ein Projekt du leitest.
Scrum basiert auf den Prinzipien des Empirismus, also kommt das Wissen aus Erfahrung und Entscheidungen über das, was zu jedem gegebenen Zeitpunkt bekannt ist. Scrum verwendet einen iterativen und inkrementellen Ansatz, der durch drei Säulen kombiniert wird:
- Transparenz,
- Inspektion und
- Adoption.
Dies hilft, die Vorhersehbarkeit zu erhöhen und das Projektrisiko besser zu kontrollieren. Fünf Hauptwerte kontrollieren das Risiko:
- Engagement,
- Mut,
- Konzentration,
- Offenheit und
- Respekt.
Das Hauptziel jedes Scrum Teams ist es, durch die Umsetzung der drei oben genannten Säulen Vertrauen gegenüber allen Beteiligten aufzubauen.
Wenn wir über Scrum Teams sprechen, gibt es drei Rollen - einen Product Owner, das Entwicklungsteam und einen Scrum Master.
Scrum - die Grundlagen
Der Scrum Guide beschreibt die Pflichten und Beziehungen jedes Team-Mitglieds genauer. Lass uns aber kurz auf die Rollen eingehen.
Der Product Owner wird wahrscheinlich der erste Kontakt mit der Scrum-Welt in der Softwareentwicklung sein. Der PO ist verantwortlich für die Maximierung des Produktwertes und der Arbeit des Entwicklungsteams und die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist.
Klingt einfach, oder? Es ist genau das Gegenteil. Der Product Owner ist eine Art Puffer zwischen allen Beteiligten und dem Dev Team. Außerdem müssen seine oder ihre Entscheidungen von der gesamten Organisation respektiert werden.
Niemand sonst hat die Autorität, das Entwicklungsteam zu leiten und ihnen zu sagen, dass sie mit unterschiedlichen Anforderungen arbeiten sollen. Ja, das ist richtig. Wenn du ein Mitglied des Dev-Teams bittest, etwas für dich vorzubereiten, wirst du an den Product Owner zurückgeschickt, und das ist völlig korrekt. Das Entwicklungsteam darf nur nach den Anweisungen des Product Owners handeln, und nicht nach denen der anderen.
Mit dem Entwicklungsteam scheint das ziemlich unkompliziert zu sein. Ein Team von 3-9 Profis entwickelt ein Produkt, indem es am Ende jedes Sprints potenziell freischaltbare Increments liefert. Als Team verfügen sie über alle notwendigen Fähigkeiten, um ein Produkt Increment zu erstellen, was sie funktionsübergreifend und selbstorganisierend macht, da niemand dem Entwicklungsteam sagen kann, wie man Product Backlog in Increments umwandelt.
Allerdings gibt es noch zwei weitere Dinge, die es wert sind, erwähnt zu werden. Scrum erkennt keinen anderen Titel in einem Team, außer der Rollenklassifizierung “Teammitglied”. Wenn ein Mitglied ein Programmierer, ein anderes ein QA-Ingenieur und wieder ein UX-Designer ist, werden sie trotzdem als “Entwickler” bezeichnet.
Außerdem erkennt Scrum keine Unterteams innerhalb des Entwicklungsteams an. Zu diesen Regeln gibt es absolut keine Ausnahmen.
Was bleibt also für einen Scrum Master übrig?
Überraschenderweise… Sehr viel. Der Scrum Master stellt sicher, dass alles, was oben erwähnt wurde, korrekt abläuft und dass die täglichen Routinen von Scrum akribisch befolgt werden.
Die Mehrheit der Leute findet es sehr verwirrend, dass der Scrum Master nicht die Leute managt, sondern den Prozess selbst.
Laut dem Scrum Guide hat der Scrum Master keine überlegene Macht oder Rechte, sondern ist allen anderen Teammitgliedern gleichgestellt. Diese Rolle wird gewöhnlich als dienende Führung beschrieben. Der Scrum Master dient dem Team auf verschiedene Weise, unter anderem
- Er beseitigt Hindernisse, die den Fortschritt behindern,
- den Leuten außerhalb des Teams zu helfen, zu verstehen, welche ihrer Interaktionen mit dem Scrum-Team unerwünscht sind,
- Coaching des Dev Teams in Selbstorganisation,
- das Dev Team in Cross-Funktionalität zu coachen und
- das Moderieren von Meetings.
Der Scrum Master unterstützt auch die agile Transformation in einer Organisation und teilt agiles Wissen mit den anderen. Das oben genannte ist die grundlegende Rollenbeschreibung in einem Scrum Team. Schauen wir uns weiter die Scrum Events an.
Scrum Teams arbeiten in sogenannten Sprints.
Irgendwie kann man es mit dem Laufen auf ein Sprint-Ziel zu vergleichen. Das aber in einem nachhaltigen Tempo. Der Sprint beginnt direkt nach dem vorherigen Sprintabschluss und dauert zwischen einer Woche und einem Monat. Normalerweise handelt es sich um ein- oder zweiwöchige Zyklen. Während der gesamten Dauer eines Sprints ist es nicht erlaubt, Änderungen vorzunehmen, die das Sprintziel gefährden könnten. Aus diesem Grund muss jede Anfrage für Features (mindestens) bis zum nächsten Sprint warten.
Wie funktioniert ein typischer Scrum Sprint?
Sprints dauern zwischen einer Woche und höchstens einem Monat. Sie beginnen mit der Sprintplanung, den täglichen Scrum-Meetings, der eigentlichen Entwicklungsarbeit, dem Sprint-Rückblick und der Sprint-Retrospektive. Der nächste Sprint beginnt direkt nach den Schlussfolgerungen des vorigen Sprints. Der gesamte Sprint Lifecycle ist unten abgebildet.
Eine weitere wichtige Sache bei der Arbeit in Scrum ist die Definition von “Done”. Jeder in einem Team muss verstehen, was “Done” bedeutet. Die Definition von “Done” wird verwendet, um zu beurteilen, wann die Arbeit am Produkt Increment abgeschlossen ist.
Wenn Scrum-Teams reifen, entwickelt sich ihre Definition von “Done” weiter und beinhaltet genauere Definitionen der strengen Kriterien für eine erhöhte Arbeitsqualität.
Es ist theoretisch möglich, nur Teile von Scrum zu implementieren. Jedoch wird der Output nicht Scrum sein und wird gewöhnlich als “Scrum-artige” Arbeitsweise bezeichnet.
Die Rollen, die Ereignisse und die Regeln von Scrum sind unveränderbar; daher existiert Scrum nur, wenn es vollständig eingesetzt wird.
CodeCoda-Entwicklungsteams arbeiten ausschließlich auf der Grundlage bewährter Methoden zur Verwaltung von Softwareentwicklungsprojekten. Ob Scrum oder Kanban, qualitativ hochwertige Software ist ein Muss und tief in unserer Firmenkultur verwurzelt.
