Zu viel Arbeit und zu wenige Leute. Das hört sich doch vertraut an. Oder?

Zu viele Leute im Team bei der Softwareentwicklung? Das klingt fast nach Utopie und Luxusproblem, wo doch Personal überall knapp ist und Geld sowieso.

Trotzdem kommt es häufiger vor als einem lieb ist. Vor allem in frühen Phasen von Software-Entwicklungsprojekten.  

Es wäre manchmal besser, einen Teil der Mannschaft erst mal zum Tischtennis spielen zu schicken, bis die Zeit für ihren Einsatz im Entwicklungsprojekt gekommen ist. Denn sonst stehen sie bis dahin mit gut gemeinten Aktionen oder gar Aktionismus den wirklich wichtigen Aufgaben im Projekt im Weg und verzögern es dadurch nachhaltig.

Und genau darum geht es in diesem Artikel.

Warum tun viele Leute einem Projekt zu Beginn eigentlich nicht gut?

Das ist eines der berühmtesten Zitate in der Software-Engineering Geschichte. Aus dem Buch „The Mythical Man Month“ .

Man könnte also meinen, wenn es schon schlecht ist, viele Leute spät ins Projekt zu holen, dann müsste es ja gut sein, sie früh ins Projekt zu holen. Und jetzt soll das auch nicht gut sein?

Zu Beginn eines Softwareprojekts muss erst mal geplant werden und ein Fundament geschaffen werden. Dazu braucht es eine klar erarbeitete Produktvision und eine hinreichend gute Vorstellung von der Architektur. Diese Aufgaben lassen sich beim besten Willen nicht gut auf eine größere Zahl von Leuten aufteilen. Diese können nämlich kein in sich stimmiges Gesamtbild entwerfen.

Erst wenn eine gewisse Stabilität bezüglich der Produktentwicklung erreicht ist, gibt es auch eine gute Grundlage für „Divide & Conquer“, eines der wichtigsten Prinzipien von Softwareentwicklung. Und Projekten im Allgemeinen.

Aber was tun, wenn die Leute halt nun mal schon im Projekt sind? Natürlich kann man auch ohne solide Grundlage einer Produktvision und einer Architektur die Teams einteilen und sie arbeiten lassen. Das führt dann aber oft zu drastischen Problemen:

• Es ist unklar, wer für was zuständig ist; Dinge werden doppelt oder gar nicht gemacht.
• Kommunikation ist extrem ineffizient, weil ohne klares Fundament überall eigene Begriffe erfunden werden und sowohl in den Teams als auch zwischen Teams keine gemeinsame Sprache gefunden wird.
• Es werden in Windeseile technische Schulden angehäuft, weil der Plan fehlt, nach dem gearbeitet werden soll. Später heißt es dann aber: Das hat uns Hundertausende Euro gekostet, das können wir nicht noch mal neu machen.
• Ein Großteil des Aufwands geht in Abstimmung und in Onboarding von neuen Leuten und damit weiterhin nicht in die so dringend benötigte Konzeption. Das heißt, es dauert noch länger, bis ein Fundament geschaffen wird. Die, die das Fundament legen könnten, werden davon abgehalten und die, die das Fundament bräuchten, bauen dann eben notgedrungen Dinge ohne Fundament.
• Die Effizienz geht in den Keller: die genannten Gründe führen dazu, dass trotz hohen Personaleinsatzes nur sehr wenig Ergebnis rauskommt. Und das Ergebnis ist dann meist noch von unzureichender Qualität.

Dem Satz von Fred Brooks können wir also direkt noch einen weiteren Satz hinzustellen:

Warum werden Entwicklungsprojekte überhaupt zu früh mit zu viel Personal ausgestattet?

Eigentlich erscheint es paradox, weil es ja nur unnötiges Geld kostet und dann auch noch Probleme macht. Es gibt aber leider sogar zahlreiche Gründe, warum es immer wieder passiert:

• Enger Zeitplan: Oft ist die Deadline für ein Softwareprojekt sehr ambitioniert. Das Management sagt sich also: Wir wollen die zusätzlichen Leute so früh wie möglich ins Projekt holen, damit es möglichst schnell vorwärts geht. Gut gemeint, aber es gibt wie oben gezeigt eben auch „zu früh“.
• Leute haben Zeit: Manchmal gibt es Teams oder einzelne Personen, die nicht in Projekten gebunden sind. Aus welchen Gründen auch immer. Manchmal sogar, weil sie schwierig einzusetzen sind. Dann sollen diese Personen doch lieber in das Projekt, dann können sie mithelfen, damit es noch schneller vorangeht. Und schon nimmt das Unheil seinen Lauf.
• Leute gebucht, dann aber Verzögerungen: Meist ist es nötig, sich frühzeitig um das Ramp-up des Teams zu kümmern. Egal ob die Personen von intern oder extern geholt werden. Kommt es jetzt in der Frühphase oder gar vor dem Projektstart zu Verzögerungen, dann ist es schwierig, den Einsatz der Personen gleichermaßen zu verschieben. Also fangen sie schon mal im Projekt, wird schon nicht so schlimm werden. Meist dann doch …
• Experten fehlen: Manchmal fehlt es auch an einem starken Kernteam. Das wird dann gerne dadurch kompensiert, dass mehr Leute ins Projekt geholt werden. Teils einfach um die Problematik des langsamen Konzipierens zu verschleiern. Besser wird es dadurch natürlich nicht …
• Delegierte: In Großprojekten, die sich über viele Abteilungen eines Unternehmens erstrecken oder in riesigen öffentlichen Konsortialprojekten will keine Einheit etwas verpassen und von Anfang an „jemanden von uns mit dabei haben“.
• Agile Entwicklung: Manchmal scheint eine agile Vorgehensweise besonders gut geeignet zu sein, Teams möglichst schnell loslaufen zu lassen, weil ja später noch Refactored werden kann und sich vieles ja sowieso erst im Projekt ergibt. Wer aber schon mal mehrere unabhängige agile Teams gesehen hat, die ohne Fundament und gemeinsamen Plan in aller Agilität loslaufen, der weiß, wozu das meist führt. Natürlich kann man die Schuld für dieses Problem nicht der agilen Methodik zuschieben. Aber es gibt eben häufig solche oder ähnliche Fehlinterpretationen.

Auch wenn die meisten dieser Gründe auf „gut gemeinte“ Maßnahmen zurückzuführen sind, so erreichen diese Maßnahmen bei genauer Betrachtung leider genau das Gegenteil.

Und was machen wir jetzt? Tischtennis spielen?

De facto wäre es nicht selten am besten, ein Teil des Teams würde für eine überschaubare Zeit die Bahn frei machen für die Arbeiten am Fundament. Findet man keine sinnvollen Aufgaben für die betroffenen Team-Mitglieder und man kann sie auch nicht auf andere Projekte auslagern, dann ist es besser sie zum Tischtennis spielen zu schicken. So hart das auch klingt. Damit würden viele Probleme beseitigt, die Gesamtkosten wären niedriger und die Konflikte weniger.

Trotzdem wird es in der Realität so gut wie nie gemacht. Es fühlt sich nach Management-Versagen an. Es macht das Dilemma für alle sichtbar. Es fühlt sich „unfair“ an, wenn manche „arbeiten müssen“ und andere „Tischtennis spielen dürfen“. Oder doch „arbeiten dürfen“ und „Tischtennis spielen müssen“?

Trotzdem sollten wir alles dafür tun, um am Anfang mit einem kleinen schlagkräftigen Team ein gutes Fundament fürs Produkt und das Projekt zu legen.

Für die Leute, die erst etwas später zum Einsatz kommen, gibt es meist trotzdem sehr sinnvolle Aufgaben zu tun. Die müssen aber gesucht und dann ordentlich betreut werden. Das reicht von Skills aufbauen über Dokumentation von bisher stiefmütterlich behandelten Projekten über die Pflege von Assets und Dokumentation bis hin zu kleinen Support-Projekten, die man immer schon mal machen oder haben wollte.

Dafür ist dann vielleicht etwas mehr Kreativität und Überzeugungskraft nötig. Aber es lohnt sich, wenn dadurch ein solides Fundament entsteht, auf dem dann nach und nach alle starten und abliefern können. Und dann können auch alle Tischtennis spielen gehen.