Es ist ein offenes Geheimnis, dass sich am Scrum-Rahmenwerk nichts ändert. Ken Schwaber hat bis heute streng darüber gewacht, dass Scrum nicht verändert, ausgebaut oder gar verwässert wird. Dementsprechend selten wird auch der Scrum Guide (die autoritative Definition von Scrum) überarbeitet. Das letzte Mal, dass der Guide überarbeitet wurde war vor rund drei Jahren (Juli 2013) Doch nun ist es also wieder so weit.

Was wurde geändert? Ein neuer Abschnitt mit der Überschrift „Scrum Werte“ („Scrum Values“) ist dazugekommen. Ansonsten gab es keine Änderungen. Der neue Abschnitt ist so kurz, dass ich mir erlaube ihn hier zu zitieren (siehe dazu Scrum Guide July 2016, S. 4):

„When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.“

 

„Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.“

 

Warum wurden diese beiden kurzen Abschnitte zum jetzigen Zeitpunkt hinzugefügt?

Obwohl im bisherigen Text diese Werte (Commitment, Mut, Fokus, Offenheit, Respekt) zwischen den Zeilen gelesen werden konnten, wurden sie nirgends so explizit genannt und in den Vordergrund gestellt. Eigentlich war dies ein grosses Versäumnis. Selbst bei eXtreme Programming (XP) wurden die zugrundeliegenden Werte (Einfachheit, Kommunikation, Feedback, Respekt, Mut) hervorgehoben.

Jetzt wo agile Methoden im Mainstream angekommen sind und sich viele daran machen agile Praktiken in ihrem Unternehmen auf die eine oder andere Weise einzuführen, wird zunehmend evident, dass bei vielen „agilen Transformationen“, irgendwo zwischen SAFe und bipolarer (ja Du hast richtig gelesen) IT, die agilen Grundwerte auf der Strecke geblieben sind.

Schauen wir uns die fünft Scrum Werte einmal genauer an und beleuchten kurz, inwiefern sie in einem Team fehlen könnten, obwohl man dem Buchstaben nach „Scrum macht“ (eigentlich schlimmer Ausdruck).

Commitment

Commitment (Neudeutsch für Selbstverpflichtung, Verbindlichkeit, Zusage) ist in gewissen Teams ein Fremdwort, manchmal sogar eine Provokation. Wen wir zu Beginn eines Sprint einen Sprintbacklog zusammenstellen, dann beinhaltet dies auch ein inhärentes Versprechen, das wir abgeben, nämlich unser Bestes zu tun, um das Ziel, das wir uns stecken, zu erreichen. Und ja es ist unserer professionellen Einstellung geschuldet, das Sprintziel erreichen zu wollen und wenn möglich ohne Abstriche.

Natürlich kann manchmal etwas im Sprint dazwischen kommen und wir schaffen es nicht alle geplanten User Stories im Sprint fertig („done“) zu bekommen. Aber das sollte die krasse Ausnahme sein. Die Einstellung: „Wenn nicht in diesem Sprint, dann halt im nächsten.“ hat in einem Scrum-Team keinen Platz. Scrum drängt ein Team nie dazu, dem Kunden das Unmögliche zu versprechen. Management tut es leider öfter.

Mut

Wenn es einen Wert gibt, der ganz gross geschrieben werden sollte, dann ist das Mut. Ohne mutiges Inspizieren und Adaptieren, ist es unmöglich Verbesserungen in der Vorgehensweise, in der kulturellen Ausprägung und in der Zusammenarbeit zu erreichen. Jegliche „Transformation“ ist zum scheitern verurteilt, wenn ein Unternehmen nicht lernt der Realität in die Augen zu sehen und dann mutig Taten folgen zu lassen. Auf halbem Weg stehen zu bleiben ist keine Option. Der Schaden kann grösser sein als der erhoffte Nutzen.

Die geforderte Transparenz ist für viele Personen schmerzhaft. Auf einmal wird sehr transparent, was sie wirklich leisten können. Auf einmal werden vollmundige Verkaufsversprechen durchschaubar. Auf einmal kann der Kunde einschätzen ob das Projekt was wird. Plötzlich kann das Glas halb leer statt halb voll erscheinen. Es braucht Mut sich auf vollständige Transparenz einzulassen. Und in der Regel wird dieser Mut belohnt, da auf lange Sicht Vertrauen geschaffen werden kann.

Es braucht Mut, zu erkennen das der versprochene Geschäftswert nicht geschaffen wurde und sodann die Business-Strategie oder zumindest den Produktbacklog entsprechend anzupassen, selbst wenn das heisst gewisse Business-Stakeholder vor den Kopf zu stossen.

Fokus

Alle reden von Fokus und dann sehe ich einen Sprintbacklog wie einen Gemischtwarenladen. Kein gemeinsames Sprintziel ist auszumachen. Geschäftswert wir weder überlegt noch gemessen. Kein Wunder weiss auch das Entwicklungsteam nicht was wichtig ist. Dementsprechend werden in Sprint 1 Nebensächlichkeiten und Spielereien implementiert, ohne das irgendjemand mit der Wimper zuckt.

Wir sind in Scrum-Teams organisiert, aber siehe da: ganz wichtige Mitarbeiter gehören gleich mehren Teams an oder arbeiten an verschiedensten Projekten gleichzeitig. Sie sollen sich häppchenweise auf mehrere Aufgabe fokussieren. Im Nachhinein wundert man sich, dass im Sprint wieder wenig erreicht wurde. Wenn es den jemandem auffallen würde, denn jeder Sprint ist gleich „produktiv“.

Offenheit

Ja, wir sind alle offen. Offen für die Ideen anderer. Für ihre Eigenheiten und ihre Talente. Das enge Zusammenleben im crossfunktionalen Team kommt ohne diese Offenheit nicht aus.

Wie sehr es mit neuen Technologien, Vorgehensweisen und Praktiken. Nun, offen wären wir schon, wenn da nicht so viele Regeln und Standards wären. Und auch die firmeninterne Compliance ist zu beachten. Also bitte zuerst die Befehlskette durchlaufen.

Offen sein bedeutet aber auch zu akzeptieren, dass der Kunde neue Ideen für das Produkt haben kann auch spät in der Produktentwicklung. Er darf seine Wünsche ändern, dem Markt anpassen.

Zudem muss man offen sein, um mit Kritik an der eigenen Person oder am Team richtig umgehen zu können. Nur so wird es möglich sich laufend zu verbessern.

Respekt

Und dann ist da viel zitierte Respekt. Gleichzeitig ziehen Tester über Entwickler her und Entwickler über Requirements Engineers. Die Product Owner sind doch wieder nur Projektleiter und benehmen sich als Chefs. Und die ScrumMaster machen eigentlich keinen richtigen Job, nach dem Motto: „Rapportier du mal am Daily, was du den lieben langen Tag tust.“.

Und wie ist es um den Respekt für den Anwender bestellt. Habe ich da ein „Der ja ja wirklich keine Ahnung was Sache ist. Das machen wir ganz anders.“ gehört?

Fazit

Dies waren nur ein paar ausgewählte Punkte, die zeigen, dass die Scrum Werte die Grundlage für jeglichen Prozess, für jegliche Zusammenarbeit und jeglichen Erfolg in der Anwendung von Scrum sind. Lasse sie weg und alles bricht zusammen.

Und das schöne ist, dass wir alle merken, wenn die Werte nur aufgesetzt, vorgespielt sind. Wir haben alle die Begabung ein Fake in dieser Hinsicht zu durchschauen.

Aber das noch schönere ist, dass wir alle in der Lage sind, diese Werte selbst an den Tag zu legen und dadurch zum Erfolg von Scrum substanziell beizutragen.