Attention à l'agile !

Le manifeste agile définit les quatre valeurs fondamentales suivantes:

• L’interaction avec les personnes plutôt que les processus et les outils
• Un produit opérationnel plutôt qu’une documentation pléthorique
• La collaboration avec le client plutôt que la négociation de contrat
• La réactivité face au changement plutôt que le suivi d'un plan

Le travail essentiel à faire en agile est de travailler sur l'équipe. L'interaction avec les personnes correspond à la dynamique d'équipe. Le produit opérationnel est une valeur qui renforce la focalisation et mobilisation d'une équipe. La collaboration avec le client formalise la cohésion de l'équipe, le client fait partie de l'équipe. La réactivité face au changement est une valeur qui demande que l'équipe soit à un niveau de maturité élevé.

L'accompagnement d'une équipe vers l'agilité s'apparente plus à du coaching d'équipe qu'à du conseil ou de l'expertise sur la méthode. Même si les méthodes agiles introduisent le planning game, la standup meeting, le binômage, les rétrospectives, tous ces "outils" ne servent à rien s'ils ne sont pas introduit au bon moment. Les imposer peut créer une rétiscence au changement et surtout une déresponsabilisation de l'équipe par rapport à l'outil et donc une équipe qui n'est pas efficace.

Par exemple:

• une standup meeting peut être très vite un lieu où le chef de projet affirme son autorité plutôt qu'un échange entre membres de l'équipe
  
• un bilan d'itération peut devenir un espace de discussions conflictuelles ayant un effet démobilisateur sur l'équipe


• La rétrospective peut être un lieu d'échange qui ne débouche pas sur des actions, voir qui débouche sur des actions qui ne sont pas faites par la suite

Beaucoup de Scrum masters appliquent la méthode de façon stricte sans prendre en compte le système équipe et sa maturité, ce qui donne des résultats peu satisfaisants voir des situations instables, désorganisées où l'équipe n'assume plus des fonctions vitales comme le pilotage par exemple.
Je m'interroge sur l'application actuelle du coaching agile en France (celui que je connais) et à l'étranger. J'ai peur des dangers de la certification Scrum master où des coachs certifiés après 2 jours de formation sont amenés à accompagner des équipes vers l'agilité. Je m'interroge aussi sur le manque de cadre qui est donné à ce metier: "coach agile" - "scrum master" qui ne fait que décribiliser le métier. Le monde du coaching est aussi sujet à ces risques mais au moins un certain nombre de mesures ont été prises pour l'en protèger: Les formations durent 1 an, les coachs sont pour la plupart supervisés, le cadre d'accompagnement et un code déontologique sont définis. On ne s'improvise pas coach d'équipe comme on s'improvise pas coach agile.

Quand est ce que le métier "coach agile" sera considéré comme un métier à part entière, un métier d'accompagnement et pas comme un supplément au consultant, à l'expert technique, à l'architecte ?

XMLUnit

XMLUnit permet de tester unitairement la comparaison de XML et la validation des expressions XPath.

Exemple:

 @Test
 public void xmlEquals() throws Exception {
  XMLAssert.assertXMLEqual("<toto><titi></titi><tata></tata></toto>","<toto><tata></tata><titi></titi></toto>");
 }
 
 @Test
 public void xmlFile() throws Exception {
  Assert.assertTrue(XMLUnit.compareXML(new StringReader("<toto><titi></titi><tata></tata></toto>"),"<toto><tata></tata><titi></titi></toto>").similar());
 }

 @Test
 public void xmlXPath() throws Exception {
  XMLAssert.assertXpathExists("//toto/titi[name='rod']", "<toto><titi><name>rod</name></titi><tata></tata></toto>");
 }

Pour aller plus loin, Jettez un coup d'oeil au Tutorial

Dans le pom maven, ca donne ça:

  <dependency>
   <groupId>xmlunit</groupId>
   <artifactId>xmlunit</artifactId>
   <version>1.2</version>
   <scope>test</scope>
  </dependency>

Unitils++

J'avais écrit un article sur Unitils qui permet de simplifier l'utilisation des mocks avec les annotations. A l'époque où j'ai écrit l'article, Unitils utilisait EasyMock pour son implémentation des mocks, depuis la version 2, ils ont construit leur propre implémentation des mocks qui est beaucoup plus simple qu'EasyMock, de quoi faire comprendre facilement comment marche un mock en formation. Adieu Easymock, je t'aimais bien !

Un exemple:

@RunWith(UnitilsJUnit4TestClassRunner.class)
public class CalculatorWebServiceTest {
 @InjectIntoByType
 private Mock<Calculator> calculator;
 @TestedObject
 private CalculatorWebService webservice;

 @Test
 public void result() {
  // define mock behaviour
  calculator.returns(1).result();
  // assert result
  Assert.assertEquals(1, webservice.result());
  // assert mock invocation
  calculator.assertInvoked().result();
 }
}

Pour aller plus loin, le Tutorial d'Unitils est bien foutu.

Pour ceux qui veulent maveniser tout ça:

  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.4</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>org.unitils</groupId>
   <artifactId>unitils</artifactId>
   <version>2.2</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>cglib</groupId>
   <artifactId>cglib</artifactId>
   <version>2.2</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>asm</groupId>
   <artifactId>asm</artifactId>
   <version>3.1</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>asm</groupId>
   <artifactId>asm-analysis</artifactId>
   <version>3.1</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>asm</groupId>
   <artifactId>asm-tree</artifactId>
   <version>3.1</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>org.objenesis</groupId>
   <artifactId>objenesis</artifactId>
   <version>1.1</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>org.objenesis</groupId>
   <artifactId>objenesis</artifactId>
   <version>1.1</version>
   <scope>test</scope>
  </dependency>

Le changement

Parfois dans votre vie, vous changez de paradigme, vous prenez la pilule rouge comme dans Matrix et vous voyez une autre réalité, c’est ce qu’apporte la systémique.

Jacques-Antoine Malarewicz dans Systémique et entreprise énonce quelques axiomes du changement que j’ai repris ici :

• Il vaut mieux ne pas parler de changement : nous participons tous au changement sans le savoir, chacun de nous est le changement
• Le changement est un processus : chaque étape compte même si aucune d’entre elles n’est déterminante, c’est une succession d’essais et d’erreurs
• Le changement est un processus complexe : l’idée n’est pas de contrôler une situation, mais de la provoquer et d’accompagner. Un consultant qui prétendrait contrôler une situation voudrait dire qu’il se substitue aux dirigeants de l’entreprise
• Changement et non-changement vont de pairs : le mandant qui demande du changement va en général tout faire pour qu’il n’y ait pas de changement
• Changer l’état d’esprit : changer d’état d’esprit, c’est un changement de vision, de paradigme
• Le changement est saltatoire : le changement se fait par saut, avec de longues phases de stagnation
• Les solutions immédiates apportent moins que l’anticipation des changements ultérieurs
• Système complexe et changement: plus un système est complexe, moins il faut d’énergie pour y introduire un changement de part son instabilité, plus un système est simple plus il faut d’énergie de part sa rigidité
• Parfois la meilleure façon d’introduire du changement dans une situation est de la complexifier
• Il n’est de changement que spontané
• Le changement provient de la marge, quand il est annoncé il est immanquablement mis en échec
• Le changement est à la fois un processus de désapprentissage et d’apprentissage
• La compréhension et le changement : le changement n’est pas compréhensible, il est préférable de répondre au comment qu’au pourquoi
• Il n’est de véritables changements sans implications émotionnelles
• Le changement se produit au « bon moment », au consultant de le détecter
• Ce sont d’avantages des permissions que des solutions que le consultant extérieur doit pouvoir donner
• La place du passé : le passé est revu dans le présent
• Changer c’est rendre possible l’impossible
• Rien n’est jamais acquis

Simplicité ou complexité ?

Extreme Programming propose 5 valeurs fondamentales: communication, simplicité, feedback, courage, respect.

Je m'interroge aujourd'hui sur la valeur simplicité, en effet il n'est pas toujours si évident que la simplicité crée de la valeur. La théorie des systèmes nous prouve le contraire. Dans un projet, créer 2 équipes ajoute de la complexité et peut dans certains cas créer une dynamique et une efficacité globale plus forte. La simplicité est réductrice, d'une certaine façon la simplicité me fait penser à une procédure, à la rigidité. Si un observateur regarde une équipe qui a atteint le dernier stade de maturité d’Intelligence collective, il est probable qu'il pense que c'est le bordel, c'est tout sauf simple, impossible de voir qui est le chef, l'équipe semble désorganisée. En fait, c'est tout l'inverse, l'équipe a atteint un tel niveau de maturité qu'elle est capable de changer sa structure très rapidement pour s'adapter. La complexité est souvent source de créativité. Ici s’oppose le cartésianisme, philosophie rationaliste et la systémique, philosophie irrationaliste.

C’est probablement ici que réside toute la difficulté d’un consultant qui souhaite introduire les méthodes agiles chez son client : jouer entre simplicité et complexité.

Recadrage de point de vue

Le recadrage de point de vue ou aussi appelée changement de positions perceptuelles est une technique issue de la Programmation Neuro Linguistique (PNL) qui peut être utilisée pour gérer une situation de conflit ou plus conventionnellement de trouver un terrain d’entente. Dans le cas d’un conflit entre deux personnes, l’idée est de permettre à chacun des deux personnes de se mettre à la place de l’autre.

Dans l’idéal, le recadrage se fait en trois étapes :

1. Chaque personne joue son propre rôle auprès du médiateur
2. Chaque personne se met dans la peau de l’autre personne auprès du médiateur
3. Chaque personne se met en position dissociée ou appelée « Méta » auprès du médiateur

Les règles de départ de la médiation:
• Valider que les deux personnes souhaitent obtenir un terrain d’entente
• Énoncer aux deux personnes que pendant qu’une des personnes est questionnée par le médiateur, l’autre ne doit pas intervenir, elle a le droit de prendre des notes

Pour la position « Méta », j’utilise des figurines comme des playmobiles qui permettent de faciliter la position « Méta »

Ressources:
• Cas de coaching commentés

Modèle de Congruence

Gerald M. Weinberg a complété les positions d’incongruence de Satir par le modèle suivant : Soi, Autres, Contexte.

Quand nous agissons de manière congruente, nous agissons en prenons en compte consciemment ou inconsciemment des trois aires suivantes : soi, les autres, le contexte

• Soi : Nous devons prendre en compte nos propres besoins et capacités. Par exemple, des managers qui essayent d’assister à chaque réunion technique consommeront tout leur temps de disponibilité pour faire leur travail de manager ou même pour pouvoir avoir une réelle contribution technique
• Autres : Nous devons prendre en compte les besoins et les capacités des autres personnes. Par exemple si un développeur est complètement capable d’écrire du code lisible, mais refuse de le faire, alors tester ou maintenir ce code sera un fardeau
• Contexte : Nous devons considérer la réalité du contexte dans lequel nous opérons. Si un manager d’une start-up dépensait de l’argent comme si l’entreprise possédait demi milliard d’euros dans son budget, alors il est probable que l’entreprise échoue au-delà des qualités du produit qu’elle vend et de la performance de l’équipe

Ce modèle peut être lié avec les postures d’incongruence de Satir. Weinberg en ajoute une nouvelle posture qui est « Aimant – Détestant », les personnes en action ne prennent pas en compte le contexte

Le « Réprimandeur » ne prend pas en compte les autres : « Je suis tout, vous n’êtes rien »







La « Carpette » ne s’estime pas : « Je ne suis rien, vous êtes tout »







L’ « Hyper-raisonnable » ne prend en compte que le contexte, il ne ressent rien en soi et dans les autres







Le « Distracteur » ne prend ni en compte lui-même, les autres et le contexte.







« Aimant – Détestant », les personnes en action ne prennent pas en compte le contexte



Ressources:
• Quality Software Management Congruent Action