Seit fünf Jahren arbeite ich als Softwareentwickler in einem Scrum Team. In diesem Blogbeitrag schildere ich meine Erfahrungen mit Scrum und welche 3 Fehler man bei dessen Anwendung vermeiden sollte.
„Scrum is like your mother-in-law, it points out ALL your faults.“ – Ken Schwaber
Fehler 1: Aus zwei mach eins
Ursprünglich bestand mein Team aus Mitgliedern, welche in zwei verschiedenen technologischen Bereichen arbeiteten. Wir waren ein Team aus zwei Teams. Meine Erfahrung hat gezeigt, dass diese Teamkonstellation sehr ineffizient war, da:
- am Refinement Arbeitspakete besprochen wurden, welche nur einen Teil der Teammitglieder betrafen
- nicht jedes Teammitglied für jedes gemeldete Problem Support leisten konnte
- Die Planung der Arbeitspakete für den Product Owner (PO) besonders herausfordernd wurde:
- Priorität der Arbeitspakete über zwei Bereiche definieren und
- Anwesenheit der Mitglieder aus den einzelnen Bereichen bei der Planung berücksichtigen
Gemäss Scrum Guide sollte so eine Teamstruktur vermieden werden. Er definiert dazu:
„Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.“
Fehler 2: Aufgaben auf Vorrat schätzen
Gerne eine kleine Anekdote, um die Problematik zu erklären. In meinem Team mussten wir auf Verlangen des PO alle Arbeitspakete schätzen, welche zum Backlog hinzugefügt wurden. Obwohl unklar war, wann die Pakete umgesetzt werden würden. Als uns der PO verliess und wir das Backlog für seinen Nachfolger bereinigten, bemerkten wir das Ausmass dieser Praktik: Wir hatten Arbeitspakete für rund drei Teamjahre geschätzt. Etwa 90% der Schätzungen waren nicht mehr adäquat. 70% der Arbeitspakete löschten wir, da diese nie eingeplant worden wären.
Kurz zusammengefasst, wieso Schätzen auf Vorrat ineffizient ist:
- Ein System verändert sich mit jeder Iteration und damit auch die Annahmen und Vorbedingungen für zukünftige Arbeitspakete.
- Die Anforderungen des Business verändern sich und können Arbeitspakete obsolet machen.
- Schätzen bedeutet Aufwand fürs Team und dadurch höhere Kosten.
Somit sollten möglichst wenige Arbeitspakete auf Vorrat geschätzt werden. Im besten Fall nur für die nächste Iteration.
„There is nothing so useless as doing efficiently that which should not be done at all.“ – Peter Drucker
Fehler 3: Ein Scrum Master für drei Teams
Unsere Abteilung besteht aus drei Teams, welche sich einen Scrum Master teilen. Was auf den ersten Blick wie effizientes Personalmanagement wirkt, täuscht leider. Wieso das?
- Der Scrum Master verursacht Abhängigkeiten zwischen den Teams, da diese die Scrum Events aneinander vorbeiplanen müssen, um dem Scrum Master eine Teilnahme zu ermöglichen.
- Die Ressourcen des Scrum Masters müssen auf die Teams aufgeteilt werden.
- Der Scrum Master hat wegen allen Scrum Events der Teams seinen Kalender voll. Will er mehr Freiräume schaffen, muss er einzelne Scrum Events absagen, was ihm die wichtigste Quelle für die Erkennung der Impediments entzieht.
- Es ist schwieriger für den Scrum Master sich auf die Beseitigung der Impediments zu fokussieren. Ihm fehlt die Zeit dazu.
Und nun?
Auf der Suche nach besseren Lösungen sollten wir bestrebt sein Neues auszuprobieren. Dabei werden wir Fehler machen. Aus Fehlern lernen ist einer der wichtigsten Werte von Scrum. Mit dem Machen von Fehlern treiben wir einen Prozess an, welcher uns insgesamt vorantreibt.
„Failure is simply the opportunity to begin again, this time more intelligently“ – Henry Ford
Habt ihr auch Fehler bei der Anwendung von Scrum gemacht? Ich bin gespannt auf eure Kommentare 😊
