Scrum im Selbststudium – Teil 4: Zur Lösung komplexer Probleme hat sich ein empirischer Ansatz bewährt
Willkommen zum 4. Teil der „Scrum im Selbststudium“-Artikelreihe. Die Übersicht zu allen Teilen findest du am Ende dieses Beitrags.
Was bedeutet „empirischer Ansatz” beim agilen Arbeiten?
Da Scrum an vielen Stellen der Prozesssteuerung auf Empirie setzt, um die Vorhersagbarkeit zu optimieren, betrachten wir dieses Konzept nun genauer.
„Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden.“ – Scrum Guide, 2020
Das heißt, wir lassen uns durch unsere Erfahrung und Beobachtung leiten. Das theoretische Fundament von Scrum liegt in der Idee, dass Wissen und Erkenntnis nicht aus langer Analyse und Planung stammen, sondern auf realer Erfahrung beruhen. Statt also langfristige Annahmen zu tätigen, sollten wir unsere Entscheidungen auf dem aufbauen, was wir zu gegebener Zeit wahrnehmen. Damit sich Scrum-Teams bei ihrer Arbeit wirksam von ihrer Erfahrung leiten lassen können, müssen sie die drei empirischen Scrum-Säulen implementieren. Auf diesen drei Prinzipien fußt jeder empirische Prozess.
- Transparenz: Die Arbeit muss nicht nur sichtbar sein, sondern auch von allen im Team verstanden worden sein. Wenn die Arbeit verstanden ist, dann können wir sie auch wirkungsvoll überprüfen. Transparenz setzt sich somit aus Sichtbarkeit und Verständnis zusammen.
Nur Transparenz ermöglicht Überprüfung.
- Überprüfung: Scrum-Teams schauen auf die erledigte Arbeit zurück und überprüfen sie im Hinblick auf das Produkt, die Zusammenarbeit und den Wertschöpfungsprozess.
Nur die Überprüfung ermöglicht Anpassung. In Scrum erachten wir Überprüfung ohne Anpassung als unsinnig.
- Anpassung: Für Scrum-Teams ist es in Ordnung, ihre Meinung zu ändern, um neue und bessere Entscheidungen zu treffen.
Vertrauen als Grundlage für echte Transparenz und wirksame Anpassung
Letztendlich geht es bei Scrum darum, häufig und regelmäßig die Möglichkeiten dafür zu schaffen, neue und bessere Entscheidungen zu treffen. Die Grundlage dafür ist Vertrauen. Vertrauen im Team, zwischen Team und Organisation und zwischen Team und Kunden.
Was macht Vertrauen auf Team- und Unternehmensebene aus?
Dies wird in einem bekannten Comic trefflich auf den Punkt gebracht. Dort fragt ein Entwickler in der Kaffeeküche einen Kollegen: „Wie kommst du mit deinem Projekt voran?“ Darauf antwortet sein Kollege: „Es ist ein verdammter Haufen Versagen.“ Später wird ihm die gleiche Frage noch mal von seinem Manager gestellt, nun lautet seine Antwort: „Alles bestens!“
Es fällt uns nicht schwer, zu sehen, dass der Entwickler seinem Kollegen vertraut und ihm die Wahrheit über den Projektfortschritt mitteilt. Seinem Manager vertraut er hingegen nicht und deshalb sagt er ihm nicht die Wahrheit, um erst mal keine Konsequenzen fürchten zu müssen. Es herrscht also kein gemeinsames Verständnis über den Fortschritt des Projekts und somit auch keine Transparenz. Die Auswirkung ist bekannt und wird im Scrum Guide festgehalten:
„Eine Überprüfung ohne Transparenz ist irreführend und verschwenderisch.“ – Scrum Guide, 2020
Wie kann ein solches Vertrauen hergestellt werden?
Das erfährst du im nächsten Teil: Die Grundlage eines funktionierenden empirischen Prozesses ist Vertrauen.
Wenn du Fragen hast, schreibe sie gerne in die Kommentare hier im Blog oder auf unserem Colenet-Linkedin-Account.
Hier findest du alle Teile der Reihe “Scrum im Selbststudium”:
Teil 1: Agile Projekte sind erfolgreicher
Teil 2: Scrum in 11 Schritten im Schnelldurchlauf erklärt
Teil 4: Zur Lösung komplexer Probleme hat sich ein empirischer Ansatz bewährt
Teil 5: Die Grundlage eines funktionierenden empirischen Prozesses ist Vertrauen
Teil 6: Die Scrum Artefakte stellen Transparenz her
Teil 7: Die mögliche Zukunft – Das Product-Backlog
Teil 8: Die Gegenwart – Das Sprint Backlog
Teil 9: Die Vergangenheit – Das Produkt-Inkrement
Teil 10: Scrum Events erlauben, die Artefakte zu überprüfen und anzupassen
Teil 11: Sprint – Erstellung eines Inkrements
Teil 12: Sprint Planning – Planung der Arbeit des Sprints
Teil 14: Sprint Review – Überprüfung der Sprint-Ergebnisse und weitere Planung
Teil 15: Sprint Retrospektive – Aus dem vergangenen Sprint lernen und Verbesserungen planen
Teil 16: Das Scrum-Team und seine Verantwortung
Teil 17: Der Product Owner maximiert den Wert des Produkts
Teil 18: Die Entwickler schaffen jeden Sprint ein nutzbares Inkrement
Teil 19: Der Scrum Master verantwortet die Effektivität des Scrum-Teams