Sunday, August 6, 2017

Human organization: Collaboration First

Bad news first: Agile has failed to provide enough support for collaboration/collaborative work. Yes, we have some principles and in the mainstream Agile promote various meetings for collaborative work. Wait! Is the main support for collaborative work based on monthly and daily meetings? How Agile is that? How adaptive and lean is that?

Why will we need collaboration? If this is still a question, that is one of the causes of failure. The essence of the software development is to manage knowledge in conditions of complexity and incertitude.

Why is failed? More useful than a technical point of view will be a people point of view. 

Technical viewpoint for human organization

STANDARD APPROACH:  Individuals, teams, …enterprise
  • Team – main subject of software process/agile approaches: it is described team level process (product team)
  • Team at scale - Teams of teams, but reduced to collaborating teams working on the same product
  •  Enterprise -  In most of the cases it is reduced to DevOps, all other aspects being disregarded  
  • Agile Manifesto, XP, Scrum, SAFe, Unified Process and others do not cross too much these borders.

ENHANCED APPROACH - Individuals, teams, enterprise, community
  • Enterprise - Disciplined Agile goes beyond DevOps and offer guidelines for an Agile Enterprise
  • Community - too few references:
    • Manifesto for Software Craftsmanship principle: “Not only individuals and interactions, but also a community of professionals” ([B3])
    • Disciplined Agile: specify “Community” as superior level from Enterprise and encourage improving Enterprise level collaboration with Communities of Practice ([B1])

PROBLEMS- too few support
  • Most approaches do not cross the intra-team collaboration and process
  • Community level it is highly ignored and disregarded  

ARCHAIC WORK MODELS - What it is the explanation for this rather archaic modeling of human work and organization? First, software people have failed to better extract principles from their practices, where the best example (from original Agile methods) is the Pair Programming practice: it is fundamental to the process but is poorly represented on the principles level.

People viewpoint for human organization

RIGHT UNDERSTANDING - The technical viewpoint for the human organization it is inherently incomplete: we need to understand the principles about how humans organize their work, their life and evolve their culture. Humans civilization was developed by collaborative individuals, and this development was accelerated when they were organized in communities where they could share and persist their accumulated experience and knowledge.

CIVILIZATION GAME - We can have significant evolution problems when we do not enable the “civilization game” because of our too short vision.  We all playing in some games at various levels and timing. As Alistair Cockburn said, there are some “finite game games intended to end” as projects and deliveries, but also “Infinite games are those in which the players' primary intention is to keep the game going. Organizations, corporations, and countries play these. Their core purpose is to stay in existence.”([B6])  
The main mistake it is to consider as the final result of a human endeavor only the current work (the current game). That is not the way how humans have succeeded! What humans know to play better it is the long game, the “civilization game”, and they start winning (prehistory step to history) only when they boosted their collaboration and knowledge management with the first communities.

TEAM VS INDIVIDUAL -  Let’s start with the individual vs team difference that has already a pretty good understanding in the software world. Agile has tried to boost the work result by trying to setup a stable collaboration between a group of individuals – the team must be the same beyond the boundary of the release/project and it the “game” played is the “product development game”. The team will be able to reflect and improve its work in time based on knowledge and experience that does not disappear at the end of the release.
Anyways, common Agile thinking has significant flaws in an area where was expected to excel: managing knowledge work where people first aspect it is so important. 
TEAM COLLABORATION PROBLEMS - The first problem is not the one related to collaboration beyond the team boundary, but the one that starts with collaboration inside the team. Here are some aspects:
  • Na├»ve reduction of collaboration to meetings-only: iteration meetings and daily coordination meeting. Most exposed to these problems are teams that go beyond Scrum.
  • No practices between high-level ceremonial meetings and pair programming. Only Disciplined Agile fill this gap with non-solo development guidance and more core practices ([B7]) 
  • Not enough guidance for pair programming as collaboration and knowledge management backbone. Not even XP does not provide such guidance and principles levels support.
  • No method and no manifesto do not explicitly put collaborative work in the heart of software development (even Disciplined Agile, that has good-enough guidance and practices for these aspects). There is one exception: Alistair Cockburn “Heart of Agile” ([B9]), that put “Collaboration” as one of the four main aspects of (agile) development: Collaborate, Deliver, Reflect, Improve   
The first recommendation is to look more on these great exceptions:
  • Disciplined Agile for practices and guidance about non-solo development
  • Cockburn’s “Heart of Agile” to rethink Agile principles giving the right place to collaborative work 

BEYOND THE TEAM BOUNDARIES - The second problem is to understand that human work model cannot be reduced to team boundaries. All the advantages of team versus non-collaborating individuals are also advantages of collaborating teams (community) versus non-collaborating ones.
  • Better results: more “processing power”, experience, and skills are put together.
  • Increased robustness in skills, experience and knowledge
  • Faster improvement: exceptional results and improvements are made available, we share more good things to more people.
  • More robust improvement. For example, teams are vulnerable when lost experienced team members. For an organization that works as a community, it is easier to regenerate one team skills. 


Collaboration will boost any human organization and it is a fundamental factor in the evolution of the human civilization. Put the current work in the context of larger evolution.
People first: individuals and their collaboration in performing teams and performing communities. Individuals must be safe inside their teams and communities When we apply people first principle the most effective and efficient way is to start with collaboration practices.


  • Team level – go beyond meetings and use Non-Solo Development practices. Try to use XP Pair Programming and Disciplined Agile non-solo work practices for Envisioning, Look Ahead and Just in Time.  
  • Continuous retrospective - The logic it is expressed by XP “To maximize feedback, reflection in XP teams is mixed with doing.”. Will work only if the above mentioned collaborative practices.   
  • Stakeholders – go beyond Product Owner or On-Site Customer and use Active Stakeholder Participation ([B7]).
  • Enterprise as a community – start with Disciplined Agile Communities of Practices, Reuse Engineering, collaboration between Enterprise Architects with the teams and continues with more profound teams’ level collaboration.    
  • Connect with external communities – encourage organization members to be active members of various professional communities.
  • Improvement use “Collaboration first” as the most effective & efficient way to realize the “People first” principle  
  • Collective ownership – setup as a goal and use collaboration as a main driving force


The axe of progress is: individual, team, teams of teams, communities (See Principle for a community of professional)


Notes - other terms
  • cooperation - sometime it is perceived with this understanding "more or less active assistance from a person, organization", that is a small/patial part from a full active collaboration 
  • communication - it is included, but is just a part from what we understand by collaboration.         


Bibliography and References

[B1] Disciplined Agile - Principle: Enterprise Awareness by Scott Ambler
[B2] Agile Manifesto
[B3] Manifesto for Software Craftsmanship
[B4] Extreme Programming Explained: Embrace Change, Second Edition
  • By Kent Beck, Cynthia Andres, Addison Wesley Professional, November 16, 2004
[B5] Non-Solo Development by Carson Holmes 
[B6] Agile Software Development: The Cooperative Game, Second Edition
  • By Alistair Cockburn, Addison Wesley Professional, October 19, 2006
[B7] Disciplined Agile, Agile Modeling – Non-solo Development practices 
  • Model with others -  
[B8] Principles for a community of professionals
[B9] Heart of Agile