“Die Planung ist ja ganz nett, aber einige hier sind jetzt überlastet und andere haben nichts zu tun.” Diese Aussage hört man mit Sicherheit irgendwann, wenn man ein Team auf agile Planung umstellt. Zur Erinnerung: Bei agiler Planung versucht man nicht, sämtliche “Ressourcen” voraus zu planen, sondern sammelt Arbeitspakete mit direktem Geschäftsnutzen (in der Regel in Form sogenannter Anwender Geschichten oder User Stories) und priorisiert sie vollständig. Die Pakete werden geschätzt und der Umfang abgeschöpft, der in dem Monat geleistet werden kann. So wird immer an den wichtigsten Aufgaben gearbeitet.

In der besten aller agilen Welten funktioniert das auch: Wenn das Team von Anfang an konsequent die Entscheidungen im Team getroffen hat und immer in Paaren gearbeitet hat, ist das Wissen über das System ungefähr gleich verteilt und jeder kann jede Aufgabe übernehmen. Wenn man allerdings ein bestehendes Vorhaben (oder Produkt) auf Agilität umstellt oder die Entstehung von Kopfmonopolen toleriert hat, wird man die daraus entstehenden Probleme spätestens bei der Planung bemerken.

Zunächst möchte ich betonen, dass dies kein Problem der Planung ist, sondern Symptom für ein anderes Problem: Wenn man einmal voraussetzt, dass die Prioritäten richtig gesetzt sind, ist das Grundproblem hier die mangelnde Flexibilität im Team. Oft haben sich Kopfmonopole gebildet, die von den einzelnen Entwicklern nur ungern verlassen werden - Schließlich sichert einem das Kopfmonopol Bedeutung und Anerkennung. Es kann aber auch inhaltliche Gründe geben, solche Kopfmonopole zu erzeugen. Zum Beispiel kann es aus Sicherheitsgründen sinnvoll sein, wenn nur wenige Entwickler über bestimmte Kernkonzepte informiert sind. Und auch im Kundenkontakt sind viele Kunden (mich eingeschlossen!) dankbar, wenn sie feste Ansprechpartner haben und nicht wie im Call-Center von Pontius zu Pilatus weiter gereicht werden. Aber abgesehen von solchen Spezialfällen sind Kopfmonopole ineffizient und sollten abgebaut werden.

Warum? Die Standardbegründung, der Entwickler könnte ja das Unternehmen verlassen, ist zwar korrekt, aber eher unwahrscheinlich (sonst hat man noch ein ganz anderes Problem mit der Attraktivität des Arbeitsplatzes). Interessanter ist die Aussage, die zur Planung gemacht wurde. In der Planung sind schließlich die wichtigsten Aufgaben aufgeführt und auch genügend, um das Team rechnerisch unter Dampf zu bringen (ich persönlich empfehle normalerweise sogar, noch mal die gleiche Menge an “Nachrückern” in die Planung aufzunehmen, um gegen Fehlschätzungen gewappnet zu sein). Also an Arbeitsmangel kann es nicht liegen. Wenn dadurch nicht alle ausgelastet sind, bedeutet das, dass zu wenige Personen da sind, die sich auf die wichtigen Dinge konzentrieren können. Mit anderen Worten, es wird eher an unwichtigen Dingen gearbeitet, ein wenig effizienter Ansatz. Es ist zwar richtig, dass bei jeder Planung kritische Pfade entstehen, aber wenn Teile des Teams einen Monat lang gar nichts zu tun haben, nimmt die Verschwendung überhand.

Bevor jetzt die Controller die Personalliste zücken und einfach die “überflüssigen” Stellen streichen in dem Glauben, sie könnten dort Geld sparen, gibt es noch ein paar andere Strategien, um das Planungssymptom taktisch zu lindern und zugleich das Grundproblem strategisch anzugehen:

1. Warum die Situation nicht nutzen, um Wissen zu streuen? Wenn sich jeder nicht ausgelastete Entwickler mit einem überlasteten Kollegen zusammen setzt, um gemeinsam an den wichtigen Aufgaben zu arbeiten. Das verstärkt die überlasteten Kollegen und entschärft auch das Grundproblem, zumindest wenn man diese Strategie über einige Wochen konsequent verfolgt.
2. Abseits vom kritischen Pfad spielt Effizienz keine Rolle. So formuliert [1] Alistair Cockburn für seine Crystal Methoden. Das bedeutet, dass man abseits vom kritischen Pfad sich ruhig um Dinge kümmern kann, für die sonst “keine Zeit” ist. Zum Beispiel kann man die Testabdeckung für alten Code verbessern oder die Buildautomatisierung verbessern. Auch lange geplante größere Refactorings sind hier sinnvoll, allerdings nur, wenn die Testabdeckung schon ausreicht, um den Code einigermaßen sicher umbauen zu können. Alle diese Aktivitäten helfen später anderen Kollegen, sich einzuarbeiten.
3. Auch strenge Priorisierungen unterliegen einer gewissen Willkür. Vielleicht gelingt es ja, Dinge höher zu priorisieren, die auch die schlecht ausgelasteten Kollegen beschäftigen. Das ist zwar zum guten Teil Selbstbetrug und löst auch das zugrundeliegende Problem nicht - aber man muss ja nicht immer alle Probleme gleichzeitig angehen…

Der letzte Vorschlag ist schon nicht mehr so recht Ernst gemeint. Er dient nur dazu, sich kurzzeitig zu betäuben.

Dieses Problem ist ein weiteres Beispiel dafür, dass agile Entwicklung oft tiefere strukturelle Probleme aufdeckt, die gerade bei ihrer Einführung oft für Probleme der agilen Entwicklung gehalten werden. Man sollte aber nicht vergessen, dass dabei nur der Bote der schlechten Nachricht geköpft wird, nicht die schlechte Nachricht selbst vermieden wird.