In Beyond Culture – einem Buch über kulturelle Hintergründe unserer Entwicklung (insbesondere Lernphasen) – schreibt Edward Hall in einem kleinen Auszug folgendes über die ideale Größe von Arbeitsgruppen:
Research with business groups, athletic teams, and even armies around the world has revealed there is an ideal size for a working group. This ideal size is between eight and twelve individuals. This is natural, because man evolved as a primate while living in small groups…
Insbesondere der anschließende Teil deckt sich mit den agiler Softwareentwicklung zu Grunde liegenden Annahmen:
Eight to 12 persons can know each other well enough to maximize their talents. In groups beyond this size, the possible combinations of communication between individuals get too complex to handle; people are lumped into categories and begin the process of ceasing to exist as individuals. Tasks than can’t be handled by a group of eight to 12 are probably too complex and should be broken down further.
Kommunikation, das wohl wichtigste Merkmal agiler Entwicklung, ist bei einer Gruppengrößen zwischen acht bis zwölf Personen noch sehr gut gewährleistbar, so dass Gruppen dieser Größe möglichst effizient agieren können.
Diese These gleicht sich auch mit den in Scrum und Crystal Clear empfohlenen Gruppengrößen.
Interessant diesbezüglich ist vor allem der letzte Satz, welcher ebenfalls eine Vorraussetzungen agiler Softwareentwicklung bestätigt:
Participation and commitment fall off in larger groups — mobility suffers; leadership doesn’t develop naturally but is manipulative and political.
Agile Teams verfügen nicht über klassische Hierarchien, sondern jeder übernimmt Verantwortung für das Produkt (vgl. Lean Management).
3. November 2006 um 13:05
Frank Westphal schreibt:
Ich finde, es sagt schon ziemlich viel, dass es keine/kaum Mannschaftssportarten gibt, die aus mehr als einem Dutzend Personen bestehen. Wenn doch, dann zerfallen sie meist in Offensiv- und Defensivteam. In der Softwarewelt heißen die Splittergruppen dann Entwicklungs- und Wartungsteam … toll.
Ein beliebter Vergleich sind ja auch Jazzbands und Orchester. Wobei übersehen wird, dass diese üben, üben, üben. Wozu es in der Softwarebranche viiiel zu wenig Gelegenheiten gibt. Bin ja der Meinung, das ist einer der wesentlichen Gründe, warum so viele Projekte schief gehen.
Dank Dir für den Buchtipp!
3. November 2006 um 17:01
Dennis schreibt:
Hey Frank, je nachdem wie das Entwicklerteam zusammengestellt ist (ein Haufen zusammengesuchter Freiberufler oder ein langfristig fest zusammenarbeitendes Team – beispielsweise in Softwarefirmen) ergeben sich ja eher schlechte oder nur mittelmäßig gute Gelegenheiten zum üben.
Im zweiten Fall (festes Team) gibt es ja die Möglichkeit, die Prozesse auf längerfristige Sicht durch Retrospektiven anzupassen und sich dadurch als „Mannschaft“ zu entwickeln/verbessern (sozusagen Iteration im Großen).
Der erste Fall erlaubt diese Anpassung ja nur projektbezogen nach jeder Iteration. Dort können die Leute ihre gemachten Erfahrungen mit ins nächste Projekt nehmen, wo sich das Team dann neu formieren muss.
Das Üben findet praktisch somit in Kundenprojekten statt… fragt sich nur, wann der große Auftritt kommt?!
4. November 2006 um 15:40
Frank Westphal schreibt:
Retros sind super, um den Entwicklungsprozess zu tunen. Ich dachte jedoch mehr in Richtung Skills. Selbst Pair Programming greift da noch zu kurz, IMHO. Es wird z.B. viel zu wenig Code einfach mal weggeworfen. Vermutlich entsorgt jede andere Branche mehr Zeugs als wir Softwerker. Dojos dagegen gehen in die richtige Richtung:
http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Practices/Kata
http://wiki.agilefinland.com/?CodingDojo
4. November 2006 um 15:46
Dennis schreibt:
Dass zu wenig Code weggeworfen wird, liegt meiner Meinung nach daran, dass ganz einfach zu wenig Refactoring betrieben wird.
Danke für die Links, genau das richtige für so einen verregneten Samstag Nachmittag