Do you work in a highly fluid IT environment? Do you work in or manage a geographically disparate virtual team? Do you struggle with building in and maintaining the quality of your developments and releases? Then this article could be for you, we take a look at Red Hound Consultancies’ experience of operating a “Pair Programming” approach to successfully address these issues…
A common approach for many consultancies is to allow minimum team size of a single person often working part time. This has the following disadvantages:
- Poor requirements or technology documentation can have a big impact on a single person. Trying to cope with chaos is much easier when shared
- The sense of isolation can unnecessarily trigger off panic
- Development, Test and Documentation tend to run in traditional waterfall sequences
- Quality can often be poor for all the above reasons
- Any strengths are typically down to the individual
- Individuals can “disappear” when working virtually either intentionally or through despair!
- Single points of failure are prevalent i.e. individuals on leave of if they actually leave or if unforeseen circumstances occur – This is high risk for company and client alike!
Red Hound’s experience has shown that with the simple expedient of constructing your teams with a minimum size of 2 people the above blockers are instantly removed and what’s more this doesn’t cost you or your client anymore and doesn’t constrain your resources either. (This concurs with the experience of others – see Recommended Reading)
Specifically Red Hound recommends you consider the following:
- Maintain your initial client estimate for man days (don’t make it cost more)
- Allocate at least 2 people – they don’t have to be full time and you can mix and match e.g. 1 full time and 1 part time or any combination there of
- In conjunction with or based upon your projected resource allocation, decide if you maintain the original delivery date or bring it in
- Within the team, structure the work so that where possible activities run in parallel e.g. Dev and Test of multiple iterations. Importantly QA can run in parallel – we have found observing code development in real time significantly reduces errors
A small word of caution, you need to ensure that your pairs work successfully together and keep an eye out for issues developing such as personality clashes or the Expert dominating the Novice etc; these can be addressed either at the recruitment stage –hire the right person and set expectations from the start – or via management review.
We have been operating in the above fashion for one of Red Hound’s high profile customers and have realised all of the predicted benefits. The client has given Red Hound a very high satisfaction rating!
In summary, for no extra cost to you or your client simply creating minimum team sizes of two people drives quality and productivity across the board whilst simultaneously boosting team morale and eliminating single points of failure. Give it a go – you have nothing to lose and a problem shared…
Recommended Reading
http://en.wikipedia.org/wiki/Pair_programming
http://blog.codinghorror.com/pair-programming-vs-code-reviews/
http://www.uxbooth.com/articles/write-better-content-by-working-in-pairs/
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.9212&rep=rep1&type=pdf