Previous research in the field of Agile Distributed Software Development often focused on the a synchronicity of working hours due to different time zones, as if this was the only risk when developing software in non-co-located environments. This case study reflects a near shoring setting in which this primary impediment does not exist and investigates a broader range of risks now standing out more clearly. We observed two Polish Scrum teams working for a German company, which has been successfully applying Agile Methods for over four years. We present the actual process and practices of the external teams and contrast them to the intended way of proceeding. Main result: Agile near shoring is feasible and may produce high satisfaction amongst Product Owners, but this satisfaction might be delusive if process deviations due to misunderstandings of what Agile development means go unnoticed.

The classical definition of pair programming (PP) describes it via two obvious roles: driver (the person currently having the keyboard) and observer (the other, alternatively called navigator). Although prior research has found some assumptions regarding these roles to be false, so far no alternative PP role model took hold. Instead, most PP research tacitly assumes the classical model to be true and thus PP to be no more difficult than solo programming. We perform qualitative research (using Grounded Theory Methodology) to find a more realistic role model, and have uncovered a suprising complexity: There are more than two roles, they are assumed and unassumed gradually, multiple roles can be held by one person at the same time, and some of their facets are subtle. Mastering this complexity requires specific PP skills beyond mere programming and communication skills. By ignoring such skills, previous PP studies (in particular the controlled experiments) have investigated a rather mixed bag of situations, which explains their heterogeneous results. The emerging result is that qualitative research on the PP process will lead to constructive behavioral advice (process patterns) for pair members and to more meaningful designs for quantitative PP research.