Podcast Transkription

Scrum ist nicht neu. Die Ursprünge von Scrum reichen weit in die 80er Jahre hinein, als Toyota mit seinem „Toyota Production System“ neue Wege ging und das später so genannte „Lean-Manufacturing“ begründete. Viele agile Strömungen und Methoden sind seit dem entwickelt worden, wobei Scrum, welches eigentlich auch nur eine Zusammenfassung von „Best practices“ darstellt, aktuell die bei weitem am meisten verwendete ist.

Alle agilen Methoden basieren auf denselben Werten und bedeuten im allgemeinen tiefgreifende Änderung der Unternehmenskultur, was bei der Einführung auch eigentlich die Schwierigkeit darstellt.

Der „PDCA-Kreislauf“, worüber wir schon gesprochen haben, basiert letztlich auf einer bereits 1620 von Francis Bacon beschriebenen wissenschaftlichen Methode, die man als „Hypothese, Experiment, Evaluation“ zusammenfassen kann (Francis Bacon: Novum Organum).

Man kann also wirklich nicht behaupten, dass Scrum nur „neumodisches Zeug“ ist…

Nun reden alle über Scrum, aber warum wollen es viele machen (oder meinen es machen zu müssen)? Also starten wir mit einem Vergleich: 5 Gründe, warum Scrum besser als Wasserfall ist:

Grund Nummer 1: Der Realität ins Auge sehen

Projekte starten im Allgemeinen in einem Flow des Optimismus. Wir glauben, dass alles funktionieren wird  – wenn wir einmal alle Anforderungen aufgenommen und spezifiziert haben – und das auch im Vertrag geregelt ist, dann wird schon alles funktionieren…

Die Realität sieht leider meistens anders aus. Wenn das Projekt fortschreitet, stellen wir gewöhnlich fest, dass Anforderungen missverstanden werden oder Lösungen komplexer sind, als zunächst angenommen. Das Festpreisangebot für den festgeschriebenen Scope ist daher nicht mehr erreichbar, ohne Kompromisse bei der Qualität zu machen…was natürlich niemand will…

Die Praxis in hunderten von Projekten hat gezeigt und ich kann das bei meine Projekten, die ich als Projektmanager gemacht habe, bestätigen: Es ist naiv zu glauben, dass das, was der Kunde am Anfang an Anforderungen und Vorstellungen in seinem Kopf hat, auch genauso vom Dienstleister oder Entwickler verstanden wird.…daher kommt es bei der Präsentation der Ergebnisse nach einem langen Zeitraum (also klassisch nach der Konzept- und Realisierungsphase) oft zu unangenehmen Überraschungen…Und es kommt noch schlimmer: selbst wenn die Kommunikation im Projekt außergewöhnlich gut läuft und alles genau so realisiert wird, wie der Kunde es verstanden hat, kann man nicht davon ausgehen, dass der Kunde am Anfang des Produkts überhaupt in der Lage war zu beschreiben, was er am Ende des Projekt wirklich braucht. Das liegt nicht an der Dummheit des Kunden, sondern an der Tatsache, dass wir auf dem Weg lernen und Erfahrungen machen, die wir nunmal am Anfang nicht haben. Das hat sich ja auch in einem Sprichwort manifestiert, dass wir alle kennen: “Hinterher ist man immer klüger”…nur warum glauben wir das im Projektmanagement nicht?

Die Tatsache ist, dass Änderungen unvermeidlich sind. Fataler Weise gehen klassische Projektmanagement-Methoden davon aus, dass wir alle Eventualitäten im Voraus festlegen können (wenn wir nur intensiv genug darüber nachdenken) und dass wir Verständnis und Kundenbedürfnisse mit Dokumenten kommunizieren können und dass wir das auch noch mit einem Abnahmeprozess festschreiben und fest kalkulieren können.  Da das eigentlich noch nie wirklich funktioniert hat, müssen wir anerkennen, dass wir hier anders vorgehen müssen.

Grund Nummer 2: schneller sein…

Probleme bauen sich typischerweise in einem traditionellen Projekt über die Laufzeit auf und treten dann in der Testphase zu Tage. Die Testphase startet sehr spät, wenn alle Teilentwicklungen integriert sind. Der Nutzen kann also erst am Ende des Projekts generiert werden.

Scrum-Teams sammeln die Anforderungen nur so lange, bis verwertbare Bestandteile entwickelt werden können und setzen sie dann um. Dabei sollen die wichtigsten, fundamentalsten aber auch einfachsten Anforderungen zuerst umgesetzt werden. Ein Nutzen wird dann bereits mit dem ersten Sprint erreicht.

Die „Time to Market“ wird radikal gesenkt und es können sofort erste Kundenfeedbacks eingeholt werden. Die weiteren Entwicklungen können auf das Feedback reagieren, so dass der Kunde genau die Funktionen oder Features bekommt, die er wirklich benötigt.

Grund Nummer 3: Qualität bereits eingebaut:

Das klingt etwas provozierend, doch es ist ja so: Wenn Entwicklungs- und Testphasen zeitlich sehr weit auseinander liegen, dann dauert der Fehlerfindungsprozess auch sehr viel länger. Wenn die Tests in einem 2 Wochensprint integriert sind, bist Du als Entwickler gedanklich ja noch voll im Thema und findest den Fehler auch viel schneller. 

Aber Scrum-Teams gehen natürlich noch viel weiter: Automatische Regressionstests stellen sicher, dass die Weiterentwicklung auf Basis des bestehenden Codes funktioniert. Falls Du Product-Owner bist, solltest du aber auch darauf achten, dass genügend Zeit für die Erstellung solcher Testfälle besteht und das auch geplant wird (also auch Userstories dafür geschrieben werden). Schaffe also Dir selbst den Freiraum, die Säge zu schärfen, damit du den Baum schneller fällen kannst…

Scrum-Teams lassen nichts ungetestet. Der Code ist immer zu 100% getestet. Im Zweifel werden eher Funktionen weggelassen als Funktionen ungetestet auszuliefern. Daher gibt es am Ende keine „technologischen Schulden“, da der Fokus auf Qualität liegt.

Grund Nummer 4: Wir können jederzeit aufhören!

Im klassischen Umfeld quasi undenkbar, in Scrum sollte es jedoch Alltag sein: da wir kontinuierlich Nutzen liefern, steht uns jederzeit die Entscheidung offen, das Projekt zu beenden – nämlich dann, wenn der Nutzen für den Kunden erreicht worden ist…Was bedeutet das? Die Anwendung des Pareto-Prinzips: Du kennst das wahrscheinlich aus Deiner eigenen Erfahrung auch: um 80% des Nutzens zu errreichen brauchst Du eigentlich nur 20% des Aufwandes reinzustecken. Der Teufel liegt im Detail, die nächsten 20% bis zur 100% Umsetzung verschlingen dann 80% des Aufwandes. Nun muss man das nicht wörtlich nehmen, doch Du solltest immer bedenken: Brauchen wir das Feature wirklich im neuen Release oder kann das auch noch später kommen – vielleicht stellt sich heraus, dass wir es gar nicht mehr benötigen. 

Immerhin – nach einer Studie der Standish Group enthält Software wie Excel zu 64% Funktionen, die von den meisten Menschen selten oder gar nicht benötigt werden. Und etwas zu entwickeln, was hinterher niemand braucht, ist Verschwendung  – und die wollen wir vermeiden!

Grund Nummer 5: Bessere Planung

Es gibt eine Menge Fehlinformationen zu agilen Projekten. Wenn man das erste Mal davon hört, könnte man leicht denken, dass agil gleich planlos ist.

Doch genau das Gegenteil ist der Fall:

Die traditionelle Projektplanung an Hand von Gantt-Diagrammen und Statusreports reflektiert nicht den wirklichen Nutzen des Projekts, sondern macht nur den Fortschritt gegenüber dem Plan deutlich. So bleibt es sehr lange völlig intransparent, ob ein geplanter Nutzen auch wirklich erreicht wird. Im schlimmsten Falle wird ein Projekt komplett „grün“– also in Time, in der gewünschten Qualität und im Budget umgesetzt um dann zu merken, dass das, was da umgesetzt worden ist, gar nicht das ist, was wirklich gebraucht wird.

Um es mal zu verdeutlichen: im klassischen Projektmanagement gibt es zu Beginn des Projekts eine Planungsphase und dann wird dazu übergegangen, diesen Plan zu verfolgen. Erst wenn es erkennbare und nicht mehr zu leugnende Abweichungen vom Plan gibt, wird der Plan angepasst. Die Plananpassung gilt hierbei als etwas schlechtes.

Im agilen Projektmanagement gibt es hingegen 5 Planungshorizonte, die eine große Transparenz und Flexibilität erzeugen – diese Horizonte reichen von täglich bis zu mehreren Monaten oder Jahren:

1. Daily-Standup
2. Sprintplanung 
3. Product Backlog 
4. Releaseplan 
5. Vision

Also hier nochmal die Planungshorizonte…

• täglicher Horizont: Im Daily-Standup oder DailyScrum wird jede einzelne Aktivität täglich vom Team geplant und aktualisiert. So ist im gesamten Team Transparenz über den Stand der Arbeit gewährleistet.
• wöchentlicher Horizont 1 – Sprintplanungsmeeting: In der Sprintplanung planen Product Owner und Dev.-Team die Arbeitspakete für die kommende Iteration. Die Betroffenen planen also selbst, so kann man immer besser lernen und Planabweichungen werden mit der Zeit immer selterner.
• wöchentlicher Horizont 2 – Backlog Refinement: Die weitere Gestaltung des aktuellen Produkts planst Du als Product Owner im Refinement Meeting zusammen mit dem Team, so dass auch später kommende Aufgaben schon mit vorbereitet werden können.
• Horizont über mehrere Monate – Releaseplan: Die weitere Releaseplanung wird vom Product-Owner zusammen mit Stakeholdern, Produktmanagern über die nächsten Monate vorgenommen.
• Horizont über mehrere Monate oder auch Jahre – Vision: In der Vision kannst Du das endgültige Potenzial des Produkts planen. Der zeitliche Horizont kann hier über die nächsten Jahre gehen. Wichtig ist, dass ein gemeinsames Bild entsteht, was man zukünftig erreichen will.

Fazit: Scrum oder nicht Scrum?

Die Frage, ob Du nun Scrum anwenden sollst oder lieber nicht, solltest Du nicht einfach nur aus dem Bauch oder nur entsprechend aktueller „Modeerscheinungen“ beantworten. Bei bestimmten Aufgabenstellungen hat die klassische Projektmethode „Wasserfall“ durchaus ihre Vorteile und Existenzberechtigung. Um eine Einschätzung auf die eigene Situation zu vereinfachen, kannst Du dir einen „Schieberegler“ vorstellen, der dort hingeschoben werden kann, wo er in der aktuellen Situation in deiner Firma oder im Projekt am besten die reale Welt beschreibt. Die beiden Enden des Schiebereglers sind natürlich immer die Maximalwerte – in der Realität wird alles irgendwo dazwischen liegen.

Stell Dir also einen Equalizer vor, der 5 Schieberegler zu folgenden Themen hat:

•    Schieberegler Kultur: Ist es zum Beispiel bei Euch üblich in partnerschaftlichem Verhältnis zusammen mit Kunden oder Auftraggebern Anforderungen umzusetzen, regelmäßig Feedback zu geben und sich gegenseitig zu engagieren   ODER  herrscht ein Arbeitsklima der Abgrenzung, der Skepsis gegenüber der Leistungsfähigkeit des Partners und der Kontrolle bzw. Beschuldigung?

•     Schieberegler Time-To-Market: Sind die Aufgabenstellungen durch schnelle technische Weiterentwicklungen im Markt ständigen Schwankungen ausgesetzt ODER haben wir es mit (z.B. gesetzlichen) Anforderungen zu tun, die sich überJahrzehnte nicht grundsätzlich ändern werden?

•     Schieberegler Organisation: Wie ist Deine Firma organisiert? Wird in traditionellen Hierarchien gearbeitet, in denen Abteilungsleiter ihre Teams nach fachlichen Funktionen gruppieren und eine Zusammenarbeit zwischen verschiedenen Abteilungen eher selten vorkommt ODER wird bereits eine Form von „Soziokratie“ gelebt, in der kleine übergreifende Teams in selbstorganisierten Inseln ihre Aufgaben bearbeiten?

•    Schieberegler Technologie:  Haben wir es mit technologischen Rahmenbedingen zu tun, die schnelle Änderungen an den Systemen verhindern – wie z.B.monolithische Systeme, in denen Änderungen über bürokratische ChangeRequest-Verfahren langwierig beantragt werden müssen und vielfältigen Sicherungs- und Kontrollmechanismen unterliegen ODER arbeiten wir mit schnellen, kleinen, komponentenbasierten Systemen, die quasi „am offenenHerzen“ – also im laufenden Betrieb geändert werden können?

•  Schieberegler Markt:   Wie ist die aktuelle Marktsituation in Deiner Firma? Ist es überlebenswichtig schnell neue Produkte am Markt zu platzieren ODER ist die Produktpalette eher auf „commodities“ ausgerichtet, die sich nicht wirklich ändern (wie z.B. In der Versorgungsindustrie)?

Je nachdem, wo bei Dir der Schieberegler steht, wird die Scrum-Einführung schwerer oder leichter fallen. Die Entscheidung sollte sich aber nicht nur stoisch an der gegebenen Situation ausrichten, sondern in die Zukunft gerichtet sein. Grundsätzlich gilt aus meiner eigenen Erfahrung: je unbekannter das Produkt oder zu erreichende Ergebnis, und je unsicherer die Gesamtsituation und je größer der Druck der Konkurrenz am Markt, desto eher eignet sich Scrum zur Umsetzung von Projekten und dementsprechend zur Lösung der dringendsten Probleme in Deinem Unternehmen.

Soviel zu Scrum oder nicht scrum

Ich hoffe, die Folge hat dir gefallen.

Falls Ja – bitte ich Dich mir eine Rezension bei Itunes zu geben.

Mach’s gut 

Dein agilophiler Frank

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