"Upgrading" Pair Programming

Re-interpreting Pair Programming

NOTE:  See http://agiledesign.org/2014/09/09/i-roadmap-to-an-agile-design/ for a view of Non-Solo Developmental in context of practices for an Agile Design

XP has introduced Pair Programming as an essential Agile practice. PP is a form of very direct cooperative work: “2 people working at a single computer”. This practice try to boost the most important activity in an Agile process, the coding, using the strongest form of direct collaboration inside the team. 

Remember that Agile uprising against traditional approaches (read Waterfall) has tried to restore the importance of the coding as the true ground to deal with the design and architecture. That was an uprising against the “paper architects”, that try to delimit themselves from concrete code and coding. 
Agile states that “Code is design”, that mean real design and real architecture are only the ones finally realized and validated by the real code and not the ones just drawn on paper.

Pair Programming it is a highly effective practices, but the remaining question if has enough coverage to describe the needed cooperative work inside the team.

Unfortunately,  the practice name it is interpreted too literally, only for direct coding activities. Yes, Agile has restore the importance of the coding in the overall development, but let think a little: what is the meaning of “Programming” from XP name?
In fact it is “Development”, where the effective programming/coding it is, of course, very important. An XP programmer it is, in fact, a multi-role developer involved also in planning, requirements, architecture, and design, coding and testing. A much better term could be then “Pair Development”. 
Also, the “pairing” could be the most common approach, but a “cooperative development” could occasionally include more developers.

The extensions points for high-cooperative work are: 

•  including all the development related actvities
• considering more than 2 developers, when pairing and direct collaboration it is alternated with solo-development 

Non-Solo Development

In DAD (Disciplined Agile Delivery), Scott W. Ambler has introduced the term and the practice of “Non-Solo Development” for this extended cooperative development approach. See: 

http://disciplinedagiledelivery.wordpress.com/2011/09/13/non-solo-development/\

http://www.ambysoft.com/essays/agileTesting.html#NonSoloDevelopment

From my experience (in various projects,/products /teams/development cases) this practice was very useful for very difficult complex cases of requirements clarification, finding best architecture and design decisions, in very difficult bug-fixing activities, or even in complex planning. 

There are two main dimensions for defining cooperative development:

• Type of activity 
• “coding” (working with on the code, while design decisions are also included)
•  other: requirements, architecture/design, testing, planning
•  mixed (combining related types)
•  Type of collaboration
•  “pairing” (usually 2 persons)
•  combined:  mixing solo-development with "pairing" (2 or more persons)

	“Pairing”	Mixed
Activity - “Coding”	Pair Programming	Non-solo Programming
Activity – Modeling	Pair Modeling	Non-solo Modeling
…	…	…
Activity - Mixed	Pair Development	Non-Solo Development

Existent examples

Some already existent Agile practices are in fact sub-parts of Non-Solo Development 

• Planning Poker, Sprint Planning (and any re-planning) -  are Non-Solo Development practices where the goal is planning, but the activity types are rather mixed (requirements, solution, planning)
• Model Storming (from DAD) - the main activity type is design

Conclusions…we need both

Conclusions - I

• The most generic category/term is “Non-Solo Development” and “Pair programming” it is just a particular case

Conclusions - II

• “Non-Solo development” cannot replace “Pair Programming” because that practice has a specific, very important role in Agile and software development. “Non-Solo development” just add other missing aspects of  cooperative work 
•  It is better to be always to distinct  (by name)
•  Pair Programming  - a practice that want to boost the core activity , the “coding”
• Pair Development – a practice where the overall development is performed mainly  by pairing
• Non-Solo Development – the generic case, when are combined more than one type of activity and are involved more than 2 persons

 

Some practical results

When we have used "Non-Solo Development" for the above mentioned activities the number of involved persons was 2-3 and sometime more. Some interesting results of the experiments:

•  Overall results are much better when we have involved 3 team members instead of 2 for the specific cases with increased difficulty
• The most experienced/skilled people have a bigger ability and desire to perform cooperative work (the others have still something to prove by solo-development…)
• Unfortunately, the resulted practice from team self-organization it is solo-development. The cooperative works need to be “protected” by the most experienced team members.
• The learning curve about product knowledge has significantly improved

For goals, techniques and examples see Part 2:

http://agileand.blogspot.ro/2014/09/upgrading-pair-programming-2-non-solo.html