In diesem Artikel erklären wir, wie Scrum und Empirie zusammenhängen, was Empirie bedeutet und warum Empirie so wichtig ist für Scrum. Unter anderem klären wir auch folgende Fragen:
Was benötigen wir dafür, dass Empirie in Scrum funktioniert? Was hat das mit den Scrum Events und Scrum Artefakten zu tun? Was hat Empirie mit Transparenz, regelmäßiger Überprüfung und Anpassung (Inspect and Adapt) zu tun? Was hat das alles mit Komplexität zu tun?
In der letzten Folge haben wir dir die 5 Scrum Werte – Mut, Fokus, Engagement, Respekt und Offenheit vorgestellt und was sie bedeuten bzw. was sie nicht bedeuten, da diese gerne auch missbraucht werden, um etwas anderes zu erreichen.
Schau also unbedingt hier vorbei falls du darüber mehr lernen willst.
Dafür müssen wir uns noch einmal ins Gedächtnis rufen, in welcher Domäne Scrum am sinnvollsten eingesetzt wird. Eine der beste Erklärungen dafür ist unserer Meinung nach die sogenannte Stacey Matrix. Sie beschreibt die vier Bereiche von Arbeit/Aufgaben, nämlich „Einfach“, „Kompliziert“, „Komplex“ und „Chaos“. Die Stacey Matrix beschreibt, wie diese Bereiche mit der Klarheit (Certainty) über die Umsetzung/Lösung der Aufgabe (als dem „Wie?) und die Klarheit über die Anforderungen (Requirements) (als dem „Was“?) zusammenhängen. Sie stellt einen Zusammenhang zwischen den Eigenschaften eines Systems nach dem Cynefin-Framework und den inhärenten Unsicherheiten der Aufgabe bzw. deren Lösung her.
Wenn wir wissen, wie wir etwas umsetzen müssen und auch die Anforderungen klar sind, funktioniert ein Vorgehen nach z.B. dem Wasserfall-Modell durchaus sehr gut. Ein Beispiel wäre einem Bäcker zu sagen er soll eine Brezel backen. Er weiß (durch seine Ausbildung und Erfahrung), was er machen muss und wie er das machen muss. Für ihn ist das also eine einfache Aufgabe.
Sagen wir dem Bäcker allerdings er soll ein Brot nach einem Kundenwunsch backen, so weiß er aus seiner Erfahrung wahrscheinlich wie er das machen muss, aber er hat genau das Brot sehr wahrscheinlich noch nie gebacken. Daher ist die Unsicherheit in der Umsetzung höher und auch die Anforderungen durch den Kunden müssen nicht perfekt klar sein. Das wäre ein Beispiel für eine komplizierte Aufgabe.
Sagen wir dem Bäcker aber nun er soll eine Torte Backen nach den schwierigen Anforderungen des Kunden, so ist seine Erfahrung hier noch geringer (da er kein Konditor ist) und wiederum versteht er die Anforderungen seines Kunden schlechter. Er ist also auf keinen Fall ein Experte für diese Aufgabe. Es handelt sich also für ihn um eine komplexe Aufgabe.
Verlangen wir allerdings von diesem Bäcker eine Software für seine Maschinen oder gar die Maschinen selbst zu bauen, so wird das sicher in Chaos enden, da er hier keinerlei Erfahrung hat, wie er das Umsetzen muss, noch was er genau für Anforderungen hat.
Als erstes macht es daher Sinn, dass in einem Scrum-Umfeld jedem klar sein sollte (was eider nicht immer zutrifft…), dass es hier keine Experten gibt, die uns einen validen Plan geben können, den wir einfach einhalten müssen, um zum gewünschten Ziel zu kommen.
Wenn wir allerdings nur das grobe Ziel/Vision kennen, wo es hingehen soll, aber der Weg dahin unklar ist, macht es Sinn für eine bestimmte Zeit (time-boxed) in eine Richtung zu laufen und dann wieder auf die Karte zu schauen, um sicher zu gehen, dass wir uns in die richtige Richtung bewegt haben und gegebenenfalls die Richtung anpassen.
Wir kennen die ganzen Herausforderungen die auf dem Weg liegen nicht (z.B. wilde Tiere, denen wir ausweichen müssen), daher sind unsere Vorhersagen (Estimates/Forecasts) sehr ungenau am Anfang. Je näher wir aber dem Ziel kommen, desto genau können wir abschätzen wie lange wir benötigen. Hierzu werden wir dir auch noch einen Artikel/Podcast/Video veröffentlichen. Also Newsletter/Podcast und YouTube abonnieren 😉 .
Und genauso geht Scrum auch vor. Wir haben kurze Sprints in eine bestimmte Richtung und schauen dann nochmal nach ob wir korrigieren müssen (Sprint Review). Zusätzlich schauen wir in Scrum aber auch, wie wir uns auf den nächsten Abschnitt der Reise (nächster Sprint) besser vorbereiten können (Sprint Retrospektive).
Scrum minimiert also das Risiko zu lange das Falsche zu machen.
Und hier kommt nun Empirie ins Spiel.
Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. – Scrum Guide 2020
Das bedeutet, dass wir unser Vorgehen/Schätzungen immer wieder inspizieren und anpassen müssen (inspect and adapt). Damit das aber funktionieren kann benötigen wir Transparenz, denn nur so können wir sicher gehen, dass wir auch den wahren Zustand inspizieren und die richtigen Anpassungen machen können. Und genau das sind auch die 3 Säulen von Scrum: Transparent, Inspizieren und Anpassen. Auch hierzu wird es noch einen Beitrag in den üblichen Formaten von uns geben.
Scrum versucht nun aufbauend auf dem Gedanken von Empirie ein möglichst logischen Rahmenkonstrukt (Framework) aufzubauen, um die Risiken eines Komplexen Problems so klein wie nur möglich zu halten. Empirie ist also die Grundlage für Scrum.
Ganz einfach. Indem wir das Scrum Framework auf unseren Kontext anwenden, denn alle 5 Events von Scrum und alle 3 Artefakte von Scrum sind genau darauf ausgelegt. Nämlich durch Transparenz und regelmäßiges Inspizieren und Anpassen Empirie so einfach wie möglich zu machen. Aber wie genau fragst du dich?
Lass uns das mal anhand eines Beispiels zusammen durchgehen.
Nehmen wir mal an der Product Owner (PO) bereit das nächste Sprint Review vor und ist daher darauf angewiesen, dass der Status aller Items auch tatsächlich den aktuellen Zustand der Items widerspiegelt (Transparenz durch den Sprint Backlogs). Nun stellt er und seine Entwickler in einer hands-on Demo das neueste Inkrement vor und was dabei geschafft wurde und was nicht (Transparenz durch das Inkrement). Die anwesenden Stakeholder/Nutzer geben nun ihr offenes Feedback (siehe. 5 Scrum Werte) was dazu führt, dass der Product Backlog (PBL) inspiziert und entsprechend die Priorisierung bestimmter Items/Epics angepasst wird (Inspect and Adapt).
Somit schafft auch der aktualisierte Product Backlog wieder Transparenz. So sorgt also das gesamte Event des Sprint Reviews (vorausgesetzt es wird natürlichkorrekt durchgeführt) für durchgängige Transparenz bei allen beteiligten Rollen (PO, Stakeholder, Entwickler, Nutzer) und unterstützt den Vorgang des Inspizierens und Anpassens (Inspect and Adapt).
Genauso schaffen aber auch die anderen Events in Scrum Transparenz und ein Inspizieren und Anpassen des entsprechenden Artefakts (z.B. wird im Daily ja der Plan der letzten 24h angeschaut und der Plan für die nächsten 24h angepasst).
Scrum ist besonders sinnvoll in einem Umfeld, in dem es keine Experten gibt und in dem damit die Unsicherheiten in den Anforderungen (Was?) und der Umsetzung (Wie?) hoch sind.
Dieser Bereich wird in der Stacey Matrix bzw. dem Cynefin-Framework als „Komplex“ beschrieben.
Um diese Risiken zu minimieren bildet daher Empirie die Grundlage von Scrum, mit seinen 3 Säulen Transparenz, regelmäßigem Inspizieren und Anpassen.
Dies wird durch alle Events und Artefakte in Scrum gewährleistet.
Schreib uns gerne in die Kommentare, ob bei dir im Unternehmen wirklich alle Artefakte transparent sind und die Events genutzt werden um die Artefakte zu inspizieren und anzupassen.
Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!
Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Rahmenwerk gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:
Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.
Und auch der ist komplett kostenlos. Du findest den Glossar hier:
In der nächsten Folge stellen wir dir den Product Owner genauer vor. Also was genau sind die Aufgaben des Product Owners? Welche Verantwortung trägt der Product Owner? Wie muss der Product Owner denken und handeln?
Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:
Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:
Du stehst auf bewegtes Bild? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.
Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.
Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.
Wir freuen uns auf dich.
Deine Agile Coach Academy Gründer Ben und Alex