Die 10 typischen Fehler bei der Anwendung von Scrum

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp

Viele Unternehmen oder Teams starten ihren Weg in die Agilität mit dem agilen Rahmenwerk Scrum. Denn Scrum ist leicht zu verstehen und kommt mit wenigen Regeln aus. Doch genau diese sollte man nicht unterschätzen. Die Einführung von Scrum setzt einen großen Willen zur Veränderung voraus.

Jetzt ist es jedoch so, dass große Veränderungen klassischen Unternehmen oftmals schwer fallen. Daher passiert es nicht selten, dass das Scrum Regelwerk eingeführt wird – aber mit Anpassungen oder Einschränkungen.

„Wir machen Scrum, aber...“

Und so wird aus der agilen Methode Scrum in Wasserfall-Denkweise. Dass sich so die Vorteile von Scrum nicht entwickeln können und man sich im schlimmsten Fall noch zusätzliche Probleme ins Haus holt, fällt vielen entweder gar nicht, oder erst nach geraumer Zeit auf.

Wer Scum im Team eingeführt hat, sollte daher die folgenden 10 Fehlern unbedingt vermeiden:

1. Angepasste Rollenverteilung

Laut Scrum Guide besteht ein Scrum Team aus den Teammitgliedern, einem*einer Scrum Master*in und einem*einer Product Owner*in. Fehlt beispielsweise der*die Scrum Master*in, gibt es niemanden, der*die dem Team dabei hilft, die eigenen Praktiken innerhalb des Scrum Rahmenwerks zu verbessern, das Team zu coachen oder Hindernisse für das Team aus dem Weg zu räumen. Agiles Arbeiten wird so unmöglich gemacht.

Fehlt ein*e Product Owner*in, der*die ein Produkt-Ziel entwickelt und kommuniziert, sowie Themen priorisiert, dümpelt das Team ziellos und ohne inhaltlichen Rahmen in die Zukunft. Langfristige Ergebnisse können so nicht verwirklicht werden.

Einen ähnlichen Effekt haben zwei Product Owner*innen. Sie bringen unterschiedliche Ansichten, Priorisierungen und Wünsche mit, zwischen denen das Team dann Ping-Pong spielen darf. Bei jeder Rückfrage müssen sie sich beraten, um eine Antwort geben zu können. Dass unter diesen Umständen qualitative hochwertige Arbeit erledigt wird, die das Unternehmen in eine Richtung bringt, ist extrem unwahrscheinlich.

Manchmal kommt es auch vor, dass sich ein Projektleiter im Scrum Team befindet. Das ist ein klares Zeichen von nicht agilem Denken. Denn ein Scrum Team organisiert sich selbst und entscheidet dementsprechend auch eigenständig, wie die zu erledigende Arbeit erledigt wird. Da der*die Product Owner*in vorgibt, was getan werden sollte, benötigt es keine weitere Person, die irgendetwas managed. Gibt es diese Person dennoch, wird sie das Team immer bremsen und die agilen Werte untergraben.

2. Teammitglieder sind nicht freiwillig im Team

Agiles Arbeiten bedeutet selbstorganisiert zu arbeiten. Das funktioniert nur auf freiwilliger Basis. Wo soll sonst die innere Motivation herkommen? Wurde das Team von jemandem zusammengestellt, ohne, dass das Teammitglied dazu ja oder nein sagen konnte, werden seine*ihre Widerstände das Team ausbremsen. Auch werden die Teammitglieder so keine Verantwortung übernehmen, sondern auf Anweisungen warten.

Haben sich die Teammitglieder hingegen von selbst für ein Team entschieden, bringen sie viel Engagement und eine hohe Bereitschaft die Produktideen des*der Product Owner*in umzusetzen mit.

3. Teammitglieder haben nicht selbst entschieden, mit Scrum zu arbeiten

Wenn Teammitglieder nicht verstehen, warum agil oder mit Scrum gearbeitet wird, ist mit ähnlichen Folgen zu rechnen, wie bei Punkt 2. Agiles Arbeiten und auch Scrum funktionieren nur, wenn alle Verantwortung übernehmen und sich stetig verbessern und dazulernen wollen. Sind die agilen Werte und Prinzipien nicht angenommen oder verinnerlicht, ist eine Veränderung hin zur Agilität nicht möglich.

Wenn zudem noch aktive Widerstände hinzukommen, sprich das Team bewusst nicht mit Scrum arbeiten möchte, ist ein agiles Team praktisch handlungsunfähig.

4. Teammitglieder sind in mehreren Projekten involviert

Eine Person kann immer nur ein vollwertiges Mitglied in einem Scrum Team sein. Wer gleichzeitig in verschiedenen Projekten oder Scrum Teams arbeitet, der wird es nicht nur schwer haben, in allen Projekten wirklich gute Arbeit zu leisten, der wird auch den Flow des Scrum Teams erheblich stören. Ein gutes Teamgefüge – welches für den Erfolg eines Scrum Teams aber ausschlaggebend ist – kann sich so nicht bilden. Zudem hält es das Team auf, wenn eine Person für Rückfragen, Vorarbeiten und zur täglichen Abstimmung nicht verfügbar ist. Das verkompliziert das Planen enorm und verzögert die Umsetzung der Produktvision.

5. Teammitglieder dürfen nicht entscheiden, wie sie arbeiten

Im Scrum Guide ist klar definiert, dass das Team entscheidet, wie es die Anforderungen und Wünsche des*der Product Owner*in umsetzt. Wo immer eine Hierarchie mit Anweisungskultur existiert, wird dieses Prinzip verletzt und agiles Arbeiten ist nicht möglich. In einer solchen Umgebung sind die Teammitglieder Ressourcen und keine Individuen mit Potenzial.

Hat sich der*die Product Owner*in bereits die Lösung überlegt und diese soll lediglich ausgeführt werden, ist die Wahrscheinlichkeit groß, dass diese Lösung nicht die beste ist, die im Team hätte gefunden werden können. Zudem demotiviert es das Team, wenn es sich nicht selber einbringen kann. 

6. Angepasste Events

Laut Scrum Guide gibt es fünf sogenannte Events: den Sprint, das Sprint Planning, das Daily Scrum, die Sprint Review und die Sprint Retrospektive. Mit allem, womit ein Team von diesen Vorgaben abweicht, entfernt es sich von dem Scrum Kern.

Trifft sich ein Team beispielsweise nicht täglich zum Daily, sondern etwa wöchentlich zum „Weekly“, wird es viel zu wenig Zeit haben, die Richtung des Sprint-Ziels zu überprüfen und daher vermutlich nach einer Woche feststellen, dass das die Mitglieder in verschiedene Richtungen gelaufen sind. Die daraus resultierende, doppelte Arbeit sorgt dann dafür, dass nicht alles geschafft wird, was man sich beim Planning vorgenommen hatte. Da ist es fast nebensächlich, dass das Team bei dem wöchentlichen Termin dann vermutlich so viel zu Besprechen hat, dass die vorgegebenen 15 Minuten nicht ausreichen.

Beliebt sind auch Anpassungen der Sprint-Idee an sich. Mit unterschiedlich langen Sprints wird ein Team nie eine gemeinsame Routine finden. Und ohne diese wird es auch keinen Referenzwert haben, um die eigene Verbesserung zu verfolgen und zu Lernen. Um Konsistenz zu schaffen, sollte ein Sprint daher einen Monat oder kürzer sein. Ist er länger, verliert das Team den agilen Kern der Anpassungsfähigkeit und Leichtfüßigkeit.

7. Scrum auf Zeit

Scrum – wie auch andere agile Methoden – sind keine schnelle Notfallhilfen, von von denen man auch dann profitiert, wenn man sie nach 5 Sprints wieder absetzt. Agilität ist lebenslanges Lernen. Es gibt keinen endgültigen agilen Zustand. Wie auch, wenn sich alles um einen herum stetig weiterentwickelt? Generell benötigen Veränderungen Zeit, um ihre volle Wirkung entfalten zu können.

8. Das Team wird nicht abgeschirmt oder zu sehr

Ein Scrum Team kann nur dann bestmöglich arbeiten, wenn es auch Zeit dafür hat, die vorgenommenen Aufgaben zu erledigen. Daher muss es vor eventuellen Stakeholdern mit Sonderwünschen oder Kontrollbedürfnissen abgeschirmt werden. Dies ist die Aufgabe des*der Product Owner*in. Er*sie ist dafür verantwortlich, nur die Informationen weiterzuleiten, die wirklich wichtig sind. Schützt er*sie das Team zu wenig, wird es in der eigenen Arbeit behindert. Schützt er*sie zu viel, können sie nicht schnell genug auf Änderungswünsche reagieren.

9. Das Team trifft sich nur alle zwei Wochen

Agiles Arbeiten ist Arbeiten im Team. Menschen, die sich jedoch nur alle 2 Wochen austauschen, werden nicht als Team zusammenarbeiten können und schon gar nicht in eine gemeinsame Richtung laufen. Eine gute, tägliche Kommunikation ist daher in agilen Teams extrem wichtig.

10. Scrum als Tool ohne Werte und Prinzipien

Zu Scrum gehören die Regeln genauso wie die dahinterliegenden Werte und Prinzipien. Nur das Regelwerk einzuführen, aber die Organisationskultur nicht verändern zu wollen, wird nicht den gewünschten Effekt erzielen. Agilität wie auch Scrum wird nicht getan, sondern gelebt.

Scrum angepasst ist nicht mehr Scrum

Passt ein Unternehmen Scrum an die eigenen Vorstellungen an, kann es dies natürlich machen. Die Frage ist jedoch, was es erreichen möchte und erwartet. Wer beispielsweise lediglich alle 2 oder 3 Monate das nächste Vorgehen bespricht und das Treffen dann Sprint nennt, hält eben alle paar Monate ein Teammeeting ab. Er*sie arbeitet deswegen aber noch lange nicht agil.

Scrum in Teilen einzuführen und dieselben Vorteile zu erwarten, wird jedoch nicht funktionieren. Und je nachdem, welche Kombination an Regeln sich ein Unternehmen zusammenbaut, kann es sich so noch größere Behinderungen ins Unternehmen holen als zuvor vorhanden waren. Es ist daher nicht verwunderlich, dass die Sätze „Scrum funktioniert bei uns nicht.“ oder „Das ist ein Hype, der absolut nichts bringt“ keine Seltenheit sind. Dahinter verbirgt sich ein unvollständiges Verständnis von Scrum und eine romantisierte Vorstellungen einer agilen Transformation. Es empfiehlt sich, sich genau mit Scrum und dem eigenen Unternehmen auseinanderzusetzen, bevor man sich dazu entschließt mit Scrum zu arbeiten.

Noch mehr Wissenwertes

Veraenderungskraft Corona-Infos

Aufgrund der aktuellen Entwicklung der Corona-Infektionszahlen haben wir uns zum Wohle aller dafür entschieden, alle unsere Schulungen bis auf Weiteres online durchzuführen.