Flow, Pair Programming, Teams und das Unerwartete

January 18, 2010 at 9:42 pm 4 comments


Ich bin jetzt endlich dazu gekommen, einen Artikel zu lesen, der schon eine Weile bei mir rumlag: “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” (PDF).

Auch wenn der Artikel nicht mehr ganz frisch ist, ist er dennoch sehr erfrischend. Er untersucht die Auswirkungen verschiedener Team-Organisationsformen in agilen Projekten. Zuerst belegt er die Annahme, dass Teams, die sich selbst Tasks nehmen, die effektivste Form der Arbeitsorganisation ist. Gefolgt von Teams, denen die Aufgaben zugewiesen werden, gefolgt von Individuen, die sich die Arbeit selbst nehmen, gefolgt von Individuen, die Arbeit zugewiesen bekommen. Damit ist die klassische Form der Arbeitszuweisung am wenigsten effektiv. Interessanterweise geht FDD mit seinem Class-Ownership-Konzept aber auch in diese (ineffektive) Richtung.

Richtig interessant wird der Artikel aber bei der Frage des Pair-Programming. Die Autoren haben bei sich festgestellt, dass die Enwicklung dann mit Abstand am Effektivsten war, wenn alle 90 (!) Minuten die Pair-Partner getauscht wurden. Bei wachsender Teamgröße (11 Personen) war 120 Minuten die ideale Zeitspanne, bis die Paare wieder wechseln sollten.
Das ist wirklich erstaunlich. Normalerweise geht man davon aus, dass man für hochproduktives Arbeiten im Flow arbeiten muss. Der Flow-Zustand hat aber auch Nachteile: Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil. Durch Unterbrechungen kann er schnell zerstört werden. Nun sagen die Ergebnisse des Papers, dass man auch ohne Flow-Zustand extrem produktiv sein kann – schließlich institutionalisiert das extrem häufige Wechseln des Pair-Partners ja gerade die Unterbrechungen. Dadurch geht man immer wieder mit einer neuen Perspektive an die Aufgabe heran (“Beginners Mind”) und kommt so auf die besten Ideen. Und das ist offenbar sehr produktiv.

Und an dieser Stelle finde ich den Artikel auf einer Meta-Ebene sehr interessant: Die Autoren haben ein “Naturgesetz” in Frage gestellt – nämlich dass hochproduktives Arbeiten nur im Flow möglich ist. Und so konnten sie etwas wirklich Neues entdecken. Respekt!

Entry filed under: it-agile-blog-planet. Tags: , .

Festpreise, Aufwandsprojekte und dann? Buchtipp “Clean Code”

4 Comments Add your own

  • 1. Markus Andrezak  |  January 19, 2010 at 10:02 am

    Hi Stefan,

    Sehr schöner Bericht. Mein Problem mit dem Begriff Flow ist, dass ich zwar ahne, was er bedeutet, aber noch keine echte Definition gelesen habe ausser vielleicht eben “Fluß”, “Produktionsfluss” etc. Aber: Wann ist man im “Flow”? Wann ist der Flow gut, wann noch nicht so gut? Kann man Flow messen?

    Es gibt ja auch den Begriff hochproduktiver Teams, bei denen dieser Zustand vor allem durch akzeptiertes “Auflösen” der persönlichen Vorlieben geschieht und dadurch resultierendes “filling the spots”. Das kann man sicha lles orstellen, kommt einem aber auch ein bisschen mystisch vor. Letztens im Training: ” Who of you already experienced such a team? How did it feel?”) … naja.

    Manchmal, nur manchmal, kommt mir der Flowbegriff ein bisschen wie das Runners High vor, dass mir noch nie vo die Flinte kam😉

    Wie cih für mich selbst Flow ganz gut begreifen kann ist enfach, wenn etwa bei einem Kanbanboard die Tickets möglichst kurz “stehenbleiben” nachdem sie in einem Zustand als “fertig” gekennzeichnet wurden.

    Viele Grüße

    Markus

  • 2. Stefan Roock  |  January 19, 2010 at 12:52 pm

    @Markus Andrezak:

    In diesem Zusammenhang geht es meiner Meinung nach um den individuellen Flow-Zustand: Man ist versunken in die eigene Aufgabe, nimmt seine Umgebung nicht mehr richtig wahr und verliert das Zeitgefühl. In diesen Momenten fühlen wir uns bei der Arbeit glücklich.

    Ich selbst habe in solchen Flow-Zuständen schon gearbeitet – leider viel zu selten.

    Mit Fluss im Sinne eines Produktionsflusses hat das aus meiner Sicht erstmal nicht so viel zu tun.

  • 3. Bernd Schiffer  |  January 19, 2010 at 5:25 pm

    @Markus: Flow ist ziemlich genau definiert nach Mihaly Csikszentmihalyi. Am schönsten finde ich noch Wikipedias Definition: “Flow ist eine Form von Glück auf die man Einfluss hat.”🙂

    Ein Runner’s High ist definitiv kein Flow. Biologisch betrachtet entspricht ein Flow der kardialen Kohärenz (Blutdruck, Herzschlag und Atmung sind nahezu synchron, limbisches und kortikales System sind ausgeglichen). Ein Runner’s High dagegen ist ein Mehr an Endorphinen. Da ist dann nichts mehr synchron oder ausgeglichen🙂

    Einen Flow beim Laufen kannst Du schon nach wenigen Minuten erreichen. Das ist z.B. dann der Fall, wenn Du nach zig gelaufenen Kilometern auf einmal realisierst, dass Du Dich nicht mehr genau daran erinnern kannst, wie Du dahin gekommen bist, wo Du gerade läufst. Du hast auch null Ahnung dann, woran Du gerade gedacht hast. Du “wachst” einfach auf und bist ein ordentliches Stück gelaufen. Einfach so. Du hast was geschafft.

    Beim Laufen ist Flow ein Niveau, dass nicht zu niedrig ist (keine Unterforderung), d.h. nicht zu langsam laufen, und das andererseits nicht zu hoch ist (keine Überforderung), d.h. nicht zu schnell laufen. Bei Fahrtspiel, Tempoläufen, Sprints, Lauf-ABC, Plyometrische Übungen, Trail-Runs u.ä. gibt’s meist kein Flow, weil es körperlich zu anstrengend ist oder ständige hohe Konzentration erfordert. Dagegen sind Long Jogs, ruhige und lockere Läufe, Kraftausdauerübungen u.ä. gut für Flow geeignet, weil nicht zu leicht und nicht zu schwer.

    @Stefan: Hier möchte ich Dir widersprechen, wenn Du schreibst “Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil.” Beim Laufen kann man binnen weniger Minuten in einen Flow-Zustand gelangen und diesen bis zum Ende eines Laufs auch halten. Das ist trainierbar. Auch bei Unterbrechungen (Ampel, Radfahrer, Schlagloch) lässt sich der Zustand des Flow schnell wieder erlangen.

    Das beobachte ich auch bei Programmierern, insbesondere beim Pair-Programming: Geübte Programmierer können bewusst alle Störfaktoren ausblenden, auch in einem Großraumbüro, auch, wenn sich neben dran zwei laut Unterhalten. Und beim Pair-Programming fällt das sogar aus meiner Wahrnehmung noch leichter, da man sich weniger durch Geräusche ablenken lässt, wenn man einem anderen zuhört bzw. mit ihm redet. Man ist bei der Sache, blendet den unnötigen Rest fast komplett aus.

    Von daher könnte ich mir sehr gut vorstellen, dass ein Team, dass eine Zeit lang 90-minütige Wechsel trainiert hat, sich nur sehr kurz aus dem Flow bringen lässt durch einen Wechsel, und dann sofort weiterprogrammiert.

    Diesen Gedanken weitergedacht: Eine mögliche Erklärung für die höhere Produktivität bei 90-minütigen Wechseln muss nicht unbedingt der sein, dass man bessere Ideen hat (Beginners Mind), sondern dass man nach einer gewissen Zeit mit einer Programmieraufgabe unterfordert ist (“Habe ich verstanden, Problem ist gelöst, muss nur noch programmiert werden.”), d.h. man wegen Unterforderung aus dem Flow gerät. Nach dem Partnertausch wird man durch eine neue Aufgabe und auch durch einen neuen Partner (auf den muss man sich ja auch neu einstellen = neue Herausforderung) wieder mehr gefordert, so dass die Unterforderung wieder aufgehoben wird und man wieder in den Flow kommt.

    Ergo: NIcht zwangsläufig wurde ein “Naturgesetz” in Frage gestellt.

  • 4. mandrezak  |  January 20, 2010 at 10:26 pm

    Hi,

    ich hab die Wikipedia-Definition von Csikszentmihalyi auch gelesen und verstanden (na gut, Letzteres weiss man nie so genau). Nur: So exakt finde ich das halt nicht, sondern eher sehr subjektiv.

    Ich denke schon (gerade früher beim Programmieren, heute eher beim schreiben, Präse malen oder oder oder – ist Programmieren eigentlich besonders anfällig für Flow) in so etwas gewesen zu sein, was man eben Flow nennen könnte und sich so angefühlt hat. Es hat alle Bedingungen von Csikszentmihalyi (gut das wir nicht reden, bei dem Namen) erfüllt. Nur: Manchmal wachte ich am nächsten Morgen auf und dachte: Oh no – what a shit. Da hat mich der Flow wohl faslch mitgenommen.

    Was ich sagen will: Zum einen gefällt mir die Definition nicht und ist mir nicht exakt genug um “Flow” in diesem Sinne anstreben zu sollen/müssen. Wenn er da ist, sicher schön, aber kein Zweck an sich.

    Zum anderen deckt sich meine – rein subjektive – Erfahrung nicht damit, dass dann auch die gelieferte Qualität (und die trennen wir ja nicht mehr von der Produktivität) stimmt. aber Spaß hat’s schon gemacht.

    Noch schwieriger wird’s für mich wenn das auf Gruppen und Teams oder gar Produktionsprozesse ausgeweitet wird. da gefallen mir dann greifbare Dinge wie sie Reinertsen beschreibt und anstrebt, also im Sinne von Produktionsfluß, Pufferoptimierung, Variabiltätstoleranz, Routingmöglichkeiten usw. viel mehr. Mich hier nach einem ominösen Gruppenflow zu richten, dabei wäre mir komisch. But that’s just me being me.

    Was mich an dem Artikel ein wenig gestört hat, dass er mal von Flow, dann von Pull vs. Push usw. redet und damit also Individuum, Gruppe, Prozeß, einstellung und alles mögliche irgendwie in eine Wagschale wirft. Aber ich sage ja: Eigentlich ist er nett.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: