20 Hilferufe von Scrum Mastern 🇩🇪

In Kürze: Scrum Master Fehlverhalten

Die Gründe, warum Scrum Master den Geist des Scrum Guides verletzen, sind vielschichtig. Scrum Master Fehlverhalten reichen von unpassenden persönlichen Eigenschaften über die Verfolgung persönlicher Agenden bis hin zur Frustration mit dem Scrum Team selbst.

Lesen Sie weiter und erfahren Sie in diesem Beitrag über Scrum Anti-Patterns, wie Sie erkennen können, ob Ihr Scrum Master Unterstützung benötigt.

🗳 Update: Join the poll and its lively discussion on LinkedIn.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 35.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Der Scrum Master nach dem Scrum Guide

Bevor wir mögliche Gründe und Erscheinungsformen des Fehlverhaltens von Scrum Mastern analysieren, wollen wir noch einmal darauf eingehen, wie der Scrum Guide die Rolle des Scrum Masters definiert:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

Quelle: Scrum Guide 2020.

Der Schlüssel zur Definition der Rolle des Scrum Masters ist der Führungsaspekt. (Schade, dass dieser nicht mehr als „dienende Führung bzw. Servant Leadership“ bezeichnet wird; ich fand diese Beschreibung besser geeignet.) Leider ist es in den meisten Fällen von Scrum Master Fehlverhalten jedoch genau dieser Aspekt, den eine Person nicht erfüllt; siehe auch die detaillierten Listen der Leistungen im Scrum Guide, die der Scrum Master für den Product Owner, die Entwickler und die Organisation erbringt.

Mögliche Gründe, warum Scrum-Master den Scrum-Pfad verlassen

Die Gründe, warum Scrum Master den Geist des Scrum Guides verletzen, sind vielschichtig. Sie reichen von unpassenden persönlichen Eigenschaften und der Verfolgung persönlicher Agenden bis hin zur Frustration mit dem Scrum Team selbst. Einige oft beobachtete Gründe sind:

• Unwissenheit oder Bequemlichkeit: Ein Scrum-Standard passt zu jedem Team. Ihr Scrum Master hat das Handwerk in einem bestimmten Kontext gelernt und rollt nun genau dieses Muster in jeder Organisation, in der er oder sie tätig ist, unabhängig vom Kontext aus. Warum sollten Sie sich die Mühe machen, zu lehren, zu coachen und zu begleiten, wenn Sie den „richtigen Weg“ dem Scrum-Team auch direkt eintrichtern können?
• Ungeduld: Geduld ist eine kritische Ressource, die ein erfolgreicher Scrum Master im Überfluss aufbringen muss. Natürlich macht es keinen Spaß, ein und dasselbe Problem mehrmals anzusprechen, wenn die Lösung so offensichtlich ist — aus der Perspektive des Scrum Masters. Warum dem Team also nicht immer wieder sagen, wie man es „richtig“ macht, um so effizienter zu werden? Schade nur, dass Scrum anderen nicht aufgezwungen werden kann, sondern von diesen freiwillig angenommen werden muss — das ist die Essenz der Selbstorganisation.
• Dogmatismus: Einige Scrum Master glauben daran, den Scrum Guide buchstäblich anwenden zu müssen, was unweigerlich zu Reibungsverlusten führt, da Scrum ein Framework und keine Methodik ist. Trotzdem fühlt es sich gut an, Scrum auf diese Weise zu unterrichten:
  • Die Teammitglieder kommen und bitten um Hilfe; jetzt hat der Scrum Master eine Aufgabe.
  • Wenn die Mitglieder des Scrum-Teams die Regeln befolgen, hat der Scrum Master Einfluss bzw. Autorität.
  • Zu den wenigen Auserwählten zu gehören, die den Scrum Guide „richtig“ interpretieren, sichert Status und Respekt unter den Teamkollegen und in der gesamten Organisation.
  • Der Scrum Master kann den Fortschritt oder den Erfolg des Scrum-Teams ohne Weiteres auf seine Lehrtätigkeit zurückführen; jetzt hat man auch einen Beweis für den “Scrum-Meister”.
  • Schließlich ist die Beherrschung von Scrum ein überzeugendes Argument für die Organisation, den dogmatischen Scrum Master auf der Gehaltsliste zu belassen. Offenbar brauchen die Scrum-Teams einen Interpreten des Scrum Guide, um die Vorteile des Frameworks zu nutzen.
• Von Laissez-faire zu Gleichgültigkeit: Das Team in eine Richtung zu lenken, in der die Teammitglieder selbst eine Lösung für ein Problem finden können, ist gute Führung. Sie ohne Führung laufen zu lassen, führt jedoch wahrscheinlich zu Gleichgültigkeit oder, schlimmer noch, zu einer Ist-mir-doch-egal-Mentalität, getarnt mit dem Mantel der „Selbstorganisation“.
• Führe mich zum Schotter—der Scrum Master-Blender: Insgeheim ist der Scrum Master überzeugt, dass dieses Scrum-Ding eine Modeerscheinung ist, erkennt aber, dass es eine gut bezahlte ist: „Ich werde den Nachfragerückgang nach Projektmanagern mit einem Scrum-Master-Zertifikat überbrücken. Wie schwer kann das wohl sein — das Handbuch umfasst nur 13 Seiten?“ Diese Überzeugung wird sich mit der Zeit unweigerlich offenbaren.
• Perlen vor Säue — der frustrierte Scrum Master: Der Scrum Master arbeitet sich seit Monaten die Finger wund, aber das Team reagiert nicht auf die Anstrengung und der Grad der Frustration wächst. Es gibt viele mögliche Gründe für ein Scheitern auf dieser Ebene: das fehlende Sponsoring von der C-Ebene der Organisation, die weit verbreitete Überzeugung, dass „Agile“ nur der neueste Management-Trend und damit ignorierbar ist. Die Teamzusammensetzung ist falsch. Es gibt keine psychologische Sicherheit, um Probleme im Team anzugehen, und die Unternehmenskultur legt weder Wert auf Transparenz noch auf radikale Offenheit. Oder die einzelnen Teammitglieder haben persönliche Agenden, die nicht mit dem Ziel des Teams abgestimmt sind — um nur einige Gründe zu nennen. Gelingt es in diesem Kontext nicht, das Ruder herumzureißen, wird das Team wahrscheinlich seinen Scrum-Master verlieren. (Bitte beachten Sie, dass der Scrum Master diese Probleme nicht selbst lösen kann. Dies erfordert den Einsatz des gesamten Scrum-Teams und der Organisation.)
• Der taktische Scrum Master: Diese Scrum Master hat sich von der Personalabteilung überzeugen lassen, dass der Scrum Master eine Position ist, keine Rolle. Es gibt nunmehr einen Karrierepfad vom Junior-Scrum-Master zum Head Agile Coaching. Folglich beschränken taktische Scrum Master ihre Arbeit strikt auf das Scrum Team und ignorieren ihr Tätigkeitsfeld in der Organisation, bis sie zum entsprechenden Level befördert werden.
• Der Anfänger: Wenn Sie Occam’s Razor auf die Situation eines unterdurchschnittlichen Scrum Masters anwenden, können Sie ggf. herausfinden, dass Ihr Scrum Master nicht ignorant oder inkompetent, sondern lediglich unerfahren ist. Da wir alle regelmäßig neue Fertigkeiten erlernen müssen, sollten wir in diesem Fall nachsichtig mit ihnen sein und ihr Lernen unterstützen. Scrum zu meistern ist eine Reise, kein Ziel, und man reist in der Regel nicht allein.

Der Scrum Master als Agiler Manager

In meinen Augen ist „agiles Management“ ein Widerspruch in sich. Der primäre Zweck jeder agilen Praxis ist es, diejenigen, die einem Problem am nächsten sind, in die Lage zu versetzen, eine Lösung für dieses zu finden. Mit anderen Worten, das Team soll sich im Laufe der Zeit selbst organisieren und so der Organisation ein angemessenes Maß an geschäftlicher Agilität verleihen. Selbstorganisierende Teams brauchen Coaches, Mentoren und dienende Führungskräfte (Servant Leader), aber keinen Manager im tayloristischen Sinne des Wortes.

Achten Sie daher auf diejenigen Scrum-Master-Fehlverhalten, die dieser ‚agilen Manager‘-Einstellung entsprechen:

• Management: Selbstorganisation bedeutet nicht die Abwesenheit von Management: Warum sollte ein Scrum Team z. B. die Verantwortung für die Lohn- und Gehaltsabrechnung übernehmen? Würde das bei der Wertschöpfung zugunsten der Kunden helfen? Wahrscheinlich weniger. Ein selbstorganisierendes Team zu sein, bedeutet also nicht die Abwesenheit von Management an sich. Es bedeutet aber, dass das Team kein Mikromanagement braucht, vergleichbar mit der Praxis in einem Montagewerk von General Motors im Jahr 1926. Der Scrum Master ist daher weder ein Vorgesetzter noch ein Disponent.
• Das Wort bei Meetings erteilen: Wenn Teammitglieder den Blickkontakt mit dem Scrum Master suchen, bevor sie das Wort ergreifen, hat der Scrum Master bereits die Moderationsrolle zu Gunsten des Vorgesetzten-Modus verlassen.
• Das Scrum-Team abhängig halten: In diesem Szenario umsorgt der Scrum Master das Team auf einem Niveau, welches das Team von seinen Diensten abhängig macht: Meetings organisieren, Stickies und Stifte bestellen, Notizen machen, Jira aktualisieren – Sie bekommen eine Vorstellung von diesem Service-Level. Noch kritischer ist es jedoch, wenn der Scrum Master beschließt, das Team über Prinzipien und Praktiken im Dunkeln zu lassen, um seinen Job zu sichern. Dieses Verhalten ist nur einen kleinen Schritt von der dunklen Seite entfernt.
• Verfolgung fehlerhafter oder ungeeigneter Metriken: Die Verwendung vordefinierter Jira-Berichte ist wahrscheinlich ein eher Zeichen von Unwissenheit oder Bequemlichkeit. Hingegen ist es ein kritisches Zeichen, wenn individuellen Leistungskennzahlen — wie z. B. die Story-Punkte pro Entwickler pro Sprint — erfasst und diese an den Vorgesetzten dieser Person gemeldet werden. Das ist eine klassische Vorgehenweise, um Command & Control durch die Hintertür wieder einzuführen. Diese führt unweigerlich zu einer Version von Cargo-Cult-Scrum, welche für alle Beteiligten unbefriedigend ist.
• Langer Arm des Managements: Während des Sprints berichtet der Scrum Master dem Management, ob das Scrum-Team den aktuellen Forecast einhalten wird oder nicht. Dieses Fehlverhalten habe ich aus einem Jobangebot entnommen, das ich erhalten habe: „Sie koordinieren und steuern die Arbeit der anderen Teammitglieder und sorgen dafür, dass Zeitpläne eingehalten und Verstöße eskaliert werden.“
• Fokussierung auf Teamharmonie: Der Scrum Master kehrt Konflikte und Probleme unter den Teppich, indem er oder sie Sprint Retrospektiven nicht dazu benutzt, diese offen anzusprechen. Dieses Verhalten ist oft ein Zeichen dafür, dass man sich der Politik beugt und stattdessen Manipulation einsetzt, um organisatorische Anforderungen zu erfüllen, die den Scrum-Werten und -Prinzipien entgegenstehen. Wenn die Organisation ihre Untergebenen dafür schätzt, dass sie die ‚Regeln‘ befolgen, anstatt die Wahrheit zu sagen, warum sollten dann überhaupt Retrospektiven durchgeführt werden? Ein ‚Scrum Master‘, der an Cargo-Cult-Scrum teilnimmt, ist erneut eher Vorgesetzter als ein agiler Praktiker.

Scrum Master Fehlverhalten nach Scrum Ereignissen

Das Sprint Planning

Die folgenden Anti-Patterns konzentrieren sich auf das Sprint Planning:

• 100% Auslastung: Das Entwicklungsteam knickt regelmäßig vor dem fordernden Product Owner ein — „im letzten Sprint habt Ihr 25 Story-Punkte geliefert, jetzt wählt Ihr nur noch 17“ – und nimmt mehr Arbeit in das Sprint Backlog auf, als es verkraften kann. Der Scrum Master spricht in Folge nicht an, dass dies ein respektloses Verhalten ist, welches das Vorrecht der Entwickler auf Selbstorganisation negiert und die Notwendigkeit für Slack Time ignoriert. (Die Effektivität des Teams wird erheblich behindert, wenn das Team nicht jeden Sprint technische Schuld abbauen kann. Es wird auch darunter leiden, wenn es keine Zeit für Pair Programming oder gegenseitige Unterstützung gibt. Eine hundertprozentige Auslastung reduziert immer die langfristige Produktivität des Teams; die Auslastungsoptimierung ist ein klassisches Beispiel für tayloristisches Managementdenken.) Wenn am Ende eines Sprints 50% aller Aufgaben unvollendet in den nächsten Sprint übergehen und dies ein regelmäßiges Muster ist, dann praktiziert das Team kein Scrum. Wahrscheinlich ist es eine Art Kanban mit Zeitboxen — was selbstverständlich auch in Ordnung wäre. Entscheiden Sie sich einfach, wie Sie das Leben Ihrer Kunden verbessern wollen. Vielleicht wäre Kanban anstelle von Scrum in diesem Fall eine gute Wahl.
• Unverfeinerte Sprint Backlog-Einträge: Der Scrum Master geht nicht auf die Übernahme von „unvorbereiteten“ Product Backlog-Einträgen in das Sprint Backlog durch die Entwickler ein. Dies ist ein sicherer Weg, dass die Entwickler in Folge das das Sprint-Ziel verpassen werden, was ein Kernprinzip von Scrum nutzlos macht: das Erreichen des Sprint-Ziels durch die Bereitstellung eines oder mehrerer wertvoller, potenziell lieferbarer Inkremente. (Dieser Punkt bezieht sich auf regelmäßige Arbeit, nicht auf Notfälle).

Der Sprint

Die folgenden Scrum-Master-Fehlverhalten adressieren den Sprint:

• Flow-Unterbrechung: Der Scrum Master ermöglicht es den Stakeholdern, den Flow des Scrum Teams während des Sprints zu unterbrechen. Es gibt mehrere Möglichkeiten, wie Stakeholder den Fluss des Teams während eines Sprints unterbrechen können. Jedes der Beispiele wird die Produktivität des Teams behindern und kann die Erreichung des Sprint-Ziel gefährden. Es ist die Aufgabe des Scrum Masters zu verhindern, dass diese Verhalten sich manifestieren: 
  • Der Scrum Master hat eine Laissez-faire-Politik, was den Zugang den Entwicklern betrifft. Insbesondere schulen sie die Stakeholder nicht über die negativen Auswirkungen von Störungen und wie diese die Erreichung des Sprint-Ziels gefährden können.
  • Der Scrum Master widerspricht nicht, wenn Vorgesetzte Teammitglieder aus dem Scrum Team nehmen und ihnen andere Aufgaben zuweisen.
  • Der Scrum Master hat nichts dagegen, dass das Management Teammitglieder als Experten zu anderen Meetings einlädt.
  • Der Scrum Master drückt ein Auge zu, wenn der Product Owner die Prioritäten mitten im Sprint ändert.
  • Schließlich erlaubt der Scrum Master den Stakeholdern oder Managern, das Daily Scrum in eine Reporting-Session zu verwandeln.
• Zuweisung von Teilaufgaben an Entwickler: Der Scrum Master hindert den Product Owner — oder auch andere Personen — nicht daran, Aufgaben direkt Entwicklern zuzuweisen. (Die Entwickler managen sich selbst, ohne dass ein externes Eingreifen erforderlich wäre. In dieser Hinsicht wirken Scrum Master durchaus als ein Schutzschild für das Team.)
• Technische Lösungen definieren: Ein Entwickler, der zum Scrum Master wurde, „schlägt“ nun vor, wie das Entwicklungsteam Aufgaben umsetzen soll. (Alternativ verfolgt der Product Owner oder ein Außenstehender den gleichen Ansatz, z. B. ein technisch Verantwortlicher).
• Fehlende Unterstützung: Der Scrum Master unterstützt Teammitglieder nicht, die Hilfe bei einer Aufgabe benötigen. Oftmals erstellen die Entwickler Arbeitspakete, die ein Entwickler innerhalb eines Tages erledigen kann. Wenn jedoch jemand länger als zwei Tage mit einem solchen Job kämpft, ohne zu kommunizieren, dass er oder sie Unterstützung benötigt, so sollte der Scrum Master das Problem ansprechen und Unterstützung anbieten. Übrigens ist dies auch der Grund dafür, dass man jeden Tag auf Sprint-Boards diejenigen Tasks mit roten Punkten markiert, die sich nicht bewegt haben. (Mit anderen Worten: Wir verfolgen das Work-Item-Alter.)

Die Retrospektive

Die letzten Beispiele von Scrum Master Fehlverhalten betrifft die Sprint Retrospektive:

• Zeitverschwendung: Das Team wertschätzt die Retrospektive nicht. Wenn einige Teammitglieder die Retrospektive für wenig wertvoll oder wertlos halten, ist es meistens die Retrospektive selbst, die nervt. Ist es jedes Mal das gleiche Vorgehen, ritualisiert und langweilig? Dann machen Sie eine Meta-Retrospektive über die Retrospektive selbst. Ändern Sie den Veranstaltungsort. Organisieren Sie eine Bier- oder Wein-Retrospektive. Es gibt so viele Dinge, die ein Scrum Master tun kann, um Retrospektiven wieder zu beleben und die Abwesenheitsrate zu reduzieren. Und ja, nach meiner Erfahrung nehmen auch introvertierte Menschen gerne an Retrospektiven teil — wenn diese das richtige Format haben und psychologische Sicherheit garantieren.
• Und täglich grüßt das Murmeltier: Die Retrospektive ändert sich in ihrer Struktur, ihrem Veranstaltungsort und ihrer Dauer nicht. In diesem Fall besteht die Gefahr, dass das Team immer wieder die gleichen Themen aufgreift — es ist wie „Groundhog Day“ nur ohne das Happy End. In Folge läuft das Scrum Team Gefahr, dass die Retrospektive als Zeitverschwendung betrachtet wird.
• Verschieben wir die Retro: Das Team verschiebt die Retrospektive auf den nächsten Sprint. Über die „Inspektion & Adaption“ des Scrum Teams hinaus soll die Retrospektive m. E. auch als ein Moment des Abschlusses dienen, damit sich das Team mental auf den neuen Sprint einstellen kann. Zusätzlich sollte das Scrum Team sich Gedanken über wichtige Verbesserungsaktionen für den kommenden Sprint machen. Deshalb erfolgt die Retrospektive vor der Sprintplanung des folgenden Sprints. Eine Verschiebung der Retro in den nächsten Sprint kann daher den Fluss des Teams unterbrechen und wird wahrscheinlich ein oder mehrere wichtige Teamprobleme für die Dauer eines Sprints unangesprochen lassen. Außerdem ist es eine Gratwanderung. Wenn die Verschiebung von Retrospektiven ein akzeptabler Ansatz ist, warum sollten wir sie dann überhaupt durchführen?
• #NixRetro: Es gibt keine Retrospektive, da das Team glaubt, dass es nichts zu verbessern gibt. Meines Erachtens gibt es kein agiles Nirwana, wo alles einfach perfekt ist. Wie so schön gesagt wird: Agilität ist eine Reise und kein Ziel. Es gibt immer etwas zu verbessern.
• #NixDokumentation: Niemand macht Notizen für den späteren Gebrauch. Eine Retrospektive ist eine beträchtliche Investition und sollte ernst genommen werden. Notizen und Fotos unterstützen diesen Prozess.
• Keine psychologische Sicherheit: Die Retrospektive ist ein endloser Kreislauf von gegenseitigen Schuldzuweisungen. Das Team gewinnt gemeinsam, das Team scheitert gemeinsam. Die Schuldzuweisungen dokumentieren sowohl das Scheitern des Scrum Master als Moderator der Retrospektive als auch die mangelnde Reife und Kommunikationsfähigkeit des Teams.

• Mobbing: Ein oder zwei Teammitglieder dominieren die Retrospektive. Dieses Kommunikationsverhalten ist oft ein Zeichen für einen schwachen oder uninteressierten Scrum Master. Die Retrospektive muss ein sicherer Ort sein, an dem jeder Probleme ansprechen und sein Feedback frei von Einflüssen Dritter geben kann. Wenn einige der Teammitglieder das Gespräch dominieren und wahrscheinlich sogar andere Teammitglieder dadurch einschüchtern, wird die Retrospektive keine psychologische Sicherheit bieten. Dieser Misserfolg führt dazu, dass die Teilnehmer sich aus der Retrospektive zurückziehen und die Ergebnisse weniger nützlich sind. Es liegt in der Verantwortung des Scrum Masters, sicherzustellen, dass jeder gehört wird und die Möglichkeit hat, seine Gedanken zu äußern. Übrigens, eine gleichmäßig verteilte Redezeit innerhalb eines Teams ist laut Google ein Zeichen für ein leistungsstarkes Team. Weitere Lektüre: What Google Learned From Its Quest to Build the Perfect Team. Sehen Sie sich auch die “Conversation Café”-Übung der Liberating Structures an, welche dieses Problem mit einer einfachen Übung angeht, die gut in eine Retrospektive passt.
• Stakeholder-Alarm: Die Stakeholder beteiligen sich an der Retrospektive. Es gibt mehrere Möglichkeiten in Scrum auf die Kommunikations- und Informationsbedürfnisse der Stakeholder einzugehen: Hauptsächlich ist es der Sprint Review, die Möglichkeit, in das Daily Scrum hineinzuhören, wahrscheinlich sogar das Refinement des Product Backlogs und ganz zu schweigen von den Möglichkeiten, ein Gespräch bei Kaffee oder während der Mittagspause zu führen. Sollte dieses Spektrum an Möglichkeiten immer noch nicht ausreichen, so können Sie zusätzliche Meetings in Betracht ziehen, wenn Ihr Team dies für notwendig hält, siehe die Meta-Retrospektive. Die Teilnahme an der Team-Retrospektive sollte jedoch für Stakeholder tabu sein.

Scrum Master Anti-Patterns — Das Fazit

Es gibt viele Möglichkeiten, als Scrum Master hinter den Erwartungen zurückzubleiben. Manchmal ist es der Mangel an Unterstützung aus der Organisation. Manche Menschen sind für die Aufgabe nicht geeignet. Andere stellen sich aus fragwürdigen Gründen über ihre Teams. Manchen Scrum-Mastern fehlt einfach das Feedback ihrer Scrum-Teams und Stakeholder. Wie dem auch sei, versuchen Sie, Ihrem Scrum Master in der Not zu helfen, die Misere zu überwinden. Scrum ist ein Teamsport.

Welche Scrum Master Fehlverhalten habe ich nicht angesprochen? Bitte teilen Sie uns diese in den Kommentaren mit.

Weitere Artikel

28+2 Sprint Anti-Patterns

20 Sprint Planning Anti-Patterns

Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team

21 Sprint Retrospektive Anti-Patterns

27 Product Backlog Anti-Patterns

Alle Artikel über Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide for free.

Sehen Sie sich das Videos des Webinars über Scrum Master Anti-Patterns an

Das Video des Webinars ist jetzt verfügbar:

Anmerkung: Wenn der Browser das Video nicht automatisch startet, klicken Sie hier um das Webinar zu Scrum Master Anti-Patterns direkt auf Youtube zu sehen

✋ Nicht versäumen: Werden Sie Mitglied im 11.000-köpfigen „Hands-on Agile“ Slack Team

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Der Artikel Scrum Master Fehlverhalten — 20 Hilferufe von Scrum Mastern ist zuerst auf Berlin-Product-People.com erschienen.