10 häufige Fehler bei der Anwendung von Scrum und wie man sie vermeidet

„Wenn die meisten Leute an Agile denken, denken sie an Scrum“.

Scrum ist das am weitesten verbreitete Agile-Framework. Da es einfach in der Konzeption ist, schleichen sich leicht Fehler und Missverständnisse ein. Hier sind die 10 gängigsten Fehler bei der Anwendung von Scrum sowie Tipps, um diese zu vermeiden.

 

1. Erwartung einer einfachen Transformation hin zu agile

Gerne werden Bücher über agile Projektsteuerung oder Scrum zu Rate gezogen, um Projektanforderungen in User-Stories umzuwandeln, tägliche Stand-Up-Meetings abzuhalten oder Software in 2-3 Wochensprints zu entwickeln. Ist man so einfach agil? Sie werden wahrscheinlich eine Verbesserung Ihrer Reaktionsfähigkeit auf Änderungen feststellen oder möglicherweise sogar eine Weile schneller und besser funktionierende Software bereitstellen. Es wird jedoch nicht allzu lange dauern, bis die Versprechungen von agile sich weniger erfüllen, Teams sich vergeblich darum bemühen, das Tempo zu halten, Software nicht immer den Erwartungen der Benutzer entspricht und agile Projektsteuerung als Misserfolg gewertet wird. Agile Transformation braucht Zeit und fängt fast immer recht chaotisch an. Die wirkliche Transformation offenbart bestehende Unternehmens- und Kulturprobleme, die es zu lösen gilt. Hierunter zählen schlechte Kommunikation, mangelnde Rechenschaftspflicht, Misstrauen etc. Effektive agile Transformation bringt oft einen vollständigen Kulturwandel mit sich. Geben Sie ihm Zeit, und seien Sie bereit, durch den Schmerz und Widerstand gegen kulturelle Veränderungen zu gehen.

 

2. Praxis ohne Regeln

Einfache Dinge wie Scrum Meetings zu implementieren, Scrum Rollen auszufüllen und die richtigen Scrum-Artefakte zu verwenden ist zwar ein guter Anfang, aber nur die halbe Miete. Die agilen Prinzipien sind es, die dafür sorgen, dass die Praktiken gut funktionieren und nachhaltig getragen werden. Grundsätze sind viel schwerer zu integrieren als Gewohnheiten, dies ist der Grund warum viele Firmen dabei zu kurz kommen – sie nehmen den leichten Ausweg. Techniken anzuwenden, ohne zu verstehen, warum Sie diese anwenden, kann zu Frustration führen. Agile bezieht die Personen, Interaktionen und Kulturen mit ein und dreht sich nicht um Prozesse, Praktiken und Werkzeuge.

 

3. Den Agile/Scrum Startup verkomplizieren

Tun Sie alles, was Sie können, um agile Startups einfach zu halten. Agile Projekte können ohne das neueste, coolste Kollaboration- oder Lifecycle-Tool erfolgreich sein. Kleben Sie die Bilder auf eine Wand, organisieren Sie Aufgaben in einer Tabellenkalkulationstabelle oder erstellen Sie manuell ein Burn-Down Diagramm. Wertvolle Zeit damit zu verbringen, ein Werkzeug am Laufen zu halten, anstatt Menschen zusammenarbeiten zu lassen, ist vergeudete Zeit. Das agile Manifest legt mehr Wert auf Individuen und Interaktionen als auf Prozesse und Werkzeuge. Nichtsdestotrotz spricht auch viel für eine digitale Lösung wie Atlassian’s Jira.

4. Führen von Scrum-Teams wie ein Projektleiter

Eine „Führungs- und Kontrollmentalität“ steht im Widerspruch zum agilen Rahmenwerk. Ein Leiter, der Aufgaben und Diktieraufwand zuteilt, beschreibt gegensätzliche Muster von agile. Große agile Teams organisieren sich selbst, der Scrum Master ist lediglich ein begleitender Leiter. Die Teams lernen durch regelmäßige Inspektionen und Anpassungen besser zusammenzuarbeiten, um einen höheren Wert zu liefern. Oft wird eine Lektion durch Erfahrung besser gelernt als durch die bloße Anweisung, was zu tun ist. Lassen Sie das Scrum-Team Dinge selbst herausfinden, Fehler machen und von ihnen lernen, um Zufriedenheit zu erlangen und so ein produktives Team zu werden. Scrum Masters und agile Coaches führen mehr als sie steuern.

 

5. Das unfertige Produkt-Backlog

Ein Produkt-Backlog, das nicht fertig ist sowie unmotivierte Teams sind die häufigste Ursache für Fehler im Sprint . Außerdem fördert es geringe Projektdurchführungsgeschwindigkeiten sowie minderwertige Ergebnisse. Die meisten Produkt-Owner sind nicht bereit, auf eigene Faust produktiv zu sein. Sie benötigen Anweisungen, Coaching und müssen für die ersten Sprints an die Hand genommen werden. So erlernen sie, einen Produkt-Backlog zu entwickeln und beizubehalten, der genügend wertvolle Eigenschaften hat, um auf hohem Niveau geschätzt und von Geschäftswerten priorisiert zu werden. Das Vorbereiten des Backlogs vor dem nächsten Sprint ist ein Muss, um den Workflow aufrecht zu erhalten. Die Rolle des Produkt-Owners kann sehr zeitaufwändig sein. Stellen Sie die richtigen Erwartungen, sorgen sie für das Training ihrer Mitarbeiter und helfen Sie dem Product-Owner, den Arbeitsfluss aufrecht zu erhalten.

6. Kommunikation durch den Scrum Master

Scrum-Teams nutzen oftmals den Scrum Master, um ihre Botschaften an bspw. Kunden weiterzugeben. Wenn ein Entwickler eine Frage zu einer User-Story hat; anstelle direkt an den Product-Owner heranzutreten, schreibt dieser dem Scrum Master eine E-Mail. Ein wesentliches Prinzip von agile- ist die fortwährende Kommunikation von Angesicht zu Angesicht. Die Zeit, die zum Verfassen der E-Mail benötigt wurde, wäre wahrscheinlich alles gewesen, was nötig gewesen wäre, um die Antwort direkt von den Stakeholdern zu erhalten. Aber für viele technische Leute ist die persönliche Kommunikation eine beängstigende Sache, wenn sie daran gewöhnt sind nicht mit Menschen sprechen zu müssen. Dies ist ein kulturelles bzw. persönliches Problem, das überwunden werden muss. Es verschwendet Zeit und erhöht vor allem das Risiko von Kommunikationsfehlern.

7. Ein Product-Owner, der nicht verfügbar oder beteiligt ist

Die Rolle des Product-Owner kann sehr zeitaufwendig sein. Viele, die diese Rolle erhalten, sind nicht bereit für das Engagement oder unterschätzen, wie stark sie in Projekte eingebunden werden müssen. Zusammenarbeit ist in der agilen Welt von entscheidender Bedeutung. Geschäftsleute und Entwickler müssen zusammenarbeiten, um Projekte erfolgreich abzuschließen, die der Kunde wünscht. Dies geschieht durch ständige Kommunikation, Zusammenarbeit und kurze Feedback-Zyklen zur Validierung oder Kurskorrektur innerhalb des Projektes. In der Praxis ist der Product Owner sehr stark in die alltägliche Arbeit des Projektteams involviert, sodass die Sprint-Überprüfung oftmals nur eine reine Formalität darstellt. Ursache legt darin, dass der Product-Owner bereits mehrere Iterationen der Features während des Sprints durchlaufen hat und das Team zum Projektziel geführt hat, was besonders positiv ist.

8. Lockere Daily Stand-Ups

Das tägliche Stand-Up-Meeting ist in mehrfacher Hinsicht sehr wichtig. Täglich werden die Menschen 15 Minuten lang direkt miteinander in Kontakt gebracht, wobei die Kommunikation und Zusammenarbeit erzwungen und die Transparenz des Projekts geschaffen wird. Für ein solches Schlüsselgespräch ist es wichtig, die richtigen Erwartungen im Vorfeld zu definieren, damit das Team weiß, welche Prioritäten innerhalb des Projektes existieren. Das mag ungewöhnlich klingen, aber ein tägliches Stand-Up ist nie freiwillig. Hierbei gilt insbesondere: Start und Ende des Dailys pünktlich. Halten Sie sich dabei an die folgenden drei Fragen:

  • Was habe ich gestern für das Projekt erreicht?
  • Woran werde ich heute arbeiten?
  • Welche Hindernisse hindern mich daran, meine Arbeit termingerecht zu erledigen?

Lassen Sie keine Nebengespräche, Diskussionen oder Problemlösungen während des Stand-Ups, sondern erst nach dem Stand-Up zu. Dies führt dazu, dass die Teammitglieder sich gegenseitig sowie die Zeit jedes Einzelnen respektieren und dabei lernen besser zu kommunizieren, indem sie sich an die Ziele halten.

9. Hindernisse nicht früh genug beheben

Das tägliche Stand-Up bietet die Möglichkeiten, jeden Tag Hindernisse anzusprechen um die Projektziele zu erreichen. Eine der primären Funktionen des Scrum Master ist es, Hindernisse zu beseitigen, damit sich das Team auf die Bereitstellung von Software konzentrieren kann; aber wenn Hindernisse nicht aufgezeigt werden, kann der Scrum Master auch nicht helfen, sie zu beseitigen. Bis sich die Teammitglieder daran gewöhnt haben, Hindernisse rechtzeitig zu kommunizieren, erinnert der Scrum Master das Team zu Beginn jedes Stand-Ups, um potentielle Hindernisse aufzudecken, die ihre Arbeit verzögert oder sie dazu bringt, ihrem Sprint-Engagement nicht gerecht zu werden.

10. Die Durchführung von rückblickenden Meetings nach jedem Sprint

Eines der zwölf Prinzipien hinter dem agilen Manifest lautet: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an“. Leider werden die Sprintrückblicke oft wie ein Add-On oder Luxus behandelt und nur „wenn es Zeit gibt“ durchgeführt. Tatsache ist, dass es bei agiler Projektentwicklung immer nur um Anpassungen geht, um Feinabstimmung und Reaktion auf Veränderungen. Jedoch ist es wirklich schwer Korrekturen und Feinabstimmungen durchzuführen, wenn die notwendigen Anpassungen nicht identifiziert werden. Hierbei ist der Status Quo nicht agil, sondern kontinuierliche Verbesserung.

Haben Sie Fragen? Wir bieten Ihnen eine ausführliche Beratung zum Thema Agile und unterstützen Sie bei der Integration sowie Optimierung Ihrer agilen Prozesse.