"Upgrading" Pair Programming (2) - Non-Solo Development

Notes

.

•  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
• Non-Solo Development it is Agile practice explicitly included in DAD - Disciplined Agile Delivery method
• Here it is presented a custom experience with this practice
• See previous : http://agileand.blogspot.ro/2014/09/upgrading-pair-programming.html  

Introduction

Non-Solo Development it is an Agile practice that goes beyond programming/coding ("Pair Development") and could combine pairing and solo-development techniques in a mixed approach.

Pair Programming and any other Pair Development techniques could bring significant advantages on fulfilling some process goals as: better decisions, collective ownership, knowledge sharing and fast learning. Anyway, many times, the decisions to adopt or not the pairing it is seen as an option between:

• Full-time Pair Programming/Pair Development 
• Solo-Development (no pairing)

That it is a false and harmful dilemma.

We will see later  that:

• It is mandatory to use, at least for critical decisions, a mixed approach of Non-Solo Development, in order to not jeopardize some significant process goals
• Discipline it is a major factor for getting good results from cooperative development  

 

Non-Solo Development - goals and techniques

.

The main goals of Non-Solo Development could be:

• increased capability of taking decisions
• sharing knowledge and collective ownership
• effective learning

N-SD could be successfully in combining pairing with solo development only if the most important parts related to these goals are realized. For example, pairing it is mandatory for taking the most important decisions.

In fact, there are 3 techniques that could be used:

• Pair Development 
• Solo Development 
• Simple Conversation (just inform the others, and if is necessary, switch to Pair Development)

 

Comparing mixed approach with pure pairing 

. 

(Mixed - combine paring with solo development and conversations)

Pairing advantages

• force/ensure collaboration (built-in discipline)
• larger channel of sharing  the information 

Mixed approach advantages

• more flexibility on using resources versus concurrent tasks
• enable sometime necessary solo-development
• enable direct collaboration beyond pairing: 3 or more persons (up to "mob" development) 
• seems to be more "natural" 

IMPORTANT: Mixed approach is more flexible , but it is very fragile in case of  poor collaboration  discipline. 

 

Pairing/Direct collaboration need

. 

When pairing and direct collaboration are highly desired? When the work is associated with critical parts related to the goals:

• most important decisions 
• sharing critical info
• learning critical issues

Because of that, we can evaluate some significant practices versus N-SD approach:

• All the practices
• N-SD it is mandatory at least as a mixed approach

• Architecture envisioning , Look Ahead Modeling
• Some of the most important decisions related to the solution - direct collaboration must be also used
• Model Storming 
• Need pairing at least to validate and inform
• The practice from AM - Agile Modeling suppose mostly the direct collaboration
• Requirements clarification
• Need pairing at least to validate and inform
• Coding
• Need paring at least for significant decisions: transforming to code the ones from the envisioning and modeling and for the ones taken directly in the code 

For some of the mentioned practices, see http://agilemodeling.com/.  

 

Mixed approach example - discipline versus problems

.

A, B, C, D are agile developers involved in a software project. Here it is possible disciplined  sequence of activities based mainly on Non-Solo Development and inspired from a real case (Where A,B or A,B,C means paring/direct collaboration):

• A - Requirements clarification with the customer
• A, B -  Requirements analysis
• A - document requirements 
• A, B -  Requirements clarification with the customer
• A,B, C - Requirements conversation 
• A - document requirements
• A, B - Architecture Envisioning
• A,B, C - Architecture conversation
• B - Look Ahead Modeling
• B, C - Look Ahead Modeling
• A,B,C  - Design conversation 
• B - Solo Programming
• B, C- Pair Programming 
• B - Solo Programming
• A,B, C - Programming Conversation

The above sequence could have fulfill all the listed goals: capability, sharing, collective ownership ans fast learning.
Let consider another sequence:

• A - Requirements clarification with the customer
• A - Requirements analysis
• A -  document requirements, but not saved in the repository
• A, C - Requirements conversation 
• A - Architecture Envisioning
• A, C - Architecture conversation
• A - Look Ahead Modeling
• C - Solo Programming

For this sequence, with significant less discipline on adopting direct collaboration on critical parts, we have the following problems:

• B it is totally excluded from collective ownership and C only partial
• Most of the important decisions have been taken by a single person 
• There is no sharing for a lot of information 
• B and C will need a significant effort to recuperate the gaps in their knowledge

Some conclusions

• Full paring could be optionally, but direct collaboration, at least for critical development decisions, is mandatory for good results on both short and long terms
• Discipline on adopting cooperative development it is essential  
• Solo-development hast its place in the process, but individualism has not