4.8 4 Votes
Artikel-Rating

Empirische Prozesssteuerung – oder auch empirische Prozesskontrolle bzw. Empirismus – ist ein Kernelement des Scrum Frameworks. Im Scrum Guide findest Du an vielen Stellen die Information, dass Scrum auf Empirismus basiere. Aber was soll das eigentlich genau heißen? Und wie funktioniert empirische Prozesskontrolle nun genau?

In diesem Artikel gehe ich näher drauf ein, wann empirische Prozesssteuerung sinnvoll ist, auf welchen drei Säulen sie basiert und welche Rolle Hypothesen und Metriken dabei für Dich und Dein Scrum Team spielen.

Wann ist empirische Prozesssteuerung sinnvoll?

Empirismus bzw. empirische Prozessteuerung in der Produktentwicklung oder im Rahmen eines Projektes ergibt immer dann Sinn, wenn sehr viele Unabwägbarkeiten, Unsicherheiten, Variablen und Risiken existieren. Diese Umgebungen oder Systeme bezeichnen wir Agile Coaches auch als komplexe Systeme – im Gegensatz zu komplizierten Systemen.

Komplexe vs. komplizierte Systeme

Komplizierte Systeme sind umfangreich und schwer zu durchschauen. Allerdings besitzen sie eine erkennbare Ordnung. Und genau deshalb können wir sie durch eine genaue, vorherige Analyse verstehen. Diese Analyse hilft uns beispielsweise dabei, einen Plan zur Umsetzung eines Projektes zu entwickeln. Vielleicht benötigen wir dazu einen Experten, jedoch ist eine vorherige Analyse der Zusammenhänge grundsätzlich möglich.

Komplexe Systeme hingegen sind ungeordnet. Sie lassen sich nicht vorab analysieren. Beispielsweise weil viel zu viele Variablen und Wechselwirkungen existieren. Die Funktionsweise eines komplexen Systems und die darin verborgenen Kausalitäten lassen sich deshalb erst dann erkennen, wenn wir mit diesem komplexen System interagieren. Oft ist es sogar so, dass unsere eigene Interaktion mit einem komplexen System eine bestimmte Reaktion erst hervorruft.

Beispielspiel für komplexe & komplizierte Systeme

Die Produktion eines Autos ist beispielsweise ein sehr komplizierter Prozess. Aber er lässt sich soweit perfektionieren, dass jedes Auto am Fließband hergestellt werden kann.

Das Designen oder “Erfinden” eines neuen Automodells hingegen ist ein komplexer Prozess. Autohersteller unternehmen viele Tests & Experimente, um sicherzustellen, dass ihr neuestes Modell später auch genau so funktioniert, wie sie sich das wünschen. (Denk nur an die sogenannten Erlkönige.)

  • Grundlegendes zu diesem Unterschied kannst Du in meinem Artikel über Komplexität erfahren.

  • Die Stacey Matrix ist ein hilfreiches Tool, mit dessen Hilfe sich die Komplexität eines System beurteilen lässt. Sie hilft Dir dabei zu entscheiden, ob empirische Prozesssteuerung für Dein Projekt oder die Entwicklung Deines Produktes sinnvoll ist oder nicht.

  • Ein weiteres, gut geeignetes Tool, um zu entscheiden, ob agile Methoden sinnvoll anzuwenden sind, ist das sogenannte Cynefin Framework.

Empirische Prozesskontrolle hilft dabei, Komplexität zu bewältigen

Wenn eine Umgebung, ein System oder Projekt komplex ist, ist es unmöglich, eine vorherige Analyse durchzuführen oder vorab einen exakten Plan zu entwerfen. Genauso wenig wie es möglich ist, ein neues Automodell auf dem Reißbrett zu entwerfen und anschließend direkt am Fließband herzustellen. Auch bei einem Schachspiel kannst Du nicht vorab Deine Spielzüge aufschreiben, um das Spiel zu gewinnen. Denn jeder neue Spielzug verändert die aktuelle Situation. Das macht es notwendig, dass Du Dich bei jedem Deiner Spielzüge neu entscheiden musst.

Deshalb müssen wir bei hoher Komplexität auf Experimente bzw. empirische Prozesskontrolle zurückgreifen, um Zusammenhänge zu durchschauen. Weil wir erst durch die Interaktion mit einem komplexen System verstehen, ob das, was wir tun, wirklich zum gewünschten Ergebnis führt.

Die 3 Säulen empirischer Prozesssteuerung

Empirische Prozesskontrolle basiert auf drei wichtigen Säulen.

  • Transparenz

  • Überprüfung (Inspection)

  • Anpassung (Adaption)

Transparenz

Die Grundvoraussetzung für Empirie ist Transparenz über “das, was ist”. Je besser es uns in einem komplexen System gelingt, Klarheit und Transparenz herzustellen, desto bessere Entscheidungen können wir treffen.

Überprüfung (Inspection)

Transparenz alleine hilft uns jedoch nicht weiter. Wir müssenden den aktuellen Zustand unseres Systems, Projektes oder Produktes auch regelmäßig überprüfen (engl. Inspection) und neue Erkenntnisse gewinnen.

Anpassung (Adaption)

Diese neuen Erkenntnisse können wir dann dazu nutzen, unseren aktuellen Plan anzupassen (engl. Adaption).

Je häufiger wir diesen Kreislauf von Überprüfung & Anpassung durchlaufen und je größer die Transparenz ist, desto flexibler und besser können wir auf neue Erkenntnisse und Veränderungen reagieren.

Beispiel für empirische Prozesssteuerung

Ein gutes Beispiel für empirische Prozesssteuerung ist ein Thermostat.

Um die Temperatur eines Raumes regeln zu können, muss das Thermostat zunächst einmal wissen, wie die aktuelle Temperatur des Raumes ist. Dies wird über einen Messfühler ermöglicht, der Transparenz herstellt.

Der Temperaturwert wird dann in regelmäßigen Zyklen vom Thermostat überprüft.

Ist die Temperatur zu hoch oder zu niedrig, kann der Thermostat durch ein Steuermechanismus die Temperatur anpassen.

Empirische Prozesssteuerung - Regelkreis

Gleichzeitig unterliegt die Raumtemperatur natürlich gewissen Schwankungen bzw. Störungen. Es kann sein, dass ein Fenster geöffnet wurde oder sich die Außentemperatur verändert hat etc. Das Thermostat muss den Prozess von Transparenz, Überprüfung und Anpassung also in fortlaufenden Schleifen wiederholen.

Empirische Prozesssteuerung in Scrum

Scrum basiert auf den gleichen drei Prinzipien wie das Thermostat aus dem obigen Beispiel. Im Scrum Guide kannst Du dazu lesen:

Scrum is founded on empiricism […]. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.

3-Saeulen-von-Scrum.png
Product Backlog
Sprint Backlog
Increment
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospektive
3 Säulen von Scrum

Das Scrum Framework hat die 3 Elemente empirischer Prozesskontrolle fest in seinem Regelwerk verankert. Deshalb spricht man auch häufig von den 3 Säulen von Scrum. Die notwendige Transparenz wird durch die sogenannten Scrum Artefakte sichergestellt. Die beiden anderen Elemente, Überprüfung & Anpassung, werden durch vier der insgesamt fünf Scrum Events realisiert.

Transparenz durch Scrum Artefakte

Die drei Scrum Artefakte stellen die notwendige Transparenz für eine empirische Prozesskontrolle her. Dazu zählen das Product Backlog, das Sprint Backlog und das Increment. Sie alle repräsentieren Wert oder noch zu erledigende Arbeit.

  • Das Product Backlog erzeugt Transparenz darüber, was für das Produkt noch getan werden kann bzw. muss, um seinen Wert zu steigern.

  • Das Sprint Backlog erzeugt Transparenz darüber, wie viel Arbeit noch zu erledigen ist, um das Sprintziel zu erreichen.

  • Das Increment erzeugt Transparenz darüber, wie es um den Zustand eines Produktes bestellt ist und welchen Nutzen es stiftet.

Überprüfung & Anpassung durch Scrum Events

Die beiden anderen Säulen der empirischen Prozesskontrolle, Überprüfung & Anpassung, werden durch vier Scrum Events erzielt.

  • Im Sprint Planning überprüft Dein Scrum Team den aktuellen Stand des Product Backlogs und entwirft einen Plan für den nächsten Sprint, um den Wert des Produktes bestmöglich zu steigern. (Anpassung)

  • Im Daily Scrum überprüfen die Entwickler Deines Scrum Teams mit Hilfe des Sprint Backlogs, wie es um die Erreichung Eures Sprintziels steht und planen auf Basis dieser Erkenntnisse, was am heutigen Tag zu tun ist. (Anpassung)

  • In der Sprint Review überprüft Dein Scrum Team gemeinsam mit wichtigen Stakeholdern das Ergebnis des Sprints anhand des Increments. Das dort entstehende Feedback und der aktuelle Stand des Increments wird dazu genutzt, das Product Backlog zu überarbeiten. (Anpassung)

  • In der Sprint Retrospektive überprüft Dein Scrum Team, wie gut die Zusammenarbeit im letzten Sprint funktioniert hat und beschließt Maßnahmen (Anpassung), wie es im kommenden Sprint wieder ein kleines bisschen besser werden kann.

Die Rolle von Hypothesen in der empirischen Prozesssteuerung

Wie oben darstellt führt Komplexität dazu, dass wir nicht wissen können, wie ein System funktioniert oder reagieren wird, bevor wir mit ihm interagiert haben. Empirische Prozesskontrolle basiert daher immer auf einer Hypothese darüber, was passieren wird, wenn wir einen Plan in die Tat umsetzen.

Wir wissen beispielsweise nicht, ob ein neues Feature im Produkt unsere Nutzer wirklich zufriedener machen wird (oder nicht). Wir wissen auch nicht, ob tägliche Social-Media-Beiträge dazu führen werden, dass sich die Besucherzahlen unserer Homepage verbessern werden.

Wir glauben vielleicht, dass es so sein wird. Sicher können wir uns jedoch erst sein, wenn wir das Feature entwickelt haben bzw. einmal täglich einen Beitrag auf Twitter verfasst haben.

  • Mehr dazu erfährst Du in meinem Artikel Hypothsen formulieren. Dort zeige ich Dir, welche Arten von Hypothesen es gibt, wie Du messbare Hypothesen formulierst und welche Tests & Experimente Du dazu nutzen kannst.

Messbarkeit zur Überprüfung von Hypothesen

Wenn Du Hypothesen im Rahmen einer empirischen Prozesssteuerung nutzt, dann ist es sehr hilfreich, wenn konkrete Metriken existieren, anhand derer Du bestimmen kannst, ob das gewünschte Ergebnis wirklich eingetreten ist oder nicht. Du kannst beispielsweise den Net Promoter Score nutzen, um die Zufriedenheit Deiner Nutzer messbar zu machen. Oder die monatlichen Besucherzahlen auf Deiner Internetseite zu Rate ziehen, ob Deine Social-Media-Kampagne erfolgreich war oder nicht.

  • Wenn Du Dich näher mit dem Thema Messbarkeit & Metriken beschäftigen möchtest, empfehle ich Dir einen Blick auf meinen Artikel zum Evidence-Based Management. Hier gehe ich sehr ausführlich darauf ein.

Fazit zu empirischer Prozesssteuerung

Ich hoffe, ich konnte Dir zeigen, wie Scrum empirische Prozesssteuerung in seinem Rahmenwerk verankert hat und warum Du deshalb auch nicht einfach Elemente von Scrum “weglassen” kannst. Schlecht umgesetzte oder gar fehlende Artefakte führen zu weniger Transparenz. Ausgelassene Scrum Events führen zu einer verpassten Möglichkeit zur Überprüfung & Anpassung.

Solltest Du noch Fragen zur empirischen Prozesskontrolle haben oder Ideen, Anregungen oder Kritik zu diesem Artikel haben, freue ich mich wie immer auf Dein Feedback in den Kommentaren!