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.
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 / Update: Diese Woche flatterte mir eine Anfrage auf den Tisch. Für ein Scrum-Team wurde 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.
