Posted by ShriKant Vashishtha mid-morning: June 2nd, 2009
One of the key USPs of pair-programming is – it provides value which is more than simple typing. That includes ACTIVE participation in code-review, knowledge sharing on continual basis, frequent design discussions with minimal distractions etc. If you primarily focus on knowledge sharing, pair-programming essentially provides true form of knowledge sharing as instead of looking at some bulky heartless documents you sit together with a person who has already worked on the subject and can have conversations and design discussions.
It works very well when team is collocated as pair-switching, driver-navigator role change and design discussions in person is quite seamless in collocated environment.
What if you are the part of a distributed team? Developers still pair-up but not necessarily with team-member from distributed location. Though many teams have started implementing the concept of distributed pair-programming with the help of newly available communication tools (Skype for voice conversations and Skype Mikogo plugin for desktop sharing to name a few) quite successfully in which developers in distributed locations pair-up with each other .
While working in one such distributed project, we realized that knowledge areas were getting localized as distributed teams used to work on different stories. Standups by nature are brief and don’t give a lot exact implementation details. Planning-2 meetings help in defining low level design and steps but during implementation those steps are also bound to change sometimes. Because of above mentioned reasons, we felt the need of a forum for knowledge sharing between distributed teams.
We started having distributed knowledge sharing sessions using Skype voice-communication and Mikogo desktop sharing tool and they were quite effective. Even though it may be difficult to grasp entire flow in one session, it still provided a good view on implementation issues which helps in implementing future stories or fixing any maintenance issue quickly,
During those discussions we also used to get design feedback within the team which were helpful in identifying any design flaws, points of improvements, refactoring areas etc.
