Die erste Fassung dieses Textes habe ich 2011 geschrieben. Möglicherweise war zu Beginn des Scrum-Hypes eine Menge Unkenntnis im Spiel, wenn es zu unvollständigen und manchmal abstrusen Scrum-Implementierungen kam. Zwischenzeitlich sollte das mit der Unkenntnis erledigt sein. Dennoch begegnen mir in letzer Zeit wieder vermehrt sehr seltsame Ideen mit der Aufschrift “Scrum”. Deshalb habe ich beschlossen dieses Text nach und nach zu ergänzen.

Originaltext aus dem Jahre 2011

Kürzlich wurde ich unfreiwilliger Ohrenzeuge eines so genannten Scrum-Meetings. Warum nur Ohrenzeuge? Das Meeting fand telefonisch statt und ich habe das Telefonat unfreiwillig mitgehört. Einer der Teilnehmer fragte mich hinterher: “Wie funktioniert Scrum wirklich?” Im weiteren Gespräch, in dem ich Details über das gerade beendete “Scrum-Meeting” erfuhr, stellte sich dann heraus, dass womöglich keiner der Beteiligten wirklich wusste wie Scrum funktioniert. Um ehrlich zu sein mir standen nach dem Gespräch die wenigen verbliebenen Haare zu Berge. Es gibt Organisationen, die guten Gewissens sagen “Wir machen Scrum” und dennoch in der täglichen Praxis ein Musterbeispiel abgeben, wie man es nicht machen sollte. Einige der Punkte aus dem Gespräch möchte ich nachfolgend kurz skizzieren und kommentieren:

• Es gibt kein Scrum-Meeting, es gibt das daily scrum. Das ist eine kurze, straff organisierte Zusammenkunft des Teams. Eine tägliche Telefonkonferenz von zwei Stunden ohne Moderation ist kein daily scrum.
• Das daily scrum ist eine Zusammenkunft des Teams und keine Konferenz eines ständig wechselnden Personenkreises. Das Team sollte wissen wer dazugehört und nicht erst zu Beginn des Termins erfahren wer heute dabei ist. Wenn nicht einmal klar ist wer zum Team dazu gehört ist schon die Minimalbedingung erfolgreicher Teamarbeit nicht erfüllt.
• Probleme werden im daily scrum nur öffentlich gemacht und angerissen. Sie werden notiert und außerhalb geklärt, gelöst oder einer Lösung zugeführt und nicht stundenlang im Meeting diskutiert. Wenn z.B. Schulungen notwendig sind werden diese organisiert und nicht im im daily scrum abgehalten. Das Notieren von Problemen und Hindernissen wie z.B. Schulungsbedarf und die Organisation von Abhilfen sind unter anderem Aufgaben des Scrum-Masters.
• Eine tägliche Telefonkonferenz mit Zeitzonenverteilung rund um den Globus1 ist wenig effektiv weil immer einer halb im Bett ist. Hier wäre eine andere Einteilung des Teams oder eine Aufteilung in zwei kleinere Teams die bessere Lösung.
• Qualitätskriterien werden als Abnahmekriterien für die User Stories formuliert und nicht als Meta-Use-Cases, deren Inhalt nichts mit den User Stories zu tun hat.
• Ein Scrum Team muss kompetent sein, das heißt die Teammember sollten in Summe die für die Arbeit notwendigen Kenntnisse besitzen. Es macht wenig Sinn eine Gruppe von Cobol-Entwicklern auf ein PHP – Projekt anzusetzen und sie als PHP-Scrum-Team zu bezeichnen.2

In besagter Organisation gibt es weder einen Scrum-Master noch einen Product-Owner. Insofern ist es faszinierend, dass überhaupt das Wort Scrum in den Mund genommen wird.

Epilog

Scrum ist ein außergewöhnlicher Ansatz im wahrsten Sinne des Wortes, der dementsprechend außergewöhnliche Ernsthaftigkeit in der Umsetzung erfordert. Ein Etiketten-Schwindel hilft niemand. Dann lieber wie bisher weiter machen – und – nennt es bitte nicht Scrum.

Nachtrag 1: Aus einer Projektanfrage, die mir auf den Tisch geflattert ist: Für ein Scrum-Team wird ein Projektleiter gesucht. Meine Rückfrage “Brauchen Sie einen Scrum-Master oder einen Product-Owner” stieß auf völliges Unverständnis. Scrum und die normale Projektleiter-Rolle passen nicht zusammen, zumindest nicht innerhalb des Aufgabenbereichs eines Teams.

Nachtrag :2 Die Rollen in Scrum sind wichtig. Die Aufgaben des Scrum-Masters können nicht vom ohnehin vorhandenen Projektleiter nebenher mitgemacht werden.

1. Im konkreten Fall: Europa, USA Ost, USA West und Indien, d.h. einer schläft immer. [↩]
2. So bizarr sich der Cobol – PHP Vergleich anhören mag ist er dennoch ein reales Beispiel mit dem ich mich schon auseinandersetzen musste. [↩]

Bernd Oesterreich schreibt im GPM-Blog über timeboxing und erklärt den Unterscheid zwischen Timebox und Iteration. Besonders gefallen hat mir seine Klarstellung bzgl. der eigentlichen Bedeutung des in Scrum verwendeten Begriffs des “Sprint” (siehe letzter Abschnitt). Lesenswert!

Was ist eigentlich timeboxing?