Join in the debate

Rachel Davies has stepped down as the chair of the Agile Alliance and
Brian Marick has taken the seat. Brian has instigated a wide ranging discussion on the future of the agile alliance and associated issues. Read Brian's suggestions here:
http://www.exampler.com/blog/2007/05/20/help-me-stir-things-up/ and join the contribute to the discussion here: http://forum.agilesoftwaredevelopment.org/ .

Is Agile for the Average?

I have spent the last couple of weeks talking about agile implementation in average teams. A colleague I regularly work with has been implementing agile technologies for a number of years and been very successful at it too!

A couple of weeks ago he called me up and told me that it didn't work! Well, taken aback, I asked him what on earth he was talking about! After evangelising for years about Agile he was now saying it was junk - had he hit his head?

After a bit of digging it became clear that he was struggling to implement agile ideas in the team he is currently working with. His explanation for this is that he has always worked with exceptional teams and in this, his first experience of an unexceptional team he is finding it incredibly challenging to get them on board. Which got us thinking - does Agile actually work in average teams?

There is a fair amount of debate around whether or not agile works for average teams. Much has been written suggesting that agile works most effectively in high performing teams, and yet many argue that agile is an effective tool for average teams.

I think that both can be true. High performing teams often have a culture of personal development, problem solving and a desire to be challenged. An average programmer is far more likely to be focused upon their technical ability and concerned with completing their own work.

The key to successful implementation of agile in average teams is to have a clear understanding of the level of both technical and non-technical skills within the team at the outset. If a programmer is of average ability then it is likely that they will not have been required to learn and develop the non-technical skills required in an agile environment. An exceptional developer is more likely to have had experience selling their ideas, influencing others, communicating clearly and openly and negotiating and expressing opinion.

Therefore, if we are to implement agile in average teams without such experience we must first train and nurture those skills, allow for practice and build in the time and processes to support their development.

So, my friend is back with his team, auditing the skills sets and building in processes to facilitate the change.

Next time, some more detail on the non-technical skills set requirements.

Paired Programming - benefits for individual and team development

Overview

Paired programming is a technique where all programming is undertaken by two developers working at the same machine.(1). This article reviews material examining team and professional development as a result of paired programming.

Much has been written about the effect of pair programming in development teams. There is a body of evidence that argues a strong case for the economic benefits of pair programming (2, 3). Significantly less time is spent in testing and quality assurance code production is continually reviewed. Problems are identified as part of the coding process rather than identified and subsequently fixed during the testing process.

Continuous design and code review has a similar impact upon support costs of software. Identifying and fixing problems prior to customer release significantly reduces support costs and increases customer satisfaction and confidence.

However, pair programming has much to offer in terms of developing and maintaining effective, open and transparent teams. An overview of some of the benefits for personal and team development are discussed below:

Learning

Qualitative and empirical research points to the positive effect of paired programming on learning for both junior and experienced programmers (2, 3).

Concerns are often raised over a range of issues:
Junior programmers may feel uncomfortable being observed by more senior staff, and may approach paired programming with an attitude of assessment rather than one of knowledge sharing.
Senior staff may consider the process time consuming and of little learning value to themselves. There may be an attitude of regarding paired programming as a “mentoring only” approach.

However, both empirical and qualitative reports point to the benefits of paired programming for both junior and senior staff. For example senior staff regularly self report on their learning experiences in industry:

“I noticed very quickly that this most junior of programmers was actually helping me! Me! …..That has been my experience every time thereafter, in

pair-programming. Having a partner makes me a better programmer. …” - Ron Jeffries (3)

“It is interesting to point out that learning is almost always a two way street. We often see junior programmers teaching senior programmers.” (4)

Therefore, paired programming can offer technical development opportunities for all team members. Learning is truly a two way process.

Team development

There is range of evidence in the literature that suggests that the practice of pair programming can have a positive impact on team development.

Pairs work well together share expertise and problems. Pairing encourages team members to seek help earlier in a problem, compared to lone programmers. Resulting in quicker, and often more effective solutions.(3, 4)
Effective communication can lead to an open, transparent environment. Issues are raised immediately, and agendas are open rather than hidden – again this can lead to increased confidence, productivity and perceived job satisfaction for team members (1, 3).

There are obvious benefits for both individual learning and team dynamics that result from paired programming. Increased communication within teams, confidence and shared problem-solving all have positive effects on the speed of development and quality of completed software (4).

However, the introduction of paired programming should be handled with care. It is a process that is often met with scepticism. Teams should be given the tools to develop the communication skills required, and processes to manage issues that rise should be in place and clearly communicated throughout the team. Finally, clarity with regard to individual input, pair difficulties and ongoing team development are required.

With appropriate tools, organisational support and a willingness to review practice in place, pair programming can be an effective, productive and cost efficient process for collocated teams.

Bibliography:

1. Jan Chong, Robert Plummer, Larry Leifer, Scott R. Klemmer, Ozgur Eris, and George Toye, Pair Programming: When and Why it Works. In Proceedings of Psychology of Programming Interest Group 2005 Workshop. Brighton, UK, June 2005. Available online at: http://www.stanford.edu/~jchong/research.shtml#papers

2. Cockburn, A. and L. Williams. The Costs and Benefits of Pair Programming. in First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000). 2001

3. Williams, L., et al., Strengthening the Case for Pair-Programming. IEEE Software, 2000. 17: p.19-25.

4. Meloche. T, Goebel. J, Sheridan. R. Paired Programming in the Software Factory - Questions and Answers. 2003. Available online at : http://www.menloinnovations.com/freestuff/whitepapers/pairedprogramming_qanda.html