(luKa)

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:

• The Agility Advantage: A Survival Guide For Complex Enterprises and Endeavors;
  David S. Alberts; 2011
  
• Power to the Edge: Command...Control...in the Information Age;
  David S. Alberts and Richard E. Hayes; 2003

Read Also

• The dimensions of Agile
  
• Current state of Agile values and practices evolution
  
• On understanding software agility from a social complexity point of view

The key characteristics of Agility

1. Flexibility: the ability to try and employ multiple ways to succeed, when the preferred response does not work, and the capacity to move seamlessly between them; learning more than one way to do things
   
   
2. Adaptability: the ability to change work processes and the ability to change the organization; the ability to recognize changes in the environment and in shifting priorities and rapid change, identify the critical elements of the new situation and trigger changes accordingly
   
   
3. Responsiveness: the ability to react to a change in the environment in a timely manner; it involves speed and also the consideration of when would be the appropriate time to act
   
   
4. Versatility: allow an entity to continue to operate effectively as is, despite changes in circumstances or conditions
   
   
5. Resilience: the ability to recover from or adjust to misfortune,damage, or a destabilizing perturbation in the environment; with the ability to repair, replace, patch, or otherwise reconstitute lost capability or performance, at least in part and over time
   
   
6. Innovativeness: the ability to do new things and the ability to do old things in new ways, accomplish something—a discovery or invention when there is no known adequate response for the situation .
   

Contexts where Agility lead to better performances

Continue to read here...

________________________________________________________________

Back to the start

Agility: definition, characteristics, advantages and inhibitors 1/4

Contexts where Agility lead to better performances

Agility is a significant competitive advantage in term of performances and for the possibility to succeed in contexts with those elements that become more common in the current Information Age:

• The environment is highly connected with frequent interactions that cause a diminished capacity to predict.
• There is a condition of time pressure because the amount of information and information processing required exceed the available time.
• A certain level of shared understanding is needed to succeed in important endeavors because the high level of interdependency.
• The nature and extent of the uncertainty associated with a situation affects our ability to both formulate the problem and find an acceptable solution. And at times we are uncertain about how uncertain we are.
  
• There exists rare, very low probability events that can occurs and bring great opportunities or risks, together with huge consequences.
  

Factors that inhibit Agility



________________________________________________________________

Back to the start

Agility: definition, characteristics, advantages and inhibitors 1/4

Factors that inhibit Agility
Those environmental and personal factors can inhibit the ability to develop and use agility:

• Restrictions on access to information
• Confidence that the best approach in already known and always knowable
• Intolerance to risks and uncertainties
• Lack of diversity
• Resistance to change
• Passive reliance on approved planning, models, methods
• Optimized process and investment with lack of basic research and experimentation and exploration

And also:

• Fear of failure and disincentives
• Lack of proper education and training
• A model of the reality that is over simplistic
• A narrow view of self
• Stove-piped organizations

 

 

________________________________________________________________

Back to the start

Agility: definition, characteristics, advantages and inhibitors 1/4

Ciao Gian Maria,

commento qui il tuo post perche' dai commenti il sito mi risponde con un bel 500 !
 
ti condivido queste riflessioni sul argomento che ho approfondito recentemente.
Per chi e' interessato ci sono due capitoli sul tema nel libro Continuous Delivery di Addison Wesley (sul Cap.3 e Cap.14).


I DVCS come Git (o BitKeeper, Mercurial o Baazar, e altri ancora) nascono e sono preferibili ai tradizionali VCS nei casi di team di sviluppo distribuiti remoti, ancora di piu se in time-zone differenti (per cui puo succedere che il team che ha il controllo del repository o quello da cui viene un check-in che sta creando un problema puo essere offline quando serve).


Ecco i 2 aspetti chiave dei DVCS per team distribuiti remoti:

• in caso di temporanei problemi di linea/connessione ogni team (ognuno) puo continuare a lavorare in locale perche' dispone in locale tutto il repository con tutta la storia
  
• e' piu facile gestire i casi di problemi (es. build rotta, merge con errori, etc.) causati da check-in remoti da team (dev) che ora non sono immediatamente raggiungibili, ad esempio lavorando sul proprio repo locale fino a quando il problema e' risolto o aggiungendo dei contolli prima di fare il merge da team/dev remoti che sono offline (come ad es. le pull-requests in bitbucket e github).

Il terzo aspetto chiave e' per progetti open-source:

•  abilita la formazione spontanea di team perche' chiunque ha un interesse a fixare un bug o aggiungere una feature puo fare un fork, implementare la cosa e poi mandare la pull-request con il lavoro fatto. Niente a che vedere con il laborioso invio di patch via mail che si usava una volta.

Sul Branching e il Merging
E' facile fraintendere l'utilita dei DVCS all'inizio, il punto di forza sembra in branching e il merging evoluto che in realta' serve per gestire meglio il pull dei commit dai vari repository distribuiti remotamente.
Creare branch ad eccezzione di casi rari e per tempi molto brevi resta un antipattern, causato da cattiva modularita' della code-base o da una carenza di buone pratiche di sviluppo. In quei casi usare i branch va nella direzione contraria della Continuous Integration che e' considerata una pratica moderna necessaria per lavorare in modo professionale, in team Agili e non. 
I Dev e i responsabili di Change Management che fanno questo errore sono gli stessi che abusano dei branch anche nei normali VCS quindi non considererei questo un punto a favore dei DVCS o dei VCS.


Alcuni patiti di git preferiscono la linea di comando e anche per questo all'inizio puo sembrare piu complicato di quanto in realta' e', esistono GUI anche per i DVCS che gli rendono molto piu semplici da usare nella stragrande maggioranza delle situazioni.






Nel post confronti TFVC con i DVCS/Git. Aggiungo questi punti alla tua lista :

• DVCS/Git supporta scenari di team distribuiti meglio di VCS/TFVC
  
  
• Con DVCS/Git ogniuno ha la storia completa del repo in locale. In alcuni casi queste possono essere info sensibili, in altre alcune aziende tradizionali hanno la filosofia di limitare l'accesso alle informazioni e questo potrebbe essere un problema e in questi casi VCS/TFVC sono preferibili. Per aziende piu moderne che ritengono sia un valore dare accesso ai dipendenti alle info, questo e' un vantaggio supportato dai DVCS/Git.
  
  
• DVCS/Git permette di abusare dell'uso distribuito dei branch&merge (tipo fare il merge in locale tra 2 dev prima di fare il push al repo principale) e della possiblita' di cambiare la storia in locale (es. riordinare i commit locali o cambiare il commento del commit locale) e questo non e' possiblice coi VCS/TFVC. Quindi aziende che sono piu inclini al controllo, VCS/TFVC non permette queste cose e per questo potrebbe essere preferibile.
  
  
• Il Plugin TFVC per VS e'  integrato a VS e questa e' una caratteristica distintiva primaria di TFS (anche se esistono altri modi di accedere a TFS e TFVC senza plugin ne VS).
  Di conseguenza ci sono dipendenze di compatibilita' tra versioni di TFVS plugin e Visual Studio e TFS e .NET Framework (vedi ad es. la Compatibility Support Matrix qui). Cambiarne la versione di uno puo richiedere di aggiornare a domino le versioni anche degli altri componenti (un esempio qui), in alcuni casi  richiedendo per un certo tempo lo stop della linea di produzione.
  In alcune realta aziendali serve poter fare modifiche graduali e incrementali al ambiente di sviluppo senza interrompere lo sviluppo, per quelle aziende TFVC con plugin non e' adatto.
  
  
• TFVC e' molto simile a Perforce in fatto di funzionalita e supporto dei tool, il secondo ha scalabilita e prestazioni superiori adatte anche a organizzazioni molto grandi