Ein Team. Ein Keyboard. Ein Task. Eine Story.


Post Image

Software Engineering ist und bleibt ein faszinierendes Thema – schon alleine wegen der unterschiedlichen Praktiken, die sich laufend entwickeln und erfinden. Es gibt immer wieder etwas Neues zu lernen. Das hört auch nach fünf, zehn oder zwanzig Jahren nicht auf. Ständig tauchen frische Ideen und Konzepte auf, auch wenn sie manchmal schon älter sind und einfach neu entdeckt werden.

Haben Sie jemals von “Mob Programming” gehört? Wir auch nicht, aber diese Entwicklungsmethode existiert bereits seit fünf Jahren, und es gibt dazu auch eine Website, die sich mit dem Thema auseinandersetzt. Das Konzept eines Teams, das an einem Computer arbeitet, ist ein Ansatz, den wir im Laufe der letzten Monate bei 25th-floor kennen- und schätzen gelernt haben.

Stellen sie sich vor, ein Team aus fünf oder sechs Entwicklern sitzt um einen Rechner/Beamer herum und arbeitet sich Task für Task, eine Story nach der anderen, durch den Sprint. Das klingt oberflächlich betrachtet nicht sehr effizient, aus der Sicht eines Kunden sogar regelrecht verrückt. Man bezahlt plötzlich nicht für die Aufwände eines Entwicklers, sondern gleich für fünf, sechs oder mehr Entwickler-Stunden. Die Schlussfolgerung, dass man das Sechsfache bezahlt, liegt nahe.

Ähnliche Argumente und Bedenken wurden aber auch bei Extreme Programming, Pair Programming, dem Wandel vom Wasserfall hin zu agiler Software-Entwicklung, bei den ersten Implementierungen von Scrum und gegen all das, was auf den ersten Blick als neu, unbekannt oder ineffizient angesehen wurde, hervorgebracht.

Das Argument der Ineffizienz

Gehen wir einen Schritt zurück und betrachten wir die folgenden Annahmen und Rahmenbedingungen: Die Story, die wir implementieren müssen, ist nicht trivial. Die nachfolgenden Storys bauen auf dieser Implementierung auf, und wir haben es mit einer großen Anzahl komplexer und teilweise unbekannter Faktoren zu tun.

Jetzt erweitern wir das Ganze noch um den Umstand, dass Schätzungen bei der Software-Entwicklung alles andere als genau sind. Gerade das Gegenteil ist der Fall, wenn wir es mit Problemen zu tun haben, zu denen wir keinerlei Erfahrungswerte aus der Vergangenheit haben (s. auch Cone of Uncertainty). Ein einzelner Entwickler kann schnell zum Bottleneck werden, in die komplett falsche Richtung unterwegs sein oder sich in Details verirren.

Weiters muss man auch die Aufwände in Betracht ziehen, die durch Code-Reviews, durch das Einlesen in bestehenden Code und dessen Verstehen entstehen, wenn die nachfolgende Story oder ein anderer Task derselben Story von anderen Entwicklern übernommen wird. Hinzu kommen noch die versteckten Folgekosten der Code-Qualität. Je mehr Entwickler am Review-Prozess beteiligt sind und regelmäßig am gleichen Code arbeiten, desto höher die Qualität.

Viele der vorher genannten Probleme lassen sich durch “Mob Programming” lösen oder zumindest in den Griff kriegen. In der kleinsten Form besteht ein Mob aus zumindest drei Entwicklern, einem Computer, einer Tastatur und einem Projektor. Im Normalfall gibt es ein Kern-Team, das über die Dauer eines Sprints bestehen bleibt, und weitere Entwickler, die dazustoßen, wenn es sinnvoll ist – jeder, der zur Implementierung beitragen kann, kann und soll ein Teil des Mobs werden.

Unsere Erfahrungen

Wir haben bei 25th-floor diese Methode in den letzten drei Sprints übernommen und damit sehr viele Erfolgsmomente erlebt.

Die Vorteile wurden vor allem bei den komplexeren Features und Storys sehr deutlich:

  • Wenige bis gar keine Ablenkungen und Hürden am Weg, weil immer jemand eine Lösung für ein anstehendes Problem hatte.
  • Keine Code-Reviews, weil das komplette Team den Code geschrieben hat.
  • Keine nachträglichen Diskussionen über Implementierungsdetails oder den Code-Style, da jeder von Anfang bis Ende dabei war.

Wie funktioniert das jetzt?

Grundsätzlich ist es ganz einfach. Um damit zu beginnen, müssen Sie nur Folgendes berücksichtigen:

  • Ein Computer
  • Eine Tastatur
  • Ein Beamer
  • Nur ein Task gleichzeitig
  • Eine Story von Anfang bis Ende
  • Jeder muss einmal die Tastatur übernehmen (Driver)
  • Der Driver muss alle 15-30 Minuten wechseln
  • Niemand, der etwas zur Implementierung oder Problemlösung beitragen kann, wird ausgeschlossen

Außerdem empfehlen wir das Zeitraffer-Video und die Artikel von Woody Zuill, der u.a. den Begriff des Mob Programming geprägt hat.

Das Konzept ist unter den folgenden Umständen wirklich leicht umzusetzen:

  • Jedes Team-Mitglied ist aufgeschlossen dafür, mit anderen gemeinsam zu programmieren, und nicht daran interessiert, Informationen bzw. Know-how zu horten.
  • Das Unternehmen und das Management verstehen, dass mehr Entwickler nicht nur höhere Kosten bedeuten. Es braucht die Bereitschaft, Neues auszuprobieren sowie die positiven Effekte auf Qualität und Wirtschaftlichkeit zu erkennen und anzuerkennen.
  • Kunden stellen hohe Qualität und Investitionsicherheit über Kampfpreise.

Finden Sie raus, ob es funktioniert!

Wenn Sie die passende Umgebung in Ihrem Unternehmen haben, also eine Kultur, die Zusammenarbeit fördert, ein Management, das den Nutzen versteht, und Kunden, die Ihren Qualitätsanspruch lieben, dann sollten Sie es unbedingt versuchen.

Vermutlich werden Sie nicht damit beginnen, einen Mob um jede Story und jedes Feature zu formen. Einigen Sie sich einfach auf die nächste, richtig komplexe Story, die sich schon im Backlog befindet, und die für einen der nächsten Sprints zu erwarten ist.

Probieren Sie Team bzw. Mob Programming für ein paar Sprints aus, und reflektieren Sie über die Ergebnisse – z.B. bei der Retrospektive oder nach dem Daily. Es wird für Sie funktionieren oder auch nicht, aber ohne es zu versuchen, entgeht Ihnen und Ihrem Team oder dem gesamten Unternehmen vielleicht eine großartige Chance.

Im besten Fall motivieren Sie Ihr Team/Ihre Teams wie noch nie zuvor, stärken den Team-Fokus und die Zusammenarbeit, bringen neue Mitarbeiter oder Junior-Entwickler so schnell wie noch nie an Board, uvm. Laden Sie auch den Product Owner und sogar den Kunden dazu ein, im Mob etwas Großartiges zu schaffen.

Wenn Sie daran interessiert sind, wie wir bei 25th-floor arbeiten oder Ihre Erfahrungen mit Mob Programming mit uns teilen wollen, freuen wir uns über eine Nachricht!


Dieser Artikel wurde ursprünglich auf Medium veröffentlicht und für das 25th-floor Blog übersetzt