arrow arrow--cut calendar callback check chevron chevron--large cross cross--large download filter kununu linkedin magnifier mail marker menu minus Flieger phone play plus quote share

Pairing als Default

Ein Experiment
Foto von Susann Lassmann
Susann Lassmann

Software Developer

Wie man Probleme im Entwicklungsprozess besser nicht angehen sollte

Das Review läuft irgendwie nicht so ganz nach Plan. Die präsentierten Stories sind ja schon quasi fertig und nur noch nicht ganz zu Ende getestet und bei der Präsentation passiert es dann schließlich: ein Bug tritt auf und die präsentierende Person sagt nach einer kurzen aber unbehaglichen Pause die berühmten Worte: „Eigentlich sollte jetzt dies und das passieren…“.
Die Stories können nicht final abgenommen werden und eine allgemeine Enttäuschung macht sich breit, obwohl man die ganzen letzten drei Wochen ja eigentlich ziemlich viel gemacht hat. Trotzdem werden die Sachen einfach nicht so richtig fertig.

In der darauffolgenden Retrospektive wird versucht die Ursache für unser Problem zu finden.
„Ist ja klar, dass sich die Sachen in Test stauen, wenn der Tester grad im Urlaub ist.“
„Die Pull-Requests liegen halt viel zu lange herum und werden nicht schnell genug gemergt.“
„Wir haben zu viele Sachen parallel in Arbeit und niemand hält das WIP Limit ein.“
„Die ganzen Meetings zwischendurch dauern so lange! Logisch, dass man nichts schafft, wenn man nicht zum Arbeiten kommt.“

Danach gibt es zwar recht viele Ideen, wie man die Probleme angehen könnte, so richtig an die Umsetzung wird sich aber nicht gemacht. Wo fängt man da auch an? Der Wunsch nach Pair Programming kam schon häufiger auf, aber das löst ja nicht das Problem mit den sich stauenden Spalten im Jira-Board und überhaupt funktioniert die Zusammen­arbeit zwischen den Entwicklern doch eigentlich auch so schon voll gut. Die WIP Limits sind sowieso vollkommen überzogen und soll man als Entwickler jetzt etwa einfach zwei Tage lang nicht weiterarbeiten, bis die Designerin wieder da ist, um ihr Review zu machen oder bis die Test-Spalte nicht mehr so voll ist? Schließlich ist man ja Entwickler und kein Tester.

Kommt euch das bekannt vor? Uns auch.

Glücklicherweise kam bei uns in diesem Moment Jakob Holderbaum als externer Berater hinzu. Er half uns mit seinen Ideen und Erfahrungen dabei, unser gesamtes bisheriges Vorgehen über den Haufen zu werfen. Von diesem Experiment wollen wir euch jetzt erzählen.

Fokus auf Team Responsibility

Wir erkannten recht schnell, dass unser Hauptproblem war, dass wir uns zu sehr auf unsere einzelnen Rollen als Frontend- oder Backend-Entwickler, Tester oder Designer fokussiert hatten, obwohl wir als gesamtes Team dafür verantwortlich sind, eine Software gemäß unserer Definition of Done zu liefern - völlig unabhängig von unseren einzelnen Disziplinen. Da hatten wir auch schon unser zweites Problem: Unsere Definition of Done war unauffindbar. Ein im Teamchat verschollenes Foto von Stichpunkten auf einem Whiteboard. Natürlich hat sich somit auch niemand daran gehalten.

Also war unser erster Schritt, zusammen eine Team Policy („Wir sind eins!“) sowie eine Definition of Done zu erstellen. Das ging dann erstaunlicherweise so schnell, dass wir unser drittes Problem in Angriff nehmen konnten: die mangelhafte Kommunikation im Team untereinander.

Das physische Board für bessere Transparenz

Wenn zuvor ein Kollege bei einer Teamentscheidung nicht dabei war, wurde er am nächsten Tag auch nicht so richtig darüber informiert. Die Tickets wurden kommentiert, doch danach tat sich daran ein paar Tage nichts mehr, weil niemand auf die Kommentare reagierte. Wer hatte eigentlich woran gearbeitet und wen konnte man fragen, wenn man zu einem entwickelten Feature noch nicht ganz verstand, was jetzt eigentlich noch abgenommen werden musste?

Um unsere Arbeit transparenter zu gestalten, verwendeten wir ab diesem Zeitpunkt ein physisches Board, auf dem unsere gesamte Arbeit, sowie Abwesenheiten und Neuigkeiten dargestellt wurden. Mit personalisierten Magneten war sofort ersichtlich wer woran arbeitete. Im Daily wurde nun nur noch dieses Board verwendet.

Als nächstes gingen wir die Auflösung der Wissensinseln in unserem Team an, indem wir ab sofort nur noch im Pair an den Tickets arbeiteten.
„Wie jetzt? Die ganze Zeit? Wie soll das denn bitte gehen?“
Das haben wir uns auch gefragt.

Wie disziplinübergreifendes Pair Programming die Produktivität steigert

Die Vorteile von Pair Programming liegen eigentlich klar auf der Hand. Eine kurze Recherche ergibt: Im Pair entwickelte Software ist weniger fehleranfällig und qualitativ hochwertiger. Durch das gemeinsame Arbeiten wird Wissen im Team schnell verbreitet und auch die Kommunikation verbessert sich. Feedback, auf welches man bei einem Pull-Request erstmal warten würde, kommt sofort und somit werden die Aufgaben schneller fertig. Entwickler arbeiten im Pair fokussierter und das gemeinsame Verantwortungsbewusstsein für die entwickelte Software steigt ebenfalls.

Wir fingen also einfach an. Da der Stau in der Testspalte zu diesem Zeitpunkt am größten und unser WIP Limit (wie üblich) überschritten war, schnappten wir uns eins der Tickets aus der Test-Spalte, setzten uns zu fünft in einen Raum und wechselten uns der Reihe nach an der Tastatur ab, während die Übrigen diskutierten und diktierten. Der Lerneffekt war hoch, da einige Entwickler das Test-Framework bis dahin noch gar nicht kannten und wir konnten auch direkt ein paar der Tests überarbeiten. Zudem konnten wir uns den Pull-Request und das Codereview sparen, da ja schon während der Entwicklung mehrere Leute daran gearbeitet hatten.

Als nächstes fiel uns auf, dass das Ganze noch viel effektiver wäre, wenn wir disziplinübergreifend als Pair oder Mob arbeiten würden. Also gab es in den nächsten Tagen dann Pairs mit Designerin und Entwickler, mit Tester und Entwickler, mit Frontend- und Backend-Entwickler usw. Wir lernten Bereiche unserer Anwendung kennen, mit denen wir uns vorher noch gar nicht auseinandergesetzt hatten und wir merkten, dass die vielen Statusspalten in unserem Board überhaupt nicht mehr notwendig waren. Darum reduzierten wir unser Board auf ganze drei Spalten.

Und so wanderte Ticket um Ticket in die Done-Spalte. Es gab kaum noch Staus oder längere Blocker und dann plötzlich war es soweit: Wir hatten erstmals unser WIP Limit eingehalten! Schon in den ersten beiden Wochen hatten wir einen unglaublichen Produktivitäts-Boost und eine allgemeine Euphorie machte sich breit. Die Arbeit als Pair war sehr effizient und man arbeitete viel fokussierter als zuvor. Auch die Wissensverteilung funktionierte nun besser und auch wenn jemand im Homeoffice war, arbeiteten wir über Screensharing zusammen.

Natürlich programmierten wir nicht rund um die Uhr im Pair. Das war allein schon wegen der unterschiedlichen Arbeitszeiten der Kollegen schwer umzusetzen. Doch es gab nun für jedes Ticket immer mehrere Ansprechpartner und nachdem Mails gecheckt wurden und die wichtigen Dinge wie Mittagspausenzeiten abgeklärt waren, ging es ans Pair Programming.

Nach den drei Wochen verließ uns Jakob wieder und wir waren guter Dinge, dass wir das Pairing als Default auch weiterhin beibehalten würden.

Lessons Learned: Pair Programming im Alltag

Und wie sieht es denn nun ein paar Wochen später aus?

Die WIP Limits werden nach wie vor eingehalten. Trotzdem arbeiten wir nicht immer im Pair. Mal wird jemand krank oder Teammitglieder sind im Urlaub sodass gar nicht immer ein Pair zusammen kommt. Dann haben wir in diesen Fällen natürlich weiterhin Pull-Requests und Codereviews. Auch Homeoffice stellt für uns beim Pairing noch ein Hindernis dar. Zwar funktioniert der Ansatz über Screensharing, ist auf Dauer aber doch um einiges anstrengender, als einfach für eine Weile völlig unbeeinflusst in seinem Tunnel zu verschwinden. Zudem gibt es ab und zu ein paar Aufgaben, die wir parallel zu dem auf unserem Board abgebildeten Tickets erledigen. An dieser Stelle müssen wir noch besser an der Transparenz untereinander arbeiten und uns immer wieder ins Gedächtnis rufen, für welche Arbeitsweise wir uns gemeinsam entschieden haben. Unser von uns bestimmter Lord of the Board erinnert uns regelmäßig daran.

Insgesamt ist unser Wissen nun viel besser verteilt. Auch wenn jemand nicht anwesend ist, können wir trotzdem ungehindert weiterarbeiten und es entstehen kaum noch Staus oder Blocker innerhalb des Entwicklungsteams. Zwei neue Kollegen sind nun schon richtig gut eingearbeitet, was ohne das Pairing (höchstwahrscheinlich) nicht so schnell möglich gewesen wäre. Gefühlt haben wir weniger Bugs, was sich bisher aber noch nicht tatsächlich messen lässt, da der Zeitraum für einen Vergleich noch zu kurz ist. Natürlich arbeitet man durch unseren Arbeitsmodus auch schon mal an Dingen, die einen selbst nicht so brennend interessieren, muss aber dafür auch nicht extra warten, bis der passende Ansprechpartner da ist, um fertig zu werden.

Und das ist unser wichtigstes Fazit: Die Sachen werden fertig. Unsere bisherige Produktivität seit der Umstrukturierung gibt uns Recht. Natürlich ist so eine Umstellung nicht immer einfach und braucht Zeit. Doch wir sind uns sicher, dass unser Ansatz sinnvoll ist und wir werden versuchen, weiter daran festzuhalten:

Wir sind eins und deshalb ist das Pairing bei uns der Default-Modus.