Weniger ist häufig mehr

Software schneller entwickeln mit der Magical Number Seven
Kommentare

Schnell soll das agile Team sein. Das erwarten Auftraggeber und Mitarbeiter gleichermaßen. Aber was, wenn die Arbeit auch agil nicht schneller von der Hand gehen will? Hier kann die Magical Number Seven – ein psychologisches Prinzip, das sich mit der Grenze an gleichzeitig im Kurzzeitgedächtnis speicherbaren Informationen befasst – einen guten Anhaltspunkt bieten, um Probleme aus der Welt zu schaffen.

Wann schafft ein Team mehr? Dann, wenn es möglichst viel auf einmal erledigt oder dann, wenn es sich ganz auf eine Aufgabe konzentriert? Diese Frage wird natürlich bereits von den Grundprinzipien vieler agiler Arbeitsweisen beantwortet: Die Menge des gleichzeitigen Work in Progress sollte immer limitiert werden. Also sind Teams wohl schneller, wenn sie nur wenig zur gleichen Zeit zu erledigen haben.

Die magische Grenze: Sieben Chunks…

Woran liegt das aber? Das viel beschworene Buzzword des Multitaskings stellt hier eine wichtige Stolperfalle dar. Während es vielen Menschen nämlich bis zu einem gewissen Grad leicht fällt, mehrere Aufgaben zeitgleich zu bewältigen, gibt es eine deutliche Grenze dafür. Diese verläuft spätestens an der Stelle, an der die Magical Number Seven ins Spiel kommt. Dieses Prinzip könnte Entwickler sogar schon bekannt sein: Die gleiche Theorie ist nämlich auch dafür verantwortlich, dass Methoden in der Programmierung nicht mehr als sieben Parameter haben sollten.

Das kognitive Aufnahmevermögen des Menschen ist begrenzt. George A. Miller konnte in einem Experiment zeigen, dass der durchschnittliche Versuchsteilnehmer nur sieben (plus/minus zwei) Informationsteile, sogenannte Chunks, im Kurzzeitgedächtnis behalten kann. Dieses Prinzip wird als Magical Number Seven oder millersche Zahl bezeichnet. Die genaue Menge an erinnerbaren Chunks ist zwar umstritten, zeigt aber doch auch im Kontext der wichtigsten Kritiken noch gut das Problem auf, das zu einem verlangsamten Arbeitstempo durch Multitasking führt. Obwohl Alan D. Baddeley nämlich nachgewiesen hat, dass zusammenhängende Informationen auch über eine Menge von sieben Chunks hinaus erinnert werden können, ändert das bezogen auf Multitasking-Situationen nichts an der Problemstellung. Hier handelt es sich zumeist nicht um kontextuell einfacher erinnerbare Informationsteile.

…für vier Aufgaben?

Wer an mehreren Aufgaben gleichzeitig arbeitet, muss währenddessen mental mit Informationen und Ideen zu gänzlich verschiedenen Tätigkeiten jonglieren. Dies lastet einen Teil der kognitiven Verarbeitungs- und Speichermöglichkeiten des Gehirns aus, sodass weniger Platz für Elemente bleibt, die zum gegenwärtigen Zeitpunkt von besonderer Relevanz sind. So geht die Arbeit an jeder einzelnen Aufgabe einerseits langsamer voran, andererseits steigt aber auch das Risiko von Flüchtigkeitsfehlern, weil wichtiges vergessen wird. Um die dadurch entstandenen Bugs wieder auszubessern, ist erneut Zeit notwendig.

Eine häufig gegebene Empfehlung lautet an dieser Stelle, tatsächlich immer nur an einer einzigen Aufgabe zu arbeiten. Das bildet jedoch häufig nicht den realen Arbeitsalltag vieler Entwickler ab. Insofern ist es wohl sinnvoller, jedes Team dazu aufzufordern, seine eigene Grenze zu definieren. Diese auch durchzusetzen, ist natürlich eine weitere Hürde auf dem Weg zum erhöhten Arbeitstempo. Hier sind auch Vorgesetzte gefragt, diesen Aspekt der Selbstorganisation agiler Teams zu fördern und zu fordern. Am Ende ist, wie Bob Gower meint, weniger nämlich mehr, sodass es sich lohnt, auf das Team zu hören.

Die sieben Zwerge und das Backlog

Auch in Bezug auf andere Teile der Arbeit an einem Projekt kann die millersche Zahl einen guten Richtwert darstellen. Immerhin wird auch hinsichtlich der Größe von Teams häufig davon gesprochen, dass nicht mehr als sieben plus/minus zwei Mitglieder zu einer Gruppe gehören sollten, maximal aber zehn. Dieses Prinzip findet sich sogar im militärischen Bereich wieder, wo bereits seit der Zeit der römischen Legionen häufig genau acht Personen zur kleinsten Organisationseinheit gehörten. In größeren Teams, so besagt die psychologische Theorie, wird die Kommunikation ineffizient.

Wenn aber sowohl bezogen auf die individuelle Arbeitsleitung und auch auf das Team hier eine Grenze verläuft, wie sieht es dann hinsichtlich anderer Grundelemente des agilen Arbeitens aus? Ein Product Backlog kann schnell lang werden, vor allem dann, wenn jeder Bug und jede User Story aufgenommen wird. Das kann durchaus sinnvoll sein, immerhin gerät so nichts in Vergessenheit. Wenn der Kunde jedoch zu lange auf eine bestimmte Funktion warten muss, entsteht aus einem langen Backlog schnell wieder Druck zum Multitasking. Auch hier sollte das Team also zu lange Aufgabenlisten eher kritisch betrachten und die Möglichkeit bekommen, Aufgaben zu einem gegebenen Zeitpunkt abzulehnen, statt sie auf das Backlog zu setzen.

Sieben mal Sieben mal Sieben

Dafür gibt es außerdem einen weiteren Grund. Wer nur sieben Elemente im Kurzzeitgedächtnis behalten kann, könnte Schwierigkeiten damit haben, eine fundierte Entscheidung über die individuelle Relevanz von zwanzig, zweihundert oder mehr Chunks zu treffen. Also könnte es auch dem Product Owner entgegen kommen, das Backlog zu reduzieren. Dazu stehen natürlich verschiedene Ansätze zur Verfügung. Nur sieben Elemente überhaupt aufzunehmen, ist natürlich kein praktikabler Ansatz; eine Unterteilung in sieben Oberkategorien kann jedoch zweckdienlich sein. Sobald eine Hierarchie unter diesen Elementen gebildet wurde, kann der gewählte Bereich erneut in fünf bis neun Abschnitte untergliedert werden, um schlussendlich zu einer guten Entscheidung über den sinnvollen nächsten Schritt zu gelangen.

Darüber hinaus schafft ein Bewusstsein für die Grenzen eines Teams auch die Möglichkeit, den Wert einer Funktion neu einzuordnen und bessere Pläne aufzustellen. Wer sich seines Leistungsvermögens bewusst ist, kann besser einschätzen ob eine Aufgabe es wert ist, zum aktuellen Zeitpunkt einen Teil der verfügbaren Ressourcen zugeteilt zu bekommen. Auch die Planung anstehender Aufgaben lässt sich so besser durchführen; Einschätzungen der noch benötigten Zeit werden exakter. Unvorgesehene Probleme sind auf diese Weise ebenfalls leichter zu bewältigen, wenn die Zahl der gleichzeitig laufenden Arbeiten eingeschränkt wurde.

Strittige Unstrittigkeiten

Es ist also erst einmal eine ziemlich unbestrittene Tatsache in der agilen Softwareentwicklung, dass Teams schneller arbeiten, wenn der Work in Progress limitiert wird. Dem entsprechen auch viele andere alltägliche Erfahrungen. Wer hat beim Einkauf noch nie die Milch vergessen, weil er gedanklich bereits mit der nächsten Mail, der Wäsche und dem Handwerkertermin beschäftigt war? Und auch die Intensivierung kommunikativer Schwierigkeiten mit steigender Teamgröße ist recht intuitiv zugänglich. Wenn zwanzig Personen an einem Meeting teilnehmen, kann nicht jeder binnen dreißig Minuten zu Wort kommen. Bei nur fünf Teilnehmern ist das ganz anders.

Fixe Zahlen wie die Magical Number Seven unterliegen hingegen einer stetigen Diskussion und sollten nicht als starre Grenzen verstanden werden. Das Beispiel der römischen Legionen zeigt zwar, dass die grundlegende Idee schon lange vor Millers Forschung bekannt war, am Ende stellt sie jedoch immer nur ein Richtwert dar. Ein agiles Team mit zehn Personen ist also natürlich nicht deshalb langsamer als eines mit neun, weil damit die magische Grenze der millerschen Zahl überschritten wurde.

Viele Störquellen neben der Sieben

Darüber hinaus spielen außerdem auch andere Faktoren eine Rolle, wenn es um die Arbeitsgeschwindigkeit eines Entwicklerteams geht. Neu entstehende Teams arbeiten beispielsweise erst einmal langsam, da sie einander kennenlernen und interne Konflikte austragen müssen. Aber auch hier gilt natürlich, dass diese Probleme größer werden, je mehr Teammitglieder beteiligt sind. Spätere Veränderungen an der Teamzusammenstellung führen auch wieder zu Unruhe. Und natürlich sind Qualität und Quantität allzu oft Metriken, die einander widersprechen: Soll das eine steigen, sinkt das andere nur zu schnell. Wer das Optimum erreichen möchte, muss auf ein Gleichgewicht abzielen, statt einen der Faktoren ins Zentrum zu stellen.

Die Liste der Störfaktoren für eine schnelle agile Softwareentwicklung könnte nahezu endlos fortgesetzt werden. Wer das Arbeitstempo seines Teams aber erhöhen möchte, tut gut daran, die millersche Zahl im Kopf zu behalten und sowohl auf die Größe des Teams als auch auf die gleichzeitig anfallenden Aufgaben anzuwenden. Mit dieser magischen Zahl lassen sich nämlich viele typische Problemquellen erkennen und beheben.

Aufmacherbild: Lucky craps game dice rolling out chance number seven via Shutterstock / Urheberrecht: Olivier Le Queinec

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -