In pair programming you sit with a pair (usually 2) programmers at one computer and work on the same code. And that is supposed to make sense? ... We programmers in the Shopoffice team think so: Yes! We write better code, produce less bugs, are more concentrated at work and most important: We have more fun at work.
Sure, we already use pair programming extensively here in the team - but there is always something to improve. So why not bring someone into the team who has more practice in this area and has had experience with pairing in various projects? We decided to bring in Thomas Much to join us for a sprint. Thomas had already been on numerous projects as a Java and Pair Programming coach and that's exactly what we wanted to benefit from.
Every team member here surely had their own idea how Thomas could integrate into the team to make us better pair programmers. That's why, at the beginning of the coaching, we put our ideas together and thought about how the collaboration could work. Each team member had the opportunity to say:
We came to the conclusion that Thomas should not exclusively pay attention to our pairing behavior. Rather, he should pay attention to everything he notices in our daily work - i.e. Scrum methodology, programming methodology and potential "broken windows" in the code.
We then started the Sprint. Thomas then "paired" through the team each day, learning about our way of working and the overall system. At the beginning of each day, we pragmatically decided in the Daily which pairs would work together on a task. After just one day, Thomas was able to get his bearings and start giving us tips and making suggestions for improvement.
As discussed in the kick-off, we took time in the middle of the sprint for coach feedback. Some suggestions for improvement were included in a presentation. Fortunately, the feedback was largely positive. Our pairing behavior, the test-driven work, the code design were praised. But also many small things, for which we have simply become too operationally blind, were to be found here as suggestions for improvement:
The coaching ended together with the end of the sprint. This also gave us a good topic for the retrospective to evaluate the coaching. What did it do for us as a team? What did it do for me personally.
In the end, the coaching did not bring us an enormous profit, but what remains is a good feeling that we are on the right track. Many tips were helpful and will help us to become even better and more effective in the upcoming sprints. We also started to implement the tips right away. Alright, triples might be ineffective. But according to the motto "A lot helps a lot!" we are now programming in sextuple.
Hi José, schön, dass dir der Artikel gefällt. Wegen deines Vorschlags: Schick mir doch einfach eine kurze Mail, dann schauen wir, was wir hinbekommen!
Super Sache! Man sollte hier vielleicht auch einfach mal erwähnen, dass Pair Programming zwar schon lange an Universitäten gelehrt werden aber bei weitem noch nicht die Verbreitung in Unternehmen finden, wie es eigentlich sein sollte.
Während des lesens des Artikels kam mir gerade eine Idee. Diese ist vielleicht zu hoch gegriffen oder Absurd aber darf man auch als Mitarbeiter im Zuge des PP mal für ein Tag bei euch mitmachen. Klar meine Aufgaben sind hier im Unternehmen eigentlich andere, aber man würde so vielleicht auch einfach die Leute sowie und vor allem die Arbeit kennen lernen. In wie fern ich da nun ein Vorteile draus ziehen kann, weiß ich gerade nicht. Aber ich finde den Gedanken sehr interessant.
Hallo José,
in unserem Team (Entdecken aka FT3) hatten wir gelegentlich schon mal einen Interessenten, der für einen Tag mit uns zusammen im Pair gearbeitet hat. Wir können gerne über Stefan oder mich einen Tag vereinbaren.
VG, Guido
Hallo Dirk,
vielen Dank für deinen Kommentar. Beim Pairen versuchen wir, wie bei allen anderen Dingen übrigens auch, gesunden Menschenverstand walten zu lassen. Es gibt also keinen Zwang dazu. Beim Daily wird meist entschieden, welche Paare zusammen an den Tasks arbeiten. Dabei versuchen wir immer neue Kombinationen zu finden. Um herauszubekommen ob Konstellationen zu häufig vorkommen, hilft eine Pairing-Matrix in der man festhält, wer mit wem gepaired hat.
Wenn es sich einrichten lässt, dann pairen wir den ganzen Tag, unabhängig davon ob jemand eingearbeitet werden muss oder das Thema neu ist. Somit ist niemand allein für den Code verantwortlich (Stichwort: Collective Code Ownership). Coding-Conventions haben wir, sind aber nicht mehr so wichtig. Es entsteht schnell ein gemeinsames Verständnis von gutem Code. Das Team lernt somit viel voneinander und das ist gut für die Qualität!
Viele Grüße,
Robert Breetzmann
Interessanter Beitrag.
Wir bei aixigo (www.aixigo.de) sind mittlerweile auch vermehrt mit Pairprogramming unterwegs. Nach meinem eigenen Erfahrungen ändert sich die Arbeitsweise aber ziemlich stark und einige Dinge fallen irgendwie unter den Tisch, wenn man den ganzen Tag "paired".
Wie macht ihr das? "Paired" ihr den ganzen Tag oder nur stundenweise?
Das ganze Projekt durch, oder nur am Anfang bis jeder im Thema und mit den Entwicklungswerkzeugen firm ist?
Wann wechselt ihr eure Paringpartner?
Welche Erfahrungen habt ihr mit der Codeverantwortung gemacht? Wenn jeder alles macht, kann man sich ja ganz gut in der Gruppe verstecken. ;-)
Coding-Conventions machen sicherlich auch Sinn oder kann bei Euch jeder nach eigenem Gutdünken kodieren.
Gruß,
Dirk
[…] 14 Friends of Pair Programming http://dev.otto.de/2013/09/23/14-friends-of-pair-programming/ […]
[…] collections. Immutability as default is a milestone in my life as a developer. I compare it to git, pair-programming, continuous integration and IntelliJ IDEA (with Cursive now, of course). There was a time when I […]
[…] des kurzen Zeitraums waren wir, dank zahlreicher Entwicklerbeteiligung, in der Lage zum Teil Pair Programming einzusetzen. Dabei viel auf, dass zwar auch zwei übermüdete Entwickler vor einem Rechner teils […]
We have received your feedback.