In der letzten Folge haben wir dir die 5 Scrum Events – den Sprint, das Scrum Daily, das Sprint Planning, Sprint Review und die Sprint Retrospektive vorgestellt und die Personen, die anwesend sein müssen und welche anwesend sein können.
Schau also unbedingt hier vorbei falls du darüber mehr lernen willst.
Am 5.März hatten wir die Ehre im Pilot des neuesten Workshop „The value in the Scrum Values“ (= Der Wert der Scrum Werte) von Gunther Verheyen mit dabei zu sein und uns mit ihm und 15 weiteren Erfahrenen Scrum Mastern und Agile Coaches zu dem Thema austauschen zu können.
Gunther ist Professional Scrum Trainer von scrum.org seit vielen Jahren und sein bekanntester Artikel (Link) dreht sich genau um das Thema der Scrum Werte.
Daher freuen wir uns jetzt mit dir unsere Erkenntnisse aus dem Workshop und unsere Erfahrungen hier in diesem Artikel zu teilen. Wir freuen uns schon auf deine Fragen und Feedback.
Jetzt soll es aber um die Scrum Werte gehen. Diese sind grundlegend für Scrum und sorgen für ein guten Umgang miteinander und für (psychologische) Sicherheit (engl. psychological Safety) am Arbeitsplatz.
Und hier kommt schon die erste Erkenntnis aus dem Workshop. Gunther sagt nämlich, und diese Meinung teilen wir auf Grund unserer Erfahrung auch:
Scrum is more about behaviour than it is about processes.
Also „In Scrum geht es mehr um Verhalten als um Prozesse.“ Natürlich sind die Scrum Events eine Art Grundlage für Scrum (siehe Agile Trinity), denn sie sorgen für den Rahmen von Scrum. Allerdings werden wir schnell merken, dass wir, wenn wir uns nur an die Scrum Events halten und nicht auch die Prinzipien von Agilität und die Scrum Werte leben, schnell an eine Grenze kommen und die Verbesserungen schnell abnehmen.
Um die Scrum Werte wirklich leben zu können, müssen wir diesen auch eine Bedeutung geben und uns im klaren sein, dass jeder diese 5 Worte sonst anders interpretiert. Im folgenden findest du, wie wir die Werte interpretieren und wie nicht. Das muss natürlich mit den Interpretationen anderer nicht übereinstimmen. Daher ist es umso wichtiger, dass jeder sich aber im Klaren ist, was für ihn/sie persönlich diese Werte bedeuten.
Mut bedeutet für uns zu allererst Probleme anzusprechen und ansprechen zu können, sowie zu sagen, dass man etwas nicht weiß oder etwas nicht verstanden hat und Hilfe benötigt. Diesen Mut sollte jeder im Scrum Team, aber auch jeder Manager haben. Denn nur dann können wir Probleme schnell verstehen und lösen. Dazu gibt es auch ein sehr empfehlenswertes Video von Simon Sinek (leider nur auf englisch).
Mutig zu sein bedeutet aber auch Verantwortung zu übernehmen für das Produkt, an dem man gerade arbeitet. Dies ist ein Problem, das wir in den Firmen leider immer wieder sehen. Jetzt da es keine klar vorgeschriebenen Verantwortlichkeiten mehr gibt, fühlt sich auf einmal keiner mehr verantwortlich und jeder zeigt auf den andern. Aber das ist NICHT Scrum. Ein guter Agile Coach oder Lean Change Agent macht die Verantwortlichkeiten, die es in Scrum auf jeden Fall gibt (besonders mit dem neuen Scrum Guide 2020), von Anfang an klar. Wenn das klar ist, werden wir uns alle so viele Stunden sparen, um herauszufinden, wer eigentlich für was verantwortlich ist. Und ja das kann auch mal Tage dauern und mehr als 5 Stationen sein.
Für uns bedeutet es aber nicht mutig zu sein, wenn jemand unmögliche Deadlines einführt und sagt, man soll doch mutig sein und es wenigstens versuchen. Das hat nichts mit Mut zu tun, sondern das ist ein Versuch weiterhin mit klassischen Methoden zu arbeiten aber mit Scrum Begriffen zu argumentieren.
Genauso gehört kein Mut dazu Überstunden einzufordern, wann immer es geht. Klar kann es vorkommen, dass Überstunden mal nötig sind, aber das sollte nicht die Regel sein, da härter/mehr arbeiten nicht skaliert. Sollte das Team aber genug Verantwortung/Autonomie bekommen und eine klare Vision haben, so wird jeder im Team von sich aus verstehen, dass für das aktuelle Sprint Ziel nunmal Überstunden nötig sind. Dafür muss aber jeder die Voraussetzungen selbst schaffen!
Mut hängt für uns natürlich eng mit Offenheit der anderen im Team und auch der Manager zusammen, darum gehen wir darauf als nächstes ein.
Kommen wir zum Thema Offenheit. Hier geht es unserer Meinung nach stark darum, offen zu sein für andere Ideen. Vor allem wenn diese der eigenen Meinung widersprechen. Jeder sollte versuchen möglichst die ganze Intelligenz des Teams zu nutzen und so auf die, nach aktuellem Wissen, beste Lösung für das Problem oder für die Implementierung des Produkts kommen. Dabei ist es vollkommen irrelevant wie viele Jahre Erfahrung jemand hat. Selbst das neueste Teammitglied kann wertvolle Beiträge liefern, da er/sie im Job davor etwas sehr ähnliches implementiert hat (hier sollte man natürlich aufpassen, da keine zwei Probleme gleich sind).
Offenheit bedeutet für uns aber auch, dass wir offen sind unser Wissen mit anderen zu teilen. Es gibt ein sehr passendes Zitat hierzu:
We rise by lifting others – Robert Ingersoll
Das bedeutet so viel wie, wir steigen nur auf, indem wir anderen hoch helfen. Dieses teilen von Wissen mit anderen bringt uns alle weiter. Ich denke jeder von uns kennt die Situation in der wir jemand anderem etwas erklärt haben und dann macht es auf einmal „Klick“ und wir selbst haben das Problem besser verstanden und kommen bei unserem eigenen Problem voran. Also sei offen und hilf anderen. Du hilfst dir damit selbst.
Offenheit bedeutet aber nicht, dass nur weil das Team z.B. offen seine Velocity darstellt, dass jeder seine Schlüsse daraus ziehen darf und das Team mit einem anderen Team vergleichen sollte.
Velocity ist keine Leistungs-Metrik, sondern eine Planungs-Metrik!
Die Velocity ist, wenn man sie richtig nutzt eine sehr gute Metrik. Leider wird diese nur all zu oft sehr falsch verwendet und ist damit nutzlos.
Respekt bedeutet für uns vor allem ein respektvoller Umgang miteinander. Egal welche Rolle wir einnehmen. Dazu gehört es z.B. niemand zu unterbrechen während er spricht, sondern die Hand zu heben (geht ja auch in Zoom, MS Teams, … 😉 ). Es ist aber genauso wenig respektvoll, das man, nur weil einen keiner mehr unterbricht, ewig reden darf. Respekt heißt auch sich in seinen Antworten kurz zu halten und andere auch zu Wort kommen zu lassen.
Respekt heißt dahingegen aber nicht, dass man alles akzeptieren muss, was einem aufgetragen wird. Ganz im Gegenteil. Man sollte respektvoll mit der Anfrage umgehen, aber genauso gehört es dazu „Nein“ zu sagen, wenn man die Anfrage nicht in der Zeit und/oder Qualität abliefern kann und deshalb um einen späteren Zeitpunkt bittet. Genauso ist es respektvoll sich selbst gegenüber, wenn man die eigene Zeit wertschätzt und bittet die Anfrage über den Product Owner priorisieren zu lassen, um die Anfrage in der gewünschten Qualität abliefern zu können und nicht nebenher.
Das englische Wort „Commitment“ ist nicht einfach zu übersetzen, aber unserer Meinung trifft es am besten das Wort „Engagement“. Weil Engagement, sowie auch Commitment, bedeuten ein Versprechen einen bestimmten Aufwand in die Erreichung des Ziels zu stecken, aber es bedeutet nicht, dass man verspricht ein Ergebnis zu erreichen.
Dieser Wert wird leider all zu oft falsch interpretiert und deshalb falsch ausgenutzt. Das Engagement des Teams ist nämlich dem Sprint Ziel gegenüber (und dieses bietet Spielraum, wie und was genau man erreicht) und nicht gegenüber einzelner Items oder User-Stories.
Genau über dieses Sprint Goal z.B. hängt Engagement mit dem nächsten und letzten Scrum Wert, dem Fokus, zusammen.
Fokus bedeutet für uns, dass wir uns auf die Erreichung des Sprint Goals fokussieren und nicht versuchen noch möglichst viele andere Anfragen auch noch zu beantworten. Das passiert leider all zu oft, da man gerne anderen helfen will (und das ist natürlich gut so), aber man sollte nie vergessen, dass am Ende des Sprints ein Mehrwert für den Nutzer/Kunde stehen sollte.
Fokus bedeutet auch, dass man sich in dem jeweiligen Meeting darauf fokussiert, was erreicht werden soll. Also auf das Ziel des Meetings fokussiert. Was wir z.B. sehr häufig in der Arbeit mit Teams feststellen, ist, dass während des Dailies schon versucht wird das angesprochene Problem zu lösen. Das ist aber nicht Teil des Dailies. Was wir daher machen ist eine Art „Parkplatz“ für solche Themen zu haben, die dann im Anschluss an das Daily direkt von den benötigten Leuten besprochen werden können.
Fokus bedeutet aber nicht, dass wir NUR an dem einen Thema arbeiten dürfen und sonst nichts. Man muss abwägen, welches Thema z.B. wie viele Teams blockiert bzw. welchen Mehrwert liefert. Hier möchten wir auf das Konzept des „Swarming“ (=ausschwärmen) aus DevOps hinweisen. Das bedeutet, dass sobald ein Thema mehrere Teams betrifft oder pipelines blockiert, sollte dies durchaus so schnell wie möglich gelöst werden.
Allerdings kennen wir auch die Leute, bei denen alles super dringend ist und am besten gestern schon fertig wäre. Hier darf man auch gerne mal auf den Product Owner verweisen und sich dann wieder auf das Sprint Ziel fokussieren.
Natürlich war das jetzt keine vollständige Liste aller Punkte, die wir für die Scrum Werte wichtig bzw. nicht wichtig erachten (das würde jeden Rahmen sprengen). Was wir damit erreichen wollen ist einen Austausch und eine respektvolle Diskussion anzustoßen, da die Scrum Werte ein ganz entscheidender Baustein für den Erfolg einer Agilen Transformation und den Erfolg von Scrum an sich darstellen. Der Grund dafür ist einfach:
Values drive Behaviour.
Unsere Werte und auch die Werte unseres Umfelds (Firma, Beziehung,…) beeinflussen unser Verhalten und nur mit gemeinsamen Werten werden wir den maximalen Erfolg und Zufriedenheit erzielen.
Ich bin mir sicher, dass du dem ein oder anderen Punkt nicht zustimmen wirst. Und das ist auch gut so! Lass uns gerne in den Kommentaren dazu deine Meinung da, wie du die Scrum Werte interpretierst und auch welche Punkt du anders siehst.
Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!
Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Rahmenwerk gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:
Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.
Und auch der ist komplett kostenlos. Du findest den Glossar hier:
In der nächsten Folge stellen wir dir Empirie in Scrum genauer vor. Also was genau bedeutet Empirie im Kontext von Scrum? Was benötigen wir dafür? Was hat das mit den Scrum Events und Scrum Artefakten zu tun? Wir werden dir hierbei genau erklären, wie Empirie mit Transparenz, regelmäßiger Überprüfung und Anpassung zusammenhängt.
Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Manager werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:
Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:
Du stehst auf bewegtes Bild? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.
Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.
Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.
Wir freuen uns auf dich.
Deine Agile Coach Academy Gründer Ben und Alex