Alle paar Wochen wird scheinbar eine neue Sau druchs Dorf getrieben, die angeblich die Lösung aller Problem sein soll. Aktuell lese und höre ich sehr viel über Mob Programming. Das soll nicht nur den Wissenstransfer innerhalb des Teams unterstützen sondern auch noch schnellere und bessere Ergebnisse liefern als das klassische Modell eines Entwicklers, der allein vor seinem Monitor sitzt.
Die Frage nach dem Wissenstransfer dürfte recht unstrittig sein, leuchtet es doch ein, dass eher juniorige Entwickler oder eben diejenigen, die in einem Bereich der Anwendung noch nicht so fest verwurzelt sind, von der direkten Zusammenarbeit mit sehr erfahrenen Kollegen profitieren dürften. Das löst sicherlich eines der Probleme, die uns in jedem Team begegnen, nämlich dem, dass es immer Experten gibt, die sich in bestimmten Bereichen sehr gut auskennen, und man daher dazu neigt, dass sich eben diese um die komplizierteren Fälle kümmern. So wird das bestehende Wissensgefälle sogar noch aus- statt abgebaut.
Selbstverständlich ist es eine Illusion, dass alle Kollegen alles können sollten, aber das hindert uns nicht daran, dafür zu sorgen, dass Wissen möglichst breit gestreut ist. Als Mindestziel sollte man sich vornehmen, dass jede Aufgabe in einem Team von mindestens zwei Personen erledigt werden kann. Es ist ganz normal, dass ein Kollege eine Sache schneller oder eleganter lösen kann als ein anderer. Wichtig ist für uns zunächst nur, dass die Sache von zwei Personen getan werden könnte, und dass wir nicht dumm aus der Wäsche gucken, wenn unser Spezialist ein paar Tage Urlaub hat.
Reiten wir nicht lang auf der Wissensverteilung herum. Dass Mob Programming uns dabei helfen kann, ist klar. Alle sehen gemeinsam in den Code und entwickeln etwas Neues. Am Ende haben nicht alle unbedingt den gleichen Wissensstand, da auch Erfahrung viel ausmacht, aber alle sollten sich jetzt gut im angefassten Bereich auskennen.
Vielleicht ein klein wenig schwieriger lässt sich die Frage nach der Qualität des Ergebnisses beantworten, aber auch hier dürfte leicht nachvollziehbar sein, dass vier Augen (oder mehr) eben mehr sehen als zwei, und dass zwei Gehirne (oder mehr) auch gemeinsam zu einer besseren Lösung kommen können. Die Entwickler werfen Ihr Wissen zusammen, stellen sich gegenseitig Fragen, machen Vorschläge und wählen den besten Weg aus. Aus dem Ansatz und der groben Idee zur Implementierung einer Person wird durch den Input weiterer Personen das Beste, wozu das Team gemeinsam in der Lage ist. Das kombinierte Wissen der Gruppe kommt zum Tragen.
Ein weiterer Punkt kommt hinzu: Es treten weniger Bugs auf, da sich die Kollegen gegenseitig auf Schwächen aufmerksam machen und alles, was entwickelt wird, von mehreren Personen überdacht und automatisch geprüft wird. Unterschätzen Sie diesen Punkt in keinem Fall. Eine einzelne Person macht sehr viel leichter einen Fehler als eine ganze Gruppe, weil man Dinge übersieht oder eine Sache nicht bedacht hat. Was aber der eine übersieht, fällt sehr wahrscheinlich einem anderen in der Gruppe auf.
Die schwierigste Frage, mit der ich anfänglich auch große Probleme hatte, war die nach der Geschwindigkeit und der Effizienz. Pair Programming kann man immer leicht argumentieren: ein erfahrener Kollege nimmt eben einen anderen an die Hand und gibt sein Wissen auf diesem Wege weiter. Wenn sich ein ganzes Team im Mob Programming zusammenfindet, steht gelegentlich ein Bereichsleiter, der die Kosten im Kopf hat, schwitzend in der Tür und fragt (völlig berechtigt) danach, ob es nicht schrecklich ineffizient sei, fünf Personen an eine einzige Programmieraufgabe zu setzen, die im besten Fall auch ein einzelner erledigen könnte. In seiner Rechnung wird dieses Feature fünfmal so teuer.
Für jemanden, der in Zahlen und Entwicklerstunden denkt, ist durchaus nachvollziehbar, dass der Wissenstransfer diese Rechnung ein wenig nach unten korrigiert. Hinzu kommt, dass ein ganzes Team wahrscheinlich ein wenig schneller ein schweres Problem lösen kann als ein einzelner, und dass diese Lösung vielleicht auch ein wenig besser ist. Wer nur in Zahlen denkt, lässt sich vielleicht davon überzeugen, dass dieses Feature nicht fünfmal sondern nur dreimal so teuer ist.
Danach wird es aber schwierig, wenn wir weiter mit Zahlen argumentieren möchten. Die eigentlichen Vorteile des Mobs sind nicht quantifizierbar. Der Wert des besseren Ergebnisses läst sich ebenso wenig beziffern wie der Effekt des gemeinsamen Lernens. Dennoch verstehe ich diese Befürchtung selbstverständlich. Eine Entwicklerstunde ist teuer, und wenn ein ganzes Team einen ganzen Tag zusammensitzt, dann kommt eine recht ansehnliche Summe zusammen.
Und doch vergessen wir dabei einen ganz wichtigen Punkt: die Teamdynamik. Gemeinsam an einem Problem zu arbeiten, beflügelt unsere Kollegen. Man spricht offen über Lösungen und Wege, die man allein vielleicht nicht gehen würde, weil man dann dazu neigt, sich in bekannten Gewässern zu bewegen. Im Team ist man experimentierfreudiger. Selbstverständlich geht man dabei auch einmal in eine falsche Richtung. Durch die gemeinsame Arbeit an einem Problem bemerkt man das jedoch sehr schnell.
Das Team findet bessere und elegantere Lösungen. Allein das sollte Grund genug sein, einmal das Experiment zu wagen. Natürlich eignet sich nicht jede Aufgabe für einen Versuch mit dem Mob. Triviale langweilige Fleißarbeiten, die keine Herausforderung darstellen, eignen sich verständlicherweise kaum. Auch ist nicht jedes Team geeignet. Wenn Sie einen Entwickler in Ihrer Mannschaft haben, der immer im Mittelpunkt stehen muss, die Weisheit mit Löffeln gefressen hat und selbstverständlich immer recht haben muss, dann wird es nicht funktionieren. Dieser Kollege wird nur glücklich sein, wenn er allein ganz tolle Dinge tun kann, für die er anschließend gebührend gelobt wird.
Mob Programming ist mehr als alles Andere eine Teamprozess. Selbstdarsteller und Rechthaber können leicht alles zerstören. Auch sollte das Team bereits seit einiger Zeit zusammenarbeiten und sich gut kennen. Nur auf dieser vertrauensvollen Ebene ist ein effektiver Mob möglich. Bei einem frisch zusammengesetzten Team sind Unsicherheiten und fehlende Kenntnisse über die Kollegen noch zu groß.
Wenn Sie sich zu diesem Experiment entscheiden, dann sorgen Sie zunächst einmal für Ruhe, indem Sie einen Raum organsieren, in dem das Team ungestört (und ohne andere zu stören) arbeiten kann. Ein Arbeitsplatz und ein Beamer, genügend Sitzplätze und keine störenden Termine. Es wäre schade und schädlich, wenn ein Kollege zwischendurch für eine Stunde verschwinden müsste, weil er ein Meeting hat.
Ähnlich dem Pair Programming gilt auch hier das Driver-/Navigator-Prinzip. Der Driver tippt, die Navigatoren (also alle anderen) geben Input. Dabei geben Sie die Richtung vor, sie diktieren nicht Wort für Wort, Befehl für Befehl. Dennoch äußern Sie sich natürlich zu dem, was der Driver tippt und geben Hinweise, wie die Implementierung evtl. verbessert werden könnte.
Der Fahrer wechselt ständig, etwa alle 15 oder 30 Minuten nimmt ein anderer Entwickler an der Tastatur Platz. Achten Sie darauf, dass sich nicht immer nur zwei Kollegen abwechseln. Bei der eigentlichen Arbeit gibt es zwei Ansätze, den »harten« und den »weichen« Weg. Bei der ersten Variante, sind die Rollen von Fahrer und Navigator strikt getrennt. Der Fahrer setzt das um, was die Kollegen ihm sagen, bei der zweiten Option beteiligt dich der Fahrer an der Diskussion.
Teilnehmen sollten neben dem Team sowohl der Scrum Master als auch der Product Owner, um ggf. noch während der Implementierung Fragen beantworten zu können. Aufgabe des Scrum Masters ist es, auf die Durchführung zu achten. Er sorgt dafür, dass die Rollen Fahrer und Navigator getrennt bleiben und lenkt eventuell ausufernde Diskussionen wieder auf das Thema zurück.
Den Navigatoren sollte es frei stehen, eigene Laptops mitzubringen, um zwischendurch Dinge zu recherchieren und zu prüfen. Sie sollten jedoch darauf achten, dass niemand Dinge parallel entwickelt und dann irgendwann eincheckt. Das widerstrebt dem Gedanken der Kollaboration.
Das Team sollte die Ausahl der zu bearbeitenden Aufgabe treffen. Die Entwicklerkollegen können selbst am besten beurteilen, was sich hierfür am besten eignet. Es sollte eine Anforderung sein, die Neuerungen aufweist (ansonsten könnte sie jeder allein bearbeiten), die aber nicht zu groß ist, als dass sie an einem Tag nicht erledigt werden könnte. Veranschlagen Sie ruhig den ganzen Tag, und lassen Sie dabei auch eine lockere Atmosphäre zu. Wenn Humor im Spiel ist, haben die Kollegen mehr Spaß an der Aufgabe. Als Scrum Master achten Sie lediglich darauf, dass der Witz nicht die eigentliche Arbeit verdrängt.
Es ist schwierig, beim Mob Programming eine feste Timebox anzusetzen, da der zeitliche Rahmen für die Aufgabe anfänglich meist nur schwer zu bestimmen ist. Wenn die Kollegen früh fertig werden, ist das kein Problem. Wenn sich zeigt, dass die Fertigstellung an einem Tag nicht abgeschlossen werden kann, fragen Sie nach einem guten Breakpunkt, der einen Teilbereich abschließt und es ermöglicht, die Aufgabe am nächsten Tag fortzuführen.
Sie sollten auch erst am Folgetag mit Ihrem Team über die Erfahrungen im Mob sprechen und mit etwas Abstand eine Mini-Retrospektive durchführen. Im allgemeinen finden sich nach den ersten zwei bis drei Terminen noch Verbesserungsvorschläge, danach sollte es rund laufen. Wenn das Team seinen Rhythmus gefunden hat, werden Sie bemerken, wie effektiv und schnell es Dinge bearbeiten kann. Sie werden überrascht sein.
Abschließend: Mob Programming eignet sich nicht für jedes Team, jede Aufgabe und jedes Unternehmen. Wenn der Widerstand im Unternehmen zu groß ist, sollten Sie nicht versuchen, das Experiment durchzudücken. Man wird nach Gründen suchen, es für gescheitert zu erklären. Auch sind einige Teams begeistert von der Idee, andere reagieren mit größter Skepsis. Zwingen Sie Ihre Kollegen nicht. Die meisten Teams, mit denen ich Mob Programming ausprobiert habe, rotten sich ungefähr einmal pro Sprint zusammen, und tun das auch mit gleichbleibend hoher Begeisterung. Die Ergebnisse sind erstaunlich. Nur ein Team hat das Experiment nicht fortgeführt. Ein verhindertes Alphamännchen fühlte sich nicht genug beachtet.
