Scrum – Ein minimales Framework.

Scrum ist als Framework bewusst minimal gehalten. Mit wenigen Artefakten und Events hilft es uns, den Rahmen für unsere individuellen Zwecke ganz bewusst auszugestalten. Wir erreichen dies auf Basis des systematischen Lernens aus der eigenen Erfahrung heraus und verhindern damit, dass wir blind den “Kochrezepten” anderer folgen. Was genau zu diesem minimalen Rahmen gehört, wird im Scrum Guide beschrieben. Es sollte demnach in der Praxis keine Missverständnisse darüber geben, was Scrum ist und was nicht. Häufig zeigt sich jedoch, dass  persönliche Präferenzen und bewährte Praktiken mit dem verwechselt werden, was wirklich Teil von Scrum ist. Daraus resultiert oft eine Überladung des minimalen Rahmens. Aus dieser Überladung von Scrum entsteht häufig der Drang, Scrum zu entschlacken und nicht selten wird dabei der minimale Rahmen von Scrum so aus den Angeln gehoben, dass er an Wirkung verliert oder seine Dysfunktion größer ist als sein Nutzen. 

In den kommenden Folgen meines Podcasts “Scrum meistern”  liegt der Schwerpunkt auf den Scrum Elementen. Es geht darum, weit verbreitete Praktiken näher zu betrachten und damit Inspirationen für eine effektivere Nutzung zu geben. Mit der Folge “Scrum – Ein minimaler Rahmen” möchte ich euch einen Überblick darüber geben, was Scrum als minimales Rahmenwerk bedeutet.

Scrum ist …

Scrum ist ein minimales Framework zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte, das von Ken Schwaber und Jeff Sutherland entwickelt wurde. Das Scrum-Framework besteht aus Scrum-Teams und den dazugehörigen Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.

Meine Erfahrung hat gezeigt, dass einige Elemente als fester Bestandteil von Scrum betrachtet werden, die eigentlich nicht zwangsweise Bestandteil sein müssen. Hierzu gehören beispielsweise das Task-Board, User-Stories, Burn-Down-Charts oder das Planning-Poker. Das Scrum Framework wirkt dadurch unter Umständen umfangreicher, als es eigentlich ist. Es handelt sich hier um Praktiken, deren Einsatz sinnvoll sein kann. Dies ist jedoch stark abhängig vom Kontext. Auch wenn sie sich häufig bewährt haben, sind sie nicht verpflichtend. Darüber hinaus sollten sie nach ihrer Intention in der jeweiligen Umgebung ausgestaltet werden oder, falls ein Einsatz nicht sinnvoll erscheint, durch passende Praktiken ersetzt werden. 

Aus einem empirischen Steuerungsrahmen Produkt und Umgebung ausgestalten

Aus dieser Überlegung heraus macht es Sinn, sich noch einmal vor Augen zu halten, dass Scrum ein empirischer Steuerungsrahmen ist, der dazu dient, aus der Erfahrung heraus das Produkt und die Umgebung auszugestalten. Der Wunsch nach klar definierte Praktiken passt nicht zur Grundintention von Scrum sondern ist vielmehr ein Gedanke des klassischen Managements. Für komplexere Einsatzgebieten, für die Scrum gedacht ist, ist dies jedoch weniger sinnvoll. Denn dort  haben wir nicht die eine Best Practice, die auf alles passt, sondern wir müssen etwas Passendes für den jeweiligen Kontext schaffen. Scrum basiert auf einem empirischen Ansatz und gibt dabei den Rahmen, systematisch aus Ergebnissen zu lernen. Dies erreichen wir in einer Umgebung, in der wir transparent zusammenarbeiten. Aus dieser Transparenz in unserer Arbeit wird auf verschiedenen Ebenen inspiziert und adaptiert. Die Ausgestaltung geschieht also aus der Arbeit und der gesammelten Erfahrung heraus, innerhalb der jeweiligen Umgebung.

Im Umkehrschluss bedeutet das: wenn wir an unserem Arbeitsplatz seit einem Jahr Scrum anwenden und unsere Umgebung heute noch genauso aussieht wie damals, dann hat keine aktive Ausgestaltung stattgefunden. Aufgrund der in diesem Zeitraum gesammelten Erfahrung müsste sich einiges verändert haben – denn aktives Ausgestalten bedeutet, zu lernen und sich dabei zu wandeln. Und aktives Lernen ist elementarer Bestandteil von Scrum. 

Solltet ihr in eurer Umgebung die Veränderung und damit das aktive Lernen nicht verspüren, kann ich euch nur dazu ermutigen, eure Arbeitsweise unter folgenden Gesichtspunkten näher zu hinterfragen:

• Wie funktioniert unsere Arbeit, um zu guten Ergebnissen zu kommen? 
• Haben wir gute Punkte, aus denenen heraus wir inspizieren und uns fragen “wo stehen wir gerade”?
• Werden diese Punkte auch aktiv zur Ausgestaltung der Umgebung genutzt?

Scrum ist bewusst minimal

Scrum besteht aus seinen Werten und einem Dutzend an Elementen  (Rollen, Ereignisse, Artefakte). Es ist bewusst minimal gehalten, da man ja bereits in einer komplexen Umgebung agiert. Denn: Würde man einem komplexen Umfeld mit einer komplexen Methode begegnen, würde das mit Sicherheit zu einer Überladung und einer Überforderung der Akteure führen.  

Eine Alternative könnte es sein, einen Rahmen zu schaffen, der für viele Anwendungsfälle eine vielzahl von Alternativen berücksichtigt, die bei Bedarf weggelassen werden können. Meiner Meinung nach fühlt sich das beim Start besser an, führt aber langfristig zu einer suboptimalen Umgebung. Anhand eines Beispiels lässt sich besonders gut verdeutlichen, warum minimale Ansätze den umfangreichen vorzuziehen sind. Ich erinnere mich an den Einsatz von Rational Unified Process (RUP), ein umfassendes, tool-basiertes Rahmenwerk. RUP ist verhältnismäßig standardisiert und mit mehr als 30 Rollen, mehr als 20 Aktivitäten und mehr als 70 Artefakten relativ  komplex. Die Grundidee war es, dem Nutzer die Möglichkeit zu geben, diejenigen Elemente wegzulassen, die unpassend erscheinen. 

Nun befinden wir uns bei der Anwendung allerdings in einer Change-Situation und die meisten Menschen reagieren auf Veränderung mit Unsicherheit. Dies führt zwangsweise dazu, dass Anwender im Zweifel eher mehr Elemente behalten, als verwerfen. Eine nur allzu menschliche Reaktion, die allerdings dazu führt, dass eine komplexe Variante des Rahmenwerks von 120 Elementen auf schätzungsweise 70 Elemente reduziert und damit nur unwesentlich vereinfacht wird. Ein weitere Resultat ist, dass die Elemente, die bestehen bleiben, nicht deswegen inkludiert werden, weil sie von allen als wertstiftend erachtet werden, sondern höchstwahrscheinlich nur aus einer prozessgläubigkeit heraus. 

Das Scrum Framework geht genau den entgegengesetzten Weg: Man startet mit wenigen Rollen, Events und Artefakten im kleinen Rahmen und ergänzt und erweitert bewusst um das, was im jeweiligen Kontext als sinnvoll und wertstiftend erachtet wird. Man hinterfragt sich bewusst: Was brauchen wir, dass dieser Rahmen ausreichend ist um weiterzuarbeiten? Was müssen wir weiter ausgestalten, damit der Rahmen zu unserer Situation und Umgebung passt? Das ist nicht unbedingt einfach, aber definitiv eine bewusste Vorgehensweise und nicht ein von Unsicherheit getriebenes Festhalten an Elementen. 

Scrum-Elemente weglassen?

Wenn es nun bei der Anwendung doch so scheint, als sei das Scrum Framework überladen, so stellt sich dann die Frage, an welcher Stelle genau. Ich möchte vorwegnehmen, dass die Definition von Scrum sehr eindeutig zeigt, was zu Scrum gehört. Das Weglassen von Elementen führt dazu, dass Scrum nicht mehr Scrum ist. Bei genauerer Betrachtung wird man feststellen, dass das auch hochgradig Sinn macht, denn: Die Elemente von Scrum passen sehr gut zusammen. Sie ergänzen sich und greifen ineinander. 

In dem angedachten Einsatzgebiet von Teamarbeit in einem anspruchsvollen Aufgabengebiet (nämlich genau dafür ist Scrum bestimmt) fällt es mir wirklich schwer, das Rahmenwerk um dessen Elemente zu reduzieren. Da ich aber nicht an einer Definition festhalten möchte, nur um nicht davon abzuweichen, möchte ich an dieser Stelle einmal hinterfragen, ob wir durch das Weglassen bestimmter Scrum-Elemente bessere Ergebnisse erzielen könnten. 

Wird Scrum also besser, wenn wir … 

• das Daily weglassen, in dem das Team sich täglich abstimmt und den gemeinsamen Kurs festlegt? 
• auf die gemeinsame Planung des Sprints verzichten?
• darauf verzichten, das Produkt-Inkrement zu inspizieren um daraus zu Backlog zu adaptieren?
• die Retrospektive in der wir unsere gemeinsame Arbeitsweise verbessern, weglassen? 

Mit Überzeugung kann ich hier behaupten: Nein. Gleiches gilt für die Rollen und die Artefakte. Ein Weglassen wird nicht dazu führen, dass sich unsere Zusammenarbeit oder unsere Ergebnisse verbessern werden. Ich rate daher dazu, Elemente bei Bedarf minimal auszugestalten, jedoch nicht darauf zu verzichten.

Scrum braucht einen passenden Arbeitskontext

Anders sieht es aber aus, wenn wir uns in einem unpassenden Arbeitskontext befinden. Ein Weglassen einzelne Elemente verbessert auch in diesem Fall nicht die Ergebnisse oder die Zusammenarbeit. Allerdings sollte man sich in einem unpassenden Arbeitskontext hinterfragen, ob Scrum das richtige Rahmenwerk darstellt. In den folgenden Arbeitsumgebungen würde ich von dem Einsatz des Scrum Frameworks abraten.

• Fehlende Bereitschaft und Strukturen, als Team zu arbeiten
  Oft ist man es in Organisationen nicht gewohnt, als Team zu arbeiten. Wenn Scrum kritisch gesehen und eine Zusammenarbeit im Team verhindert wird  (und demnach nicht stattfinden kann), macht Scrum als Ganzes keinen Sinn. Scrum kann nur in enger Zusammenarbeit als Team erfolgen und wird mit einer Ansammlung von Individuen, die in dieses Rahmenwerk gezwungen werden, nur auf Unmut stoßen.
• Geringe Komplexität
  Wenn wir uns nicht mit anspruchsvollen Aufgaben beschäftigen (uns also nicht in einem komplexen Umfeld befinden, sondern das Was und das Wie völlig klar sind) und unsere Arbeit durch saubere Planung bewältigen können, dann ist Scrum als Rahmenwerk nicht notwendig und ebenfalls nicht zu empfehlen.
• Fehlende Offenheit gegenüber Transparenz
  Scrum basiert auf dem Willen, aus der Transparenz heraus Optimierungsbedarf zu erkennen, Fehler anzusprechen und anzugehen. In manchen Organisationen ist diese Offenheit nicht gewünscht oder durch Strukturen nicht möglich. Auch hier macht es keinen Sinn, Scrum einzusetzen.

Wenn eine derartig enge und abteilungsübergreifende  Zusammenarbeit in Teams nicht gewünscht ist, die Komplexität einer Aufgabe nicht gegeben oder die Offenheit gegenüber transparenter Offenlegung von Missständen oder Fehlern nicht vorhanden ist, dann ist Scrum nicht das passende Rahmenwerk. Es muss vielmehr grundsätzlich hinterfragt werden, was erreicht werden soll.

Zusammenfassung

Scrum ist ein bewusst minimales Rahmenwerk. Es wird oft fälschlicherweise überladen mit Praktiken, die sich in anderen Bereichen bewährt haben. Hieraus entsteht die Gefahr, blind die Kochrezepte anderer zu übernehmen. Scrum basiert im wesentlichen darauf, dass wir durch systematisches Lernen aus der Erfahrung, in der eigenen Umgebung und aus Feedback heraus, ausgestalten und nachjustieren. Wenn wir dies nicht tun, ist es weder agil, noch ist es Scrum. 

Ich hoffe, ich konnte dir einen guten Überblick über Scrum als minimales Rahmenwerk geben. In den kommenden Folgen von „Scrum meistern“ werde ich näher auf die Scrum Elemente eingehen und freue mich, wenn du auch dann wieder reinhörst/reinliest. Hast Du Fragen oder Anmerkungen? Hinterlasse gern einen Kommentar. Ich freue mich immer über ein Feedback.