Ich bin gerade in Stefan Hagen’s PM-Blog über einen ganz interessanten Beitrag zum Thema „Wie entwickelt Google“ gestolpert. Das spannendste waren für mich die Projektgrößen: Google rechnet in „Units“, das sind Teams mit drei Personen, die Projektdauer beträgt drei bis vier Monate. „Große“ Projekte bestehen zum Beispiel aus vier Units, also zwölf Personen. Da hat jemand wirklich verstanden, wie man Projekte klein macht.

Wer meint, solche Projekte seien nicht ernst zu nehmen, werfe noch kurz einen Blick auf den Aktienkurs und die wirtschaftliche und gesellschaftliche Bedeutung von Google weltweit.

„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.
Weiterlesen →