"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 

"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