- Die hinter Scrum stehenden Werte (Mut, Offenheit, Vertrauen, Fokus...) tauchen nicht im ScrumGuide auf
- Forecast ist "schwächer" als Commitment
- Das "Team" heißt jetzt "Development Team"
- Burndowns sind verschwunden
- Es gibt keine Releaseplanung mehr
Die meisten Diskussionspunkte führen deshalb zu erhitzten Gemütern, weil die Idee des ScrumGuides sich geändert hat. Während in der Vergangenheit versucht wurde, "ganz Scrum" zu beschreiben ist die neue Idee, ein "Regelbuch" herauszubringen, das auch nur dieses enthält: Die Regeln. Strategien, Best Practices und Hintergründe sind nicht Bestandteil dieser "Spielanleitung", sondern separate Dokumente - wenngleich auch sehr wichtig.
Sehen wir uns vor diesem Hintergrund die einzelnen Punkte etwas genauer an:
- Die hinter Scrum stehenden Werte fehlen. Sie sind das, worauf Scrum aufbaut und weshalb Scrum entwickelt wurde. Unbestreitbar sind sie das Wichtigste an Scrum überhaupt (zumindest für mich). Trotzdem stehen sie genau da: Hinter Scrum. Sie sind nicht Bestandteil des Regelwerkes, sondern der Grund dafür, dass bestimmte Regeln entwickelt wurden. Es ist zwar wünschenswert, aber nicht notwendig, dass jeder Anwender von Scrum versteht, warum bestimmte Regeln (z.B. Retrospektive oder Timeboxing) existieren - solange er sie befolgt. Meine Vision ist trotzdem, die Werte von Scrum in die Welt hinaus zu tragen (dazu brauche ich aber den ScrumGuide nicht).
- Forecast ist schwächer als Commitment. Auch hier kann es helfen, den Urheber zu fragen. "Commit" war in Scrum schon immer als "forecast" gemeint. Um es noch etwas mehr zu präzisieren: Schon immer hat das Team versprochen, fokussiert und mit Hochdruck auf das Sprintziel (bzw. die PBIs) hinzuarbeiten, bei gleichzeitiger Einhaltung der DoD. Schon immer galt bei der Auswahl der PBIs, dass das Team zwar glaubt diese zu schaffen, sich aber nicht sicher ist. Das wurde in der Vergangenheit aber von den "Druckaufbauern" und "Kontrollfreaks" missverstanden: Diese Fraktionen werteten auch den zweiten Teil als "Das Team hat versprochen, das Ziel zu erreichen". Das ist natürlich falsch und wird durch "forecast" richtig gestellt. Noch etwas: Wer es nötig hat, hier Druck aufzubauen, sollte sich fragen, ob er seinem Team vertraut ("trust" ist übrigens ein Grundwert von Scrum). Menschen denken unter Druck nicht schneller.
- Manch einer hat Angst, dass die Umfirmierung von "Team" zu "Development Team" dazu führt, dass einige der Teammitglieder sich angegriffen fühlen. Schließlich "entwickeln" Tester und UI-Experten ja nicht. Oder etwa doch? In meinen Augen ist "Entwicklung" nicht gleichbedeutend mit "Programmierung", sondern bezeichnet den Akt der Produkterstellung von der Idee bis zur Auslieferung. Wenn sich jetzt Teammitglieder darüber beschweren, wird eher ein schon länger existierendes Problem deutlich. Nachforschen kann hier nicht schaden.
- Kann man Scrum auch ohne Burndowns machen? Na klar! Die Dinger sind zwar einfach und oft hilfreich, aber eben nicht maßgeblich für Scrum. Ich kann meinen Fortschritt auch anders visualisieren. Zum Beispiel mit einem Taskboard. Oder mit Burnup-Charts. Oder wie es eben sonst nützlich und angebracht in meinem Team ist.
- Die fehlende Releaseplanung hat auch mich zunächst irritiert. Dann ist mir aber der folgende Leitsatz eingefallen: "Was braucht man, um mit Scrum beginnen zu können? - ein Ziel und ein Team!". Nicht in jedem Setting ist eine Releaseplanung sinnvoll. Außerdem ist eigentlich jeder Sprint ein Release ("potentially shippable product increment"), daher sollte man wohl eher von einer "Langfristplanung" sprechen. Diese sollte wiederum jeder PO haben - in dem Maße, in dem es für sein Team und sein Projekt/Produkt sinnvoll ist.
Es kann immer helfen, sich auch mit den Hintergründen einer Angelegenheit zu befassen, anstatt nur die eigenen Schlüsse zu ziehen. "Kommunikation über Dokumentation" sollte normalerweise auch bedeuten, dass ich zunächst den Verursacher meines schlechten Bauchgefühls befrage, bevor ich ein Dokument gegen ihn verfasse. Ken redet übrigens gerne über den ScrumGuide: Fragt ihn doch einfach, wenn ihr einen bestimmten Punkt diskutieren wollt.