zx
Nachdem wir bereits Fehlverhalten von Scrum Mastern, Interessenvertretern und Product Ownern beschrieben haben, befasst sich dieser Artikel mit Fehlverhalten der Scrum Entwickler, wobei wir alle Scrum Events sowie das Produktbacklog berücksichtigen. Erfahren Sie mehr darüber, worauf Sie achten sollten, wenn Sie Ihre Teamkollegen, die das Produktinkrement erstellen, auf dem Pfad der kontinuierlichen Weiterentwicklung unterstützen wollen.
Regelmäßig erscheinen Artikel von Entwicklern, in denen detailliert dargelegt wird, warum “Agile” im Allgemeinen und das Wesen von Scrum im Besonderen unsere kollektive Geringschätzung verdienen.
Was mir in dieser Diskussion immer aufgefallen ist, ist die Emotionalität der Beteiligten. Tatsache ist, dass Scrum ein Werkzeug ist, das nützlich ist, um eine primäre Aufgabe zu erfüllen: den Kunden von neuen, in komplexen Umgebungen entstehenden Produkten einen Mehrwert zu bieten und gleichzeitig die Risikoexposition eines Unternehmens zu mindern.
Wenn also Scrum in einer Organisation nicht funktioniert, liegt das vielleicht daran, dass Scrum von vornherein auf die falsche Situation angewendet wird. Oder, dass es mechanisch umgesetzt wird, angetrieben von Leuten, die nicht wissen, was sie tun. (Im Ernst, wie kompliziert kann Scrum schon sein, wenn das Handbuch 18 Seiten umfasst?)
Die Frage lautet daher: Warum sollte ich ein Werkzeug “hassen”, das für den beabsichtigten Zweck ungeeignet ist oder inkompetent angewendet wird? Würde ich einen Hammer dafür verabscheuen, dass dieser nicht in der Lage ist, eine Schraube präzise in einen Holzbalken zu drehen? Wahrscheinlich nicht, denn der Hammer wurde nicht für diesen Zweck konstruiert, und weder die bloße Willenskraft noch Aufstampfen mit den Füßen werden daran etwas ändern.
Letztes Jahr habe ich eine (nicht repräsentative) Umfrage durchgeführt, wie Scrum Master ihre Zeit aufwenden, wenn sie mit einem einzigen Scrum Team arbeiten. Zur Überraschung vieler Leser belief sich das direkte Scrum Master Engagement mit einem Scrum Team von durchschnittlicher Größe und einem typischen zweiwöchigen Sprint auf etwa 12 Stunden pro Woche.
Dieses Ergebnis führte sofort zu zwei zusätzlichen Fragen: Was machen Scrum Masters den Rest der Woche, und in welcher Weise manifestiert sich die Arbeit eines Scrum Masters im Laufe der Zeit? Während die Beantwortung der obigen Frage zusätzliche Recherchen und Datenerhebungen erfordert, kann letztere bis zu einem bestimmten Grad beantwortet werden, indem man sich auf einige wenige gängige Szenarien konzentriert.
Der erste Artikel dieser Serie befasst sich daher mit dem Scrum Master Engagement mit dem Entwicklungsteam.
