Kurze Ankündigung: Ich habe einen neuen Newsletter „Scrum mit KI“.
Darin teile ich jede Woche ein KI-Playbook für Product Owner und Scrum Master, die mach KI zu deinem persönlichen Assistenten machen wollen und Teams in KI-Ära führen wollen.
Vielleicht ist das auch für dich hilfreich.
Aber jetzt zum den 5 „Feinde“ die das Budget verbrennen – noch bevor Features live gehen:
Mit einigen Unterbrechungen arbeite ich jetzt seit 10 Jahren in der IT-Beratung.
Schön langsam wiederholen sich bestimmte Muster. (Obwohl mir jeder Kunde versichert, dass seine Situation speziell sei.)
Einige dieser Muster (Oder sollte ich „Schmerzen“ sagen?) haben es mir angetan. Ich nenne sie die unbezwingbaren „Feinde“. Zum einen wirken sie sich drastisch auf die Kosten von Softwareentwicklung, die Einhaltung von Lieferterminen und die Verlässlichkeit von IT-Abteilungen aus. Zum anderen gibt es so gut wie kein Unternehmen, das sie vollständig eliminieren konnte.
Ich möchte sie dir heute mal der Reihe nach vorstellen.
Los geht’s:
Feind #1: Häufige Unterbrechungen und ungeplante Arbeit
„Könntest du mir kurz bei einer Anfrage helfen?“
Diese Bitte wurde im Jahr 2019 mehrfach im Sprint an die Entwickler eines Teams gestellt. Ich habe mir erst mal nichts weiter gedacht. Im Sprint-Review kam es dann zum Eklat. Unserem Team wurde vorgeworfen, dass wir immer langsamer werden. Und die Zahlen standen auch gegen uns: Die Velocity war in den letzten Sprints von 45 Punkten auf 33 gefallen.
Von diesem Tag an fing ich an, Unterbrechungen zu sammeln, auszuwerten und die Auswirkungen davon sichtbar zu machen.
Die Auswirkungen sind stärker, als ich angenommen habe:
- Verbringt der Tester im Team 28 Stunden pro Sprint damit, den Support zu unterstützen oder Angebote mit dem Vertrieb zu schreiben, dann fehlt die Zeit offensichtlich in der Entwicklung.
- Allerdings fehlt der Tester auch in der Entwicklung. Soll heißen: Die restlichen Entwickler müssen warten, bis der Tester ihre Arbeit testen kann.
- Und es bleibt auch nicht bei den 28 Stunden.
Unterbrechungen sind jedoch nur der erste Feind. Seinen großen Bruder werden wir in #3 kennenlernen.
Jetzt erst mal zu einem anderen.
Feind #2: Technische Schulden und unfertige Arbeit
Bei der Terminierung von Lieferterminen gehen wir stillschweigend davon aus, dass wir auf ein sauberes Fundament aufsetzen.
Aber mal Hand aufs Herz, in Wirklichkeit kämpft jedes Team mit:
- Altlasten,
- Workarounds,
- aufgeschobenen Updates von Libraries,
- ungeklärten Bugs und
- angefangener, nie beendeter Arbeit.
Diese unsichtbare Arbeit taucht weder in Sprint-Plannings noch in Projektplänen auf. Betrachten wir die Auswirkungen anhand von Integrationstests:
Angenommen, das Team entschließt sich, die Integrationstests später nachzuentwickeln und erst mal nur die Features fertigzustellen.
1 Feature = 0 Tests
2 Features = 2 Tests
3 Features = 6 Tests
4 Features = ???
Du siehst, wo das hinführt, oder?
Ungetane Arbeit – wie nicht erstellte Integrationstests – wächst exponentiell. Gleiches gilt für technische Schulden.
In meinen „Professional Scrum Product Owner“-Schulungen visualisiere ich dieses Verhalten mit dieser Grafik. Sie erklärt gut, warum unsichtbare Restarbeiten schnell dazu führen, dass wir „nie“ fertig werden und sofort den Ruf haben, unplanbar zu sein.
Feind #3: Projekt-Multitasking
Viele Kunden, bei denen ich über die Jahre war, brüsten sich damit, wie gut sie im Multiprojekt-Management sind.
Was wie gutes Projektmanagement klingt, ist der Produktivitätskiller schlechthin und kommt Unternehmen teuer zu stehen. Dazu kommen wir gleich. Aber erst mal:
Woran erkennst du das Multitasking, das aus dem Multiprojekt-Management resultiert?
Im besten Fall äußert es sich dadurch, dass das Team an vielen Einträgen des Backlogs zur selben Zeit arbeitet. Im schlimmsten Fall arbeitet das Scrum Team an mehreren Projekten zur gleichen Zeit. Unter uns: Dies ist auch in 9 von 10 Fällen der Grund, warum Teams Schwierigkeiten haben, EIN Ziel für sich zu definieren.
Aber warum kommt Multitasking Unternehmen 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.
Allein dieser Kontextwechsel kostet Unternehmen also 800.000 Euro im Jahr. Alles dank Multiprojekt-Management statt Priorisierung.
Dazu kommen wir jetzt:
Feind #4: Unklare Prioritäten
Jeder kennt die Weisheit: Wenn alles Priorität 1 ist, hat am Ende gar nichts Priorität.
Leider ist das in meiner Arbeit mit Teams einer der Gründe, warum Projekte mehr kosten und später fertig werden als geplant.
Woran habe ich bisher immer unklare Prioritäten erkannt?
Hier meine Top 5:
- Product-Owner verbringen viel Zeit in Meetings damit, Prioritäten zu diskutieren.
- Teams starten neue Themen, bevor die aktuellen fertig sind.
- Das Product-Backlog hat über 100 Einträge.
- Jede Arbeit gleicht einem Notfall und Fire-Fighting ist die Normalität.
- Es gibt Backlogs für Features, Bugs, technische Schulden, Kundenwünsche usw.
Und jetzt kommt die unangenehme Wahrheit:
Unklare Prioritäten verwirren nicht nur Entwickler. Sie verbrennen Budget, weil sie automatisch zu den Kosten führen, die wir gerade berechnet haben: Multitasking.
Und dabei gibt es so viele Methoden, wie priorisiert werden könnte:
- Cost of Delay (CoD): Was kostet es uns eigentlich pro Woche oder Monat, wenn dieses Feature nicht live geht? Das macht den wirtschaftlichen Schaden von Verzögerungen sofort greifbar.
- Weighted Shortest Job First (WSJF): Hier kombinieren wir den Wert (CoD) mit der Dauer. Wir suchen die „Quick Wins“, also die Aufgaben, die den höchsten Wert in der kürzesten Zeit liefern.
- FIFO (First In, First Out): Der Klassiker: „Wer zuerst kommt, mahlt zuerst.“ Fair, aber oft gefährlich, da wichtige Marktveränderungen ignoriert werden.
- Oder von mir aus auch HiPPO (Highest Paid Person’s Opinion).
Das alles spart am Ende Unternehmen mehr Geld, als keine Prioritäten zu haben.
Zum Abschluss noch ein unsichtbarer Feind:
Feind #5: Abhängigkeiten
Kommt dir eine dieser Situationen bekannt vor?
- Vor dem Sprint-Planning 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 kann den Stakeholdern nur ein Mock-up des neuen Features präsentiert werden. Ausprobiert werden kann es nicht, da es nur auf dem Rechner eines Entwicklers lauffähig ist.
- In der Sprint-Retrospektive wirft das Team einen Blick auf die Cycle-Time und stellt fest, dass die von Sprint zu Sprint zunimmt.
Das sind alles Beispiele aus meinen vergangenen Projekten. Alle haben eines gemeinsam: Sie sind auf Abhängigkeiten zurückzuführen.
Abhängigkeiten sind der unsichtbare Feind jeder Softwareentwicklung. Und sie sind tückisch. Sie bleiben meistens versteckt. Deshalb stelle ich mir Abhängigkeiten immer als Spinnennetz vor. Wenn wir nicht aufpassen, verstrickt sich das Team immer mehr darin. Es kann sich irgendwann nicht mehr vor- oder zurückbewegen, bis es ganz gefangen ist.
Abhängigkeiten können in drei Bereichen auftreten: Architektur, Fachwissen oder Arbeitsorganisation.
Hier ein Beispiel, wie Abhängigkeiten aufgedeckt aussehen können.
Diese Situation ist für Product-Owner fatal. Denn bereits zwei abhängige Einträge des Backlogs reduzieren die Anzahl der Möglichkeiten, das Backlog anzuordnen, um 50 %.
Ergo: Je mehr Abhängigkeiten, desto weniger Entscheidungen können Product-Owner noch treffen.
Mein Fazit aus 10 Jahren IT-Beratung
Die fünf Feinde – Unterbrechungen, technische Schulden, Multitasking, unklare Prioritäten und Abhängigkeiten – liegen nicht in der Natur von Softwareentwicklung.
Sie sind das Ergebnis von Management-Entscheidungen.
Und das ist eine gute Nachricht. Denn was durch Entscheidungen entsteht, lässt sich durch Entscheidungen auch wieder beheben. Suchst du Unterstützung dabei, Entscheidungen datenbasiert und nicht nach Bauchgefühl zu treffen?
Dann könnte mein „Professional Agile Leadership – Evidence Based Management“-Training genau richtig für dich sein.