XP Practices Implementation with Varying Skillsets on a Team

Problem Domain
The problem domain was described as an environment where pair programming and XP practices were being implemented and the levels of expertise around XP practices and modern programming in general were great. The team recognized that their throughput became negligible and decided to abandon pair programming in the interim. The practices under discussion were:

• different skillsets/expertise in OOD (be it DDD or otherwise) vs. procedural (senior developers tend to have more procedural experience)
• different skillsets/expertise in TDD
• different skillsets/expertise in unit-testing

Discussion
The group’s reaction to the development team’s decision to stop pair programming was mixed, but the general consensus was that abandoning pair programming was the wrong thing to do. The team’s decision to delay the implementation of pair programming to a point in time were it is more convenient would never come to fruition – experience shows there never is a more convenient time. The group re-emphasized that pair programming was intended as a mentoring instrument – beyond all the other benefits of pair programming such as implicit code review, knowledge transfer, better quality, etc. From this point the discussion revolved around how to address the team’s specific issues and what the team and the business could do going forward to successfully implement pair programming.

It should be recognized that when implementing agile (or any new methodology for that matter) there will be a drop in productivity while the team learns and gains experience over time. Altering methodologies is likely considered a longer term goal but shorter term goals should be realistic. For example, expecting that the team would have fair productivity with such a diversely experienced team is not realistic. The group suggested that a phased-in approach is likely the more successful approach to take – with full commitment from the business to allow this to happen.

The costs associated with the drop in productivity are something that need to be budgeted from the business perspective. Budgeted models could come in many forms, but ultimately there is a cost to implementing pair programming measured in the drop in productivity of the team until the team becomes seasoned. Suggestions made to budget for learning as pair programming is being phased in include:

• setting aside 1 user story per iteration/sprint (increasing the count as the team gains experience) that must be completed in accordance with all XP practices (pairing, TDD, etc.)
• setting aside a timeslot per day where XP-seasoned developers pair with non XP-seasoned developers
• implementing a training program (either in-house or external) where junior XP developers could gain basic knowledge and experience to get them started and provide them with basic skills to continue their learning

Regardless of the above points, the group made clear that the business must set aside enough time and budget to permit learning at the workplace. Failing to do so will always have developers putting in their test experiences into production code – something that should be done in a learning/training environment. The rationale behind this is that professional developers always seek to better themselves and without enough time allotted for them to learn in a safe environment, they will inevitably learn in a non-safe production environment. The group suggested that one of the goals of the business should be continuous learning for all their staff. That being said, the group also raised questions about how people learn and to what extent they are willing to.

It was brought up that people have different change motivations, pressure points and resistance. Where one person has the willingness or capability to embrace change quickly, others do not share that enthusiasm or capability. It was generally agreed that more-junior developers (by amount of time spent in the IT industry) were apt to change quickly and adopt new methodologies and concepts, senior developers presenting more of a challenge in this area. Whatever direction the team decides to take on pair programming, the team would have to take into consideration the willingness to change as part of its implementation plan. The business would have to support the direction of the team and be willing to ensure that an alignment of goals occurs. This may include having the right people for the job – forcing people to adopt change generally does not lead to excellence in work.

In the end, if and when a team decides to implement pair programming and XP practices, the group agreed that the backing of the business is a necessity. This includes rewarding performance on several different fronts beyond just throughput. The point was made that if incentives provided to developers was based solely on throughput, then no time would be spent mentoring. Any incentive or job measurement program would have to have a balance of the following to achieve success on an XP project:

• quality of time and time spent on mentoring
• team work
• process improvement
• throughput