Worum geht es?
Scrum ist ein leichtgewichtiges Rahmenwerk um komplexe Probleme zu lösen. Die Regeln wie wir sie im Scrum Guide finden sind wichtig. Und dennoch wage ich zu behaupten, dass die unterliegenden Prinzipien noch wichtiger für einen nachhaltigen Produkterfolg sind. Erst dann kann das volle Potential von professionellem Scrum genutzt werden.
Die drei unterliegenden Prinzipien im Herzen von Scrum sind:
- Empirie
- Selbst-Management des Scrum Teams
- Kontinuierliche Verbesserung
Die Prinzipien im Detail
Empirie
Wissenschaftler arbeiten seit dem 17. Jahrhundert empirisch. Das heisst, sie erstellen Hypothesen, machen Beobachtungen und sammeln Fakten durch Experimente und können anhand dieser empirischer Daten fundierte Theorien entwickeln um wissenschaftlichen Fortschritt zu erzielen. Dieses Vorgehen hat sich in der Wissenschaftswelt also seit mehreren Jahrhunderten bewährt.
Scrum wird für komplexe Probleme angewendet, das heisst es ist mehr unbekannt als bekannt. Daher ist ein empirischer Ansatz sehr hilfreich um Risiken zu managen und neue lohnenswerte Wege zu finden.
Um empirische Prinzipien anzuwenden, schaffen wir Transparenz und können dann unsere Annahmen überprüfen und entsprechende Anpassungen an unserem Plan, unseren Zielen und schlussendlich am Produkt vornehmen.
Scrum gibt uns in jedem Event eine Chance Empirie anzuwenden. Wir schaffen Transparenz durch Ziele und Artefakte, dann überprüfen wir wo wir stehen und können dann faktenbasiert Anpassungen vornehmen. Aber gerade hier liegt die Schwierigkeit. Dazu brauchen wir Transparenz, und im komplexen Umfeld wo mehr unbekannt als bekannt ist, ist die Intelligenz des ganzen Teams ein Wettbewerbsvorteil. Daher ist es absolut essentiell, dass
alle Beteiligten ein gemeinsames Verständnis haben
Dabei spielt weniger eine Rolle was in irgendwelchen Dokumenten steht, sondern ob ein gemeinsames Verständnis in den Köpfen des Scrum Teams herrscht. Dazu ist es unerlässlich miteinander zu reden und zu diskutieren und das gemeinsame Verständnis im Product Backlog oder Sprint Backlog in einer geeigneten Form festzuhalten. Bei geringer Transparenz können schlechte Entscheidungen getroffen werden, die Risiken erhöhen oder Wert reduzieren. Jeden Tag trifft jedes Scrum Team Mitglied viele Entscheidungen, auch wenn es vielleicht nur viele kleine Entscheidungen sind, die Summe der Entscheidungen manifestiert sich im Produkt.
Zudem ist es nötig Annahmen zu validieren indem wir qualitatives und quantitatives Feedback einholen. Wenn man häufig ein Release rausbringt, dann und nur dann kann man
zeitnah Feedback aus produktiver Nutzung einholen.
Das ist das entscheidende Feedback, alles davor sind nur Indizien.
Selbst-Management des Scrum Teams
Das Scrum Team managt sich selbst, das heisst sie entscheiden intern, wer was wann und wie macht.
Wenn das Scrum Team diese Entscheidungen nicht selber trifft, dann wird es von aussen organisiert oder es herrscht Chaos. Beide Fälle sind nicht gut um Empirie anzuwenden. Jede Person von aussen hat zwangsläufig nicht die volle Transparenz, die im Team herrschen kann. Und im Chaos ist jeder Erfolg ein Ergebnis des Zufalls.
Eine Product Owner:in oder Scrum Master:in, die dem Scrum Team diktiert was sie wie, wann und wer tun soll, beschränkt die Intelligenz des Teams auf die eigene Intelligenz. Die Scrum Team Mitglieder (siehe auch The surprising truth about what motivates us) werden demotiviert, und die mögliche Wertschöpfung reduziert. Daher ist Selbst-Management eine Team Aufgabe, und das ganze Scrum Team ist verantwortlich ein wertvolles und nützliches Increment in jedem Sprint zu schaffen.
Kontinuierliche Verbesserung
Das Scrum Team erhält in jedem Sprint mit Scrum die Chance das Produkt und seinen Prozess zu verbessern. Eine kontinuierliche Investition in den Prozess und den Skills der Scrum Team Mitglieder ist letztendlich ein Investment in eine mögliche erhöhte Wertschöpfung in der Zukunft.
Die Maximierung der Wertschöpfung hängt massiv davon abhängig wie gut das Scrum Team in der Lage ist zu liefern. Wenn ein Scrum Team zum Beispiel nicht die Skills hat mit einer Technologie umzugehen, nur begrenzt in der Lage ist Transparenz zu schaffen, nicht effektiv zusammen arbeitet (z.B. Tuckman Modell) oder die Business Domäne mit den Kund:innen und Nutzer:innen nicht wirklich kennt, dann kann es sein volles Potential nicht ausnutzen. Wie mit jeder Investition, man muss erst mal investieren bevor man den Erfolg ernten kann. Dazu muss man es auch wirklich ernst meinen und tun. Teams, die nur alle paar Sprints mal halbherzig eine Verbesserung angehen, können leicht von der Konkurrenz abgehängt werden.
Call to Action
Das klingt alles nicht nach Raketenwissenschaft, oder? Nee, ist es auch nicht. Aber das berühmte "Knowing-Doing-Gap" steht vielen Scrum Teams im Weg.
Wer lernen möchte wie ein Scrum Team oder eine Product Owner:in effektiv diese Prinzipien anwendet, für den sind die folgenden Trainings ideal.