Speed-Dating in der agilen Entwicklung

Auf dem Scrum Coaching Retreat 2015 in Rückersbach haben wir u.a. eine neue Technik namens „Speed-Dating“ entwickelt.
Erst vor Kurzem
 haben wir die Technik das erste Mal einem Praxistest unterzogen. Um aber Speed-Dating zu verstehen, sollte man zunächst Pair-Programming verstehen.

Pair Programming

Zwei Leute, die zusammen an einem Task arbeiten, praktizieren noch lange kein Pair-Programming. Pair-Programming ist eine der intensivsten, anstrengendsten, herausforderndsten und effektivsten Praktiken in der Softwareentwicklung.

Zwei Leute programmieren an einem Task. Sie wechseln sich häufig ab (z.B. alle 10 Minuten). Einer ist der Driver (bedient die Tastatur), der andere der Navigator (sagt, wo es lang geht). Im ExtremeProgramming (XP) schreibt einer einen Test, der andere die Implementierung und den nächsten Test – usw.

Man erkennt Pair-Programming daran, dass man spätestens nach acht Stunden nicht mehr kann – es ist hilfreich, wenn man am Anfang kurze Pausen einbaut. Und daran, dass man etwa das doppelte geschafft hat, als man sonst geschafft hätte.
Meine Erfahrung sagt mir, dass man weiß wenn man wirklich Pair-Programming gemacht hat. Wenn also Dein Projektmanager nichts von Pair-Programming wissen will, dann wurde in der Vergangenheit etwas anderes gemacht – vermutlich zwei Leute, die einfach an einem Task arbeiten.

Mythen

  • Pair-Programming eignet sich nur für große oder komplizierte Tasks, keinesfalls für „einfache“ Styling-Aufgaben
    Das einzige, was meiner Meinung nach schwierig ist, sind reine Support-Aufgaben wie „änder mal schnell die Farbe“ oder dem Kunden Fragen zu beantworten – wobei ich das noch nicht getestet habe.
    Alle anderen Aufgaben haben ein deutlich besseres Ergebnis, wenn man sie im Pair-Programming erledigt.
  • Es ist Verschwendung von Arbeitszeit, wenn zwei Leute dasselbe machen
    Auch wenn das auf den ersten Blick so scheint, zeigt das Ergebnis etwas anderes.
  • Ich kann mich alleine viel besser konzentrieren
    Alleine verbringt mal viel Zeit mit Mails, Chat, Kaffee und vor allem Nachdenken oder Suchen nach Lösungen. Zu zweit hat man weder Zeit, sich ablenken zu lassen, man wird weniger gestört. Und man findet viel schneller Lösungen, da man quasi mit einem Dual-Core entwickelt.
  • Ich mach nur Frontend und der andere nur Backend
    Wahrscheinlich gehört auch dieser Mythos irgendwann der Vergangenheit an. Klar kann niemand 10 Jahre Erfahrung in einem Bereich einfach weg pair-programmen. Aber um in ein Thema hineinzukommen und etwas neues zu lernen, ist das der richtige Weg – so schafft man wirkliche Cross-Functional-Teams und erhält spezialisierte Generalisten.

Fakten

  • Pair-Programming ist die sinnvollste Methode für Wissensverteilung
  • Pair-Programming ist anstrengend, weil extrem fokussiert
  • Pair-Programming führt zu schnelleren und besseren Ergebnissen als Einzelarbeit
  • Pair-Programming reduziert jede Art von Ablenkung
  • Pair-Programming macht extrem viel Spaß
  • Pair-Programming ist auf lange Sicht die kostengünstigste Variante
  • Pair-Programming muss richtig gemacht werden oder garnicht
  • Man weiß am Abend, was man getan hat

Am besten findet man sich ins Pair-Programming, wenn man als erfahrener mit einem unerfahrenen Entwickler immer mal einen Tag Pair-Programming macht – nicht immer mit demselben. Zwei unerfahrene Entwickler (auch z.B. in einem Thema unerfahren) tun sich schwer und profitieren auch nicht in dem Maße davon. Nach einer Weile lernt man die Stärken kennen und kann es immer mehr als Entwicklungspraxis etablieren. Man lernt auch wirklich, wofür es sich eignet und wofür nicht. 

Speed-Dating im Praxistest: Safe2fail Experiment

Speed-Dating war dabei eine interne Idee, die wir zu fünft in der Theorie entwickelt und in Theorie und Praxis getestet haben. Im Grunde ist es Pair-Programming, nur dass man z.B. in einem Vierer-Team arbeitet und auch immer die Teams wechselt. Dabei gibt es zwei Ideen: Ein Task pro (halbe) Person oder pro Computer. Wobei wahrscheinlich „Ein Task pro Computer“ die sinnvollere Methode ist.

So hat eines unserer Teams an einer Aufgabe für einen Kunden gearbeitet und entwickelte ein modulares Kontaktformular. Safe2fail war das Experiment, da wir es nur einen Tag gemacht haben.

speeddating
TD-Team Energy beim Speed-Dating Praxistest

Bedingungen

Keine Mails. Kein Chat. Nur Programmieren, direkt neben dem Product Owner. Ein Rechner macht zunächst die Konfiguration und das Templating, der andere die Applikationslogik. 15 Min der eine, 15 Min der andere. Dann Teams wechseln.

Ergebnis

Wir haben an einem Tag eine komplett funktionierende Applikation aus dem Nichts entwickelt, die eigens konfiguriert und modular verwendet werden kann. Wir haben faktisch neun Stunden entwickelt – am Abend war Schicht im Schacht. Noch anstrengender als reines Pair-Programming.

Beobachtung

Wir hatten uns bei der Entwicklung des Speed-Datings sehr viele Gedanken gemacht, wer wo wann wechseln muss, dass es sinnvoll ist. Tatsächlich sind wir irgendwann durcheinander gekommen, haben es dann noch halbwegs sinnvoll fortgeführt, was für das Experiment nicht schlimm war. Auf Dauer ist eine kleine Matrix wahrscheinlich hilfreich, dass man eine gute Reihenfolge hat, wer wann wechselt. Der entscheidende Vorteil war dieser: Ich hatte eine Vorstellung, wie das technisch ablaufen sollte und schon einige Male etwas Ähnliches gemacht. So konnte ich sehr schnell mein Wissen im Team verteilen und jeder wusste von allem sehr schnell bescheid. Jeder kann jetzt theoretisch jeden Teil davon anpacken – was speziell bei diesem Feature wichtig ist, da die Applikation das wichtigste Conversion-Element auf der Seite ist. 

Schlussfolgerung

Ich würde jederzeit wieder Speed-Dating machen und hoffe, dass andere Teams sich der Idee anschließen – zunächst mit Pair-Programming vertraut werden und sich dann an das Speed-Dating machen. Das Ergebnis spricht für sich…

Speed Dating in Retrospektiven

Speed-Dating lässt sich auch wunderbar in Retros einsetzen. Beispiel Fragestellung: „Was ist letzte Woche gut gelaufen?“ Sechs Leute stellen sich gegenüber, reden zwei Minuten darüber: Dann wird gewechselt, bis jeder mit jedem gesprochen hat. Hinterher hat jeder ein gleichmäßiges Verständnis darüber, was gut gelaufen ist. Das ist auch bei ungeraden Teamzahlen einfach, da die Iterationen kürzer sind und einer z.B. die Zeit nehmen kann.

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.