Diese 5 gängigen Probleme machen Scrum Teams langsamer. Werden sie nicht behoben, kosten sie Unternehmen bis zu 800.000 Euro.
Die meisten denken, es liegt daran, dass Scrum nicht verstanden wurde.
Aber das stimmt nicht. Der größte Geldverlust entsteht durch dieses Problem:
Problem #1: Zu viel „Work in Progress“
Multitasking ist der stille Produktivitätskiller.
In Scrum Teams äußert sich Multitasking im besten Fall dadurch, dass das Team an vielen Einträgen des Sprint-Backlogs zur selben Zeit arbeitet. Im schlimmsten Fall arbeitet das Scrum Team an mehreren Projekten zur gleichen Zeit. Dies erkennst du daran, dass das Team nicht in der Lage ist, ein Ziel für den Sprint zu finden.
Aber warum kommt Multitasking Unternehmen so teuer zu stehen?
Hier eine Beispielrechnung: Angenommen, ein Team arbeitet an drei Projekten gleichzeitig. Dann geht aus einer Studie von Gerald Weinberg hervor, dass die Teammitglieder 40 % ihrer Arbeitszeit mit Kontextwechseln verbringen.
Was sind 40 % Kontextwechsel in Euro? Nehmen wir weiter an, dass ein Entwickler am Tag 1.000 Euro kostet und wir 10 Entwickler im Team haben. Bei 10 Arbeitstagen pro Sprint und 20 Sprints im Jahr, kommen wir dann auf 2.000.000 Euro. 40 % davon sind 800.000 Euro.
Der Kontextwechsel kostet Unternehmen also 800.000 Euro.
Wie lassen sich Multitasking und die damit einhergehenden Kosten durch den ständigen Kontextwechsel verhindern? Ein einfacher Weg ist, die „Work in Progress“ im Sprint zu limitieren. Also die Anzahl der Projekte oder Einträge im Sprint-Backlog, an denen das Team gleichzeitig arbeitet. Deshalb spart Fokussierung Kosten und sorgt dafür, dass das Team schneller arbeitet.
Willst du lernen, wie du in deinem Team den „Work in Progress“ limitieren kannst? Dann empfehle ich dir den Besuch des „Applying Professional Kanban“-Trainings in München. Mein Kollege Peter gibt dir nicht nur eine konkrete Anleitung, sondern warnt dich auch vor den typischen Fehlern, die Anfänger beim Limitieren von „Work in Progress“ begehen.
Einem weiteren Problem, das Teams ausbremst, widmen wir uns jetzt:
Problem #2: Zu viele Abhängigkeiten
Kommen dir diese Situationen bekannt vor?
- Vor dem eigentlichen Sprint-Planning im Team muss der Product-Owner noch weitere Abstimmungsrunden mit anderen Teams drehen, damit die Arbeit für den Sprint geplant werden kann.
- Im Daily Scrum berichten die Entwickler, dass sie nicht weiterarbeiten können, da die Datenbankspezialistin nicht auf ihre Anfragen reagiert.
- Im Sprint-Review können den Stakeholdern ein Mock-up und der Source-Code des neuen Features präsentiert werden, aber ausprobiert werden kann es nicht, da es nur auf dem Rechner eines Entwicklers lauffähig ist.
Dies sind alles Beispiele aus meiner Arbeit als Scrum Master in den letzten Jahren. Was haben sie alle gemein?
Du hast es erraten: Abhängigkeiten.
Abhängigkeiten behindern die Arbeit von Scrum Teams. Abhängigkeiten machen Scrum Teams langsam. Abhängigkeiten sind deshalb der unsichtbare Feind der Agilität. Und Abhängigkeiten zeigen sich auf unterschiedliche Weise:
- Architektur: Abhängigkeiten in der Software machen Änderungen zeitaufwendiger.
- Aktivitäten: Abhängige Aktivitäten verzögern die Fertigstellung.
- Fachwissen: Warten auf bestimmte Personen führt zu Verzögerungen.
Wie lassen sich Abhängigkeiten auflösen?
Abhängigkeiten in der Software lassen sich durch moderne Softwareentwicklung verbessern. Versionskontrolle, Branching-Strategien und API-Versionierung helfen, Stück für Stück Abhängigkeiten in der Software zu reduzieren. Abhängigkeiten in den Aktivitäten lassen sich durch das Refinement der Product-Backlog-Einträge erkennen und reduzieren. User-Stories sollten so weit verfeinert werden, bis sie unabhängig umgesetzt werden können.
Abhängigkeiten, die durch fehlendes Fachwissen entstehen, führen zu Engpässen. Dieses Problem ist so weit verbreitet in Scrum Teams, dass ich es separat aufgelistet habe:
Problem #3: Engpässe bei den Fähigkeiten
Du erkennst Engpässe daran:
- Nur eine Person ist in der Lage, die Arbeit zu testen.
- Blockiert ein Entwickler das Team, indem er etwas implementiert, worauf alle anderen warten?
- Beginnen andere Mitglieder im Team damit, irgendwelche belanglosen Aufgaben anzufangen, nur weil sie nichts anderes zu tun haben?
Dies deutet alles auf Engpässe hin. Davor warnt uns bereits der Scrum Guide:
„Scrum Teams sind interdisziplinär, d. h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.“
Fehlt es dem Team an Fähigkeiten, kommt es zu Engpässen. Sind die Fähigkeiten nicht breit im Team gefächert, entstehen ebenfalls Engpässe. In beiden Fällen führt dies zu Verzögerungen. Das Scrum Team wird zwangsläufig langsamer werden.
Wie kannst du diese Engpässе aufdecken?
Nutze eine Fähigkeiten-Matrix:
Die Matrix hilft dir transparent zu machen, welche Fähigkeiten noch fehlen, um eine fertige Version des Produkts zu entwickeln.
Problem #4: Zu viele technische Schulden
Partytime:
Du hast viele Gäste bei dir zu Hause. Einige Gäste essen kein Fleisch. Jemand anderes verträgt keinen Pfeffer, und die Kinder wollen unbedingt Wiener Schnitzel mit Pommes. Natürlich möchtest du auch eine Vorspeise und eine Nachspeise servieren. Das gehört ja schließlich zu einer guten Party dazu. Zusammengefasst: Du musst also mehrere Gänge und mehrere Speisen nacheinander zubereiten.
Was passiert, wenn du nach dem ersten Gang die Töpfe und Pfannen nicht abspülst? Welche Auswirkung kann es haben, wenn du die Messer nicht schleifst? Ist es ein Problem, wenn du die benutzten Teller der Vorspeise nicht abräumst und spülst?
Erstmal passiert nichts.
Im Gegenteil, du hast dir etwas Zeit geborgt. Du kannst sie nutzen, um mit all deinen Gästen zu reden, bevor du wieder in die Küche verschwinden musst. Schreitet der Abend aber fort, wirst du diese geborgte Zeit irgendwann zurückzahlen müssen. Bevor du den nächsten Gang zubereitest, wirst du die Töpfe wohl spülen müssen. Und bevor du den Gang servierst, wirst du die benutzten Teller vom Tisch abräumen müssen. Und vielleicht wirst du auch die Messer schleifen müssen, bevor du das Rindfleisch in hauchdünne Scheiben schneiden kannst. Mit dem Resultat, dass die Gäste länger auf den zweiten Gang warten müssen als geplant und vielleicht auch bereits angekündigt.
Kurzfristige Geschwindigkeit auf Kosten von Qualität aufzunehmen, nennen wir in der Softwareentwicklung „technische Schulden“. Wie beim Kochen werden Scrum Teams diese Zeit irgendwann zurückzahlen müssen, was in Verzögerungen resultieren wird.
Scrum Teams können dies verhindern, indem sie jeden Sprint ihre technische Schuld transparent machen. Im nächsten Sprint sollten sie diese Schulden umgehend zurückzahlen.
Problem #5: Kein gemeinsames Ziel
Gründe, auf Sprintziele zu verzichten, gibt es genügend:
- Wir arbeiten nicht an einem Produkt, sondern an (mehreren) Projekten.
- Während des Sprints kommt es zu unvorhergesehener Arbeit. Ein Sprintziel beraubt uns der Flexibilität, darauf zu reagieren.
- Unsere Arbeit hat viele Abhängigkeiten von anderen Teams. Wir können erst mit unserer Arbeit beginnen, wenn das andere Team fertig ist.
- Das Team hat Angst, sich auf nur eine Sache zu verpflichten, da die Stakeholder auch noch andere Dinge von uns erwarten.
Gleichzeitig schreibt der Scrum Guide seit der Version aus dem Jahr 2010 ein Ziel für jeden Sprint vor:
„Nach der Auswahl des Product-Backlogs wird ein Sprint-Ziel erstellt. Das Sprint-Ziel ist ein Ziel, das durch die Umsetzung des Product-Backlogs erreicht wird. Es handelt sich um eine Aussage, die das Team darüber informiert, warum es das Inkrement erstellt.“
Warum ist das so? Vereinfacht gesagt:
Ohne Ziel, kein Team.
Bestenfalls besteht das Scrum „Team“ dann aus einer Gruppe von Fachexperten, die ihre Arbeit koordinieren. Es sollte dann wohl eher Scrum „Gruppe“ heißen. Ein gemeinsames Ziel fördert die Motivation und das „Wir-Gefühl“ im Team. Whitworth und Biddle haben dies mit ihrer Forschung im Jahr 2007 nachgewiesen. Sie konnten zeigen, dass in agilen Teams das Engagement für Teamziele den Zusammenhalt, die Teameffektivität, den Wissensaustausch und die Feedback-Prozesse erhöht. Meiner Erfahrung nach führen mehr Zusammenhalt und effektiveres Arbeiten dann auch zu mehr Geschwindigkeit bei der Entwicklung von qualitativ hochwertiger Software.
Willst du mehr über Sprintziele erfahren? Suchst du nach Tipps, wie du Sprintziele in einem Team definieren kannst? Dann wirf gerne einen Blick auf meinen Webcast dazu.