Here at Otto, we use Pair Programming in software development and I am often asked why we do this - especially by non-developers. That's why I've come up with a session in which I make Pair Programming tangible and tangible for people who don't come from software development.
At our last Barcamp, I held a half-hour session "Pair Programming for Non-Developers".
Why that, ...well, why "for Non-Developers"?
Here at Otto, we use Pair Programming in software development and I am often asked why we do that - especially by non-developers. That's why I've come up with a session in which I make Pair Programming tangible and tangible for people who don't come from software development.
The basis of the session is the game "Pair Draw" which I discovered on http://www.industriallogic.com/blog/pairdraw-2/. Pair Draw is about drawing two human faces in 2 x 2 minutes. In the first round alone, in the second round in a pair. For the second round I added the rule "draw alternately". After the game is over, there is a "debriefing" with all participants, where I ask some questions: How was it for you? What were the differences? Which round produced the most creative results? Which round was more exhausting?
To round off the session, there was some theory after the game:
A few more questions came up in plenary, of course, which I'll summarize as a quick Q/A:
Q: We painted two faces per person in two minutes in the first painting exercise. In the second painting exercise, two faces per pair in two minutes. So pair programming is twice as expensive, right?
A: Referring to slide 8 and the picture on the bottom left with the two doctors at the operating table, I answered the question with the counter question, is it always about cost? It's also about distribution of knowledge, about safety and risk mitigation, about new ways of solving problems and maybe simpler ones.
Q: How long can you do pair programming a day? Doesn't it get tiring at some point?
A: A best practice says "three quarters of the working day at most". This certainly depends on the task currently being worked on, the composition of the pair, the frequency of rotation, etc.
Q: Is Pair Programming also suitable for training?
A: Yes, especially then. Here it should be noted: If the level of knowledge is too different, it can be too fast for one and too slow for another, leading to much faster "fatigue". At this point, the individual responsibility of the respective developers and teams counts, who must determine for themselves how much time is invested in individual familiarization and how much time in familiarization in pairs.
How would you have answered the questions and what questions do you still have? Just write your comment below...
And then: Try it out!
We have received your feedback.