8 Top-Gründe, warum Du Scrum nicht deinem Scrum Master überlassen solltest!

Bist du vielleicht einer der Menschen, sich auf einmal in einem Scrum-Umfeld wiedergefunden haben. Auf einmal gab es Backlogs und Sprint-Reviews und Stories und Definitions of Ready oder Done und dies und das. Und niemand  hat sich die Zeit dafür genommen, dir in Ruhe zu erklären, warum was das ist und wozu das eigentlich gut ist.

Oder bist du einer von denen, die richtig (zu Recht) stolz auf ihre Python- oder Spock- oder Kafka-Kenntnisse sind, und die einfach nur ein richtig cooles Produkt bauen wollen, und mit dem ganzen Scrum-Dingsbums einfach nichts am Hut haben wollen?

Dann ist dieser Artikel genau für dich!

Und möglicherweise passt er dir gar nicht, denn ich möchte dir hier 8 gute Gründe vorstellen, warum du trotzdem Scrum nicht einfach deinem Scrum Master überlassen solltest. Es fiel mir tatsächlich gar nicht schwer diese 8 zu finden. Vermutlich heißt das, es gibt noch deutlich mehr. Wenn dir noch weitere einfallen, würde es mich sehr interessieren, sie zu hören. Schreib sie einfach in einen Kommentar.

Aber genug der Vorrede, los geht’s mit dem ersten Grund.

Grund #1: Du hast gar keinen Scrum Master!

Leider ist es gerade bei Unternehmen, gerade erst dabei sind, den Nutzen von Scrum für sich zu entdecken, häufig so, dass der Mehrwert, den ein guter Scrum Master für ein Team bringt, völlig unklar ist. Und wer investiert schon in etwas, dass er nicht versteht? Also darf einer von euch Entwickler:innen nebenher den Scrum Master spielen. Oder schlimmer noch: es herrscht die Denke „Solange ihr etwas macht, dass ihr Daily nennt und etwas, dass ihr Backlog nennt, in Jira pflegt, ist schon alles gut.“ Ist es leider nicht!

In so einer Situation ist es echt hilfreich zu verstehen, was deine Verantwortung als Entwickler:in ist, welcher Gestaltungsraum bei dir liegt, und welche Verantwortungsbereiche gerade brach liegen, weil es eben keinen Scrum Master gibt.

Grund #2: Dein Scrum Master hat nur einen Einführungskurs besucht und ist total grün hinter den Ohren

Natürlich, jede Reise beginnt mit einem ersten Schritt. Dein Scrum Master hat sich immerhin mal einige Stunden intensiv mit dem Thema beschäftigt und vermutlich einige wertvolle Erkenntnisse mitgebracht. Das ist toll! Jemand mit einem “Seepferdchen” kann erheblich besser schwimmen als ein Nichtschwimmer.

Aber ich würde nicht darauf vertrauen, dass so jemand dich und dein Team sicher durch die vorausliegenden Stromschwellen geleiten wird.

In so einer Situation ist es extrem hilfreich, selbst über Scrum Bescheid zu wissen. Vermutlich wirst du aus einer Scrum-Einführung Dinge mitnehmen, die an deinem Scrum Master vorbeigegangen sind, z.B. praktische Alternativen zu Planning Poker oder die Idee hinter dem Begriff “technische Schulden”. Wenn ihr euer Wissen und eure Perspektiven übereinanderlegt und neugierig seid, macht es vielleicht sogar auf einmal Spaß, gemeinsam zu lernen.

Grund #3: Das Wissen Deines Scrum Masters besteht aus uralten Mythen

Immer wieder treffe ich auf Scrum Master, die vor vielen, vielen Jahren von jemand, der es irgendwann davor von jemand anderem gehört hat, eine Idee von Scrum aufgeschnappt haben. Und seitdem war ihr Alltag so hektisch, dass sie keine Zeit hatten, am Ball zu bleiben und das sich weiter entwickelnde Verständnis von Scrum aufzunehmen.

Hinweise darauf sind z.B.:

• Dein Scrum Master denkt, er muss das Daily Scrum moderieren, indem er jeden im “Developer-Team” die berühmten (berüchtigten) drei Fragen beantworten lässt. Und dabei ist er schon 3 Mythen aufgesessen: Mythos 1: Der Scrum Master muss das Daily Scrum moderieren. Mythos 2: Die Developer bilden ein eigenes Sub-Team.  Mythos 3: Scrum schreibt vor, dass die Developer im Daily Scrum diese 3 Fragen beantworten müssen.
• Er glaubt, dass das Ziel des Sprint Reviews eine Abnahme durch die Stakeholder ist.
• Er glaubt, dass das Sprintziel klar ist, wenn die Developer im Sprint Planing sich darauf committen, eine bestimmte Menge von “Stories” fertig zu kriegen.

Da ist es wirklich hilfreich, diesen Mythen ein eigenes, aktuelles Verständnis entgegen setzen zu können. Scrum funktioniert erheblich besser, wenn man nicht an diese Mythen glaubt.

Grund #4: Dein Unternehmen hat nicht verstanden, welchen Mehrwert ein guter Scrum Master liefert und schickt euch den billigsten, den sie kriegen konnten

Das kommt gerne in Situationen vor, in denen Unternehmen bei der Einführung von Scrum bemerken, dass sie keine eigene Expertise im Hause haben. Dann wird bei externen Beratern gesucht, und da man noch nicht so gut darin ist, gute von weniger guten Scrum Mastern zu unterscheiden, nimmt man halt den billigsten.

Und der hilft euch vermutlich genau gar nichts. Wenn ihr richtig Glück habt, seid ihr in der Situation von Grund #2 und könnt dann gemeinsam versuchen, das Beste daraus zu machen.Vielleicht erwischt ihr aber auch einfach einen richtig schlechten, einen Scrum Master from Hell, der sich gar keine Mühe gibt, sich weiter zu entwickeln, und seine Zeit lieber als Scrum Polizist verbringt und Scrum euch mit seiner speziellen DarkScrum-Version zur Hölle auf Erden macht.

Da ist es super wertvoll, wenn du dank deines eigenen Wissens über Scrum so jemanden entlarven und wieder dahin zurückschicken kannst, wo er (oder sie) hergekommen ist.

Grund #5: Dein Scrum Master drückt euch Dinge oder Abläufe auf, die nicht hilfreich sind

Sie meint es gut, sie will euch helfen, aber es ist einfach nicht hilfreich. Das passiert nicht nur Anfängern gelegentlich. Und da ist man als Scrum Master – glaub es mir! – super froh, wenn es unter den Entwicklern jemand gibt, der eine eigene Perspektive mitbringt, gespeist aus eigenem Wissen und aufmerksam gemachten Erfahrungen. Und dann nicht nur ja und Amen sagt, sondern diesen anderen Vorschlag auch einbringt.

Sei doch du diese:r Entwickler:in.

Grund #6: “Aber im Scrum Guide steht…” ist der Lieblingssatz eures Scrum Masters

Für jedes Element von Scrum gibt es erheblich bessere Gründe als “Es steht im Scrum Guide”. Eine wichtige Aufgabe eures Scrum Masters besteht darin, diese Gründe in euren Kontext zu übersetzen und konkret verstehbar zu machen. Ohne zu verstehen kannst du auch nicht mitdenken. Das frustriert, und das lässt Verbesserungspotenzial ungenutzt links liegen. Und zwar ein gewaltiges Potenzial, denn Entwickler sind meiner Erfahrung nach sehr feinfühlig im Aufdecken von Ineffizienzen. Aber wie sollst du beurteilen, ob etwas überflüssig ist oder in eurem Kontext besser anders gemacht werden sollte, wenn du den Sinn dahinter gar nicht verstanden hast.

Da ist es sehr wertvoll, selbst Ahnung zu haben und fundiert mitdenken zu können. Und in der dadurch entstehenden Arbeitsumgebung macht die Arbeit auch mehr Freude.

Grund #7: Euer Scrum sieht noch genauso aus wie vor 6 Monaten

Ein ganz wesentliches Element von Scrum ist eine echte, wirksame Feedback-Schleife, die zu kontinuierlichen Verbesserungen in der Art, wie ihr arbeitet, führt. Es geht nicht darum, einen dokumentierten Prozess möglichst perfekt abzuspulen. Wenn euer Scrum Master darauf fokussiert, hat er ein ganz wichtiges Prinzip hinter Scrum (noch) nicht verstanden.

Vielleicht darf der Anstoß zum echten Anders-und-besser-machen von dir kommen! Mit deinem Wissen über Scrum findest du so für dein Team einen Ausweg aus einer monotonen, ineffizienten Tretmühle.

Grund #8: Vielleicht wird ja in ein paar Jahren “Technical Agile Coach” für dich zu einer spannenden Karriereperspektive!

Das ist vielleicht sogar der beste Grund! Manche Developer:innen möchten auf Dauer nicht in der Entwickler-Rolle bleiben, sondern sie entwickeln Freude daran, ihr Wissen und ihre Erfahrung an andere weiter zu geben und Organisationen und Teams dabei zu helfen, richtig gute Software zu entwickeln. Mit hoher Qualität und dabei flexibel neue Marktsituationen schneller aufgreifend als alle anderen.

Aber welche Weiterbildungsmöglichkeiten zum Technical Agile Coach gibt es für Developer? Abseits von Zertifikaten zu konkreten Technologien leider nicht sehr viele, insbesondere wenn man sich dazu noch wünscht, dass die Weiterbildung auch mit anerkannten Zertifikaten dokumentiert wird, was ja bei vielen Arbeitgebern sehr gern gesehen ist.

Eine der hochwertigsten und langfristig gedachten Ansätze ist aus meiner Sicht der von der Scrum Alliance angebotene Weg zum Certified Scrum Professional® als Developer (CSP-D), der “Path-to-CSP” für Developer. Von dort aus hast du dann sogar anschließend die Möglichkeit, Certified Team Coach®, Certified Enterprise Coach® oder auch Certified Scrum Trainer® zu werden. Und keine Angst, es dreht sich nicht immer nur um Scrum, im Gegenteil. Je weiter du auf diesem Weg voranschreitet, desto desto mehr geht es um Technical Agile Leadership und wie du deine persönlichen Stärken einbringen und entfalten kannst, und immer weniger um Scrum.

Ok, ich will Scrum nicht meinem Scrum Master überlassen. Was kann ich tun?

Natürlich gibt es viele Möglichkeiten, mehr über Scrum zu lernen. Doch achte darauf, dass du deine wertvolle Zeit nicht in veraltete Materialien oder minderwertige Kurse investierst. Im Internet findest du viel hervorragenden Content, aber leider noch mehr Schrott. Und es ist nicht immer einfach, selbst die Spreu vom Weizen zu trennen.

Und wenn du außerdem gerne interaktiv und durch Erleben lernst, ist eine sehr empfehlenswerte Möglichkeit, einen Certified Scrum Developer® (CSD®) Kurs zu besuchen. Er entspricht vom Level her einem Certified ScrumMaster® (CSM®) Kurs, vermittelt aber ein tiefes Verständnis von Scrum aus einer konsequenten Entwickler-Perspektive und adressiert darüber hinaus wichtige Engineering- und Collaboration-Techniken, die die erfolgreiche und nachhaltige Produktentwicklung mit Scrum erst möglich machen.

Wenn du also als Developer Scrum besser verstehen und für dich nutzen lernen willst, damit du nicht von deinem Scrum Master abhängig bist, dann besuche nicht einen CSM-Kurs, sondern lieber einen speziell für Entwickler:innen gestalteten CSD-Kurs. Und ganz nebenbei öffnest du dir einen Weg zu einem Technical Agile Coach. Denn der Path-to-CSP der Scrum Alliance führt für Entwickler vom CSD über den Advanced CSD (A-CSD) bis zum Certified Scrum Professional als Developer (CSP-D).

Neugierig geworden? Dann wirf doch in einen Blick in unser Kursangebot zum CSD.

Und sehr gerne würde ich noch weitere Gründe hören, warum du dich in punkto Scrum-Kompetenz lieber nicht komplett auf deinen Scrum Master verlassen möchtest. Schreib sie einfach in die Kommentare unter den Artikel.