Le monde est une scène

Quand je parle autour de moi du projet du référentiel des pratiques Agiles, une question revient à l'occasion: "Est-ce que tu vas parler des rôles du Scrum Master, du Product Owner?.."

Je ne suis pas tout à fait à l'aise avec ces notions de "rôles", en tout cas avec l'importance qu'on leur donne. En y réfléchissant bien, mon raisonnement repose sur un principe simple; je l'ai déjà énoncé en passant mais il mérite que j'insiste:

Ce qui compte surtout pour le succès d'un projet, c'est ce que les gens font.

Il existe bien sûr des contraintes: les journées de travail ne faisant (en principe) que 8 heures, une même personne ne peut pas tout faire. On doit bien se spécialiser afin de mener certaines activités de façon compétente; le temps que j'investis à devenir un meilleur développeur est autant de temps que je ne passerai pas à acquérir des rudiments de graphisme.

Le principe de Ricardo ou principe de l'avantage comparatif me pousse à m'associer à une personne compétente dans le domaine graphique, et montre que je peux y trouver un avantage même dans le cas où je suis un peu doué en graphisme. (Ce qui est contre-intuitif dans le principe de Ricardo, c'est l'idée que même si je suis strictement meilleur en développement ET en graphisme qu'une autre personne, m'associer avec elle en nous spécialisant chacun dans un domaine peut quand même être intéressant pour chacun des deux.)

Mais ce qui vaut en analyse économique ne vaut pas nécessairement dans un projet. Par exemple les acteurs d'un projet ne travaillent pas chacun dans leur coin: ils ont besoin, chacun, de comprendre ce que font les autres acteurs. Trop de spécialisation peut engendrer ce que j'appelle le "syndrôme du bébé", d'après une conversation entre parents, par exemple au supermarché: "Dis donc, le bébé n'est pas avec toi?" - "Ah non, je croyais qu'il était avec toi..." - "Alors où est-il?" Transposé au monde du projet, cela donne des tâches importantes qui ne sont pas réalisées parce que chacun pense qu'elles relèvent de la responsabilité de quelqu'un d'autre.


Prenons donc l'exemple d'un des nouveaux "rôles" Agiles les plus emblématiques, celui du Scrum Master. Le Scrum Master est chargé:

• de lever les obstacles signalés par l'équipe lors des réunions quotidiennes ("mélées")
• d'être un facilitateur lors de ces réunions
• de rappeler à l'équipe les fondamentaux théoriques de Scrum
• de protéger l'équipe des interruptions

Sur le papier, ce rôle est cohérent. Mais imaginez la situation suivante: dans votre équipe, une personne est très douée pour agir et communiquer vers l'extérieur; une autre est très à l'aise pour animer des réunions. A votre avis, vaut-il mieux:

• donner à l'une de ces personnes les quatre responsabilités ci-dessus, au risque que deux d'entre elles soient moins bien assurées, ou
• jeter aux orties la définition stricte du rôle du Scrum Master, et répartir ces quatre responsabilités entre les deux équipiers en fonction de leurs talents?

 Je penche, vous l'aurez compris, pour la seconde solution.

A mon sens un rôle formellement défini n'est qu'une "checklist", un rappel utile d'un certain "lot" d'activités ou responsabilités dont il est important de garantir que chacune est assurée par au moins un membre de l'équipe, afin d'éviter le "syndrôme du bébé". La spécialisation a du sens au niveau des responsabilités isolées, pas au niveau de rôles agrégeant plusieurs responsabilités.

Il existe, bien sûr, des corrélations. Un développeur compétent est probablement une personne plus apte à se charger d'un travail de rédaction technique qu'un graphiste compétent. Mais c'est seulement une tendance (peut-être même pas une tendance très marquée). Lorsqu'il s'agit de se répartir des tâches précises, identifiées, au sein d'un projet particulier, entre des personnes réelles, dans toute leur singularité, la notion de rôles doit passer au second plan. C'est la place que je compte leur accorder dans le référentiel, sauf à entendre des arguments convaincants bien entendu!

Agilité en kit: les outils de montage

Une autre raison me pousse à vouloir donner un coup de projecteur sur les pratiques Agiles, plutôt que sur les étiquettes Scrum, XP, etc. Chacune de ces différentes approches est présentée comme un tout: un ensemble de pratiques qui vont donner un bénéfice maximal si on les met en place ensemble.

Oui, mais vouloir passer d'un seul coup de "pas Agile du tout" à "tout Scrum" ou "tout XP" est, du point de vue humain et managérial, une situation très rare. Elle peut se produire lorsque les équipes sont en crise et sont prêtes à tout pour en sortir; ou encore lorsque des gens se retrouvent pour un nouveau projet qui ont déjà utilisé Scrum ou XP précédemment. Mais la situation encore la plus courante est celle d'équipes et d'entreprises qui veulent bien mettre un pied dans l'eau, mais pas plonger la tête la première.

Une première idée est d'appliquer la logique Agile à la transition elle-même: "Adoptez la pratique qui vous semble la plus importante, puis itérez". Ce type de conseil a un intérêt limité, d'une part parce qu'il n'est justement pas évident de déterminer quel outil "agile" est pertinent dans telle ou telle situation, d'autre part parce qu'une seule pratique utilisée en isolation peut avoir des bénéfices marginaux. Enfin, il existe un risque que le discours consistant à dire "cette pratique ne s'applique pas dans mon contexte" serve de prétexte à ne pas se remettre en question.

Pour éviter les écueils du type "Culte du Cargo", nous voudrions une démarche qui permette de déployer, dans un contexte donné, et à diverses étapes d'un projet, les pratiques agiles les plus pertinentes. Avec au départ 'un "kit" de pratiques, et des outils permettant un assemblage cohérent, on va fabriquer une méthodologie sur mesure.

Le premier de ces outils est la modélisation du processus de développement.

En fait de modélisation, on pratique trop souvent ce que j'appelle le "modélisme": une activité somme toute assez prenante, et qui constitue un excellent passe-temps, mais qui ne produit pas des résultats très constructifs. Ma définition de "modèle" est la suivante: un modèle est une représentation d'une situation réelle, qui sans y être fidèle dans tous les détails est utile pour répondre à des questions concernant cette situation.

Les modèles les plus utiles ne sont pas en UML - voyez ci-dessous pour une notation plus simple. Les modèles les plus utiles ne sont pas nécessairement visuels - une ou deux équations, une phrase de texte peuvent utilement servir de modèle. Et les modèles les plus utiles ne sont pas nécessairement des représentations d'une architecture ou d'un logiciel. On peut également modéliser utilement le processus de développement lui-même.

Un exemple. Un des principes Agiles consiste à tester tout au long du projet: on a remis en cause l'approche classique consistant à laisser le test pour la fin. La base de cette critique est une réflexion sur les modèles qui conduisent à prendre cette décision. Dans un modèle trop simplifié, on part du principe que la production de code aboutit à une certaine production de défauts, et qu'il suffit une fois le code produit de procéder à l'élimination de ces défauts:

 Si on croit cela, on va légitimement remettre les tests à la fin du projet. Le diagramme ci-dessus, dans une notation appelée "diagramme d'effets", permet de rendre explicite cette supposition, et on peut le comparer avec le diagramme suivant:

Dans ces diagrammes on s'intéresse aux caractéristiques quantitatives des situations: une bulle est une quantité susceptible, si on le voulait, d'être mesurée. Une flèche est un lien de cause à effet. Lorsqu'elle est ornée d'un "+", l'effet et la cause vont dans le même sens (si l'un augmente, l'autre augmente, et vice-versa); ornée d'un "-", cause et effet vont dans le sens opposé. On doit ce type de diagramme à Peter Senge et Jerry Weinberg.

 Je dis "susceptibles d'être mesurée" parce que ces diagrammes donnent surtout des résultats qualitatifs. Il existe des outils permettant de transformer des diagrammes de ce type en simulations numériques. Mais dès que l'on fait intervenir tous les facteurs qui rendent l'analyse plus réaliste, la complexité des modèles rend cette analyse laborieuse, alors qu'on peut obtenir de très bons résultats sur la base d'une analyse quantitative. Ainsi on voit sur le second diagramme que le coût du test est fonction de plusieurs variables, notamment la taille du projet et le délai entre réalisation et test: on rend compte du fait que plus il s'écoule de temps entre l'introduction d'un défaut et sa mise en évidence par le test, plus il est difficile à corriger. Comme les effets de ces deux variables se renforcent, on peut s'attendre à ce que le coût du test augmente plus que linéairement avec la taille des projets.

Les paramètres qui nous préoccupent sont souvent les mêmes d'un projet à un autre: taille du projet, taille de l'équipe, délai, productivité, qualité, etc. Par contre les influences qui s'exercent sur ces paramètres peuvent être très différentes, selon le type d'entreprises (SSII, éditeur, industriel), le secteur d'activité (finance, scientifique, commerce) et autres caractéristiques du contexte. Et, toujours en fonction du contexte, la priorité accordée à ces différents paramètres peut être très différente. Chez un éditeur on pourra privilégier le respect des délais par rapport à la qualité, dans un contexte industriel l'inverse peut se produire; dans la finance de marchés les performance peuvent être le critère dominant, etc.

Par conséquent, il faut s'attendre à ce que chaque projet soit régi par un modèle différent. L'idéal est de réunir plusieurs personnes concernées par la situation et chercher à explorer, dans une session de type "brainstorm", les liens de causalité entre les différentes variables. Ensuite, on cherche à trouver des interventions: des modifications dans la façon habituelle d'aborder le projet qui, en modifiant le sens d'une relation existante, en supprimant ou créant de nouvelles relations, aient une influence favorable sur les paramètres qui nous préoccupent sans pour autant avoir d'influence néfastes. (C'est souvent là qu'est l'os...)

Souvent, on ne trouve une réponse efficace qu'après avoir obtenu un "déclic" qui permet de réduire le modèle à un nombre moins importants de variables. Les pratiques agiles sont autant d'interventions permettant de modifier la structure des influences mutuelles entre les paramètres du projet. Ainsi la pratique du développement par les tests modifie profondément l'interaction modélisée ci-dessus: pour une bonne partie l'activité de test a lieu avant le développement, la valeur moyenne du paramètre "délai entre l'introduction d'un défaut et le test permettant de le détecter" est réduit de plusieurs ordres de grandeur.

Ces diagrammes d'effets font partie des outils utilisés par les meilleurs consultants étiquetés "Agiles" pour s'assurer de l'efficacité de leurs interventions. Pour être efficace avec une approche Agile il faut non seulement très bien connaître les mécanismes "typiques" qui régissent les projets de développement, mais encore être capable d'analyser finement les variations de ces mécanismes propres à un contexte donné. La simple connaissance des pratiques ne suffit pas: il faut savoir pourquoi et comment elles fonctionnent, mais aussi quand elles sont susceptibles de ne pas fonctionner.

Pratiques agiles: précautions d'utilisation

Attention, terrain miné. J'ai dit précédemment que pour tirer parti des approches Agiles, il était plus efficace de s'intéresser en priorité aux pratiques: à ce que font les équipes et les individus; les principes servant plutôt de règles générales pour vérifier la cohérence de ces actions.

Pour autant, il y a un risque majeur à trop se focaliser sur ces pratiques: celui de tomber dans l'imitation, ce que l'on connait sous le nom de Culte du Cargo, en référence à ces tribus mélanésiennes qui, durant la seconde guerre mondiale, voyaient les militaires japonais et américains construire des pistes d'atterrissage et des tours de contrôle. Activités systématiquement suivies de l'arrivée d'avions chargées de cargaisons de vivres et autres objets sophistiqués. Lorsque la guerre cessa, et faisant le lien logique entre l'activité et son résultat, certains chefs tribaux promirent à leurs ouailles la reprise des livraisons: il suffisait pour cela... de construire des répliques en bambou des tours et des pistes!

On aurait tort de se moquer, tant on retrouve souvent la même attitude au sein d'équipes et d'entreprises dans le domaine du logiciel. "Chez Goopple les équipes utilisent des pratiques Agiles: du TDD, des rétrospectives, des itérations. Et regardez leur valorisation en bourse! Chez nous aussi, faisons du TDD, des rétrospectives et des itérations. On devrait avoir les mêmes résultats." (De même  - ça fait déjà quelques années que j'en parle - pour l'approche "classique" des projets de développement: les boîtes qui marchent bien font un contrat, puis un cahier des charges, puis une conception technique détaillée, puis implémentent et testent, alors on va faire la même chose. Ainsi se perpétue une "méthode" qui, en réalité, ne fonctionne pas.)

L'utilisation judicieuse des pratiques et des compétences proposées par la communauté Agile exige d'abord de bien connaître les mécanismes par lesquels on produit du logiciel, puis de comprendre en quoi les pratiques qu'on souhaite utiliser modifient ces mécanismes.

Si l'on ne se préoccupe pas du tout de la question sous-jacente, "qu'est-ce que c'est, finalement, que cette activité qui consiste à produire du logiciel", on se retrouve dans une situation analogue à celle des tribus Mélanésiennes, qui voient arriver "magiquement" du cargo mais ignorent tout de la formidable complexité du système industriel qui, à des milliers de kilomètres, est responsable de la production de ces richesses.

Voici donc, en version courte, la notice d'utilisation des pratiques et compétences Agiles:

On déploie une pratique ou une compétence dans le but d'en obtenir des bénéfices bien identifiés; l'hypothèse selon laquelle nous obtiendrons ces bénéfices doit être justifiée par un mécanisme supposé (on pourrait aussi dire une modélisation de l'activité de développement) qui nous permet de penser que cette pratique aura les bénéfices attendus. L'utilisation sur la durée de cette pratique ou compétence doit être soumise à une vérification empirique, si nous n'obtenons pas, dans un délai préalablement établi, les bénéfices attendus d'une façon que nous pouvons un tant soit peu objectiver, alors il nous faudra, d'une part abandonner ou modifier cette pratique, d'autre part remettre en question notre compréhension des mécanismes.

(Voici, soit dit en passant, pourquoi je suis très peu favorable à un mouvement actuellement en vogue visant à "étendre les approches Agiles au-delà des technologies de l'information". Notre compréhension de la façon dont fonctionne le développement logiciel ne s'applique certainement pas à l'identique dans d'autres domaines; faire la supposition que des pratiques qui "marchent" bien, dans le domaine bien précis des technologies basées sur du logiciel, vont marcher aussi dans d'autres domaines, n'est pas sans rappeler le Culte du Cargo.)

La question "qu'est-ce que c'est que la production de logiciel" est évidemment très vaste, mais on ne peut pas en faire l'économie. Pour être utile, la description des pratiques Agiles doit faire le lien entre la nature de cette activité d'une part, les "lois" et les contraintes qui la régissent, et d'autre part les bénéfices attendus et le raisonnement qui nous laisse penser que ces pratiques apporteront ces bénéfices.

Principes, concepts, pratiques et compétences

Voici résumés dans le titre, et par ordre croissant d'importance, les éléments qui font le contenu de l'approche Agile. Pour résumer le contenu de ce billet: les principes, c'est ce qui nous préoccupe quand on s'arrête pour réfléchir; les concepts, ce sont les définitions auxquelles on revient pour éviter de se tromper; les pratiques, c'est ce qui nous distingue visiblement d'autres équipes; mais le plus important reste les compétences, c'est-à-dire que nous nous attachons à améliorer.

La question "sommes-nous Agiles" n'a que peu d'intérêt. Bien plus importante est la question "qu'avons-nous appris, qui nous permet dans la pratique de mieux réussir nos projets?"

Lors de la réunion où fut écrit le fameux Manifeste, c'est cette question qui animait les participants. Leur objectif était de décrire leurs points de convergence les plus forts possibles: c'est une démarche qui les conduisait nécessairement à une formulation un peu abstraite, un peu éloignée de la réalité quotidienne des projets qu'ils vivaient alors. Ce sont donc les "douze principes" réputés sous-tendre la pratique Agile.

Les principes fournissent un garde-fou utile. Si je m'aperçois que la mise en place de pratiques censément Agiles a eu pour résultat de démoraliser toute l'équipe, le cinquième principe, "bâtissez le projet autour de personnes motivées", m'avertit qu'il y a peut-être une contradiction quelque part. A tout le moins, je dois le prendre comme un sérieux avertissement, envisager que j'ai pu faire fausse route.

Mais on ne peut pas construire un projet sur la seule base de quelques principes. Admettons, nous somme tous d'accord pour "satisfaire le client en livrant tôt et régulièrement des logiciels utiles". Cela ne constitue pas un conseil opérant, ou comme on le dit en anglais avec beaucoup de pertinence, "actionable". C'est comme si on vous conseillait, pour gagner en bourse: "achetez des actions lorsque les prix sont bas et revendez-les lorsque les prix sont hauts". Parfaitement juste et sensé, mais aussi parfaitement inutile: on demande immédiatement comment?

Les concepts doivent être maîtrisés sous peine de contresens fatals. Scène vécue: un "Scrum Master" nouvellement certifié débarque sur une liste de diffusion et demande, "est-il raisonnable de fixer pour le prochain Sprint une vélocité de 80% parce qu'un membre de l'équipe est absent?". Des questions de ce type me mettent mal à l'aise quant à l'efficacité et à la qualité des formations! (C'est un de ces incidents qui m'a amené à la conclusion qu'un référentiel plus clair était nécessaire.)

La mise en place d'une approche Agile exige de connaitre un peu de théorie. Pour acquérir un concept théorique il suffit le plus souvent d'en recevoir la définition, par exemple "la vélocité est obtenue en faisant le total des points (estimations) associés aux User Stories qui ont été terminées dans l'itération qui vient de s'achever". Cette définition suffit à identifier les erreurs de notre jeune Scrum Master; la vélocité est quelque chose qui se mesure, non quelque chose qui se décrete à l'avance; c'est une mesure qui s'exprime dans la même unité que les estimations, donc des points ou des hommes-jours mais en aucun cas un pourcentage. Le réflexe qui joue est le même que celui du physicien à qui on annoncerait une vitesse exprimée en mètres carrés: ce n'est pas la peine de vérifier le calcul, il faut d'abord rectifier une incompréhension théorique.

Nuançons quand même le propos: certains des termes utilisés pour décrire Scrum ou XP exigent plus qu'une définition brute, il faut comprendre comment les mettre en relation. J'affectione les simulations de projet comme outil pédagogique pour garantir que des termes comme vélocité ou itération sont bien compris.

Les pratiques, c'est ce dont on peut constater la mise en place sur le terrain, de façon visible. Par exemple, une heuristique que j'emploie fréquemment pour juger qu'équipe prend au sérieux l'approche Agile: les murs de la salle de travail sont-ils recouverts de tableaux blancs remplis, de grandes feuilles de papier chargés de Post-It, de documents divers relatifs au projet et mis à jours récemment? La présence de ces indices n'est évidemment pas une garantie de succès, mais elle met en évidence certaines pratiques communes parmi les équipes Agiles: utilisation d'un tableau de tâches par exemple.

Ou bien encore, je pourrais passer un peu de temps avec un développeur, et constater quelques différences visibles entre son travail et ce que j'ai vu faire ailleurs. Lorsqu'il programme, je le vois systématiquement se préoccuper de tests unitaires automatisés, qui se matérialisent par une "barre verte" ou "barre rouge" dans l'outil qui gère ces tests. Ou bien, je remarque qu'il ne travaille que rarement seul, mais le plus souvent avec un autre développeur assis au même bureau; il ne travaille pas en silence mais explique (sans trop lever la voix pour ne pas perturber d'autres binômes) le raisonnement derrière le code qu'il propose à son collègue.

Les compétences, c'est ce qu'on peut voir quand on examine de plus près certaines pratiques (mais pas toutes), ce sont celles parmi les pratiques qui amènent à distinguer des niveaux de performance. Telle équipe est meilleure que l'équipe voisine dans le domaine de la conception évolutive. Tel développeur est plus doué qu'un autre pour le refactoring, il l'applique de façon plus fluide, à une plus grande échelle, avec plus de rapidité.

Certaines pratiques ne sont pas nécessairement des compétences: d'un certain point de vue une réunion de type "stand-up" ou "daily Scrum", c'est simplement une réunion. On constate, ou non, que l'équipe se réunit une fois par jour à heure fixe pour échanger sur les progrès accomplis. Par contre on peut considérer que l'animation de cette réunion est une compétence. Si cette compétence est présente cela se traduit par une réunion courte et le sentiment (subjectif, certes) qu'elle a été utile. Si cette compétence fait défaut, la réunion peut s'éterniser et sembler contre-productive.

Attention, "animer un stand-up court" ne décrit pas une compétence! On préfèrera quelque chose comme: "telle personne est capable d'équilibrer les temps de parole lors d'une réunion, en encourageant les plus timides à contribuer et les plus extravertis à se limiter". Cette compétence s'appuie sur de l'observation (il faut avoir noté qui a parlé ou pas parlé) et sur de l'autorité (adopter le ton juste lorsqu'on demande à quelqu'un de rendre la parole: ni minauderie ni éclat de voix).

Conclusion: pour pouvoir obtenir les bénéfices d'une approche Agile, il me semble important d'avoir accès à une description approfondie et détaillée du contenu de cette approche, avec une attention particulière aux pratiques et aux compétences qui, sans doute parce qu'elles sont plus difficile à décrire finement, ont jusqu'à présent surtout fait l'objet d'une "tradition orale", d'un apprentissage par la transmission individuelle. Même si cette dernière garde son importance dans la culture Agile, elle ne peut que bénéficier d'un corpus écrit, si celui-ci est soigneusement réalisé et entretenu.

Dans une bonne bouteille, vous buvez l'étiquette?

Une question malicieuse pour un sujet très sérieux, puisque l'une de mes plus grandes inquiétudes est de voir notre profession se détourner d'idées qu'elles vient pourtant à peine de découvrir et qui, bien maîtrisées, lui font le plus grand bien.

Ce qui est important dans l'ensemble certes un peu hétéroclite de notions associées au terme "Agile", ce n'est évidemment pas le mot "Agile", de la même façon que ce qui nous procure du plaisir dans une bonne bouteille de vin, c'est (en principe) son contenu.

En principe? Oui, une des vertus de cette analogie, c'est de nous rappeler que trop souvent on se délecte de l'étiquette. On appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors même que si nous faisions l'essai à l'aveugle nous ne saurions pas distinguer une piquette d'un cru à la mode.

Je ne jetterai donc la pierre à personne, mais le fait est que nous courons un risque à trop parler des étiquettes: Agile, Lean, Scrum, XP... J'entends des choses parfaitement absurdes, par exemple "Lean est le successeur d'Agile".

C'est un contre-sens pour qui connaît le contenu qu'on désigne par le terme Agile: un ensemble de pratiques, certes pas toutes de la même origine, certes pas toutes aussi largement connues et pratiquées, mais dont statistiquement, en interrogeant un assez grand nombre de personnes faisant partie de la communauté depuis longtemps (cette appartenance pourrait se déterminer par un critère concret tel que la participation à des conférences), le recouvrement nous donnerait une idée assez précise.

Citons en vrac, et pour l'exercice: le développement par les tests (TDD), le refactoring, l'automatisation du build, l'intégration continue, la conception incrémentale, les User Stories, les tests de recette, les critères "Done", les Personas, le Story Mapping, le Planning Poker, les itérations timeboxées, les rétrospectives, le tableau des tâches, le libre choix des tâches, la réunion quotidienne ou "mélée", la programmation en binômes, les demandes d'aide explicites...

Parmi les "méthodes Agiles" (le mot méthode est mal choisi, mais ce sera le sujet d'un prochain billet) on peut effectivement recenser certaines dont les préconisations sont des sous-ensembles de cette longue liste: Scrum et XP notamment.

Si on se pose la question de savoir de quel mode de pensée sont issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a de nombreuses affinités avec le discours Lean. Pour autant, le recouvrement en termes de pratiques est relativement faible.

Or, soyons clair là-dessus, ce qui fait le succès ou non d'un projet, ce n'est pas le nom du discours dont on se revendique, l'attachement identitaire des membres de l'équipe: "nous sommes Agiles" ou "nous sommes Lean". Ce qui fait le succès d'un projet c'est ce que font les gens!

De ce point de vue, force est de constater que beaucoup d'équipes se proclament "Agiles" alors même qu'elles peinent à appliquer de façon compétente des pratiques aussi élémentaires que le refactoring, ou qu'elles révèlent lorsqu'on interroge les ingénieurs des contresens sur des notions de base comme la vélocité.

Une partie de ce déficit est à mettre sur le compte de la communauté Agile elle-même: il n'existe nulle part sur le Web un "Wikipedia de l'Agilité", une description systématique, détaillée, cohérente et mise à jour des pratiques désignées par le terme "Agile".

D'où le projet actuellement prioritaire de l'Institut Agile: mettre à la disposition des personnes intéressées par le sujet un "référentiel des compétences, pratiques, notions et principes" des approches Agiles. Qu'est-ce qui différentie une compétence d'une pratique, d'un principe, etc? C'est ce que j'aborderai dans le prochain billet...

Dix ans d'agilité, et après?

Un billet rapide pour vous signaler mon entretien d'une heure et quelques avec Mario Cardinal pour le Visual Studio Talk Show, disponible en podcast (ou ballado-diffusion pour les puristes).

Nous avons parlé des dix ans du Manifeste Agile, de ce qui se passe en ce moment et de ce qui se trame à l'avenir, et donc notamment des projets de l'Institut.

Interventions programmées

Le périmètre d'intervention de l'Institut Agile couvre le territoire français.

C'est un choix délibéré: d'une part, il ne me semblait pas raisonnable d'annoncer des ambitions internationales, alors que pour l'instant l'Institut se compose d'une seule personne à temps plein. Par contre, il est désormais important de reconnaitre que la communauté Agile n'est plus un phénomène parisien; c'est à travers le pays qu'on s'y intéresse. (Au passage, il convient d'apprécier l'influence qu'a eu Agile Tour dans cette ouverture au-delà de la capitale.) L'Institut a donc des partenaires à Paris, mais aussi à Bordeaux, Marseille, Grenoble.

Jusqu'à présent, mes activités m'amenaient à voyager assez souvent à l'étranger, surtout pour des conférences; et beaucoup en France, le plus souvent pour rencontrer des clients. J'ai fait le choix de me consacrer à plein temps aux activités de l'Institut. Les conférences ainsi que ma participation à l'Alliance Agile font toujours partie de ces activités, au sens où l'Institut doit être un bon observateur de la communauté Agile.

Et, bien qu'ayant choisi de ne plus intervenir auprès d'aucun client, j'entends bien continuer à aller à la rencontre des projets Agiles partout en France. Habitué des conférences et séminaires, je suis aussi ravi de parler à des groupes d'utilisateurs ou associations. Ou même de discuter simplement en tête à tête autour d'un café avec un autre passionné.

Si vous souhaitez me rencontrer, soit à l'occasion d'un déplacement déjà programmé, soit à votre invitation, n'hésitez pas à me contacter. Je souhaite garder un calendrier de voyages relativement léger, et privilégier les déplacements que je pourrai faire dans la journée, mais tout peut s'envisager.

Je serai donc:

• le 1er octobre à Londres pour le workshop sur les tests de recette AA-FTT
• les 6, 13 et 20 octobre à Douai, où je dispense une formation créée par mes collègues Christophe Thibaut et Bernard Notarianni pour l'école des Mines
• le 8 octobre à Nancy, pour commencer à évoquer les dix ans du Manifeste Agile
• le 17 novembre à Reykjavik en Islande, pour parler de pratiques de conception
• le 25 novembre... à Paris ;) où j'interviendrai lors du MDDay pour donner mon avis sur la modélisation

Alternatives à la certification

Sur le sujet de la certification, l'Institut annonce clairement la couleur: cet organisme n'aura, en son nom, aucune activité de certification ou même de labelisation.

(Notamment, la qualité de Partenaire de l'Institut ne vaut pas, de la part de l'Institut, quelque reconnaissance que ce soit du caractère "agile" ou des compétences d'une entreprise. Les Partenaires de l'Institut sont des entreprises qui choisissent, pour des raisons économiques, de contribuer aux missions de l'Institut.)

Qu'est-ce qu'une certification? Voici ce qu'en dit la Commission Nationale de la Certification Professionnelle:

Une certification professionnelle atteste d'une "qualification" c'est-à-dire de capacités à réaliser des activités  professionnelles dans le cadre de plusieurs situations de travail et à des degrés de responsabilités définis dans un  "référentiel".

Pourquoi "en son nom"? Parce qu'il existe en France des organismes qui certifient, c'est-à-dire qui délivrent des diplômes professionnels, et qu'il est non seulement légitime mais bel et bien prévu que l'Institut contribue à définir un "référentiel" des capacités et des responsabilités que désigne le terme "développement de logiciels Agile".

Ce que l'Institut se refuse, c'est la démarche qui consiste à s'auto-proclamer organisme de certification, sans dialogue préalable avec qui que ce soit, dans le but de rendre plus attractive une offre commerciale de formation. Hélas, force est de constater que généralement dans notre domaine, cette démarche est le fait d'entreprises qui, par ailleurs, vendent de la formation.

Ces entreprises se trouvent donc juge et partie dans une situation qui peut être sensible. D'une part, si je suis déjà pourvoyeur d'une formation, il est évident que ma définition du référentiel pédagogique collera (on est tenté de dire "comme par hasard") au contenu de mes propres formations. D'où un avantage indéniable à être le premier à dégainer en proposant une certification: je n'ai rien à faire pour adapter ma propre formation aux objectifs de conformité au référentiel, par contre mes concurrents vont devoir s'aligner sur ce que moi j'enseigne.

Or ce référentiel des pratiques et compétences agiles, j'en reparlerai, est un "work in progress". La communauté Agile travaille en permanence à le faire évoluer, à y ajouter des volets entiers, à le simplifier parfois, à le reformuler pour être plus percutant et plus efficace. Dès lors, créer un système qui agit de façon à standardiser les enseignements n'a pas de sens.

De plus, ce référentiel n'existe pas encore, du moins pas encore de façon systématique et détaillée. Nous n'avons pas encore su donner dans un seul endroit une définition canonique, claire et commentée de termes comme Vélocité, Refactoring, Test-Driven, etc.

Pour finir, la plupart des formations actuellement vendues à l'aide du mot magique "certification" sont des formations courtes, qui ne peuvent en aucun cas prétendre à construire des "capacités à réaliser des activités professionnelles dans le cadre de plusieurs situations de travail". Deux jours ne suffisent pas à former un ingénieur ou un leader de projet Agile. (Ni même cinq.)

Entretenir la confusion entre formation et certification participe d'ailleurs du même principe malhonnête qui consiste à faire prendre des vessies pour des lanternes. Une certification est censée attester, notez le mot, qui est fort, d'une qualification. Elle n'est pas censée la construire: c'est justement le rôle de la formation. On peut très bien dissocier la formation, qui consiste à travailler avec des gens pour leur enseigner quelque chose, de la certification, qui consiste en fait à mettre en jeu sa réputation sur une déclaration solennelle que telle personne est qualifée pour un travail.

Si vous examinez ce qui est actuellement proposé par diverses entreprises sous la rubrique "certification Agile", vous entendrez le discours opposé: "Ah, mais attention, nous ne nous engageons absolument pas sur le fait que la personne qui a suivi nos cours est qualifiée, uniquement sur le fait qu'elle a enregistré ce qu'on lui a dit".

Vous l'avez compris, parler de certification aujourdh'ui, c'est dans le meilleur des cas mettre la charrue avant les boeufs.

Dans ces conditions, la démarche alternative me semble claire: commencer d'abord par mettre au point ce référentiel pédagogique, en invitant largement la communauté à y participer. En soi, cette démarche a de l'intérêt, parce qu'elle permettra aux personnes visées par les offres de "certification" de trouver tous les bénéfices prétendument apportés par ces offres: aux employeurs de savoir quelles questions poser aux recrues potentielles; aux ingénieurs qui souhaitent se former de savoir ce que doivent couvrir les formations qu'ils envisagent; aux formateurs de composer des parcours utiles, sans avoir à suivre un cursus imposé, mais en se sentant responsables de leur contenu.

C'est une partie du projet de l'Institut.

Agile 2010, compte-rendu partial

J'ai participé à la conférence Agile2010 mi-août et comme chaque année ce fut une semaine bien chargée.

Résurgence d'XP ou clivage?

L'un des faits marquants est l'initiative prise par certains de nos amis, associés notamment au mouvement "software craftsmanship", de redonner un coup de projecteur sur le volet technique des pratiques agiles. Cory Foy et Cory Haines ont ainsi annoncé, puis confirmé lors d'un événement "Code Retreat", en marge d'Agile2010, la tenue l'an prochain d'une conférence "XP Universe 2011".

L'annonce inquiète certains, qui y voient le signe d'une fragmentation de la communauté. Pour d'autres c'est une bonne nouvelle, car le contenu d'Agile2010 est très largement occupé par des sujets autres que le code: management, coaching, UX, DevOps, etc...

Pour d'autres encore c'est l'occasion de méditer sur le sens profond de cette conférence et de la marque Agile: j'ai ainsi entendu "Agile est le nom que l'on donne au courant qui s'intéresse à l'ensemble de la chaîne de valeur, et qui regroupe plusieurs disciplines qui s'intéressent chacune à un bout de la chaîne". Ca vous donne une idée des états d'âme du leadership de la communauté...

DevOps, un nouveau "courant" à surveiller

Le mot "nouveau" est tout relatif, cela fait au moins deux ans que des collègues comme Patrick Debois militent pour intégrer sous la bannière Agile des modes de collaboration plus efficaces entre développeurs et exploitants (Ops comme Opérations, d'où DevOps).

Cette année cependant ce groupe a fait parler de lui d'une part en apportant plusieurs sessions, d'autre part en mettant en scène un clone du personnage Borat ("de glorieuse nation Kazakhstan!") qui a sévi sur Twitter pendant toute la conférence. Blague à part, c'est une idée qui fait son chemin.

Lean Startup ou "Feedback Driven Development"

L'une des présentations les plus enrichissantes pour moi concernait les idées pour marier l'approche Lean Startup popularisée par Eric Ries avec les techniques de développement agile. J'ai particulièrement apprécier la présentation concrète - "voici des choses que vous pouvez faire en rentrant au boulot" - combinée avec une bonne maîtrise de la philosophie sous-jacente - "inclure vos clients finaux dans la boucle de développement de la façon la plus resserrée possible".

C'est ce mélange qui fait les meilleures sessions de nos conférences, je voudrais hélas qu'il soit plus systématique à Agile 2010 qui prend peut-être une teinte un peu spéculative, portée sur l'abstraction et l'auto-congratulation.

La certification toujours (hélas) d'actualité

J'ai eu une longue conversation avec Alistair Cockburn, une des stars de la communauté, j'avais été très déçu par son annonce pendant l'été d'un nouveau programme de certification appelé ICAgile.

Déçu parce qu'à mon sens la communauté n'a plus confiance dans les programmes de certification depuis les déboires qu'a connu la Scrum Alliance, et qu'il n'est plus temps de continuer à chercher à "refaire la même chose mais correctement". Il faut remettre les choses à plat et proposer au marché de plus en plus acheteur de compétences agiles une façon plus claire, plus crédible, d'identifier ces compétences. Le schéma de certification proposé par ICAgile me semble trop proche de ceux que nous avons déjà connus, trop flou sur les questions de gouvernance et d'éthique, trop vulnérable aux conflits d'intérêts.

Cela dit le travail d'Alistair rejoint celui de l'Institut sur au moins un point, la nécessité de formaliser un peu la cartographie de ces compétences. Au-delà, et malgré une évidente bonne volonté de sa part, nous ne sommes pas sur la même longueur d'onde.

Recherche: un fossé à combler

Une table ronde sur la recherche en matière de pratiques agiles m'a permis de faire le point avec des chercheurs et des praticiens. Participaient notamment Scott Ambler et Frank Maurer, avec deux points de vue très différents. Scott met l'accent sur le peu de données empiriques, Frank se montre pessimiste sur l'intérêt que portent les chercheurs en général aux pratiques agiles comme sujet de recherche.

Au cours de la semaine j'ai discuté avec plusieurs personnes à ce sujet et il m'est finalement venu une formule pour résumer l'ambition de l'Institut en ce qui concerne la recherche et l'enseignement: "le Génie Logiciel existe depuis 40 ans, et presque toutes les universités ont un département GL, alors que cette discipline semble n'avoir résolu aucune des difficultés qu'elle a été créée pour résoudre; l'objectif de l'Institut c'est créer des départements Agilité dans les universités, pour faire avancer l'état de l'art..."

Les prix Pask

Cette année les lauréats du prix Gordon Pask sont... des lauréates, ça nous change un peu. Le prix décerné annuellement depuis 2006 est destiné à mettre en avant deux personnes dont le comité estime que la communauté devrait les écouter, même si ce qu'elles ont à dire est un peu bizarre. Il a été attribué à Liz Keogh, infatigable pédagogue du BDD (Behaviour-Driven Development), ainsi qu'à Elizabeth Hendrickson, initiatrice d'un travail de réflexion et de synthèse sur les tests automatisés au delà du clivage test unitaire - test de recette. Le test à l'honneur, donc, et la technique, mais aussi la gent féminine.

 
Reprendre contact...

Comme tous les ans la conférence a été l'occasion de retrouver pas mal de collègues et amis, et de leur (re)parler du projet de l'Institut. Les retours sont unanimement positifs.

Les actualités de l'Institut

C'est la rentrée!

Les activités de l'Institut Agile se mettent en route, la phase de lancement se termine dans les semaines qui viennent. Le programme du dernier trimestre 2010 sera chargé, et j'aurai l'occasion d'en dire plus à ce sujet dans les jours qui viennent.

Ce blog vous permettra de rester informé des actualités de l'Institut, mais il sera également le lieu d'observations, de réflexions informelles sur l'état de la communauté Agile et des connaissances sur les pratiques; il donnera également un éclairage plus détaillé sur les missions et les réalisations de l'Institut.

A bientôt!