Stop starting, start finishing

delivery Feb 27, 2023
 

Heute ist mal wieder Phrasen-Dresch-Zeit: Stop starting, start finishing! Was kannst du tun, wenn sich die Projekt- oder Featureanfragen auf deinem Tisch stapeln und dein Entwicklungsteam viel zu klein ist? Interessante Frage und ich werde versuchen, eine ganze Reihe von Antworten zu geben - von theoretisch bis pragmatisch.

In einem meiner Coaching-Gespräche ist es passiert: Eine meiner Coachees sollte in ihrem Unternehmen eine übergreifende Projektplanung durchführen. Ich fragte interessiert nach, über wie viele Projekte wir denn reden. 11. Wow - das wird anspruchsvoll! Die nächste Frage ging in die Richtung, wie viele Teammitglieder denn in diesen Projekten arbeiten würden. 7. SIEBEN Teammitglieder - mir verschlug es kurz den Atem. Und ja, es handelte sich um 11 separate Projekte für 11 separate Produkte mit unterschiedlicher Codebase.

Probleme

Bevor wir zu den Lösungen kommen, lass uns zunächst über die Probleme sprechen. Welches Problem wollen wir eigentlich lösen? Spoiler: Es ist nicht die übergreifende Projektplanung. Ja, kann man machen. Sie kann aber nicht die tiefergreifenden Probleme lösen. Also, wovon spreche ich?

Es dauert sehr lange, bis Nutzen realisiert wird

Kurze Rekapitulation des Projektmanagement Einmaleins: Dauer = Aufwand / Ressourceneinsatz. Wenn der Aufwand 10 Tage beträgt und ich einen Mitarbeiter einsetze, ist die Dauer ebenfalls 10 Tage. Wenn ich 2 Mitarbeiter einsetze, reduziert sich die Dauer auf 5 Tage. Bei einem halben Mitarbeiter erhöht sich die Dauer auf 20 Tage. Logisch, oder?

Wenn ich also 11 Projekte mit einem Aufwand von je 700 Personentagen habe, dabei 7 Teammitglieder einsetzen kann und alle Projekte parallel laufen, dauert es 11 * 700 / 7 = 1100 Tage, bis die Projekte abgeschlossen sind. Das sind 5-6 Jahre. Heißt aber auch: Aus Unternehmenssicht habe ich 5-6 Jahre gar keinen Nutzen, sondern nur Kosten. Das muss man sich erstmal leisten können.

Context switching erhöht den Aufwand

Wenn deine Teammitglieder an 11 Projekten gleichzeitig arbeiten, werden sie fast zwangsläufig aus ihrer aktuellen Aufgabe rausgerissen. Eigentlich arbeitet Heinz an Thema A. Aber dann muss ein Bug in Thema B behoben werden. Und ein Kollege hat eine Rückfrage zu Thema C. Und ein Security Patch muss für Thema D eingespielt werden. Und ein Anwender braucht Unterstützung für Thema E. Und… dir fallen bestimmt weitere Beispiele ein.

Achtung: Geplantes context switching ist in der Regel kein Problem. Ich mache erst A fertig und beginne dann B. Problematisch ist context switching immer dann, wenn man plötzlich aus der Arbeit gerissen wird, bevor man die Aufgabe erledigt hat. Es dauert schlicht einige Zeit, bis man sich sortiert hat, geistig wieder an dem Punkt angelangt ist, an dem man vorher war, und weiterarbeiten kann.

Wir können eher konservativ mit 10% zusätzlichem Aufwand kalkulieren. In dem vorherigen Beispiel wären das knapp 700 Tage zusätzlicher Aufwand, der natürlich Geld kostet, aber auch ein halbes Jahr Zeit kostet.

Das sind jetzt aber alle Probleme gewesen, oder? Nein, leider noch nicht…

„Warten auf Antwort“ erhöht die Dauer

Du kennst das bestimmt: Du hast ein Problem, du kommst nicht weiter, aber du weißt, dass Heinz dir helfen kann. Dummerweise ist Heinz aber gerade in einem super-wichtigen Meeting. Und dann muss er die Präsentation für den Chef erstellen. Und dann noch schnell die Auswertung für Controlling. Aber dann, drei Tage später, hilft er dir. Dein Problem ist in 30 Minuten gelöst. Toll, oder?

Ja und nein. Natürlich ist es toll, wenn dein kniffliges Problem innerhalb von 30 Minuten gelöst wird. Aber… du hast auch drei Tage auf Heinz gewartet, weil ihr nicht gemeinsam an einem Thema gearbeitet habt, sondern viele Bälle jonglieren musstet. Multipliziere dieses Phänomen mit 7 Kollegen und 11 Projekten und du wirst schnell feststellen, dass ihr unheimlich viel Zeit mit Warten verbringt.

Wohlgemerkt: Es dreht niemand Däumchen, es gibt ja genug Arbeit. Aber die Dauer bis zur Fertigstellung eines Themas oder Projektes ist deutlich höher.

Koordination mit Team und Stakeholdern erhöht den Aufwand

Wer sorgt denn nun eigentlich dafür, dass die Kollegen an den richtigen Themen arbeiten? Wer orchestriert die Vielzahl der Stakeholder und führt Priorisierungsgespräche? Wer schüttelt und rüttelt die Projektplanung, wenn sich mal wieder Prioritäten ändern oder neue Themen hinzukommen? Richtig, der Projektleiter / Programmleiter / Kümmerer. Ich behaupte, in dieser Konstellation von 11 Projekten und 7 Entwicklern hat diese Person alle Hände voll zu tun. Aber… und jetzt kommt ein großes aber… das ist eigentlich ja nur Overhead. Am liebsten würde man sich diesen ganzen Koordinationskrempel ja sparen. Der Aufwand für die Projektdurchführung wäre signifikant niedriger.

Kaugummiprojekte zehren an der Motivation

Schließlich zehrt diese Arbeitsweise auch an der Motivation aller Beteiligten. Nichts wird fertig bzw. es dauert ewig. Überall sind lose Ende, die man wieder einfangen muss. Von den 11 Bällen, die jongliert werden, fällt jede Woche einer auf den Boden (oder in den Abgrund). „Wenn Arbeit keine Arbeit wäre, würde es ja Spaß heißen“. Schon richtig. Aber unmotivierte Teamkollegen führen dazu, dass sich der Aufwand und die Dauer erhöht und zu guter Letzt auch die Fluktuation höher ist als üblich - was dann wieder Folgekosten nach sich zieht.

Lösungen

Ich weiß, ich bin ganz schön lange auf den Problemen rumgeritten. Der Grund hierfür ist simpel: Ich möchte einerseits dir deutlich machen, dass es ungeschickt ist, diese Situation einfach laufen zu lassen. Andererseits möchte ich dir ein paar Argumentationshilfen an die Hand geben, die du in Gesprächen mit deinen Stakeholdern nutzen kannst. Die Frage wird kommen: Wieso sollen wir etwas ändern?

Jetzt aber zu möglichen Lösungen.

Etabliere feste Teams

Gemeinsam ist man stärker. Geteilte Freude ist doppelte Freude. Und so weiter. Starke Teams haben viel mehr Durchschlagskraft als eine lose Sammlung von Individuen. Bei 7 Kollegen könntest du sowohl ein als auch zwei Teams bilden. Ich würde das Abhängig vom Skillset der Kollegen, von den anstehenden Themen und der Stimmung der Kollegen untereinander machen.

Arbeite die Themen seriell ab

Ein Team, ein Thema. Es ist so simpel wie effektiv. Erst wenn ein Thema oder Projekt abgeschlossen ist, beginnt das Team mit dem nächsten Thema. Für die Arbeit im Projekt ist dies eine hervorragende Lösung. Die Herausforderung ist die Priorisierung: In welcher Reihenfolge bearbeiten wir die Projekte? Welchem Kunden oder Anwender sagen wir „nein, wir arbeiten jetzt nicht für dich“. Übrigens: Die Priorisierung und Argumentation fällt umso leichter, je klarer die Unternehmensstrategie ist. Ohne einen „Nordstern“ fällt die Ausrichtung tatsächlich schwer.

Bearbeite in einem Sprint genau ein Thema

Wenn du das Projekt nicht stringent von Anfang bis Ende durchziehen kannst, dann sorge wenigstens dafür, dass du innerhalb eines Sprints fokussiert arbeiten kannst. Du könntest dann beispielsweise in Sprint 1 an Thema A arbeiten, in Sprint 2 an Thema B, Sprint 3 wieder Thema A, Sprint 4 Thema C und so weiter. Mit dieser Arbeitsweise löst du einen Großteil der oben beschriebenen Probleme, aber das Kernproblem bleibt bestehen: Es dauert sehr lange, bis der Nutzen realisiert wird. Darüber musst du dir im Klaren sein.

Bring tageweise die richtigen Kollegen zusammen

Achtung: Diese Lösung ist wirklich nur ein Notnagel, um die Herausforderungen des Context Switchings und der Kommunikation ein wenig zu verbessern. Du bringst die richtigen Kollegen tageweise zusammen, also beispielsweise arbeiten Heinz und Karl am Montag und Dienstag an Thema A, Mittwoch und Donnerstag an Thema B und nutzen Freitage als Puffer und für die Planung. Wie gesagt, keine gute Lösung, aber eine Variante, die du vermutlich ohne Absprache mit Stakeholdern oder Vorgesetzten umsetzen kannst.

Stelle mehr Mitarbeiter ein

Nur der Vollständigkeit halber: 11 Projekte gleichzeitig mit 50-60 Entwicklern durchzuführen löst die obigen Probleme auch. Es ist zwar nicht so, dass du dann keine Probleme mehr hast, aber du hast zumindest andere Probleme…

Fazit

Zu viele gleichzeitige Projekte sind problematisch. Zu viele gleichzeitige Features übrigens auch, das gesagte gilt hier analog. Es lohnt sich ungemein, diese Probleme tatsächlich zu lösen. Es ist gut für die Mitarbeiter, es ist gut für die Projekte und es ist gut für das Unternehmen.

Die Umsetzung dieser Ideen scheitert in der Regel auch nicht an den Mitarbeitern, sondern an Stakeholdern und Management. Bleib dran und schlag auch ungewöhnliche Dinge vor. Du könntest beispielsweise eine konzertierte Aktion empfehlen: Lasst uns jetzt 1 Monat ausschließlich an Projekt Z arbeiten, um dieses endlich abzuschließen und durch die Tür zu bringen! Oder ihr führt ein Experiment durch: Lasst uns doch mal 3 Monate lang an nur einem Thema pro Sprint arbeiten. Anschließend evaluieren wir, ob die Arbeitsweise besser, gleich oder schlechter als der Status Quo ist. Mit derartigen Vorschlägen forderst du kein vollständiges Commitment deiner Stakeholder ein - sie können immer noch einen Rückzieher machen. Aber du kommst einen Schritt voran und beißt nicht sofort auf Granit.

Ich wünsche dir viel Erfolg bei der Umsetzung dieser Ideen!

Wenn du Fragen hast oder wenn ich dich bei der Umsetzung unterstützen kann, sprich mich gerne an!

In jedem Fall denk immer daran: Das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten!

Lass uns in Kontakt bleiben!

Melde dich für meinen Newsletter an, um regelmäßig Inspirationen, Informationen und Angebote zum Thema Product Ownership zu erhalten.  Deine Daten werden selbstverständlich nicht weitergegeben.

Ich verschicke kein Spam. Du kannst dich jederzeit abmelden.