Let's Self-Organise: the prerequisites for real self-organisation

It is common to see teams that are not allowed to self-organise, and few other teams that do it in total anarchy.

The challenge is a self-organisation that works. And that requires also a well functioning self-regulation and useful barriers.


Here follow the 3 fundamental prerequisites for teams self-organisation:

1 - Let people do it
2 - Self-Regulate
3 - Boundaries and barriers

And here are the remaining prerequisites.

Dealing with uncertainty, unknowns, risks and change


More traditional approaches to projects management, products development and software development life cycle management focus on what is

known & knowable

Everyone have different innate abilities and preferences among

reflection and planning Vs reaction and adaptation 

and different levels of tolerance to

 uncertainties, risk and change
 
while what matter is a balance and a tolerance that is good for the specific project/product and context.
 
What practices and skills are useful to deal with unknowns, how much risk and uncertainty is convenient for each specific product/project, what is a good balance between planning and reaction/adaptation in each specific context ?

Are you taking advantage of your Distributed Version Control System? (Comparing traditional VCS with DVCS)


At first glance DVCS (i.e. Git, BitKeeper, Mercurial, Baazar, etc) main advantage seems related to better branching and merging. Especially for those who experienced the pain of big merge-conflicts of long lived branches (*) with a traditional VCS (i.e. SVN, Perforce, TFVC, etc).



In reality DVCS born to serve distributed remote teams. This is the main point, the distinctive characteristics originate from it and this is why DVCS can do that with simplicity and flexibility.


 
Here are 2 key distinctive characteristics of DVCS:
  • Connection disruptions: when the connection between 2 remote teams goes down, each team member can continue to work autonomously as usual (**) because has the local full copy of the repository including the whole history and everything else that is needed to be autonomous and fully operative locally

  • Repository disruptions:
    • when a problem affect the central repository: a problem can affect the centralized repository and who can fix the problem is not reachable/available (i.e. because is working in a very different time-zone). Again with DVCS each team member have a self-contained first-class full copy of the repository that make him/her fully operative locally.
    • when a remote commit broke the build: a remote team member can commit code with problems (i.e. broke the build, cause merge conflicts, etc) and then go offline, can be not immediately reachable/available (i.e. because is working in a very different time-zone). DVCS enable mechanisms like i.e. the 1-click pull-requests that give a way to deal well with this kind of problems.

 

A 3dr key distinctive characteristic of DVCS is specifically related to open-source projects:

  • Anyone is enabled to and can easily fork a repository to fix a bug or add a feature, and then make a pull-request. This enable and support the spontaneous formations of teams around the open-source project.

 

All this is explained and expanded in chapters 3 and 14 of the book Continuous Delivery, Addison Wesley.

 

How are you taking advantage or your DVCS? Are you exploiting the 3 key distinctive characteristics?
Are you exploiting it in other unconventional creative ways?

 

(*) A root cause for the pain of merging long lived branches is related to the fact that the probability of merge conflict grows faster then linear (polynomially/exponentially depending on the structure of the code-base) with the lifetime of the branch.
Another root cause is that
the most difficult merge-conflicts require semantic diff and merging while the main diff and merge tools are text based.
None of these root causes are currently addressed directly by the DVCS.


(**) The impact of a connectivity disruption to Continuous Integration servers and i.e. Tests environments is not automatically resolved by the DVCS. A DVCS enable to easily setup a local autonomous CI environment to continue to work locally until the connectivity is restored.  

 

[OT] Utøya, 22 Luglio 2011 - 22 Luglio 2012

La storia di un evento traumatico avvenuto nei paesi nordici. E l'inaspettata reazione di un popolo, che riempie di sorpresa e consola. Ridà dignità e significato alle parole Uomo e Politica. Clicca il titolo per continuare a leggere.

Agility: definition, characteristics, advantages and inhibitors





Agility focus on individuals’, teams’ and organizations’ very practical characteristics and abilities that make them Agile.


I find it as a natural companion to the Manifesto for Agile Software Development,
and its origin and applications include areas as enterprises and military endeavors
beyond software development.








Agility has been defined, studied, experimented and documented by David Alberts and Richard Hayes between 2003 and 2011.



The Definition of Agility
Agility is a new way of thinking about and preparing for the
unanticipated,
is the capability to successfully effect, cope with, and exploit changes in circumstances.

Agility is the degree to which one can maintain the level of performance after a change in the circumstances.
 



The key characteristics of Agility

Continue to read here...



______________________________________________________________________________________
References
Studies, experiments and the source of this content can be found at:


Read Also