Agilophil-Daily Podcast Episode 04 – Was ist Scrum?

Was ist scrum und wie entwickelt es sich weiter?

Ich habe mir überlegt, ob ich überhaupt eine Folge zur Erklärung von Scrum machen soll. Ich habe bereits in den ersten Folgen Scrum ein paar mal erwähnt und einige Begriffe daraus genannt. Ich gehe eigentlich davon aus, dass Du Scrum schon kennst, insofern sollte das, was ich jetzt erzähle nicht neu für Dich sein. Daher ist es auch nicht schlimm, wenn du die Folge hier überspringst oder auch mal vorspulst. Aber letztlich habe ich mich entschieden: ich mache es einfach trotzdem – ich erkläre jetzt Scrum:

1.Bild: 2000 Jahre zurück

Um das zu tun,  bitte ich Dich gedanklich ein Experiment zu machen – falls Du gerade nicht Auto fährst – schließe die Augen und versetze dich gedanklich in die Zeit vor 2000 Jahren. (wenn Du Auto fährst, lasse die Augen bitte offen und versetze dich trotzdem in die Zeit vor 2000 Jahren)

Es ist also Winter kurz nach Beginn unserer Zeitrechnung. Überlege, was genau hier, wo Du jetzt bist, vor 2000 Jahren war. In den allermeisten Fällen wird das Wald sein, ggf. sumpfiges Gelände – es ist wie gesagt Winter, wahrscheinlich war es auch deutlich kälter als jetzt, aber auch knapp über 0 Grad und Regenwetter ist ja nicht gerade gemütlich…Dein Smartphone gibt es nicht – selbst wenn Du es noch dabei hättest, wäre es sinnlos, denn es gibt weder ein Netz noch einen Tarifanbieter dafür…

Die Frage ist nun: was machst Du? Du bist plötzlich 2000 Jahre zurückkatapultiert worden und sitzt nun in einem winterlichen Wald und es ist kalt. Nach dem ersten Schock wirst Du anfangen zu überlegen…Du brauchst Nahrung, Wärme und Schutz. Aber in welcher Reihenfolge…

Nun will ich hier natürlich nicht auf die psychische Belastung dieser Situation eingehen und jeder wird abhängig von der eigenen Situation vieleicht andere Prioritäten setzen, also wir nehmen einfach mal an, du hast dich entschlossen zunächst mal einen Schutz zu bauen…

Also, was machst Du?

Erstens. 1. Du überlegst, wie dieser Schutz oder vielleicht die Hütte aussehen könnte, welches Material du dazu brauchst, und welches hier zur Verfügung steht.

Die Hütte soll zunächst möglichst schnell stehen, damit du idealerweise heute Nacht schon in ihr schlafen kannst – Also Visionen von einem komfortablen Einfamilienhaus oder einem Palast scheiden in dieser Situation schon mal aus…

Zweitens 2. Du schreitest zur Tat: suchst Dir das nötige Material und baust es zusammen, so dass es am Ende die nötige Funktion hat – also vor allem den Regen und die Kälte abhalten

Drittens 3. Du probierst es aus – d.h. Du schläfst die erste Nacht in der Hütte

Viertens 4. Am nächsten Morgen schaust Du dir das Ganze nochmal an und überlegst was Du besser machen könntest – Du stellst z.B. fest, dass es an einer Stelle noch reinregnet oder der Wind durchpfeift, Du könntest Dir vorstellen, dass es gut wäre die Tür von innen zu verriegeln und so weiter und so weiter…

fünftens 5. Du beginnst wieder einen Plan zu machen, um die Verbesserungen, die Du dir überlegst hast, umzusetzen…

Deming Circle

Das war jetzt etwas vereinfacht dargestellt, aber Du wirst mir wahrscheinlich zustimmen, dass diese Art von Arbeit eine relativ „natürliche“ und menschliche ist und dass das sich seit Anbeginn der Menschheit wahrscheinlich nicht sonderlich geändert hat. In neuerer Zeit wird dieser Zyklus gerne als „Deming Cycle“ oder PDCA-Cycle bezeichnet, nach William Edwards Deming, einem amerikanischen Physiker und „Pionier des Qualitätsmanegements“. PDCA steht dabei für Plan, Do, Check, Act, also die Planen, Umsetzen, Überprüfen und verbessern.

In Scrum ist dieser Zykluns ein wesentlicher Bestandteil und der eigentliche Kern des Ganzen, denn Scrum basiert auf Iterationen, also dem Wiederholen von genau diesem zyklischen Modell. Ein Sprint bezeichnet dabei genau eine solche Iteration und ist eigentlich eine Zeiteinheit (meistens 1-4 Wochen). 

Die im Scrum-Guide beschriebenen Scrum Events verdeutlichen sehr schön die Anwendung des Deming Cycles:

Ein Sprint beginnt mit dem Planungsmeeting (also mit dem Punkt „Plan“). Das Ergebnis des Planungsmeetings ist eine Liste der Dinge, die im Sprint getan werden sollen, das sogenannte „Sprint-Backlog“. 

Der nächste Schritt ist das „Do“, also die Realsisierung der geplanten Dinge durch das Scrum-Team. Hier wird durch das Daily Standup-Meeting die Transparenz im Team hergestellt, so dass jeder weiss, was der andere tut, und wo er steht oder ggf. Hilfe benötigt. 

Am Ende des Sprints folgt das Review-Meeting, also im Deming-Cycle das „C“ für Check. Hier wird gezeigt, was das Team realisiert hat und Feedback von den Stakeholdern oder Kunden eingeholt. 

Die Frage nach Verbesserungen in der Arbeit wird in der anschließenden Retrospektive besprochen, so dass die Informationen aus dem Reviewmeeting und der Retropektive direkt wieder in das nächste Planungsmeeting einfließen können. Damit ist der Kreis geschlossen und ein neuer Durchlauf – also ein neuer Sprint kann starten.

Doch zu Scrum gehören nicht nur festgelegte Events oder Meetings, sondern auch festgelegte Rollen, die aus einem Team oder einer Ansammlung von Leuten, ein Scrum-Team machen.

Da wäre zunächst das schon erwähnte Development-Team. Das Dev.-Team besteht aus 3-9 Mitgliedern und soll all das Wissen und alle Fähigkeiten vereinigen, die zur Umsetzung der Aufgaben im Sprint benötigt werden – es soll also interdisziplinär aufgestellt sein und aus Entwicklern (Frontend-Backend), Architekten, Tester, Anwender usw. bestehen. 

Das Scrum-Team organisiert sich selbst – innerhalb des Teams gibt es keine Hierarchie oder Teamleiter-Positionen. 

Das Dev-Team ist für das „WIE“ bei der Realsisierung zuständig, also man könnte es auch umschreiben mit: Das Team ist für die Effizienz zuständig, also dafür das das was wir benötigen richtig umgesetzt wird. ( also – “die Sache richtig machen” – also mit der richtigen Technologie, ressourcenschonend usw. ).

Dazu kommt der Product Owner, der für das „WAS“ im Projekt verantwortlich ist. Der Product Owner hat die Vision des Produktes und versetzt sich in die Lage des Kunden bzw. hält Kontakt mit ihnen –  spricht auch mit ihnen. Er ist für die Effektivität zuständig also, also dass das Richtige gemacht wird um die Ziele zu erreichen oder die Probleme der Kunden zu lösen.

Die 3. festgelegte Rolle im Scrum ist die des Scrum-Masters. Die Aufgabe des Scrum-Masters ist es dafür zu sorgen, dass das gesamte Team Scrum versteht, lebt und auf Basis der agilen Werte arbeitet. Er ist dabei nicht inhaltlich unterwegs sondern kümmert sich darum auf das Team und die Zusammearbeit zu achten und darauf, dass Scrum so echt wie möglich gelebt wird. Eine weitere Hauptaufgabe des Scrum-Masters ist die Beseitigung von sogenannten „Impediments“ also Hindernissen, die das Team bei der Arbeit behindern oder das Team von schädlichen Einflüssen von außen zu schützen.

Neben den Events und den Rollen ist der 3. große Block, den Scrum ausmacht, der der Artefakte, also der „Dinge, die man anfassen kann“. Das auffälligste Artefakt bei Scrum ist zweifelsohne das Taskboard. Ein Taskboard ist eine Visualisierung der Arbeit an einer Wand – für alle einsehbar, anfassbar und transparent. Letzendlich ist das Taskboard aus Kanban übernommen worden und stellt eine Tabelle dar, die nur aus 3 Spalten bestehen zu braucht: eines Spalte “offen” für alle im Sprint geplanten und noch nicht begonnenen Aufgaben. Eine Spalte “in Arbeit” für alle Aufgaben, die aktuell bearbeitet werden und eine Spalte “Fertig” für alle abgeschlossenen Aufgaben.

Das wichtigste Artefakt ist aber das Product Backlog. Das ist die geordnete Liste aller Anforderungen, die an das Projekt oder Produkt bestehen. Dabei ist das Product Backlog niemals vollständig, sondern umfasst nur den aktuellen Stand im hier und jetzt. Es ist inzwischen sehr verbreitet die Anforderungen als sogenannte “User-Stories” zu beschreiben, was auch einen gewissen Vorteil hat. Die Anforderung wird dazu in einer bestimmten Struktur beschrieben aus der klar wird: wer fordert das an (also die Rolle des Anfordernden)? Was wird angefordert (die eigentliche Anforderung) und warum wird das angefordert? (worin besteht der Nutzen darin). Allein, dass man über diese 3 Punkte nachdenken muss, um eine Userstory zu schreiben, hilft schon sehr dabei Unsinniges sofort von Sinnvollem unterscheiden zu können. Zum Thema Userstories wird es aber noch eine gesonderte Folge geben..

Das Product Backlog wird vom Product-Owner verantwortet. Das bedeutet nicht, dass er oder sie alle Userstories oder Anforderungen selbst schreiben muss, sondern er oder sie ist dafür verantwortlich wie sie im Produkt Backlog stehen, wie sie sortiert oder priorisiert sind, was zuerst umgesetzt werden soll und was zu einem MVP  – also zu einem minimal valuable product oder zum nächsten Release gehört und was nicht. Das Product Backlog ist sozusagen der Speicher für das “WAS” im Projekt und das Product Backlog bestimmt letztlich wie die Arbeitsleistung des Teams am besten zum Wohle des Unternehmens eingesetzt werden kann. 

Bedenke immer, wenn Du Product Owner bist: die Mitglieder des Dev.Teams arbeiten (im allgemeinen) immer gleich gut, sie verdienen immer gleich viel, jeden Monat dasselbe. Du bestimmst aber welchen Wert sie für das Unternehmen darstellen und ob sie in der Zeit etwas sinnvolles machen oder nicht!

Ein weiteres Artefakt ist das Sprint Backlog – das habe ich eben schon mal erwähnt. Das Sprint-Backlog stellt eine Teilmenge des Product-Backlogs dar, nämlich der Teil der Anforderungen, der im nächsten Sprint umgesetzt werden soll.

Das Product-Increment ist ein weiterer Artefakt: Das Increment stellt ein funktionierendes kleines Produktbestandteil dar, welches nach Ende des Sprints genutzt werden kann. Hier wird Mehrwert oder Nutzen für den Kunden geschaffen – das ist immer das Ziel!

Das Burn-Down Chart wurde früher ebenfalls als Artefakt genannt, ist aber aus dem aktuellen Scrum-Guide wieder verschwunden. Das liegt daran, dass das Burn-Down-Chart zu oft zu Missverständnissen geführt hat und von Managementkreisen zu unzulässigen Bewertungen über die Teamleistung herangezogen wurde. Trotzdem ist das Burn-Down Chart nicht verboten. Es ist ein Diagramm, welches die Restarbeit im Sprint darstellt (als Anzahl von Anforderungen oder Aufwänden) und läuft im Idealfall als fallende Gerade vom Sprintstart bis zum Sprintende um am Ende die 0 zu erreichen (also keinen Rest mehr). Das große Problem beim Burn-Down-Chart ist, dass dieser ideale Verlauf nie eintritt und das oft damit verbunden wird, dem Team eine schlechte Leistung zu attestieren. Es kann aber dem Team durchaus dabei helfen, sich selbst besser zu organisieren. Hier ist der Scum-Master gefragt und seine Aufgabe wäre es, die Bedeutung des Burn-Down-Charts für das Team zu verständlich zu machen und auch dem Management die Gefahr bei Vergleichen oder Veröffentlichen von Burn-Down-Charts zu verdeutlichen. Es geht am Ende darumh das Team vor einer Mißinterpretation durch das Management zu schützen.

So weit erstmal zu den 3 Großen Bereichen in Scrum: Den Events, den  Rollen, den Artefakten.

Beschrieben wird praktischerweise alles im offiziellen Scrum-Guide (die letzte Version stammt bei Aufnahme dieses Podcasts aus dem November 2017).

Der Scrum-Guide wurde erstmals 2010 veröffentlicht und auch er unterliegt einer Evolution, wie es   bei agilen Projekten üblich ist. So ist es interessant, wie sich der Scrum-Guide im Laufe dieser Jahre verändert hat.

Der erste Scrum-Guide wurde im Februar 2010 veröffentlicht

Hier wurde noch sehr viel Wert auf die Bedeutung von Scrum als Anwendung der empirischen Prozess-Theorie gelegt und dass es ein Framework zur Entwicklung komplexer Produkte ist. Bemerkenswert ist auch, dass in der ersten Version das Release Burndown und das Sprint-Burndown als wesentliche Pflicht- Artefakte genannt werden, diese jedoch dann in den folgenden Versionen verschwinden. Zudem wird hier als 4. Säule von Scrum neben den Rollen, den Events und den Artefakten das “Timeboxen” genannt. Also der besondere Fokus auf die Einhaltung von Zeitvorgaben (z.B. beim Daily Scrum – 15min)

Die Version vom Juli 2011 kommt schon sehr Nahe an die heutige Version heran, vor allem im Aufbau: Die Definition von Scrum geht ab von der Entwicklung von komplexen Produkten hin zur Behandlung von komplexen Problemen (was natürlich eine viel breitere Anwendung von Scrum zulässt.) Ferner werden die Rollen klarer beschrieben – insbesondere der Scrum-Master als Service für den Product-Owner, das Team und die gesamte Organisation. Außerdem wird das Backlog Grooming als notwendig eingeführt – Das Backlog Grooming ist ein sehr wichtiges Meeting, welches den Blick über den Tellerrand ermöglicht. Hier wird die Vision und die später kommenden Aufgaben betrachtet und das Project Backlog überprüft und “ausgemistet”. Ein wichtiges Detail ist ferner, dass das Ergebnis der Sprintplanung nicht als commitment bezeichnet wird (was dann auch gerne als Selbstverpflichtung übersetzt wird), sondern als Forecast (also Vorhersage – die ja nicht unbedingt eintreten muss.).

Es gab noch eine weitere Version aus dem Oktober 2011, die aber keine relevanten Änderungen aufwies.

In der Version von 2013 wird der vorher verwendete Begriff Grooming geändert in Refinement, was den Sinn des Ganzen besser trifft. Das Product-Backlog soll nicht nur ausgemistet, sondern es soll den neuen Erkenntnissen angepasste werden Es soll schließlich aus dem bisherigen Projektverlauf gelernt werden.

Außerdem werden die 3 Fragen im Daily-Standup-Meeting präzisiert: es heiß nun nicht mehr: was habe ich gestern getan?- was werde ich heute tun? und was behindert mich? – sondern es geht mehr um den Teamaspekt: es heißt nun: 

• was habe ich gestern getan um dem Team zu helfen das Sprintziel zu erreichen?
• was will ich heute tun um dem Team zu helfen das Sprintziel zu erreichen?
• was hindert mich daran, dem Team zu helfen das Sprintziel zu erreichen?

Ferner entsteht nun der Gedanke, dass ein Product-Backlog Eintrag nach einem Refinement “ready for Sprint” sein soll, also soweit fertig beschrieben – also verständlich, mit Akzeptanzkriterien und vor allem klein genug, so dass es im Sprint umgesetzt werden kann.

In der nächsten Version aus dem Juli 2016 wird nun erstmals auf die Scrum-Werte eingegangen – diese Werte über die ich in der ersten Folge schon gesprochen habe, gab es zwar schon früher, aber sie waren im Scrum Guide nicht explizit erwähnt, was dazu führte, dass man das nicht als Bestandteil von Scrum interpretiert hatte. Das ist seit 2016 anders.

In der aktuellen Version von 2017 geht es vor allem darum, zu starre Formulierungen so zu lockern, dass die Teams mehr Gestaltungsfreiheit bekommen. Es wird verstärkt Wert auf den Aspekt des Wissenstransfers im Team gelegt, die 3 Fragen aus dem Daily-Scrum werden bezeichnet als nur eine Möglichkeit das Meeting zu strukturieren. Die Rolle des Scrum-Masters wird von einem Scrum-Polizisten mehr in Richtung Scrum-Coach gelenkt, der dem Team hilft Scrum zu verstehen und nicht nur die Regeln durchsetzt. Ebenfalls den Scrum-Master betrifft die Vorgabe für eine Retrospektive mindestens eine konkrete Maßnahme zu benennen, die im nächsten Sprint direkt umgesetzt werden soll um die Teamarbeit zu verbessern.

Links zur Folge:

Der Scrumguide in der aktuellen Version ist zu finden auf:
https://www.scrumguides.org

Die Weiterentwicklung des Scrumguides basiert auf einem Blog-Beitrag von Paddy Corry auf „medium.com“ („The evolution of the Scrum-Guide ‘10-‘19)
https://medium.com/serious-scrum/the-evolution-of-the-scrum-guide-10-to-19-f3ac4d82cfcb