Category Archives for "Fiche Pratique"

8

Holacracy en pratique

Dans un premier article, nous avons posé le décor en guise d'introduction à cette innovation managériale et organisationnelle qu'est Holacracy. En abordant les questions de son origine, sa définition, son positionnement par rapport aux méthodes agiles, et surtout par rapport au rôle de manager. Il est temps maintenant d'aborder son fonctionnement concret dans ce second article.

Préambule

Avant de plonger en Holacracy, je tiens à préciser qu'il faut considérer Holacracy comme une technologie à part entière avec la complexité que cela peut impliquer. Une technologie, certes "organisationnelle" - et encore c'est réducteur - mais une technologie quand même. Décrire clairement Holacracy et de façon suffisamment exhaustive pour en saisir tout le potentiel, tout en restant synthétique est un véritable challenge. Pour vous aider à saisir ce que change Holacracy au quotidien, j'ai fait le choix de nous mettre dans la peau d'une personne évoluant dans une entité fonctionnant en Holacracy. J'espère avoir réussi ce challenge. En guise d'illustration et afin de donner du corps à cet article, j'ai utilisé des captures d'écran d'un des logiciels du marché associé à la pratique d'Holacracy au quotidien.

Nous allons donc suivre Miriam qui appartient à l'entreprise d'édition de logiciel Dream Software (société fictive) fonctionnant en Holacracy. Mais avant, j'ai encore un minimum d'explications à vous transmettre sur les fondamentaux d'Holacracy

Fondamentaux d'Holacracy

En quoi consiste Holacracy en quelques mots ?

L'Holacracy consiste à distribuer l’autorité et le leadership généralement centralisé par le management afin de démultiplier l’impact de chacun sur les objectifs de l’organisation et l’amélioration continue de cette dernière. Le tout guidé par sa « raison d’être ». Une raison d'être qui sert d’étoile du nord et de « challenge collectif ». Cette innovation modifie en profondeur l’environnement de travail pour favoriser cette distribution de l’autorité et du leadership qui va souvent de pair avec le développement des collaborateurs. Des collaborateurs d’autant plus investis dans des rôles précis et régulièrement ajustés. Les rôles étant eux même investis d’une raison d’être déclinée de la raison d’être de l’organisation. Ce qui contribue à donner du sens au travail de chacun, libérer les énergies et les potentiels, et optimiser le niveau d’engagement.

Les rôles et les cercles

Une organisation fonctionnant en Holacracy, est constituée de cercles rassemblant différents rôles incarnés par des personnes. Un cercle peut contenir des sous-cercles qui peuvent eux même contenir des sous-cercles jusqu'à l'infini (c'est fractal). Et petite subtilité importante : un sous-cercle, d'un point de vue du cercle "parent" est considéré comme un rôle à part entière.

Qu'est ce qu'un rôle Holacracy ?

Un « Rôle » est une entité organisationnelle dotée d’un nom descriptif et d’une ou plusieurs caractéristiques suivantes :  

  • La fameuse « Raison d’Être » déjà évoquée, qui désigne une capacité, un potentiel ou un but inaccessible que le Rôle va poursuivre ou manifester au nom de l’Organisation.
  • Un ou plusieurs « Domaines », qui sont des choses que le Rôle est le seul à pouvoir contrôler et réglementer comme sa propriété, au nom de l’Organisation.
  • Une ou plusieurs « Redevabilités », qui désignent des activités dans la durée de l’Organisation que le Rôle va mettre en œuvre.

Voyage en Holacracy

Maintenant que les fondamentaux sont posés, nous pouvons démarrer notre voyage en Holacracy aux côtés de Miriam.

Miriam, comme la majorité des employés de l'entreprise, incarne différents rôles dans l'organisation. Le rôle "OnBoarding" par exemple, qui a pour raison d'être "Chaque nouvel arrivant est accompagné et opérationnel dans les meilleurs délais".  

Cette raison d'être contribue à donner du sens à son travail et à guider ses initiatives. Elle a toute autorité dans l'exercice de ses rôles. Personne n'a à lui dire comment les incarner. Et si elle en éprouve le besoin, elle peut bien sûr demander conseil ou prendre du recul auprès d'autres membres de l'organisation en utilisant une "dose" d'intelligence collective

Exemple d'organisation Holacracy (société fictive Dream Software)

Elle incarne également le rôle "Captain Ergo" dont la raison d'être consiste à "Offrir la meilleur expérience possible aux utilisateurs de nos solutions logicielles". À ce rôle, est également associé une redevabilité, autrement dit, quelque chose que les autres rôles peuvent exiger de ce rôle. La redevabilité en question est "Fournir les maquettes d'écran avant la planification de sprint". Un rôle peut avoir plusieurs redevabilités.

En ce moment, Miriam travaille sur un projet. Dans le vocabulaire Holacracy, on utilise le terme "projet" à partir du moment où un résultat attendu dépend de la réalisation de plusieurs actions. Hier elle a éprouvé une tension en constatant que les choses auraient pu mieux se dérouler sur son projet. Autrement dit, un écart entre ce qui s'est passé et ce qui aurait pu se passer si on était mieux organisé ou si on s'y était pris différemment. Elle a donc noté sa tension dans son carnet à tensions afin de la "traiter" lors de la prochaine réunion consacrée au traitement des sujets opérationnels. La réunion de triage. Cette réunion a lieu toutes les semaines, dure une heure et est animée par le rôle "Facilitateur" (rôle défini quant à lui par Holacracy et élu par les membres du cercle).

Réunion de triage

Ça y est c'est l'heure de la réunion de triage qui commence par un tour d'inclusion lancé par le rôle "Facilitateur". Cette étape consiste à faire en sorte que chacun puisse s'exprimer sur son degré de disponibilité et de concentration sur la réunion ou encore évoquer d'éventuelles contraintes horaires. Lorsque c'est son tour de s'exprimer, Miriam dit "J'ai encore un peu l'esprit ailleurs sur un problème d'ergonomie que je n'arrive pas à résoudre mais je vais sortir ça de ma tête le temps de cette réunion pour être pleinement disponible".

Support logiciel d'animation et d'historisation de la réunion de triage (outil GlassFrog)

Vient ensuite le moment de faire la revue de la check-list qui consiste à vérifier des points récurrents qui peuvent aussi bien concerner des rôles en particulier que l'ensemble des membres du cercle. 

Ensuite, on passe à la revue des indicateurs permettant de mesurer à quel point la raison d'être du cercle se manifeste. Suivi du partage des nouvelles sur les projets de chacun mis en visibilité en terme de statut dans le logiciel Holacracy.

On passe ensuite à l'établissement de l'ordre du jour. Le facilitateur invite chacun à inscrire ses sujets à l'ordre du jour, soit directement dans le logiciel Holacracy partagé avec tout le monde et projeté à l'écran, soit par l'intermédiaire du rôle "Secrétaire" (rôle défini par Holacracy qui tient l'historique des décisions prises directement dans le logiciel Holacracy et a le pouvoir d'arbitrer toute interprétation de la gouvernance et constitution en cas de conflit) également présent en réunion.

Aucune explication n'est requise, un simple mot peut suffire. Miriam demande au rôle Secrétaire d'inscrire à l'ordre du jour "Miriam 1". En quelques secondes l'ordre du jour est constitué avec 11 sujets.  Le facilitateur les traite dans l'ordre de son choix, arrive au sujet "Miriam 1" et s'adresse à Miriam : "Miriam, dans quel rôle parles tu et à quel rôle t'adresses tu ?". Miriam : "Dans mon rôle Captain Ergo, je m'adresse au rôle Magicien du Code" (équivalent de développeur). Miriam décrit ensuite la tension qu'elle a éprouvé et propose au rôle Magicien du Code d'exécuter une action permettant de résoudre sa tension. Le facilitateur lui demande ensuite "ok est ce que ça résout ta tension ?" Miriam répond : "Oui". Facilitateur : "Est ce que c'est quelque chose sur lequel tu voudrais compter dans la durée ?" Miriam : "Oui". Facilitateur : "Dans ce cas, je propose que le secrétaire note l'action et l'affecte au rôle Magicien du Code et que tu amènes ta tension en réunion de gouvernance pour pouvoir traiter cette tension de façon durable en clarifiant les autorités, pas juste ponctuellement" (voir paragraphe suivant).

Une fois l'ensemble des points traités, on passe au tour de clôture au cours duquel chacun dispose d'un moment de parole qui lui est dédié (mode "baton de parole") pour exprimer son ressenti sur le déroulement de la réunion. Quand son tour arrive, Miriam dit "J'ai trouvé la réunion utile et je suis soulagée d'avoir pu instruire mon point".

​Réunion de gouvernance

Trois semaines plus tard, la réunion de gouvernance qui a lieu tous les mois et dure 2 heures, prend place. On y traite tous les tensions susceptibles de modifier l'organisation ou "structure" du cercle associé. Notamment les rôles du cercle et les règles qui s'appliquent à ces derniers. On appelle ces règles, des  "politiques".

Support logiciel d'animation et d'historisation de la réunion de triage (outil GlassFrog)

La réunion animée par le Facilitateur démarre par le tour d'inclusion comme en réunion de triage. Après avoir traité les aspects logistiques (durée de la réunion, horaire de la pause déjeuner qui entre-coupe la réunion, etc), on dresse l'ordre du jour de la même façon qu'en réunion de triage.

On arrive au point amené par Miriam. Le facilitateur l'invite à faire une proposition. Après tout, on est pas là pour le plaisir de se plaindre mais pour construire l'avenir.​ Charge donc à Miriam de transformer sa tension en proposition ou de demander une discussion ouverte si elle souhaite avoir recours à l'intelligence collective du cercle. Elle décrit sa tension d'origine et sa proposition qui consiste à ajouter au rôle Captain Ergo, le domaine "Maquette des écrans". Ce qui signifie que elle seule aurait ainsi l'autorité pour définir les maquettes des écrans. Autrement dit, si quelqu'un souhaite réaliser la maquette d'un écran d'une application produite par Dream Software, il devra demander l'autorisation au rôle Captain Ergo directement..

On passe ensuite aux questions de clarification. Chacun peut alors poser une question de clarification au proposeur, donc à Miriam sur ce point. Aucune discussion ou réaction n'est permise, seules les questions de clarification sont autorisées afin de maintenir le bon niveau d'efficacité du processus de gouvernance. Le facilitateur interrompt donc immédiatement toute dérive.​ Le "proposeur" n'est pas obligé de répondre si il n'a pas la réponse.

Vient ensuite le tour de réaction. Chacun​ peut à son tour réagir à la proposition sans être interrompu par un autre et sans déclencher de discussion avec une autre personne. Juste après ce tour de réaction, à la lueur des différentes réactions, Miriam prend conscience d'un élément qui lui avait échappé. Elle profite alors de l'étape de clarification et modification pour clarifier sa proposition et l'ajuster en fonction de cette prise de recul dont elle vient de bénéficier grâce aux autres membres du cercle.

Il est temps maintenant de passer au tour d'objection. Chacun a son tour exprime ses éventuelles objections. Tony qui incarne le rôle de Magicien de Code exprime une objection. Le rôle Secrétaire la note.

Le facilitateur décide de tester l'objection identifiée afin de vérifier sa validité. Pour cela il va utiliser une série de questions. Des questions telles que  : "Penses tu qu'adopter cette proposition ferait régresser le cercle ? Si oui, te bases tu sur des faits avérés ou es tu en train d'anticiper l'avenir ?" etc... Tony s’est rendu compte que son objection n'était finalement pas valide (i.e. ne respecte pas les critères de validité d’une objection, définis dans la constitution). La proposition de Miriam consistant à modifier l'organisation à travers l'attribution d'un domaine à l'un de ses rôles est ainsi acceptée en moins de 10 minutes.

Une fois l'ensemble des points traités, on passe au tour de clôture comme en réunion de triage.

​La constitution pour règles du jeu

Il arrive à Miriam et ses collaborateurs de ne plus se souvenir des différents leviers dont elle dispose pour modifier l'organisation afin de la rendre meilleure. Elle se repose donc sur la dernière version de la constitution Holacracy en vigueur dans l'entreprise. Cette constitution décrit les règles du jeu et elle confère à chacun un pouvoir précieux pour faire en sorte que chacun puisse exercer pleinement son ou ses rôles en son âme et conscience et en toute autorité dans l'exercice de ces derniers. Afin d'officialiser ce principe fondamental, le patron de l'entreprise a soumis son propre pouvoir à celui de la constitution en signant cette dernière. 

Voici ci dessous un extrait de la constitution pour illustration. Un extrait pas choisi au hasard puisqu'il s'agit de la description du processus de décision utilisé en réunion de gouvernance. Un processus plutôt puissant à mon goût.​

EXTRAIT DE LA CONSTITUTION HOLACRACY


​3.3.5 Processus de Prise de Décision Intégrative

Le Facilitateur doit conduire le processus de Prise de Décision Intégrative de la manière suivante :

  1. Présenter la Proposition : tout d’abord, le Proposeur peut décrire la Tension, et présente une Proposition visant à résoudre la Tension. Si le Proposeur demande de l’aide pour élaborer une Proposition, le Facilitateur peut autoriser une discussion ou tout autre processus collaboratif pour l’aider. Toutefois, le Facilitateur doit concentrer cette activité seulement sur l’élaboration d’une première Proposition centrée sur la Tension du Proposeur, et non sur la résolution d’autres Tensions ou sur l’intégration des préoccupations des autres dans ladite Proposition.
  2. Questions de Clarification : une fois la Proposition faite par le Proposeur, les autres participants peuvent poser des questions de clarification pour mieux comprendre la Proposition ou la Tension sous-jacente. Le Proposeur peut répondre à chaque question, ou ne pas le faire s’il n’a pas la réponse. Le Facilitateur doit interdire l’expression de toute réaction ou commentaire à propos de la Proposition et empêcher toute forme de discussion. Au cours de cette étape, ou plus généralement à tout moment dans le processus où un participant peut parler, ce dernier peut demander au Secrétaire de lire la Proposition qui a été saisie ou de clarifier la Gouvernance actuellement en vigueur, et le Secrétaire est tenu de répondre à la demande.
  3. Tour de Réaction : lorsqu’il n’y a plus de Questions de Clarification, chaque participant sauf le Proposeur, peut partager à son tour, ses réactions par rapport à la Proposition. Le Facilitateur doit immédiatement stopper et interdire tout commentaire en dehors du tour, toute tentative d’engager les autres dans un dialogue ou tout échange de quelque sorte que ce soit, ainsi que toute réaction à d’autres réactions et non à la Proposition.
  4. Clarifier et Modifier : après le Tour de Réaction, le Proposeur peut partager des commentaires en réponse aux réactions et/ou apporter des modifications à la Proposition. Toutefois, le but premier de toute modification doit être de tenter de répondre au mieux à la Tension du Proposeur et non aux Tensions soulevées par les autres. Lors de cette étape, le Facilitateur doit immédiatement stopper et interdire tout commentaire de la part de quiconque autre que le Proposeur ou le Secrétaire, et les interventions du Secrétaire se doivent d’être limitées uniquement à la saisie de la modification de la Proposition.
  5. Tour d’Objection : ensuite, chaque participant, à son tour, peut soulever des Objections potentielles à l’adoption de la Proposition. Le Facilitateur doit stopper et interdire toute forme de discussion ou de réaction. Le Facilitateur peut tester les Objections comme décrit dans la Section 3.2.5, et doit noter toute Objection valide qui subsiste à la suite du test. S’il n’y a aucune Objection valide, le Secrétaire enregistre la Proposition en tant que Gouvernance adoptée pour le Cercle.
  6. Intégration : en cas d’Objection valide, le Facilitateur doit ensuite faciliter une discussion visant à modifier la Proposition afin de résoudre chaque Objection, une à la fois. Le Facilitateur marque l’Objection comme étant résolue une fois que l’Objecteur confirme que la Proposition ainsi modifiée ne déclencherait plus l’Objection, et que le Proposeur confirme que la Proposition ainsi modifiée répond toujours à sa Tension initiale. Durant la discussion, le Facilitateur doit appliquer les règles d’intégration décrites dans la Section 3.2.6. Lorsque toutes les Objections qui ont été notées sont traitées, le Facilitateur refait un Tour d’Objection afin de vérifier s’il n’y a pas de nouvelle Objection à la Proposition ainsi modifiée.

À retenir

Pour résumer, voici les "points forts" que l'on peut retenir d'Holacracy :

  • La raison d'être de l'organisation, déclinée jusque dans les rôles donne du sens et une orientation.
  • Les anciens managers peuvent retrouver du temps pour mettre à profit leur expertise. Le management des personnes se fait par les processus de triage et de gouvernance qui protègent chacun des jeux de pouvoir pour des prises de décision objectives et éclairées par l'intelligence collective. Raisons d'être, constitution (signée par le plus au niveau de pouvoir de l'organisation adoptant l'Holacracy), processus de triage et de gouvernance évitent toute anarchie (au sens péjoratif du terme).
  • Les modifications d'organisation (rôles, politiques, etc) sont déclenchées par les tensions apportées par les collaborateurs. Ce qui rend ces modifications pragmatiques car basées sur les faits et non des interprétations ou projections sur l'avenir.
  • Chaque collaborateur apportant une tension est encouragé par les processus Holacracy à proposer une solution plutôt qu'à se plaindre et risquer de s'enliser dans un rôle de "victime" attendant son "sauveur" (l'entreprise, un manager, etc).
  • Les prises de décision d'organisation sont rapides, du fait qu'on ne recherche pas un consensus mais à traiter uniquement les éventuelles objections qu'une décision susciterait. Une objection qui doit quant à elle être valide selon des critères clairs et pertinents. 
  • La périodicité des réunions de gouvernance donne le droit à l'erreur sur une décision de modification d'organisation. Au pire, cette décision provoquera une tension qui sera remontée et traitée lors d'une prochaine réunion de gouvernance. On peut ainsi régulièrement restructurer collectivement l'organisation pour se rapprocher empiriquement de l'efficience au service de la raison d'être.

Différences entre Holacracy et Sociocratie

Si vous avez des notions de sociocratie, vous avez certainement dû observer pas mal de notions ou vocabulaires similaires tels que les cercles, 1er lien, élection et même les processus. 

N'étant ni expert en Holacracy, ni expert en sociocratie, j'ai décidé de recueillir les propos de quelqu'un qui l'est dans ces deux domaines pour éclairer le sujet des différences entre Holacracy et sociocratie. Cet expert est Bernard Marie Chiquet du cabinet iGi Partners que je remercie pour son temps et ses enseignements.

Pour aller droit au but, ce qu'on peut dire pour commencer, c'est qu'une entreprise qui fonctionne en Holacracy est sociocratique mais l'inverse n'est pas vrai. Et on peut dire aussi, pour rendre à César ce qui appartient à César, que parmi les sources d'influence de l'Holacracy, il y a la sociocratie.

La différence fondamentale, c'est qu'un fonctionnement en Holacracy d'une entreprise ou entité d'entreprise débute lorsque son "patron" ou "patronne" soumet son pouvoir à celui de la constitution Holacracy. Constitution qui élimine la hiérarchie. Là où la sociocratie en tant que telle (si on écarte les versions dérivées de la source) s'applique sur un modèle hiérarchique (La Sociocracy a été créée et définie par Gerard Endenburg en ajoutant 4 principes de gestion sur le modèle hiérarchique). Et on pourrait presque arrêter la comparaison ici car tout le reste découle de cette différence fondamentale. Autrement dit, même si certains termes sont les même en Holacracie et sociocratie, ce principe fondamentale change radicalement la tournure que prennent les processus ou éléments qui sont derrière ces termes.

On peut cependant ajouter que le concept de Rôle et ces différents composants (Raison d’Être, Redevabilités, Domaines) n'existent pas en sociocratie et celui de tension n’est pas aussi abouti. Des concepts de base puissants en Holacracy. Le processus de prise de décision intégrative est également différent (la notion d’objection est moins claire en Sociocratie par exemple) et ne concerne pas les sujets opérationnels. Pour rappel chaque personne incarnant des rôles a toute autorité pour agir en son âme et conscience en fonction de la raison d'être des rôles associés, elle même inscrite dans la raison d'être de son cercle, elle même inscrite dans celle de son éventuel sur-cercle et ainsi de suite.

Prochain article ?

Voilà, j'espère que vous avez maintenant une vision plus concrète d'Holacracy même si je n'ai pas abordé l'ensemble de son contenu. Je n'ai par exemple pas parlé de la notion de stratégie en Holacracy. Je ne suis pas non plus rentré dans les subtilités des rôles de 1er et second lien.

J'ignore encore quel sera le contenu du prochain article, je parlerai probablement d'un retour d'expérience sur l'implémentation d'Holacracy avec les questions de conduite du changement que ça soulève.

Mais vous, que voudriez vous trouver dans ce troisième et probablement dernier article de cette série ?

Répondez ci-dessous dans la zone de commentaire.

Amicalement,
Florent

22

Introduction à Holacracy

La première claque professionnelle que j'ai pu recevoir en terme de remise en question sur la façon de travailler était la découverte des méthodes agiles en 2007. Depuis, c'est devenu une passion, un véritable levier de réussite sur les projets confiés aux équipes que j'accompagne dans l'apprentissage de cette approche. Et j'irai même jusqu'à dire, un art de vivre basé sur les valeurs et principes agiles. Cette année, soit 9 ans plus tard, je reçois une seconde claque. La découverte de Holacracy.

C'est cette découverte que je souhaite partager dans ce nouvel article. Le premier d'une série sur le même thème sans doute. Ca dépendra surtout de vous (cf. message en bas de cet article) 😉

Pour précision, j'utilise le terme Holacracy plutôt que la traduction française Holacratie car Holacracy est désormais une marque. A travers le dépôt de cette marque, les créateurs ont souhaité protéger l'intégrité et la qualité des services associés. Le contenu quant à lui est open source. De la même façon que Linux est une marque.

Allons au delà des idées reçues

Heureusement, ma curiosité et ma soif d'apprendre a été plus forte que les idées reçues ou intox qui gravitent autour de cette nouvelle technologie sociale et managériale qui fait polémique. L'idée reçue la plus répandue étant : "Avec Holacracy, on vire les chefs et c'est l'anarchie". C'est bel et bien une idée reçue.

Holacracy, successeur des méthodes agiles ?

Autre bonne nouvelle, Holacracy ne remplace pas les méthodes agiles pour ceux qui les utilisent. Au contraire, les équipes réellement agiles - dans le respect des valeurs et principes du manifeste agile - bénéficient d'un terreau fertile à l'adoption de Holacracy. En fait Holacracy revient à changer le "système d'exploitation" de l'organisation sur laquelle on peut conserver les "applications" utilisées (dont les méthodes agiles).

Autrement dit, le changement est plus profond. Je dirais que les méthodes agiles font l'objet d'un changement de paradigme en matière de gestion de produit et Holacracy fait l'objet d'un changement de paradigme de l'organisation qui l'adopte. L'agilité se positionne principalement à l'échelle d'une équipe ou projet là où Holacraty peut nativement s'appliquer à toute l'entreprise quelque soit sa taille ou son secteur.

Connaître les origines de Holacracy pour mieux cerner son potentiel

Pour aider à comprendre ce point, il y a une histoire à connaître. Celle de l'origine de Holacracy. Cette technologie sociale et managériale a été mise au point par des agilistes aguerris qui ont décidé de créer leur entreprise. Mais hors de question pour eux de travailler au sein d'une organisation similaire à celles dans lesquelles ou pour lesquelles ils avaient travaillé. Qui représente - il faut bien le dire - quelques inconvénients notoires (cf. illustration ci contre).

Ils devaient trouver un nouveau modèle d'organisation. L'inventer. On peut facilement imaginer l'ampleur et la complexité de la tâche. Ils ont donc eu recours au meilleur outil utilisé par les méthodes agiles pour faire face à la complexité et l'incertitude : un processus empirique. Pendant 7 ans, ils ont testé des idées, gardé ces dernières si elles s'avéraient utiles, les ont rejeté ou adapté dans le cas inverse. Pour aboutir à une première version publiée et partagée en 2009. Inutile de préciser le degré de pragmatisme et d'efficacité de cette technologie conçue selon une telle approche.

Une technologie applicable à n'importe quel secteur, n'importe quelle échelle et tenant compte des réalités du monde d'aujourd'hui devenu si complexe et incertain. Une technologie pouvant donner à une entreprise un degré d'agilité sans précédent tout en libérant les énergies et l'engagement des collaborateurs. Chacun y trouve donc son compte. Direction, actionnaires et collaborateurs.

Mais Holacracy ou l'holacratie, c'est quoi au juste ?

Holacracy, c'est quoi encore ce non barbare ? Il vient du mot "holarchie" qui décrit l'encapsulation d'élément(s) autonome(s) dans d'autres élément(s) autonomes de façon fractale. Ce qui caractérise une organisation holarchique par opposition à une organisation hiérarchique classique.

Quid du manager et du leadership en Holacracy ?

Etant particulièrement sensible au thème du management et étant moi même manager, la question de la place du manager dans une organisation fonctionnant en Holacracy n'a cessé de m'obséder durant les lectures et formations que j'ai pu suivre à propos de cette technologie. Avant d'y répondre, faisons un petit état des lieux des responsabilités généralement associées au manager dans le monde d'aujourd'hui.

Pour commencer, lorsque l'on devient manager, nous ne sommes plus seulement responsable de nous même mais aussi des autres, de son équipe. Nous devons donc fixer des objectifs, contrôler le travail et assurer le reporting de l'activité associée, au niveau hiérarchique supérieur. On prend généralement des engagements de délais voire de budget à respecter. On assure le suivi "RH" de ses collaborateurs : évolution de carrière, formation, augmentations & primes, etc. Nous devons souvent intervenir pour gérer toutes sortes de problèmes organisationnels, techniques, humains, etc. Bien sûr, nous devons définir la meilleure organisation possible pour être efficace. Parfois ou souvent, nous devons mettre à profit notre expertise pour des sujets pointus ou à fort enjeux. On attend souvent de la part du manager qu'il ait réponse à tout. Omniscient et omnipotent. Par ailleurs, dans le monde d'aujourd'hui, chaque service devient de plus en plus dépendant des autres,  la transversalité devient un enjeux fort, nous devons également assurer la coordination avec nos pairs et leurs équipes. Nous devons aussi faire redescendre l'information venant d'en haut et des "côtés" (autres équipes).

C'est déjà pas mal non ? Est ce bien raisonnable d'ailleurs ? Ne sommes nous pas en train de demander à ce manager d'être un véritable super héros (sans les super pouvoirs....) ?

Combien de temps reste t'il à ce manager - qui passe probablement beaucoup de temps à traiter ses mails ou en réunion - pour écouter les difficultés ou idées d'amélioration de son équipe pour les traiter ou les mettre en oeuvre ? Et quid de notre monde qui bouge et pousse les entreprises à se transformer en profondeur ? N'a t'on pas cruellement besoin des managers pour réaliser cette transformation ? Comment faire avec des managers saturés et souvent en souffrance ?

La réponse de Holacracy à ce problème ? Décharger le manager des tâches sur lequel sa valeur ajoutée est faible et remettre à profit son expertise pour des tâches à plus forte valeur ajoutée pour l'entreprise et lui même.

Ok, c'est bien beau tout ça, mais on arrive à la fin de l'article et on n'en sait pas beaucoup plus sur le fonctionnement concret de Holacracy. En effet, c'est ce que nous verrons dans un prochain article maintenant qu'on vient de poser le décor 😉

D'ici là, dites moi - via le formulaire situé en bas de cette page - ce que vous voulez absolument savoir à propos de Holacracy. J'essaierai de vous répondre au mieux dans le prochain article ou directement dans les commentaires.​

La théorie des contraintes : augmenter son rendement, diminuer son lead-time

Une belle théorie enveloppée dans un roman sympathique

Une lecture aussi enrichissante que distrayante

Réduire radicalement ses encours de développement et augmenter sa productivité pour un investissement minimum : telle est la promesse de la théorie des contraintes. Si l’on ajoute que cette méthode est simple et particulièrement compatible avec une approche agile dans une équipe logiciel, cela fait suffisamment de raisons pour la regarder d’un peu plus près.

La théorie des contraintes (ou ToC pour les habitués) ne date pas d’hier. A la manière du Lean, elle est née dans l’industrie il y a plus de 30 ans et n’a été importée dans le monde du développement que récemment, notamment à l’initiative de partisans de l’Agile. La bible des aficionados de la ToC s’appelle « le But », un roman d’entreprise remarquablement construit qui explique avec une clarté peu commune ses principes et sa mise en oeuvre. Son auteur, Eliahu Goldratt, a ensuite perfectionné son modèle et étendu cette approche au monde des services dans une douzaine d’ouvrages.

Continuer à lire

1

Gestion de Projet Simple (GPS)

Introduction

Cet article vise à décrire un cadre méthodologique de gestion de projet simple. Il s’adresse à toute association de personnes (équipe) désireuses de mener un projet quel qu’il soit aboutissant à ce qu’on appellera par abus de langage un “Produit”. Les membres de l’équipe peuvent travailler à temps plein ou partiel, partager un même lieu de travail ou non et participer à l’ensemble des étapes du projet avec ou sans hiérarchie.

Étapes du projet

Définir la vision du “Produit”

Le projet débute par la formalisation de la vision du “produit fini” faisant l’objet du projet. Elle a pour principal objectif de mettre l’ensemble des acteurs sur la même longueur d’onde et de les guider dans les choix et les décisions qu’ils seront amenés à prendre tout au long du projet. Le travail sur la vision consiste principalement à répondre aux questions « Pourquoi réalise t’on ce produit ? », « A quel public s’adresse t’il ? », etc.

Construire et ordonnancer le “Product Backlog”

Une fois que la vision est partagée et claire pour tout le monde, il est temps de faire la liste de toutes les tâches – connues à date – nécessaires à la réalisation du “Produit”. Cette liste appelée “Product Backlog” peut être modifiée/complétée tout au long du projet.

Les éléments du Product Backlog sont ordonnancés de manière à mettre en haut de la liste – dans la mesure du possible (cf. dépendance entre les tâches) – les tâches bénéficiant du meilleur rapport « Valeur ajoutée au produit” / « Coût de mise en oeuvre ».

Diviser le temps

Afin de planifier le projet, la durée totale estimée du projet est divisée en blocs de temps successifs d’une durée fixe et courte appelés “Sprints” (en général 2 à 4 semaines).

Planifier le sprint

Les tâches prioritaires du Product Backlog (en haut de la liste) sont sélectionnées par l’équipe pour alimenter la liste des tâches du Sprint sur le point de commencer. Elle réalise cette sélection en fonction de sa capacité à les réaliser dans le délais du sprint (dès que l’équipe estime que ça ne rentre plus, elle arrête sa sélection).

Exécuter le sprint

Durant le sprint, chaque membre de l’équipe prêt à commencer une tâche, s’affecte cette dernière et la passe au statut “En cours”. Une fois terminée, il la passe au statut “Terminé”. Il peut alors s’affecter une nouvelle tâche de son choix au statut “A faire” jusqu’à épuisement des tâches du Sprint. Voir paragraphe : “Outil associé” pour plus d’explications et d’illustrations.

Revue de sprint et nouveau sprint

A la fin de chaque Sprint et quelque soit son avancement, l’équipe fait le bilan des travaux réalisés au cours de ce dernier et définit un plan d’action susceptible de rendre le prochain Sprint plus efficace, agréable, qualitatif et productif. De cette façon, le processus de réalisation du produit est sans cesse amélioré. La Planification du Sprint suivant s’enchaîne et ainsi de suite jusqu’au dernier Sprint aboutissant au “produit final” ou à sa nouvelle version.

Schéma du processus de gestion de projet simple

Schéma du processus de gestion de projet simple

Outil associé

Le principal outil associé est un “Tableau des tâches” virtuel composé à minima de 3 colonnes liées aux 3 statuts de base d’une tâche :

  • A Faire : La tâche n’est pas commencée et non affectée à un membre de l’équipe
  • En cours : Un membre de l’équipe s’est affecté la tâche et l’a commencé
  • Terminé : La tâche est terminée

Les tâches sont déplacées d’une colonne à une autre en fonction de leur avancement. Ce tableau permet à toute l’équipe de connaître en temps réel l’état des lieux du sprint en terme d’avancement.

Outil Trello

Tableau des tâches sur Trello dans le navigateur web

L’outil Trello a le mérite d’être simple, gratuit, web et utilisable sur un mobile sans rien installer. Son seul inconvénient est qu’il est en anglais mais le titre des colonnes reste personnalisable.

Reste à prévoir un outil pour gérer le Product Backlog. Un simple tableau Google Sheets peut faire l’affaire.

L’outil iceScrum est une autre alternative simple, complète, en français, gratuite et plutôt fun. Elle nécessite en revanche une installation sur un serveur.

Pour une équipe partageant un même espace de travail, un tableau des tâches physique mural avec un post-it par tâche peut être plus simple et efficace (l’informatique n’est pas toujours LA solution). Idem pour le Product Backlog qu’on rendra ainsi plus visuel, transparent et plus facile à ordonnancer (simples déplacements de postit).

Informations complémentaires

Ce n’est qu’un cadre méthodologique

Ce cadre méthodologique ne fait que définir les règles du jeu de base et n’a pas pour vocation de dicter à l’équipe la façon de réaliser les tâches et de s’organiser (ce qui est souvent spécifique au contexte de chaque projet). Il définit simplement un processus itératif offrant régulièrement à l’équipe l’occasion d’améliorer son organisation et de trouver elle même les solutions à ses éventuels obstacles (lors de la revue de sprint). Le projet peut ainsi démarrer très vite avec une organisation légère qui s’affinera au fil des sprints.

Tailles d’équipe

Ce cadre méthodologique s’adresse à des équipes de 2 à 9 personnes. Au delà, la coordination est plus compliquée, il est donc recommandé de former plusieurs équipes de 5 à 9 personnes. Chaque équipe disposant de son tableau des tâches de sprint alimentées à partir d’un Product Backlog commun à toutes les équipes du projet ou plusieurs. Par ailleurs, une synchronisation des sprints (commencent et se terminent en même temps quelque soit l’avancement) de chaque équipe offre pas mal d’avantages en terme de planification et d’intégration du travail de chaque équipe.

Origine et aide à la mise en oeuvre

Ce cadre méthodologique s’inspire ouvertement du cadre méthodologique préexistant Scrum créé pour le développement logiciel. Voir mini guide Scrum. Le livre électronique “Scrum & XP depuis les tranchées” (gratuit) – bien que venant du monde du développement logiciel – peut apporter des conseils précieux dans la mise en oeuvre de la présente méthodologie. Si vous souhaitez aller plus loin dans l’adoption de Scrum, j’ai pris soin de conserver le vocabulaire. Ainsi vous ne serez pas perdu en approfondissant le sujet. Pour vous accompagner dans cette démarche, je vous invite à lire le guide de démarrage Scrum.

Glossaire

  • Product Backlog : liste des tâches à réaliser pour aboutir au “Produit” ou au moins une première version de ce dernier.
  • Tâches du Sprint : liste des tâches à réaliser sur la durée du Sprint uniquement. Cette liste est donc un sous ensemble du Product Backlog.
  • Planification de Sprint : étape consistant à sélectionner des tâches prioritaires du Product Backlog à réaliser au cours du Sprint sur le point de commencer.
  • Produit : résultat auquel le projet aboutit (objet, film, logiciel, bâtiment,…)
  • Revue de Sprint : étape marquant la fin d’un sprint au cours de laquelle l’équipe inspecte son avancement, l’état du “Produit” et réfléchit aux moyens de s’améliorer.
  • Sprint : bloc de temps d’une durée fixe et courte (2 à 4 semaines) durant laquelle l’équipe réalise un sous ensemble des tâches à réaliser pour aboutir au “Produit” visé.
  • Vision : description du “Produit” final tel qu’imaginé par l’équipe pour guider cette dernière dans ses choix.

Devenir une Dream Team – Partie 2

Lors de l’épisode précédant, nous avons vu les différents principes qui entourent la culture d’une organisation ou tribu et en quoi la faire émerger peut libérer une énergie précieuse pour faire de cette dernière une Dream Team. Une tribu qui obtient des résultats encore jamais atteints grâce à davantage de sens et de motivation. Sens et motivation principalement alimentés par les valeurs fondamentales et la noble cause ou mission de cette tribu. Dans cette seconde partie, nous allons voir ensemble quelles sont les différentes techniques qui s’offrent à nous pour identifier ces valeurs.

La bonne nouvelle pour les organisations agiles

Le travail sur les valeurs fondamentales et la mission de la tribu nécessite un état d’esprit collaboratif dans lequel le « nous » domine dans le langage utilisé plutôt que le « je ». C’est ce qui correspond au stade 4 du tribal leadership. Si la tribu n’en est pas à ce stade, il sera sans doute préférable de commencer par utiliser les leviers permettant d’y parvenir (voir article « introduction au leadership tribal »). La bonne nouvelle, c’est que si les membres de votre tribu ont déjà adopté l’état d’esprit agile et Scrum en particulier, le stade 4 est potentiellement déjà acquis. Difficile en effet de faire de l’agilité sans esprit d’équipe.

Techniques d’émergence des valeurs

Il existe plusieurs techniques permettant de faire émerger ses propres valeurs fondamentales, celles d’une autre personne ou encore celles d’un groupe. Nous allons explorer ces différentes techniques selon ces trois cas de figure.

Rechercher ses propres valeurs

Voici deux techniques vous permettant d’identifier vos propres valeurs. Sachez que vos valeurs peuvent être différentes de celles de votre entreprise, cependant elles doivent être alignées avec ces dernières.

Technique des plaisirs et colères

Posez vous dans un endroit calme, prenez quelques respirations profondes et posez vous la question « qu’est ce qui me plait dans mon travail ? ». Si votre réponse manque de profondeur (au sens où elle ne révèle pas de valeur), répondez à votre réponse par la question : « Pourquoi ? » et recommencez autant de fois que nécessaire. Voici un exemple de dialogue intérieur : « Qu’est ce qui me plait dans mon travail ? Les challenges qu’il m’apporte. Pourquoi ? Parce que j’aime apprendre continuellement. ». Dans cet exemple, la valeur identifiée est de l’ordre du développement personnel.

Inversement, vous pouvez faire une recherche en utilisant le levier de la colère avec une question du type : « Quelle situation me met en colère ou me frustre dans mon travail ? ». Après votre réponse, posez vous la question « Quel besoin fondamental n’a pas été couvert dans cette situation ? ». Il y a des chances pour que votre réponse vous mette sur la voie d’une valeur.

Technique des montagnes et vallées

Tony Hsieh Mountains and Valleys

Montagnes et vallées de Tony Hsieh (créateur de Zappos). Chaque numéro rouge fait référence à une valeur (voir légende).

La technique des montagnes et vallées consiste à se remémorer les fait marquants positifs et négatifs vécus sur la période explorée et en déduire les valeurs associées.

Prenez une feuille de papier A4 en mode paysage et tracez un axe de temps horizontal qui coupe la page en deux par le milieu. Réfléchissez maintenant aux évènements marquants de votre vie personnelle et professionnelle. Positionnez les évènements positifs au dessus de l’axe de temps et les négatifs en dessous. Plus un évènement sera positif, plus il sera haut et plus un évènement sera négatif, plus il sera bas. Poursuivez ensuite votre introspection pour identifier la ou les valeurs associées à chaque évènement. Dans le cas d’un évènement négatif, il s’agit de la valeur associée à un besoin non respecté.

Liste des valeurs associées à l’illustration ci-dessus à titre d’exemple :

  1. Participer avec créativité à quelque chose qui nécessite non seulement vous mais également d’autres personnes pour réussir; le groupe est toujours meilleur que la somme de chacun des membres.
  2. Seek out tribal (level) connectedness; this is where the spiritual resides (non traduit pour éviter de perdre le sens de la phrase).
  3. Vivre avec passion.
  4. Avoir une vision.
  5. C’est seulement quand vous êtes complètement libre que vous êtes le meilleur de vous même.
  6. Combattre l’inertie – Chercher du sens dans chaque activité.
  7. Rencontrer et traiter les personnes avec la philosophie PLUR.
  8. L’expérience compte davantage que les biens matériels.

Voici le guide d’utilisation de la technique des montagnes et vallées (en anglais).

Retenez les valeurs fondamentales et donnez leur du sens

Réduisez ensuite le nombre de valeurs à une quantité de 3 à 5. Retenez celles qui comptent le plus pour vous. Et si ce n’est pas déjà fait, formulez une phrase qui clarifie cette valeur. Un mot seul ne suffit pas. La valeur Honnêteté par exemple peut être interprétée de plusieurs façons. Est ce qu’on entend par là l’idée de dénoncer toutes attitudes malhonnêtes ou de faire preuve de franchise. La phrase suivante donne davantage de sens : « Dire les choses telles qu’elles sont. Même quant elles vont mal et même si la personne a qui on s’adresse est un responsable ou client ».

Commencez par un verbe qui associe cette valeur à l’action.

Rechercher les valeurs d’une autre personne

Vous pouvez également être amené à vouloir identifier les valeurs d’une autre personne que vous. C’est d’ailleurs l’occasion d’établir une relation plus profonde avec cette personne. Voici une technique utile dans ce cas de figure. Etant donné qu’elle se base sur une conversation, à vous de la rendre la plus naturelle possible. Il ne s’agit pas d’un entretien formel.

Technique du click

La technique du click consiste à provoquer une conversation avec la personne de votre choix et elle seule afin d’identifier ses valeurs fondamentales. Inutile de préciser que l’écoute est primordiale. A vous de vous taire, à part bien sûr pour poser des questions ;-). Vos questions doivent être ouvertes. Vous pouvez par exemple entrer en matière avec « Peux tu me citer une chose que tu apprécies particulièrement dans ton travail ? ». Vous devez analyser la réponse et identifier un mot clef sur lequel vous allez « clicker » comme si c’était un lien hypertexte. Exemple de réponse « Les challenges que je dois relever ». Clickons sur le mot « challenge » : « Pourquoi les challenges sont importants pour toi ? »… Une fois que vous arrivez à une situation de rire nerveux, de silence prolongé ou de réponse du genre « Parce que c’est comme ça ». C’est que vous avez sans doute identifié la valeur associée.

Rechercher les valeurs d’un groupe

Il est également possible d’établir les valeurs fondamentales d’un groupe. L’expérience peut même être très rapide. Il faudra cependant laisser décanter le fruit de cette expérience quelques jours, voire davantage. Afin de s’assurer de ne pas être passé à côté d’autres valeurs et d’être certains que c’est sur ces valeurs que le groupe reposera à long terme. Ces valeurs serviront notamment à prendre des décisions conditionnant l’avenir du groupe.

Exemple d'utilisation de la technique des montagnes et vallées sur un groupe (en anglais)

Exemple d’utilisation de la technique des montagnes et vallées sur un groupe (en anglais)

La technique des montagnes et vallées peut servir dans ce cas de figure. Moyennant quelques adaptations puisque le travail d’introspection va impliquer le groupe dans son ensemble. Précisons également que le groupe impliqué dans cette expérience doit être de stade 4 (selon les stades du tribal leadership). Si ce n’est pas le cas, l’expérience risque de ne pas être suffisamment collaborative et fructueuse. Une fois votre groupe réuni (sur invitation et non pas sur ordre), utilisez un tableau blanc (ou tout support équivalent), tracez l’axe de temps représentant la période la plus appropriée (de la naissance du groupe ou de l’organisation à aujourd’hui par exemple) et demandez à chacun de faire appel à sa mémoire pour retrouver les évènements professionnels marquants vécus par chacun. Chacun peut noter les évènements en question sur des post-it (un par post-it) et les positionner sur le tableau blanc. Il peut y avoir des doublons d’une personne à une autre et un même évènement peut être vécu positivement par une personne (positionnement au dessus de l’axe du temps pour rappel) ou négativement par une autre (positionnement au dessous de l’axe de temps). Chacun peut s’exprimer sur sa perception de l’évènement soulevé. Cette technique est souvent utilisée en rétrospective sur une période généralement plus courte. Une fois cette première phase exécutée, vous pouvez inviter tout le monde à prendre une pause de quelques minutes. Après la pause, il s’agit d’identifier – selon les même leviers cités précédemment – les valeurs associées aux évènements recensés lors de la première phase.

Voir l’exemple ci contre.

Démarches possibles

Voyons maintenant comment mettre en musique ces techniques. Une approche consiste à partir du leader tribal. Supposons que ce soit vous. Vous allez commencer par déterminer vos propres valeurs fondamentales avec la ou les techniques appropriées déjà décrites. Une fois au clair avec vous même, vous allez vous rapprochez des personnes de votre réseau qui devraient selon vous partager vos valeurs. Pour vous en assurer, vous allez sans doute provoquer des conversations avec ces personnes en utilisant la technique du click. Vous allez peut être découvrir d’autres valeurs qui viendront compléter votre liste. Affinez cette dernière en limitant le nombre de valeurs, de façon à retenir uniquement les valeurs fondamentales, formulez des phrases complètes commençant par un verbe afin de clarifier le sens des valeurs (voir exemples et explications détaillées plus haut). Partagez cette liste avec les membres de votre tribu, demandez des feedbacks. Invitez les à participer à un atelier de discussion sur le sujet au besoin.

Une fois que ça vous semble mûr, il est temps de prendre l’engagement formel de respecter ces valeurs quoi qu’il arrive et d’aller de l’avant tous ensemble. Il ne s’agit pas d’un engagement à la légère. En tant que leader, si vous rompez par la suite cet engagement, c’est toute cette énergie tribale que vous aurez libéré que vous risquez de perdre quasi instantanément.

Une démarche plus directe peut consister à utiliser la technique des montagnes et vallées en groupe ou d’utiliser une rétrospective ayant pour objectif la définition des valeurs fondamentales du groupe. Cette rétrospective pourrait comporter une phase de recueil des valeurs de chacun  suivie d’une phase de pondération permettant de retenir les valeurs fondamentales communes.

Dernier conseil avant de se quitter. Déterminer une valeur fondamentale maîtresse peut contribuer à la cohérence des valeurs fondamentales retenues ou à retenir. De nos jours, un bon exemple de valeur fondamentale maîtresse pourrait être « Etre une organisation apprenante ».

Valeurs fondamentales de l’Agiliste

Au passage, voici les valeurs fondamentales de l’Agiliste :

[list icon= »star »] [list_item]Partage des connaissances : Partager les connaissances acquises pour que d’autres personnes en bénéficient et que l’usage des pratiques sous-jacentes se diffusent le plus largement possible afin d’améliorer la vie au travail et les résultats.[/list_item] [list_item]Open Source : Ouvrir les contenus éditoriaux de l’Agiliste grâce à une licence Creative Commons. Ce qui signifie que chacun est libre de les utiliser, modifier et communiquer à la seule condition de citer l’auteur avec le lien de la page de l’auteur. Le présent site internet repose lui même sur le CMS Open Source WordPress.[/list_item] [list_item]Transparence : Faire preuve de transparence. Les statistiques de fréquentation du site sont rendues publiques et peuvent être consultées sur la page dédiée. Le nombre d’abonnés à la newsletter est également visible dans le formulaire d’inscription.[/list_item] [list_item]Pas de bannières de publicité : Offrir un certain confort d’utilisation de ce site en renonçant notamment aux bannières de publicité.[/list_item] [list_item]Honnêteté : Communiquer de façon franche, honnête et sans dogmatisme. Ne se soumettre à aucune autorité ou influence de la part de qui que ce soit (éditeur, société de conseil/services, gourou ou autre).
[/list_item] [/list]

Ces valeurs servent la mission suivante : « Contribuer à augmenter le plaisir au travail et les résultats ».

Source : page « A propos ».

Vous allez peut être me trouver terriblement curieux et indiscret mais…

Et vous, quelles sont vos valeurs fondamentales ?

5

Devenir une Dream Team – Partie 1

Dans l’introduction au leadership tribal, nous avons vu les 5 niveaux d’évolution d’une tribu. Le niveau 5 permettant « d’écrire l’histoire » en obtenant des résultats encore jamais atteints. Les membres d’une telle Dream Team n’ont pas besoin d’un leader pour les motiver, leur dire quoi faire, comment le faire et se donner à fond. Ils se sentent partie prenante de l’organisation et puisent leur énergie dans la « noble cause » ou « mission » et les valeurs fondamentales qu’ils ont contribué à établir et contribuent à faire évoluer.

Leur environnement de travail est d’une si grande qualité que le turn-over est minime et que la qualité du travail est optimale. Ils travaillent dur et « jouent dur ». Le principe est simple, si on prend soin du personnel, le personnel prend mieux soin des clients de l’organisation. Comme dans la vie, si je prends soin de moi, je m’occupe mieux de mes proches. Pensez aux consignes de sécurité en avion : « Mettez d’abord votre propre masque à oxygène avant de vous occuper des autres, sinon vous risquez de ne pas être d’un grand secours ».

Très bien, mais comment parvenir à une telle culture ? Comment devenir une Dream Team ? C’est justement l’objet de cette série d’articles. Largement inspirée d’une digestion lente des livres « The Culture Blueprint » de Robert Richman, de « Tribal Leadership » de Dave Logan et d’expériences personnelles vécues auprès d’équipes de développement logiciel.

Les leviers du tribal leadership

Si vos souvenirs sont lointains ou si vous n’avez pas encore lu mon article d’introduction au leadership tribal, je vous invite à le faire maintenant. Vous y trouverez les leviers associés au passage d’un niveau à un autre. Et rappelez vous bien, il s’agit d’accompagner chaque personne individuellement en adoptant un langage qu’elle peut comprendre (de son niveau ou supérieur) et de ne pas sauter un niveau car chaque niveau s’appuie sur les acquis du précédant.  Vous y trouverez aussi la « stratégie » mettant en musique les valeurs fondamentales de la tribu, sa noble cause, les résultats qu’elle vise ainsi que ses actifs et actions.

La suite de cette fiche décrit une approche sensiblement différente et complémentaire au tribal leadership pour comprendre les principes liés à la culture poser les bases. Elle est davantage orientée sur le « comment faire ». On la doit à Robert Richman ayant travaillé sur la culture de Zappos. Pour l’anecdote, Robert Richman a également fait parti de l’équipe à l’origine du Tribal Leadership. C’est aussi ce qui explique la complémentarité.

Par où commencer ou par qui ?

Vous vous dite peut être qu’un tel changement ne peut venir que d’un responsable que vous devrez convaincre. De celui de votre équipe, de votre département, de votre entreprise ou de votre organisation. En réalité, il y a de fortes chances pour que la meilleure personne pour entreprendre cette expérience, ce soit vous. Ce n’est sans doute pas par hasard si vous êtes en train de lire cet article, si son titre vous a attiré dans les résultats d’un moteur de recherche ou qu’une personne vous en ai parlé. Toutefois, vous aurez peut être à convaincre un responsable ou sponsor afin d’avoir le champ libre pour agir. Vous aurez peut être aussi besoin d’un mentor pour vous aider à prendre du recul et vous ressourcer.

Peut être que vous vous dites aussi que vous n’êtes pas un leader. Que vous n’avez pas le charisme nécessaire, etc. Détrompez vous, un leader est simplement une personne qui rassemble d’autres personnes et des ressources autour d’un objectif motivant. Trouvez ces personnes, parlez leur de votre projet (en triade idéalement) et prenez la température. Il ne s’agit pas d’un projet planifié dans le temps, ni d’une stratégie, mais d’une expérience. Et pour le charisme, dites vous bien que ça ne vient pas forcément du physique, de la stature, de la capacité à communiquer mais plutôt de vos valeurs, de votre intégrité et du profond respect pour les personnes qui vous suivent.

Evidemment, bien que l’aventure soit passionnante, ce ne sera probablement pas un long fleuve tranquille. La performance risque même de baisser à court terme (comme lorsqu’on met en place l’agilité d’ailleurs).

Alors toujours partant ?

Commençons par un peu théorie si vous voulez bien. C’est vraiment utile pour mieux comprendre la logique sous-jacente et adapter la démarche lorsque c’est nécessaire. Je vous rassure, il s’agit de théorie pragmatique comme dans l’agilité.

Les 7 principes de la culture

La culture est co-créée

Une culture ne peut être créée par une personne. Quoi que vous fassiez, ce qui fera la culture de votre organisation sera le fruit du comportement conscient ou non des membres de cette organisation. Il s’agit ici de créer cette culture AVEC ces membres et de le faire consciemment. D’autant plus que nous donnons de l’importance à ce à quoi nous participons. Par exemple, nous prenons  bien plus de plaisir à déguster un repas auquel nous avons participé en groupe, qu’un repas entièrement préparé pour nous.

Voici un exemple de processus de co-création :

  1. Rassembler le groupe.
  2. Prendre du recul est définir clairement ce que vous êtes en train de faire et POURQUOI.
  3. Demander à tout le monde ce que cette initiative provoque en eux sur le plan émotionnel.
  4. Demander leur idées pour créer cette expérience. Les laisser parler plus que vous.
  5. Noter les idées qui apportent beaucoup avec peu d’effort.
  6. Demander qui est emballé par quelle idée et serait prêt à s’engager sur une prochaine action devant ses pairs.

Partagez ce que vous voulez garder

Partagez sa culture est un bon moyen de renforcer votre intégrité et responsabilité. Vous craigniez de divulguer vos secrets de fabrique en divulguant votre culture. Rassurez vous, la culture est une question d’individus et les individus ne peuvent être copiées. Vous pouvez ainsi générer de l’appréciation du monde extérieur qui vous rappelle à quel point vous avez de la chance de vivre votre culture. Ce qui est plutôt galvanisant. De plus, partager quelque chose et en faire une habitude génère une culture du don.

La culture se nourrit de la culture

Vous allez vivre des moment forts au cours de votre expérience sur la culture. Enregistrez ces moments (photos, vidéos, etc) et partagez ces enregistrements. Il y a un amateur de montage vidéo dans votre groupe ? proposez lui de faire un montage pour l’occasion. Il y a une personne qui s’y connait en blog ? proposez lui d’en créer un sur votre tribu/culture et d’y poster les photos et vidéos. Cet échange autour de votre culture redonne de l’énergie à votre culture.

La culture mange de la stratégie au petit déjeuner

Cette formule n’est pas de moi. Elle signifie qu’un patron ou leader peut disposer de la meilleure stratégie au monde pour atteindre les objectifs qu’il s’est fixé, elle ne pourra jamais porter ses fruits si elle n’est pas alignée avec la culture de l’organisation. Je parle bien sûr de la vraie culture souvent invisible et non pas des valeurs « Marketing » affichées sur le site internet de l’entreprise.

La culture est un jeu

On se demande parfois pourquoi une équipe ne se donne pas à fond. Il arrive même qu’on la juge faignante ou de génération Y. Ou en tant que manager, on se dit qu’on inspire pas assez. Et si on faisait de notre culture un jeu ? Changeant ainsi notre rapport au travail.

Un jeu bien défini comporte :

  • Un objectif clair (exemple : « devenir l’équipe agile de référence au sein de l’entreprise »),
  • Des règles du jeu claires (exemple : les valeurs fondamentales de l’équipe),
  • Un moyen de connaître son score/feedback (ex : indicateurs de performance, indicateur d’épanouissement au travail, indicateur de satisfaction des utilisateurs),
  • La possibilité de « passer » (ex : les personnes qui ne veulent pas jouer le jeu peuvent demander à travailler sur un autre projet).

Petite parenthèse agile au passage : le cadre méthodologique Scrum se prête également bien à une approche par le jeu. La définition du rôle des joueurs est claire ainsi que les règles du jeu, la mesure du score (indicateurs d’avancement de sprint et de release) et les objectifs (de sprint et de release).

La monnaie de la culture

Imaginez que vous travailliez dans mon équipe sous ma responsabilité et que je vous dise que le support production (activité de « dépannage » des utilisateurs finaux en difficulté avec la solution livrée) est très important. Que ressentez vous ? Vous sentez vous sensibilisé(e) et prêt(e) à vous donner à fond pour que le support production soit optimal ? Pas vraiment. Peu de personnes apprécient qu’on leur dise quoi faire.

Si par contre je vous raconte l’histoire d’un utilisateur qui n’est pas parvenu à utiliser la solution, s’est retrouvé ainsi bloqué plusieurs heures au travail alors qu’il devait amener sa fille malade chez le médecin. Et que je voudrai faire tout ce qui est en notre pouvoir pour éviter que cette situation se re-nouvelle. Y compris de réfléchir avec vous aux améliorations qu’on peut mettre en oeuvre.

Cette fois, que ressentez vous ? Il y a de fortes chances pour que l’histoire de cet utilisateur et sa fille malade vous touche et vous pouvez également ressentir les valeurs humaines qui m’animent. Vous pouvez aussi sentir que je ne cherche pas de coupable ou à vous dire quoi faire. N’est ce pas plus motivant ?

La monnaie de la culture, ce sont ces histoires qui véhiculent des valeurs et donnent du sens à ce que nous faisons au quotidien.

Nouvelle parenthèse agile : Il est intéressant de noter que les pratiques des Personnas et User Stories peuvent utiliser ce même levier pour donner plus de sens à notre travail sur un projet de développement logiciel. Je sors bien sûr du registre du travail sur la culture pour cette parenthèse.

Le secret de l’innovation

Dans un monde qui bouge, l’innovation est quasi incontournable. Quel risque prenez vous à innover en proposant une nouvelle idée, en essayant une nouvelle technologie, en proposant une nouvelle méthodologie ou algorithme ? Vous pouvez vous tromper et craindre le jugement ! Par conséquent, quelle est la condition indispensable à l’innovation ? Une culture du droit à l’erreur.

Une erreur apporte avec elle un enseignement. Une piste de plus à éliminer pour nous rapprocher davantage de la solution. Célébrez vos erreurs ! Montrez que l’erreur est permise.

Poser les bases

Définir votre mission

Trouvez la mission de votre organisation. La mission doit répondre à la question « Pourquoi je vais travailler chaque jour ? ». Elle doit s’adresser à la fois au monde extérieur et à l’intérieur de votre organisation ou tribu. Elle doit également véhiculer une émotion. Prenons deux exemples. La mission de Zappos (vendeur de chaussures et autres articles annexes sur internet) est « Live and deliver WOW! » (« vivre et fournir du Wouah ! »). Autre exemple inventé par mes soins : “Fournir du logiciel que les gens adorent. Et prendre du plaisir à le faire”.

Si je prends le second exemple, la partie « prendre du plaisir à le faire » est essentielle. L’idée déjà évoqué un peu plus haut, est que pour prendre soin des autres, il faut avant tout prendre soin de soi. Par conséquent, pour que les membres d’une organisation prennent soin de ses clients (ou utilisateurs du logiciel), ils doivent prendre soin d’eux en prenant du plaisir à travailler en plus d’une vie personnelle épanouie.

Ce point est également valable pour le leader souhaitant travailler sur la culture. Il devra veiller à ne pas faire cette démarche pour compenser un vide dans sa vie personnelle. Si tel était le cas, il devra d’abord prendre soin de lui sur le plan personnel avant de travailler sur la culture avec les membres de son organisation. S’il ne le fait pas, ces derniers vont sentir ce vide à combler et ne seront pas réellement impliqués.

Définir votre vision

Une vision permet aux membres de l’organisation de s’y projeter. Pour cela, elle doit pouvoir se concrétiser sur un horizon relativement court de 2 à 5 ans. Une fois qu’une vision s’est concrétisée, il ne reste plus qu’à en trouver une autre.
Reprenons l’exemple de Zappos dont les visions successives et atteintes furent :

  • Vision 1 : Plus gros magasin de chaussures au monde
  • Vision 2 : Meilleur service au monde

La vision se construit sur les acquis de la précédente, elle est courte, facile à mémoriser et elle inspire. Autre exemple au passage : la vision des auteurs du livre Tribal Leadership était devenir un best seller (et ils ont atteint cette vision).

Pour identifier cette vision, voici une question qui peut vous mettre sur la voie : “Que ferions nous si nous pouvions faire l’impossible ?”.

Les valeurs fondamentales

Geyser erruption. IcelandVous ignorez quelles sont les valeurs fondamentales de votre tribu ou organisation (là encore, je ne parle pas des valeurs “marketing” de votre entreprise) ? Pourtant elles sont déjà là comme une source sous vos pieds prête à jaillir. Chacun est guidé au quotidien par ses propres valeurs. Reste à les faire émerger, découvrir les valeurs en commun. Certes, vous découvrirez peut être quelques conflits de valeurs d’une personne à une autre, d’une personne vis à vis de la majorité du groupe ou de l’entreprise. Mais après tout, mieux vaut tard que jamais, plutôt que de vivre dans l’illusion.

Ok mais pourquoi établir ses valeurs ?

Parce que les valeurs émergeant de ce travail collectif offrent un cadre de travail souple qui aide à la prise de décision, favorise l’auto-organisation, donne du sens. Un cadre ouvert à l’interprétation qui considère les gens comme des adultes qui ont besoin d’inspiration plutôt que de micro-management. Ces valeurs donnent une identité au groupe, un ADN qui renforce le sentiment d’appartenance. En contrepartie, certaines décisions peuvent être rendues difficiles. Comme renoncer à un business juteux en décalage avec les valeurs de l’organisation ou se séparer d’une personne en conflit avec ces dernières. Dans ce dernier cas, rien ne nous empêche d’accompagner cette personne dans une autre voie, en l’aidant financièrement, en lui offrant d’autres pistes d’évolution dans une autre équipe ou département (dans le cas d’une grosse entreprise). Inversement, ces valeurs vont attirer les bonnes personnes pour votre organisation. Des personnes qui se reconnaissent à travers ces valeurs que vous véhiculez et qui sont sans doute prêtes à se donner à fond.

Mettre en action vos valeurs

Mais encore faut’il mettre en action ces valeurs. L’approche qui a fonctionné pour Zappos se déroule 3 étapes :

  1. Définir un « standard » basé sur la valeur que vous voulez offrir sans compromis. Pour Zappos, il s’agit de mettre en place le standard « Wouah ! » en offrant une qualité de service exceptionnelle.
  2. Faire une promesse audacieuse à la fois aux clients ou commanditaires et aux membres de l’organisation. Pour Zappos il s’agissait d’expédier la commande dès le lendemain.
  3. Tenir cette promesse quelque soit l’état du marché.

Zappos a du renoncer à des parts de marché importantes en renonçant à travailler avec certaines marques qui souhaitaient expédier eux même, à leur rythme, les commandes. A court terme, les revenus ont baissé de façon très significative. Mais à long terme la situation s’est inversée. Le client est prêt à payer le prix fort pour un « standard » sur lequel il peut compter.

Encore une fois, Zappos n’est qu’un exemple pour illustration. Vous pouvez éprouver quelques difficultés pour vous projeter selon votre contexte. Vous ne vendez peut être pas de chaussures ni quoi que ce soit de ce genre. Mais votre équipe, département ou organisation a bien des clients, des utilisateurs, des personnes qui utilisent vos services.

Avant de faire votre promesse audacieuse, vous devez connaître vos valeurs fondamentales. Comment les faire émerger sera l’objet du prochain article.

 

J’espère que cette fiche vous a été utile. Maintenant il y a quelque chose que je voudrai que vous fassiez si vous voulez bien.

Dites moi, dans la partie commentaire ci dessous, quelles réactions ou réflexions vous inspire cette lecture.

Vos réponses seront une source d’inspiration pour la rédaction de la ou des prochaines parties.

Par ailleurs, vous pouvez être immédiatement averti par email de la parution de la seconde partie. Pour cela, abonnez vous à la newsletter.

6

L’art de la Rétrospective

Dans le cadre de Scrum, la rétrospective est une réunion positionnée à la fin de chaque sprint (sprint = itération) pendant laquelle l’équipe Scrum met à profit son vécu sur le sprint écoulé pour améliorer son organisation afin d’être plus efficace. La rétrospective est donc un élément clef du principe d’amélioration continue rendant une équipe auto-apprenante.

Comment exploiter au maximum ce levier d’amélioration ? Comment faire en sorte que chacun exprime son point de vue, que la rétrospective porte ses fruits avec des améliorations notables, qu’elle reste vivante malgré sa répétition. C’est à ces questions que je propose de répondre dans cette fiche pratique. J’y aborde également d’autres usages de la rétrospective.

Je tiens à rendre à César ce qui est à César en précisant que le contenu de cet article est bien évidemment issu de ma propre expérience mais aussi des enseignements donnés par le livre « Agile Retrospectives – Making Good Teams Great » de Esther Derby et Diana Larsen.

Récolter les points de vue de chacun

Il y a autant de vérités que de points de vue. Autant de points de vue que de personnes. Chaque vision permet de voir un problème ou une idée sous un angle différents pour mieux le résoudre ou la faire grandir. C’est ce qu’on peut appeler l’intelligence collective et différents facteurs permettent de favoriser cette dernière.

La posture de coach

Qu’est ce qu’un coach ? Voici ma définition personnelle : un coach est quelqu’un qui va aider une personne à trouver elle même les réponses à ses questions pour lui permettre d’atteindre un résultat qu’elle s’est fixé. Cette activité repose sur une croyance fondamentale : « la personne coachée dispose des ressources nécessaires pour atteindre le résultat visé« . On utilise souvent la métaphore de la graine qui contient toutes les informations nécessaires pour grandir et devenir un arbre. Pour l’anecdote, étymologiquement parlant, « coach » vient de « cocher » (l’ancêtre du chauffeur de taxi) qui amène une personne d’un point A à un point B.

L’animatrice ou animateur de la rétrospective doit adopter une posture de coach vis à vis de l’équipe et renoncer ainsi à la tentation de dire à cette dernière quoi faire en apportant des solutions toutes faites. C’est un exercice qui peut se révéler particulièrement difficile pour un ex-chef de projet habitué à dire aux membres de son équipe quoi faire, comment le faire et quand le faire. Surtout si cet ex-chef de projet a une formation d’ingénieur avec un cerveau « câblé » pour apporter des solutions à des problèmes.

Sans cette posture de coach, on n’aide pas l’équipe à trouver elle même des solutions, à prendre des initiatives et à innover. On fragilise son engagement à mettre en oeuvre les actions d’amélioration (puisque les actions ne viennent pas d’elle). On peut passer à côté d’idées et de solutions pertinentes. On multiplie nos chances de mettre en place des actions inefficaces voire contre-productives.

Si l’animatrice ou animateur dispose d’une expérience ou expertise particulière qui mérite d’être mise à profit en cours de la rétrospective (le Scrum Master porte par exemple l’expertise Scrum). Elle ou il peut s’impliquer dans la recherche de solution à condition de quitter temporairement le rôle d’animatrice ou animateur et de ne pas décider d’une action d’amélioration, mais plutôt de la proposer à l’équipe. En lui laissant clairement le droit de la juger inopportune. Elle ou il peut influencer mais pas décider.

Pas de jugement ni de recherche de coupable

Il est toujours recommandé d’introduire la rétrospective en mentionnant le fait que l’objectif de la rétrospective n’est en aucun cas de porter des jugements sur ce qui sera dit, en particulier à propos des idées proposées. Ni de rechercher des coupables lorsqu’on mettra sur la table les problèmes rencontrés.

Ce rappel est d’autant plus important si un responsable hiérarchique est présent pendant la rétrospective. Si c’est le cas, l’animatrice ou animateur devra briefer cette personne pour s’assurer qu’elle joue le jeu de la posture de coaching. Cette personne peut même participer à l’introduction est préciser : « Je ne suis là qu’en observateur et en position d’écoute, sentez vous libre de parler de tout, y compris de choses qui, selon vous, pourraient me déplaire ».

Un seul mot suffit parfois

Tout le monde n’est pas à l’aise pour parler devant les autres, proposer des idées, etc. C’est normal et il ne s’agit pas de forcer qui que ce soit à s’exprimer. Par contre, il faut lui en donner l’occasion. De simples tours de table peuvent aider. Et parfois le simple fait qu’une personne réservée ai prononcé un « je passe » peut la débloquer dans la suite des échanges.

L’animatrice ou animateur doit également être attentif aux dynamiques de groupe, notamment lorsqu’une personne monopolise trop souvent la parole. Au quel cas, on peut déclencher une pause et faire observer à cette personne que les autres ont rarement eu l’occasion de s’exprimer, alors que leur point de vue est sans doute intéressant.

La force du silence

Il faut parfois compter jusqu’à 10 dans sa tête après avoir posé une question à l’équipe. Le silence ainsi créé génère un espace libre qui aide l’équipe à réfléchir plus en profondeur pour y chercher une idée ou réflexion difficile à trouver.

Obtenir de véritables améliorations

Obtenir des idées, puis un plan d’actions d’amélioration est une chose. Transformer l’essai en implémentant ces actions en est une autre. Là encore la posture de coach a son importance car l’animatrice ou animateur doit résister à la tentation d’affecter arbitrairement les actions aux membres de l’équipe. Ou inversement, elle ou il doit résister à la tentation de prendre à sa charge les actions (en tant que Scrum Master par exemple). En participant activement aux actions d’amélioration, l’équipe s’habitue à s’auto-organiser et devenir « maître de son destin » au sein du cadre donné par Scrum et l’entreprise ou organisation.

Voici quelques moyens de transformer l’essai :

  • Privilégier la qualité des actions à la quantité. 2 ou 3 bonnes actions à mettre en oeuvre d’ici la rétrospective suivante peuvent suffire.
  • Rendre les actions SMART (Spécifique, Mesurable, Acceptable, Réalisable, Temporellement définie). Les questions du genre « Comment saurons nous que notre action a porté ses fruits ? » peuvent aider à alimenter la réflexion collective.
  • Favoriser l’appropriation des actions par l’équipe en demandant qui serait prêt à prendre en charge telle ou telle action. Prendre la responsabilité d’une action devant le reste de l’équipe favorise l’engagement.
  • Transformer les actions en tâches qui se rajoutent au tableau des tâches, kanban ou sprint backlog et sont ainsi estimées et suivies au même titre que les autres.

Garder la rétrospective vivante

Varier les objectifs

L’objectif « générique » de la rétrospective est du genre « Améliorer notre processus de développement pour le rendre plus efficace et plus agréable à vivre ». Il s’agit aussi d’améliorer la qualité du produit et d’adapter en conséquence la définition de « terminé ».

Mais selon l’actualité du projet, rien n’empêche de varier l’objectif d’une rétrospective à l’autre. Voici quelques exemples d’objectifs un peu plus ciblés :

  • Améliorer notre réactivité vis à vis des utilisateurs.
  • Améliorer notre relation et nos interactions avec le métier et le service marketing.
  • Comprendre les raisons pour lesquels l’objectif du sprint n’a pas été atteint.

Attention cependant à ne pas basculer dans le « trop ciblé » et occulter ainsi des sujets qui méritent d’être instruits en rétrospective.

Varier les activités

Les activités d’animation de rétrospective sont nombreuses et variées. Testez en des nouvelles. Vous apporterez ainsi du renouveau à vos rétrospectives et peut être que vous découvrirez une activité qui fonctionne mieux qu’une autre.

A ce sujet, je vous invite à lire la fiche de livre « Agile Retrospectives – Making Good Teams Great » de Esther Derby et Diana Larsen.

Changer d’animatrice ou d’animateur

Après plusieurs rétrospectives, certains membres de votre équipe se sentiront peut être à l’aise – voire se porteront volontaire – pour animer une rétrospective. Profitez en, car c’est également une bonne source de renouveau et vous serez peut être positivement étonné par les résultats. Si personne ne se propose, faite un appel à volontaire. Si la ou le volontaire a besoin de conseils avant de se lancer, rendez vous disponible pour les lui transmettre.

Faire émerger « code » de conduite de l’équipe

Avez vous pensé à utiliser des activités de brainstorming en petits groupes pour définir ensemble le code de conduite de l’équipe lui permettant de rester efficace (un peu à la Dexter pour ceux qui connaissent la série) ? Le « code » qui s’applique à la rétrospective par exemple (exemples d’accords collectifs formant le fameux « code » : « Ne pas prendre de PC portable pendant la rétro et mettre les téléphones en mode silencieux », « chacun parle à tour de rôle », etc). Mais aussi dans le quotidien des itérations (exemple subjectif : « Pas de modification du code source commun à partir de X heures avant la revue de sprint ou livraison. A l’exception de correctifs ciblés et maîtrisés par du pair programming »). Attention, ne dépassez pas 7 ou 8 accords collectifs, sinon c’est impossible à retenir.

La rétrospective de rétrospective

La rétrospective AgileOn ne pense pas toujours à améliorer un outil d’amélioration. Pourtant, c’est peut être la meilleure façon d’optimiser le retour sur investissement de la rétrospective. Vous pouvez ainsi façonner des activités spécifiques à votre contexte pour aboutir à VOTRE rétrospective, à une rétrospective sur mesure.

Pour y parvenir il existe différentes activités. L’une d’entre elles est appelée le « +/Delta » et prends seulement 10 à 20 minutes selon la taille du groupe. Elle peut servir pour une rétrospective d’itération, de release ou de projet.

Voici comment procéder :

  1. Présentez l’activité en disant: « Avant de terminer, nous allons identifier ce que nous voulons garder et ce que nous voulons changer pour notre prochaine rétrospective. ».
  2. Divisez votre feuille de paper board ou tableau blanc en deux colonnes (une ayant pour titre « + » pour les choses à garder et l’autre « Δ » pour les changements à apporter). Ajouter un titre au dessus (ex : Processus d’amélioration de la rétrospective). Annoncer le temps maximum disponible (cinq à quinze minutes).
  3. Demandez au groupe de prononcer les forces (choses à garder) et les changements. Capturez-les mot pour mot en remplissant les colonnes. Arrêtez-vous lorsque les idées se tarissent, ou à la fin du temps imparti. Attendez quelques secondes. Souvenez vous de la force du silence.
  4. Remercier le groupe pour leur participation franche. Comparez les éléments recueillis avec ceux des précédentes rétrospectives pour voir si des « schémas » (patterns) apparaissent.

Lorsqu’il n’y a plus de place pour écrire dans chacune des colonnes, c’est également le signe que vous pouvez vous arrêter. Au pire, les idées qui ne rentrent pas pourront être évoquées lors de la prochaine rétrospective de rétrospective.

Autres usages de la rétrospective

Définir ses valeurs, façonner sa culture et son organisation

La rétrospective peut également être un formidable outil pour définir les valeurs fondamentales de votre équipe. Des valeurs qui peuvent ensuite évoluer dans le temps, d’où l’intérêt de faire de telles rétrospectives régulièrement, tous les trimestres par exemple. Vous l’aurez compris, dans ce genre de rétrospective on détourne les activités de recherches collective d’idées ou d’actions en recherches de valeurs et principes. Evidemment, le nombre de personnes peut être bien plus grand, ce qui peut influencer la durée et la technique d’animation. Tout comme les rétrospectives de release ou de projet qui sont également possibles.

Pour ces dernières, on peut ainsi identifier des améliorations susceptibles de toucher l’organisation toute entière plutôt que le processus de développement seul.

Premier pas vers l’agilité

La rétrospective est également une bonne façon d’introduire l’agilité dans une organisation. On permet ainsi à l’équipe de s’exprimer librement sur ce qui fonctionne bien aujourd’hui, ce qui mérite d’être amélioré et des actions qu’on peut mettre en oeuvre à court terme. L’équipe est ainsi impliquée dès le début et partie prenante sur les décisions de changements. Au coach agile ou Scrum Master de savoir proposer ce que l’agilité a à offrir.

Message de soutien

Si vous lisez ces mots, c’est qu’il y a de grandes chances pour que vous ayez lu cette fiche jusqu’au bout et je tiens à vous féliciter pour ça car nous prenons de moins en moins le temps de faire des lectures approfondies. Si vous débutez dans l’agilité, cet article pourrait vous décourager d’animer une rétrospective. C’est pourquoi je tiens à vous rassurer en vous disant ou vous rappelant que : « Vous n’avez pas besoin d’être parfait » et je dirai même plus « vous avez droit à l’erreur ». C’est un des grands atouts d’une approche agile.

Vous trouvez que votre première rétrospective manquait de quelque chose ? de fluidité ? d’idées ? d’améliorations concrètes ?… Ce n’est pas grave. Vous venez d’apprendre des choses que vous pourrez mettre à profit lors de la prochaine rétrospective. La seule chose que vous devez vous « obliger » à faire, c’est de renouveler cette rétrospective à la fin de chaque sprint ou itération et d’y consacrer le temps nécessaire. Même lorsque toute l’équipe se dit « je pense qu’on est rôdé, il n’y a plus grand chose à améliorer ». Les choses changent ou évoluent en permanence, il y a toujours des choses à améliorer. Et quand bien même ce ne serait pas le cas, ça ne fait jamais de mal de se poser tous ensemble quelques heures après une période d’effort soutenu.

 

Les spécifications agiles

La documentation du projet est sans doute l’élément dont la durée de vie est la plus longue. Les technologies peuvent aller et venir dans le temps mais la documentation demeure l’héritage du projet. Pourtant nous échouons ou luttons souvent dans la maintenance de cette dernière. Les enjeux sont clairs : réaliser des spécifications compréhensibles à la fois par un utilisateur et par un développeur, à jour – donc fiables, donc faciles à maintenir – et non ambiguës afin de pouvoir vérifier objectivement la couverture du besoin. Cet article traite de différentes pratiques de spécification utilisées sur des projets Agile pour répondre à ces enjeux.

Partons du constat

Les principes et pratiques abordés par cet article ont pour point de départ les constats suivants :

  • Les utilisateurs ne savent ce qu’ils veulent qu’après avoir vu une première version du logiciel (Principe d’incertitude du besoin de Humphrey).
  • Les besoins changent souvent durant le processus de développement du logiciel (Principe d’incertitude de Hadar Ziv – 1996).
  • Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995).
Comparaison de l'efficacité des moyens de communication

Comparaison de l’efficacité des moyens de communication (Source : Alistair Cockburn)

Un autre constat important concerne les limites de la communication par écrit (cf. schéma ci contre). L’écrit peut être interprété de différentes façons, en particulier lorsque le sujet traité est complexe. Inutile de rappeler que, de nos jours, la réalisation d’un logiciel est une tâche particulièrement complexe tant fonctionnellement que techniquement. D’autre part, ce mode de communication n’offre pas d’interaction directe permettant de vérifier que le message porté est compris. Enfin, il fait l’objet d’un délais de réponse rarement maîtrisé (mode guichet).

Par ailleurs, sur des projets classiques menés en cascade, il arrive que le rédacteur du cahier des charges ne soit pas la même personne que le rédacteur des spécifications fonctionnelles générales, qui n’est pas la même personne que le rédacteur des spécifications fonctionnelles détaillées, qui n’est pas la même personne que celle qui développe, qui n’est pas la même personne que celle qui teste. Sur des projets longs à fort turn-over, il arrive même que ces différents acteurs ne se rencontrent jamais. Comment garantir une bonne couverture du besoin dans ces cas là ?

 

Forts de ces constats, il s’agit de renoncer à l’illusion de pouvoir spécifier à l’avance l’intégralité d’une solution logicielle. Et au contraire de spécifier, tester et développer au fil de l’eau. De communiquer le plus possible en face à face et d’utiliser l’écrit pour capitaliser l’essence du comportement applicatif visé.

Principes directeurs

  • Spécifions ensemble : Acteurs métiers et techniques élaborent ensemble les spécifications. Le métier est indispensable pour communiquer les objectifs et la valeur ajoutée visée à travers la fonctionnalité à réaliser. Les développeurs pour tirer parti de l’infrastructure sous-jacente et de la technologie émergente. Les testeurs pour identifier les cas d’usage aux limites. Les idées de chacun sont ainsi mises à profit pour parvenir à la meilleure solution possible. La responsabilité des spécifications et l’engagement associé sont alors collectifs.
  • Identifier les tests en amont afin de lever les ambiguïtés et pouvoir ainsi vérifier objectivement la couverture du besoin. La notion de “test” s’invite dès l’analyse du besoin et la conception. Le test ne sert plus seulement à vérifier l’absence de bug et la bonne couverture du besoin mais également à guider non seulement les développements en soi mais aussi la conception et l’architecture de la solution logicielle.

Règles d’or de rédaction

  • Exclure toute connotation technique et détails d’IHM de la spécification écrite. La documentation technique de type architecture (logicielle ou matérielle) trouvera sa place dans un dossier d’architecture si le projet le nécessite ainsi que dans le code source. La procédure technique d’installation est automatisée autant que possible (cf. Livraison Continue). Les détails d’IHM peuvent être portés par des maquettes au fil de fer (type Balzamiq). La charte graphique pourra être portée par la fonctionnalité de référence (cf. paragraphe « Balle Traçante »). Quant aux détails tels que les libellés (les messages d’erreurs et de confirmation de saisie d’un formulaire par exemple) coûtent si peu cher à modifier par la suite qu’on pourrait presque se passer de les « tracer » dans les spécifications. Au pire si certaines personnes ont besoin d’être rassurées, on peut les centraliser dans un document annexe (un fichier « properties » idéalement avec des clef parlantes pour les acteurs métier).
  • Privilégier le vocabulaire de l’utilisateur, le langage naturel (plutôt que télégraphique), au présent (plutôt qu’au futur) et décrire l’expérience utilisateur.

Pratiques

Spécification par l’exemple

Qui n’a pas eu naturellement recours à un exemple pour faire comprendre le comportement complexe d’une solution logicielle à concevoir ou l’expérience utilisateur associée ? La pratique décrite ici repose sur ce levier.

Terminologie

TDD (Test Driven Development) , A-TDD (Acceptance Driven Development), BDD (Behavior Driven Development) et autres sont toutes des pratiques pertinentes et efficaces. Leur multiplication et leur terminologie ont cependant contribué à semer la confusion auprès de leur utilisateurs. Plus grave encore, elles rendent difficile l’implication cruciale des acteurs métier dans le processus de spécification. Afin de couper court à cette confusion, le terme plus parlant de “Spécification par l’exemple” est proposé pour englober ces pratiques. Remarquons que ce terme est également dépourvu du mot “Agile”.

Processus

Processus piloté par les user stories

Exemple de processus de réalisation piloté par les User Stories. Schéma traduit à partir de celui de David Peterson et icônes de chapeaux de Anthony Piraino.

La notion de User Story (ou « Story ») utilisée ici se limite à la simple formalisation d’un besoin associé à une fonctionnalité à réaliser (exemple : « Paiement d’une commande d’articles »). L’utilisation étendue de la pratique des User Stories est abordée plus loin.

Le présent processus est piloté par les User Stories. Autrement dit, au sein de l’itération, chaque User Story passe individuellement à travers les étapes mentionnées. Elles n’ont pas à passer ensemble chaque étape à la façon d’un mini processus en cascade (ou V) au sein de l’itération.

Pour précision, la « Story » illustrée par le schéma ci-contre (en haut à droite) est sélectionnée à partir du Product Backlog (centralisant la liste ordonnancée des besoins ou fonctionnalités à réaliser) lors de la planification d’itération. En mode flux (Kanban), on pourra appliquer les même étapes sans notion d’itération.

Etape « Discuter »

Un testeur, développeur et expert métier s’assoient avec le product owner et discutent de la Story, décomposent et distillent progressivement le comportement visé en un ensemble de spécifications simples. La conversation (ou atelier de spécification) pourra dans un premier temps se concentrer sur 3 exemples clefs. En commençant généralement par l’exemple « heureux » selon lequel tout se passe bien. Il est généralement facile à identifier et permet d’éclairer la voie.

Point d’attention : A ce stade, il arrive que le porteur du besoin soit déjà dans la solution, court-circuitant ainsi la valeur ajoutée du développeur qui pourrait proposer une meilleure solution (potentiellement moins coûteuse, plus simple, etc) grâce à une technologie que lui seul connaît. La bonne pratique consiste donc à dériver la fonctionnalité à partir de l’objectif de fond. Quitte à remonter en arrière lorsque le porteur du besoin est déjà dans la solution. Dans ce cas de figure le recours au « Pourquoi ? » peut aider (« Pourquoi réalisons nous cette fonctionnalité ? »). Ou de façon plus diplomate « Quels objectifs devons nous atteindre à travers cette fonctionnalité ? ». Ces objectifs guideront les acteurs.

Pour illustrer ce point d’attention, un exemple nous vient de monde de l’aviation. L’expression de besoin associé à la réalisation de l’avion de combat F-16 consistait notamment à atteindre une vitesse de mach 2-2.25. Le concepteur a alors demandé pourquoi. La réponse fut « pour pouvoir échapper au combat ». Le concepteur n’a jamais atteint mach 2. En revanche il a apporté plusieurs innovations permettant d’échapper au combat. Cet avion a eu un tel succès que 30 ans après sa fabrication il est toujours en production.

Etape « Décider »

Le product owner décide que les spécifications couvrent suffisamment le comportement visé pour cette itération et le périmètre est verrouillé. Après ce verrouillage, tout comportement que l’équipe a oublié de spécifier est noté pour la prochaine itération dans laquelle il peut être priorisé de façon appropriée.

Point d’attention : Le principe évoqué en début d’article consistant à dire que l’utilisateur ne connaît pas son besoin tant qu’il n’a pas essayé une première version de l’application ne doit pas servir d’excuse pour ne pas verrouiller le périmètre puis défaire et refaire des développements d’une itération sur l’autre. Grâce à un tel processus, le délais entre la conversation sur le besoin et la fin du développement associé est si court que ce principe d’incertitude n’est pas valable.

Etape « Développer »

Le testeur affine les exemples. Le développeur instrumente les spécifications, créé des fixtures (éléments permettant de créer l’environnement propre à l’exécution des tests associés aux exemples) échouant (on vérifie d’abord que le test alerte correctement en cas d’erreur en passant au « rouge ») et implémente ensuite la fonctionnalité (passage « au vert »). Nous aborderons plus en détail dans le paragraphe suivant la notion de « spécification exécutable » associée.

Etape « Démontrer »

Une fois que tous les tests passent avec succès, la Story peut être démontrée au product owner. Les testeurs pourront également tester manuellement. Le passage au vert des tests permet d’affirmer objectivement que la fonctionnalité est « terminée ».

Les spécifications exécutables

Définitions et principe

On appelle « spécification exécutable », une spécification directement connectée au code source de la solution logicielle spécifiée. Chaque exemple porté par cette spécification est directement reliée à un test fonctionnel automatisé. L’ensemble des spécifications rassemblées forment une « documentation vivante ».

Exemple de spécification

Voici ci dessous un exemple de spécification exécutable réalisée avec l’outil Concordion.

Exemple de spécification exécutable réalisée avec l'outil Concordion

Exemple de spécification exécutable réalisée avec l’outil Concordion

A première vue, nous sommes face à une spécification statique. En réalité il s’agit d’une page web générée à partir d’une spécification exécutable (qui se présente sous la forme d’un fichier HTML) interprétée par un outillage de test automatisé. Les tests réalisés avec succès sont indiqués en vert comme sur l’exemple ci dessous (cf. résultats de la recherche) ou en rouge en cas d’échec.

Usage par l’acteur métier

L’acteur métier participe à l’identification des exemples associés à une fonctionnalité qui alimenteront la spécification exécutable (cf. étape « Discuter » du processus). Ce sera généralement le testeur et/ou le développeur qui se chargeront de la rédiger. Après les développements, il pourra se reposer sur ces spécifications pour s’assurer qu’une nouvelle fonctionnalité est bien « terminée » (tests au « vert »).

Plus tard, lorsqu’il souhaitera apporter un changement à un comportement existant de l’application, il pourra là encore se reposer sur elles pour retrouver les règles sous-jacentes à ce comportement. Il le pourra dans la mesure où ces spécifications sont fiables, car intrinsèquement connectées au code source. Dans le cas de spécifications classiques non fiables, nous devons nous reposer sur le code en faisant appel à un développeur pour retrouver les règles dictant le comportement de l’application (avec tous les désagréments que cela implique).

Usage par le testeur

Nous l’avons vu, le testeur participe à l’élaboration des spécifications et à leur affinage en ajoutant notamment les cas de test aux limites (comme les cas d’erreur par exemple). Ce travail peut se faire en binôme avec un développeur. Idéalement, le testeur aura un minimum de connaissances en HTML (rien de bien méchant) nécessaires à l’appropriation de la syntaxe de test afin de rédiger et affiner lui même les spécifications exécutables. Grâce à ces spécifications, il pourra contribuer à la qualité de la solution le plus en amont possible et vérifier en temps réel le bon comportement ou régression de la solution en fonction des évolutions du code. Les cas particuliers non automatisables feront l’objet de tests manuels.

Usage par le développeur

Le développeur participe à la rédaction des spécifications exécutables. Dans le pire des cas, il fait parti des relecteurs avant le démarrage des développements. Ses compétences pourront lui permettre de compléter les exemples et tests dérivés, ou réorienter la structure des exemples afin de rendre les tests associés automatisables. Il implémentera ensuite les tests automatisés associés à la spécification. Ces tests guideront ses développements. Ils vont l’obliger à respecter une architecture permettant l’automatisation des tests. Dans le cadre d’un modèle MVC, la couche front (ou Vue) ne comportera aucune logique métier sujette aux tests automatisés. Ces derniers se glisseront « sous la peau » de l’application organisée en composants à faible couplage. Les bonnes pratiques d’architectures logicielle deviennent alors incontournables. La logique métier se présentera sous la forme d’une « API » facilement testable.

Le développeur pourra se reposer sur cette « ceinture de sécurité » de tests automatisés quant il s’agira de réaliser des évolutions ou de réusiner des volumes de code plus ou moins importants.

Outillage

Seuls Cucumber et Concordion ont été expérimentés pour la rédaction de cet article. Cucumber a été rapidement mis de côté face à la lourdeur de préparation de l’environnement de travail associé. Concordion bénéficie d’une documentation claire, synthétique et illustrée par l’exemple en parfaite cohérence avec la pratique de spécification associée. Par ailleurs sa prise en main est rapide (moins d’une heure). D’autres outils existent tels que Fitnesse (qui a inspiré Concordion). Tous ceux cités ici sont gratuits.

Bénéfices

  • La documentation fonctionnelle est fiable (car nativement en phase avec le code).
  • L’analyse d’impact des changements et l’accomplissement de ces derniers sont facilités.
  • La compréhension commune des besoins entre acteurs métiers et techniques est assurée.
  • Les spécifications sont précises limitant ainsi le « faire et défaire » lié aux ambiguïtés autour du besoin.
  • La définition de « terminée » d’une fonctionnalité objective et partagée.
  • Les efforts de mise à jour des spécifications et d’exécution de tests manuels répétitifs sont limités.
  • La Livraison Continue est rendu possible.
  • La qualité est élevée et la relation entre client et fournisseur est ainsi améliorée.

Ne pas oublier le travail en amont

Il existe de nombreux principes, pratiques et astuces pour faire en sorte que les bénéfices de notre automatisation des tests fonctionnels soient supérieurs à l’investissement lié à leur mise en oeuvre et maintenance. Les maîtriser nécessite un apprentissage.

Ne perdons donc pas de vue les autres pratiques qui contribuent quant à elles à éradiquer le défaut à la source :

  • Test Driven Developpement qui permet de couvrir très exactement le besoin sans code superflu, de concevoir nativement une solution ouverte aux tests, de réusiner le code afin de rendre ce dernier facilement maintenable.
  • Programmation en binôme qui permet de limiter les erreurs humaines et de trouver des solutions plus simples, faciles à maintenir (deux cerveaux valent mieux qu’un). Mieux vaut privilégier la programmation en binôme obtenant ainsi un feedback immédiat de la part de son pair (comme un pilote et copilote d’avion qui vérifient réciproquement leurs opérations) que la revue de code dont le feedback intervient après coup.
  • L’Intégration Continue qui permet de détecter et traiter au plus tôt les éventuelles régressions.
  • Energie et motivation : Une équipe se donne a fond lorsqu’elle est motivée. Cette motivation peut s’obtenir par une bonne utilisation du temps passé en dehors du boulot et une forte concentration au travail. Rentrer chez soi chaque jour à l’heure, passer du temps avec ses amis et/ou sa famille et avoir des activités permettant d’éviter de penser au travail. Faire de l’exercice, avoir une alimentation saine et bien dormir. Au travail, rester concentré, mettre son téléphone en mode silencieux et désactiver les alertes mail et tchat. Définir ensemble une vision, une « noble cause » (« Pourquoi on fait ce boulot ? ») et des valeurs fondamentales qui fédèrent. Les objectifs quant à eux doivent permettre de libérer la créativité des membres de l’équipe. Cf. article « The Art of Agile Development: Energized Work » et celui sur le Leadership Tribal.

User Stories et Cas d’Utilisation Textuels

User Stories

Commençons par un exemple de User Story.

[alert type= »info » show_close= »false »]

Exemple de User Story

ID : #33
Titre : Paiement par carte bleue

Résumé : En tant que client du site internet FoireAuLivre.com je peux payer ma commande par carte bleue afin de me simplifier la vie.

Notes :…

Tests d’acceptations :

  • Tester avec une carte bleue mastercard : OK
  • Tester avec une carte sofinco : KO
  • Tester avec une carte expirée : KO
  • Tester avec un numéro de carte incorrect : KO
  • Tester avec un montant supérieur à 100 € : OK
[/alert]

Notons l’absence de connotation technique et de détails d’IHM ainsi que l’utilisation d’un template de phrase permettant de se concentrer sur l’essentiel : « En tant que … je peux … afin de ».

Par ailleurs, une User Story se veut « INVEST » :

[list icon= »ok »] [list_item]Indépendante des autres User Story de façon à ce qu’on puisse les développer dans n’importe quel ordre. Evidemment, ce n’est pas toujours possible, mais il faut garder cet objectif à l’esprit pour savoir saisir ou créer les opportunités de rendre indépendante une User Story (des techniques de découpage peuvent aider).[/list_item] [list_item]Négociable au sens où elle n’est pas orientée « solution ». Autrement dit l’acteur métier porteur du besoin et le développeur ont toute latitude pour parvenir à la meilleure solution possible selon les ressources du moment.[/list_item] [list_item]Valeur : elle doit être porteuse de valeur métier.[/list_item] [list_item]Estimable par l’équipe de développement.[/list_item] [list_item]Small : une User Story doit être suffisamment petite pour être réalisée au cours d’une seule itération. D’autre part, plus une User Story est petite, plus l’estimation est précise et la planification aisée.[/list_item] [list_item]Testable afin de pouvoir vérifier la bonne couverture du besoin. Ces tests doivent être rédigés en amont des développements afin de piloter au mieux ces derniers.[/list_item] [/list]

Le recours à un support physique (format bristol A5 par exemple) présente des avantages notables :

  • Simplicité : en cours d’itération, le développeur souhaitant travailler sur une User Story, prend le carton associé et va voir (idéalement accompagné de son binôme de développement et d’un testeur) l’acteur métier pour discuter avec lui du besoin. Ce dernier se remémore rapidement le sujet en lisant le résumé de 1 à 3 lignes. Sans avoir besoin d’un PC, ils annotent le bristol pour par exemple ajouter sous la forme d’un test supplémentaire une règle de gestion découverte au cours de leur conversation. Le développeur repart avec son bristol qu’il pose à côté de son clavier. Pendant ses développements, en un coup d’oeil, il pourra trouver l’information dont il a besoin pour implémenter ses tests et la fonctionnalité.
  • Taille limitée : le format A5 est une bonne taille car elle oblige les rédacteurs à se concentrer sur l’essence du besoin. Si il n’y a plus assez de place, c’est peut être un bon indicateur révélant la nécessité de découper la User Story.
  • Planification plus facile : Pendant la réunion de planification d’itération, c’est plus simple de prioriser les User Story en étalant les cartons sur une table ou sur le sol et en les déplaçant de gauche (priorité haute) à droite (priorité faible). La encore, pas besoin de PC et vidéo-projecteur.

Comme dans le cadre de la spécification par l’exemple, les tests portés par la User Story permettent de piloter les développements par les tests. Laissant peu de place aux ambiguïtés et mauvaises interprétations du besoin. Là aussi, une fonctionnalité n’est pas considérée comme terminée tant que les tests inscrits sur la User Story ne sont pas tous passants. La technique des User Stories peut être utilisée seule selon le contexte du projet. Le processus associé ne sera pas très différent de celui déjà décrit.

Pour aller plus loin, l’ouvrage de référence est « User Stories applied » de Mike Cohn.

Cas d’Utilisation Textuels

Dans certains contextes exigeants, les User Stories ne peuvent pas être considérées comme des spécifications mais simplement comme un support transitoire et éphémère permettant de planifier plus facilement les itérations et piloter les développements par les tests. Dans ce cas, on peut utiliser les cas d’utilisation textuels en complément pour formaliser davantage les choses et apporter la cohérence d’ensemble. Le cas d’utilisation textuel n’est pas par définition un cas d’utilisation UML. L’UML est généralement considéré comme trop difficile d’accès pour un utilisateur ou le client (parfois même pour les développeurs non initiés).

Là encore, commençons par un exemple.

[alert type= »info » show_close= »false »]

Exemple de cas d’utilisation
Titre : Commande d’article(s)
ID : 45
Résumé : Ce cas d’utilisation décrit le processus de commande d’un ou plusieurs articles en partant de la recherche jusqu’à la confirmation du paiement.
Acteur concerné : Internaute
Pré-condition : L’internaute s’est authentifié sur FoireAuLivre.com.

Scénario nominal :

  1. L’internaute lance une recherche d’article.
  2. Il sélectionne l’article de son choix parmi les résultats affichés et l’ajoute à son caddie.
  3. L’internaute affiche son caddie, vérifie le montant à payer et choisit de payer sa commande.
  4. Il opte pour le paiement par carte bleue.
  5. Il saisit son numéro, la date d’expiration ainsi que le cryptogramme de sa carte bleue.
  6. Un message affiché sur le site interne lui confirme que le paiement a été accepté.
  7. L’internaute reçoit un email lui confirmant que sa commande est enregistrée et résumant le contenu de cette dernière.

Scénarios alternatifs :

  • 3.a L’internaute répète l’étape 2 ou 1 puis 2.
  • 4.a.1 L’internaute opte pour le paiement par Paypal.
  • 4.a.2 L’internaute saisit ses identifiants Paypal.
  • 4.b.1 L’internaute opte pour le paiement par chèque.
  • 4.b.2 Un message indique à l’internaute l’adresse à laquelle envoyer le chèque ainsi que le numéro de commande à joindre à ce dernier.
  • 6.a Le paiement à échoué, l’internaute en est informé.
[/alert]

Cet exemple est un cas d’utilisation plutôt « haut niveau ». On peut au besoin descendre un peu plus et détailler certaines étapes. Dans ce cas, on souligne généralement dans le cas d’utilisation « haut niveau » le mot clef de l’étape en question illustrant le plus le sous cas d’utilisation lié (exemple : « payer », « recherche »,…). On établit ainsi un lien hiérarchique entre le cas d’utilisation et ses sous cas d’utilisation. On peut ainsi établir une cartographie des cas d’utilisation sous forme d’arborescence afin de faciliter la recherche d’information.

Le périmètre fonctionnel d’une User Story est la plupart du temps inférieur à celui d’un cas d’utilisation « haut niveau ». Autrement dit, un cas d’utilisation peut contenir plusieurs User Story mais l’inverse est rare (à moins de rédiger des cas d’utilisation bas niveau décrivant des mécanismes invisibles pour l’utilisateur).

Pour aller plus loin, l’ouvrage de référence est « Rédiger des cas d’utilisation efficaces ».

Balle traçante

A défaut de trouver une métaphore moins morbide, la pratique suivante reprend les principes de la balle traçante.

Définition Wikipedia : Une munition traçante est un type de munition muni d’un dispositif pyrotechnique émettant de la lumière tout au long de la trajectoire vers la cible. L’ogive étant très visible à l’œil nu, elle permet au tireur de suivre la trajectoire de la balle par rapport à la cible afin d’apporter des corrections à sa visée.

Dans le cadre d’un projet de développement logiciel, la pratique de la « balle traçante » consiste à réaliser de A à Z au démarrage du projet une fonctionnalité clef. On réalise la conception graphique et ergonomique ainsi que les développements jusqu’à obtenir un feedback d’utilisateurs (ou représentants d’utilisateurs) à partir de la fonctionnalité concrète terminée. Nous adaptons ensuite cette fonctionnalité en fonction de ces feedbacks et utilisons cette dernière comme fonctionnalité de référence « éclairante ». C’est donc cette fonctionnalité qui porte les spécifications graphiques et ergonomiques. C’est a partir d’elle que l’on va dériver les autres subtilités graphiques et ergonomique des autres fonctionnalités.

Par la même occasion, cette pratique permet de valider ou affiner l’architecture et les technologies choisies. Par ailleurs, la pratique de la balle traçante peut s’étendre au processus de déploiement. A partir de cette fonctionnalité « terminée », nous pouvons dès maintenant automatiser la procédure de déploiement et l’éprouver sur tous les environnements dont on dispose. Nous réduisons ainsi très tôt les risques liés à l’architecture et au déploiement et réduisons par la même occasion le stress reposant sur l’équipe.

Pour aller plus loin

 

Exemple d’organisation projet Agile

Cet article n’a pas pour vocation de servir de référence mais plutôt d’inspiration. D’autant plus qu’une organisation projet Agile part généralement d’un cadre méthodologique tel que Scrum et mûrit empiriquement d’itération en itération. Chacun aboutit ainsi à une méthodologie sur mesure adaptée à son contexte. A aucun moment cette dernière n’est considérée comme finale.

Organisation

Rôles

Product Owner

Le Product Owner est le représentant du client, il :

  • Définit les fonctionnalités du produit.
  • Décide des dates de livraison et de leur contenu.
  • Est responsable de la rentabilité du produit (ROI).
  • Priorise les fonctionnalités en fonction de la valeur métier.
  • Ajuste les fonctionnalités et leur priorité avant chaque planification d’itération.
  • Accepte ou rejette les fonctionnalités réalisées.
  • Anime la réunion de planification de sprint.

Le rôle du Product Owner est assuré par un membre de l’équipe métier (MOA) et au besoin une assistance (AMOA).

Equipe d’assistance au Product Owner

Elle assiste le Product Owner et à ce titre peut intervenir dans le cadre des activités associées aux responsabilités de ce dernier.
Plus concrètement, elle :

  • Alimente et maintient le Product Backlog, et pré priorise les éléments de ce dernier.
  • Ajuste les fonctionnalités prioritaires du Product Backlog (candidates au périmètre du prochain sprint) et s’assure que les pré-requis aux développements associés seront disponibles en temps voulu (exemples : décisions métier, jeux de données du SI amont,…).
  • Rédige les User Stories associées aux fonctionnalités prioritaires et dessine au besoin des maquettes d’écran.
  • Répond aux questions soulevées par l’équipe de développement en cours de Sprint et complète au besoin les User Stories associées.
  • Vérifie en cours de Sprint la bonne couverture du besoin des fonctionnalités terminées en collaboration avec l’équipe de développement.
  • Rédige les plans de tests.
  • Participe à la réunion de revue de sprint au cours de laquelle, elle aide le Product Owner à accepter ou rejeter les fonctionnalités présentées.
  • Teste avant mise en production la conformité du produit dans son ensemble.

Scrum Master

Le Scrum Master appartient à l’équipe de développement (MOE), il :

  • S’assure que l’équipe est pleinement opérationnelle et productive.
  • Établit une collaboration étroite entre l’ensemble des rôles et fonctions.
  • Supprime les obstacles rencontrés par l’équipe de développement.
  • Protège l’équipe des interférences extérieures.
  • Assure le suivi du processus.

Equipe de développement

L’équipe de développement :

  • Réalise les fonctionnalités du produit.
  • Présente au Product Owner les résultats de son travail sous forme de démonstrations.
  • Maintient à jour les spécifications détaillées du produit.
  • Package et livre le produit.

Processus

Processus global

Vue d'avion du processus global

Vue d’avion du processus global

Processus de la méthode Scrum

Zoom sur le processus Scrum (sources des icônes des personnages : Mike Cohn)

Résumé

Le processus itératif et incrémental du projet structure le développement du produit en cycles de travail appelés « Sprints ». La durée de ces sprints est fixée à 2 semaines dans le cadre de ce projet. L’objectif générique associé à chaque sprint consiste à transformer les exigences constituant le périmètre de ce dernier en fonctionnalités utilisables.

Juste avant de démarrer un sprint, l’équipe de développement sélectionne les éléments de la liste ordonnancée des exigences (Product Backlog) qu’elle pense pouvoir réaliser dans le délais associé au sprint. Au cours de ce dernier, le Product Owner et l’équipe de développement collaborent étroitement pour atteindre les objectifs fixés. Chaque jour, l’équipe de développement se coordonne et mesure son avancement. A la fin du Sprint, elle présente les résultats de son travail au Product Owner et aux utilisateurs finaux sous la forme d’une démonstration des nouvelles fonctionnalités réalisées. Les feedbacks sont recueillis.

Juste après le Sprint, l’équipe de développement se réunit afin de tirer les leçons du sprint écoulé et étudie les moyens de s’améliorer. S’enchaine ensuite la planification du sprint suivant.

Processus détaillé

Le paragraphe suivant décrit dans l’ordre chronologique les étapes du processus.

Préparation

Avant le démarrage d’un Sprint, le Product Owner doit s’assurer que le Product Backlog (Liste des exigences attendues) est correctement ordonnancé en fonction de la valeur métier et du coût de chaque exigence. Pour les exigences dépourvues de coût, il peut solliciter l’équipe de développement afin de procéder à des séances d’estimation. Il participe à ces séances – assisté par son équipe – en répondant aux questions de l’équipe de développement. Il doit également s’assurer que le besoin associé aux exigences prioritaires du Product Backlog (candidates au périmètre du prochain Sprint) est suffisamment mûr (décisions métiers structurantes prises, besoin formalisé sous forme de User Stories,…).

Planification de Sprint

Le Product Owner et l’équipe de développement se réunissent afin de partager ou repartager ensemble la vision du projet ainsi que les objectifs associés aux éléments du Product Backlog. L’équipe de développement sélectionne ensuite les éléments du Product Backlog en commençant par le haut (exigences prioritaires) en fonction de sa capacité à faire. Enfin l’équipe de développement, découpe chaque exigence en tâches et estime le temps nécessaire à la réalisation de chacune d’entre elles. Ces tâches sont enregistrées dans le Sprint Backlog.

Sprint

Le sprint englobe les activités d’analyse, de conception, de test et de développement. Au cours de ce dernier l’équipe de développement soulève des questions métiers. L’AMOA répond aux questions (se retourne vers d’autres acteurs tels que la MOA si nécessaire) et complète les User Stories associées. L’AMOA vérifie en cours de sprint la bonne conformité de la fonctionnalité développée, émet au besoin des feedbacks qui permettront d’adapter la fonctionnalité.

L’équipe de développement se réunit chaque jour lors de la mêlée quotidienne afin d’évoquer le travail réalisé la veille, celui de la journée et soulever les obstacles rencontrés. Chaque membre de l’équipe actualise son « Reste A Faire » sur ses tâches en cours de manière à actualiser le graphique d’avancement du sprint. Ce point est limité à 15 minutes, d’autres acteurs du projet peuvent être présents mais seuls les membres de l’équipe de développement ont la parole.

Revue de Sprint

A la fin du sprint, l’équipe de développement présente au Product Owner accompagné par l’AMOA (et autres acteurs intéressés) les nouvelles fonctionnalités produites sous la forme d’une démonstration. Le Product Owner – avec l’aide de l’AMOA – accepte ou rejette les fonctionnalités présentées. Les feedbacks sont notés. En fonction des résultats présentés, le Product Owner peut demander une livraison du produit pour réaliser des tests de l’ensemble du produit en prévision d’une mise en production. Auquel cas, quelques jours de consolidation du produit en fonction des résultats de ces tests peuvent être nécessaires. Si le Product Owner ne demande pas de livraison, une nouveau sprint est planifié (cf. paragraphe « Planification de Sprint »).

Rétrospective de Sprint

Après la revue du Sprint, l’équipe de développement ainsi que le Product Owner se réunissent afin d’identifier les adaptations susceptibles d’augmenter sa productivité. Les choses qui fonctionnent, celles qui ne fonctionnent pas ainsi que les améliorations à apporter, sont identifiées dans cette réunion. Elle s’inscrit dans une démarche d’amélioration continue. Les idées de chacun sont mises à profit.

Synthèse des réunions

NB : les comités de pilotage ne sont pas décrits dans cette organisation. Ils diffèrent généralement assez peu d’une approche traditionnelle (exemple : comité de suivi hebdo et comité de pilotage mensuel). Il peut cependant être intéressant de se caler sur le rythme des sprints, voire de mutualiser les revues de sprint avec un comité de pilotage par exemple.

Planification de sprint

  • Objectif(s) : définir le périmètre et les objectifs du sprint puis découpage en tâches de développement.
  • Responsable : Product Owner.
  • Participants : Product Owner, ScrumMaster, équipe de développement.
  • Fréquence : Avant le sprint.
  • Durée maximale : 4 heures.
  • Document(s) en entrée : Product Backlog priorisé.
  • Document(s) en sortie : Sprint Backlog.

Mêlée quotidienne

  • Objectif(s) : coordination de l’équipe de développement, identification des obstacles qu’elle rencontre, mesure de l’avancement du Sprint.
  • Responsable : ScrumMaster.
  • Participants : équipe de développement, ScrumMaster, Product Owner/AMOA (optionnel).
  • Fréquence : quotidienne.
  • Durée maximale : 15 minutes.
  • Document(s) en entrée : Sprint Backlog.
  • Document(s) en sortie : Sprint Backlog et graphique d’avancement mis à jour.

Revue de Sprint

  • Objectif(s) : présentation des fonctionnalités produites au cours du Sprint au Product Owner et utilisateurs finaux, réception des feedbacks.
  • Responsable : Equipe de développement.
  • Participants : équipe de développement, Product Owner, ScrumMaster, utilisateurs finaux, invités.
  • Fréquence : A la fin du Sprint.
  • Durée maximale : 2 heures.
  • Document(s) en sortie : Liste des feedbacks.

Rétrospective de Sprint

  • Objectif(s) : améliorer la productivité (vélocité) de l’équipe de développement.
  • Responsable : ScrumMaster.
  • Participants : équipe de développement, ScrumMaster, Product Owner/AMOA (optionnel).
  • Fréquence : Après la revue de Sprint.
  • Durée maximale : 1h30.
  • Document(s) en sortie : compte rendu de réunion (bilan de Sprint + plan d’actions).

Artefacts

Product Backlog

Le Product Backlog centralise la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles, défauts à corriger). Le Product Owner s’approprie ce Product Backlog et priorise ses éléments en fonction de la valeur métier et du coût estimé de chacun. L’unité de coût est le « point ». Le choix d’une telle unité permet d’éviter la confusion entre délais et coût, souligne le caractère « estimatif » (imprécis) et facilite la planification de release et de sprint. Ces estimations sont réalisées dans un premier temps à partir d’un besoin peu détaillé, il peut être révisé au cours de la planification d’itération en cas d’écart par rapport aux hypothèses établies lors de la première estimation.

Sprint Backlog

Le Sprint Backlog comporte la liste des tâches du Sprint (son périmètre donc) ainsi que la charge de travail associée à ces dernières. Chaque jour, le Reste A Faire de chaque tâche est actualisé par l’équipe de développement afin de tracer le graphique d’avancement de Sprint.

Tableau des tâches

Ce tableau comporte la liste des tâches du Sprint Backlog, il permet à l’équipe de développement de se coordonner. Il comporte généralement 4 colonnes : « A faire », « En cours », « A vérifier », « Terminé ». Il est mural et simple à interpréter, permettant à n’importe quel acteur du projet de connaître en un coup d’œil l’avancement « temps réel » du Sprint.

Graphique d’avancement de Sprint

Tout au long du Sprint, n’importe quel acteur du projet peut consulter la progression de l’équipe de développement grâce au graphique d’avancement actualisé quotidiennement. Ce graphique indique l’évolution du Reste A Faire (généralement exprimé en heures) en fonction du temps.

Spécifications

Introduction

Partant des constats suivants :

  • Les besoins ne sont pas complètement connus tant qu’un projet n’a pas débuté
  • Les utilisateurs savent ce qu’ils veulent uniquement après avoir vu une première version du logiciel (Principe d’incertitude du besoin de Humphrey).
  • Les besoins changent souvent durant le processus de développement du logiciel (Principe d’incertitude de Hadar Ziv – 1996)
  • Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995)

L’approche du projet, concernant les spécifications, consiste à lisser le travail de rédaction des spécifications tout au long du projet et à leur accorder une valeur contractuelle faible. Privilégiant plutôt la réalisation au plus tôt d’un logiciel qui fonctionne à la fin de chaque sprint grâce à une collaboration client/fournisseur (métier/technique, MOA/MOE) étroite.

Processus

Liste des besoins

Le Product Owner établit et maintient la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles ou défauts à corriger). A ce stade, le niveau de précision du besoin est faible. Chaque exigence peut se résumer à 1 à 3 phrases en moyenne. La liste des exigences vient alimenter le Product Backlog.

Besoins prioritaires

Avant la planification d’un nouveau Sprint, le Product Owner approfondit le besoin associé aux fonctionnalités prioritaires (en tête de liste du Product Backlog). Une bonne pratique consiste à rédiger pour chaque fonctionnalités attendue une User Story (le verso décrit le besoin et le recto énumère les conditions ou test d’acceptation permettant de vérifier la couverture du besoin). A l’issue de la réunion de planification de Sprint, le périmètre de ce dernier est fixé. Il correspond à la liste d’exigences sélectionnées par l’équipe de développement matérialisées par un ensemble de User Stories.

Conception/Développement

Une fois le Sprint démarré, le développeur s’approprie la User Story qui servira de support de communication entre lui et le rédacteur de la User Story (Product Owner, AMOA ou utilisateur). Au fil des questions soulevées et des réponses apportées, la User Story se complètera jusqu’à la fin des développements associés.

Mise à jour des spécifications

A l’issue du Sprint, l’équipe de développement, met à jour la documentation du produit.

Gestion des changements

Le besoin peut changer tout au long du projet (y compris tardivement).
Notamment dans les cas de figure suivants :

  • Découverte d’un nouveau besoin correspondant une nouvelle fonctionnalité à réaliser.
  • Modification d’une fonctionnalité déjà réalisée.
  • Retrait d’un besoin finalement inutile ou infaisable.

Principe de troc

Principe de troc d'exigence pour la gestion des changements

Principe de troc d’exigence pour la gestion des changements

Pour rappel, le Product Backlog centralise l’ensemble des exigences (ou besoins) attendues du projet. Chaque élément de ce dernier comporte une estimation de coût en points. La somme des estimations permet donc de déterminer le coût du projet (estimation).

Si les contraintes de budget voire de délais du projet sont fortes ; en cas de découverte d’un nouveau besoin ou de modification d’une fonctionnalité déjà réalisée ; un nouvel élément est ajouté au Product Backlog en échange du retrait d’un autre de même coût et de valeur métier plus faire (cf. bas de la liste). Inversement dans le cas d’une disparition d’un besoin finalement inutile, l’élément associé est retiré du Product Backlog libérant ainsi une provision pour de nouveaux besoins ou futures modifications.

Changement pendant un Sprint

Le périmètre d’un sprint fixé à l’issue de la réunion de planification ne doit pas changer. En cas de force majeure, le Product Owner peut annuler le Sprint en cours, ce qui peut engendrer des conséquences coûteuses. Les développements en cours sont stoppés, l’équipe de développement est coupée dans son élan. Un nouveau sprint doit alors être planifié.

Gestion des défauts

Processus de gestion des défauts

Un défaut qui n’a pas pu être corrigé pendant le Sprint est enregistré dans le « Bug Tracker » par le testeur. L’AMOA et l’équipe de développement qualifient ensemble les défauts constatés afin de savoir si une correction et réellement nécessaire et possible en fonction des informations renseignées par le testeur.

Les défauts confirmés sont ensuite priorisés par le Product Owner assisté par l’AMOA. Le Product Owner identifie la liste des défauts à corriger dans le prochain sprint. Il communiquera cette liste à l’équipe de développement lors de la réunion de planification de sprint au même titre que les exigences prioritaires à réaliser. Les défauts critiques (bloquant le travail de test AMOA ou présentant un risque majeur dans l’utilisation du produit prochainement mis en production) peuvent être ajoutés au besoin au périmètre du sprint en cours.

Processus de gestion des incidents de production

Les incidents de production peuvent être pris en compte par l’équipe de développement dans le Sprint en cours.

Planning

Macro Planning Agile

Macro planning Agile : « Une Release par trimestre »

Le projet est piloté par la valeur et les délais. Chaque année compte 4 releases de 3 mois afin de créer un rythme régulier, favoriser la naissance des automatismes projet, réduire l’effort de planification du projet et de coordination des acteurs internes et partenaires du projet. Ce principe de release de même durée permet également de construire des indicateurs plus facilement comparables afin d’améliorer régulièrement le processus de développement et l’organisation.

Les releases peuvent donc être considérées comme des trains partant et arrivant à heure fixe sans décalage possible. Le périmètre est donc la seule variable d’ajustement, afin de sécuriser la qualité, le budget et les délais.

Bonnes pratiques

Planning Poker

Le Planning Poker est une technique d’estimation de coût d’exigences. Cette technique se pratique en équipe et permet de procéder à des estimations rapides et aussi précises que possible selon le niveau de précision du besoin disponible.

Au cours des séances d’estimation, le Product Owner (assisté de l’AMOA au besoin) soumet une à une à l’équipe de développement les exigences dont il souhaite connaître l’estimation de coût. Il répond aux questions de l’équipe de développement qui en cas d’absence de réponse (besoin encore flou) établie des hypothèses. Les estimations de coût (dont l’unité est le point) ainsi obtenues viennent alimenter le Product Backlog et aideront le Product Owner à prioriser ses exigences. La technique de Planning Poker peut également être utilisée pour estimer en équipe (Product Owner, AMOA, utilisateurs, marketing,…) la valeur métier en points des exigences du Product backlog.

En savoir plus

User Story

La User Story est une technique de spécification permettant de synthétiser le besoin lié à une fonctionnalité en quelques phrases courtes et simples utilisant exclusivement le vocabulaire métier (absence de connotation technique ou de description d’IHM). D’autre part, une User Story énumère les tests fonctionnels connus à date permettant de vérifier la couverture du besoin de la fonctionnalité associée.

Les avantages sont nombreux :

  • Une User Story est compréhensible rapidement aussi bien par un développeur que par un utilisateur,
  • Elle favorise les interactions entre développeur et rédacteur, favorisant ainsi une bonne compréhension du besoin (communication face à face),
  • Les tests énumérés renforcent la qualité des développements.

En savoir plus

Pratiques de développement

Intégration continue

L’intégration continue a pour rôle de détecter au plus tôt les défauts d’intégrité du code (plus un défaut est corrigé tôt moins il coûte cher).

Elle est matérialisée par un outillage logiciel récupérant le dernier code disponible sur le gestionnaire de version, compilant ce dernier et exécutant les tests unitaires existants. Il réalise cette tâche automatiquement à chaque modification du code soumise au gestionnaire de version ou plusieurs fois par jour. En cas de défaut détecté, une alerte est déclenchée (email, signal sonore ou visuel,…). Cet outil permet donc de renforcer la qualité des développements et de favoriser le travail indispensable de refactoring régulier du code.

En savoir plus

Développements pilotés par les tests

Le développement piloté par les tests consiste à sensibiliser le développeur sur les tests en amont de ses développements. Concrètement, la User Story associée à une fonctionnalité à développer liste les tests qui permettrons de confirmer que cette fonctionnalité couvre effectivement le besoin. Cette approche limite les erreurs d’interprétation du besoin du développeur.

Programmation en binôme

La programmation en binôme consiste à rassembler deux développeurs sur un même poste de travail pour accomplir une même tâche de développement. Cette approche apporte plusieurs avantages :

  • Permet de réaliser efficacement des développements pointus,
  • Meilleure qualité du code (peu de défauts, uniformité, maintenabilité),
  • Rapidité de développement,
  • Rapidité de montée en compétences (cf. nouveaux développeurs, en particulier junior).

En savoir plus

Annexes

Conduite du changement Agile

L’adoption des méthodes agiles est indéniablement porteuse de changement, or l’être humain à naturellement tendance à résister à ce dernier. Consciemment ou inconsciemment. Le changement implique la perte de repères suivi d’une période chaotique jusqu’à la mise en place des nouveaux repères. Plus il est profond, plus la période de transformation peut s’avérer chaotique. Voir l’Agilité comme un processus ou une méthodologie, sans considérer sa dimension culturelle (cf. manifeste Agile), peut se révéler dangereux et provoquer l’échec de sa mise en oeuvre en sein d’organisations dont la culture est trop éloignée de la philosophie Agile et trop conservatrice. C’est pour cette raison que réussir sa transformation Agile peut faire l’objet d’un véritable défi. Cet article donne quelques outils pour faire face à ce défi.

Sources de résistance au changement

Distinguons deux grandes catégories de résistances au changement. Les résistances humaines et les résistances organisationnelles.

Voici quelques facteurs de résistances humaines :

  • Renoncer à la croyance que l’on peut spécifier intégralement un logiciel à l’avance.
  • Renoncer à la croyance que l’on peut élaborer un plan précis à l’avance sans revenir excessivement dessus.
  • Accepter de piloter par les délais et considérer le périmètre comme la principale variable d’ajustement.
  • Parler quotidiennement debout devant ses collègues de son travail et de ses difficultés.
  • Renoncer à l’illusion de l’efficacité du mode de management classique (« command and control ») sur des projets complexes.
  • Peur de perdre ses responsabilités dans le cadre d’un changement de son rôle.
  • Peur de ne pas être à la hauteur face aux nouvelles façons de travailler.

Ces facteurs peuvent générer des comportements sceptiques voire saboteurs, au mieux suiveurs.

Photo du saut en Fosbury illustrant le changement Agile

Malgré l’efficacité flagrante du saut en Fosbury, il a fallut attendre plus de 10 ans avant que cette technique se généralise. Le temps que les athlètes changent leur façon de sauter et s’approprient la technique.

Côté organisationnel, nous pouvons notamment avoir à faire face aux résistances suivantes :

  • Processus d’évaluation annuel et système de prime privilégiant la performance individuelle plutôt que collective.
  • Le règlement intérieur empêchant l’aménagement de l’espace de travail (disposition des bureaux, affichage sur les murs, etc) ou l’utilisation d’un logiciel de tchat.
  • Services Achats qui refuse de renoncer au contrat au forfait classique fixant périmètre, délais et coût, rendant obligatoire la validation de l’intégralité des spécifications du logiciel avant le démarrage des développements.

Principes

« haut vers le bas » et « bas vers le haut »

La transformation vers l’agilité peur venir de deux sources différentes. Elle peut venir des tranchées; d’une équipe de développement par exemple; (le « bas ») ou de la direction (le « haut »). Chacune a ses avantages et limites. Un mouvement venant du bas permet une meilleure appropriation des changements opérationnels mais peut vite se heurter à une MOA qui ne veut pas jouer le jeu ou un service achat qui ne veut pas entendre parler de contractualisation Agile. A l’inverse, une approche par le haut peut déverrouiller une MOA ou un service achat, financer du coaching et des formations Agile mais aura du mal à ancrer durablement le changement en raison de la résistance naturelle au changement dont feront preuve les individus « soumis » à ce dernier. L’idéal est donc de trouver un équilibre entre une approche du « haut vers le bas » qui lève les blocages organisationnels et du « bas vers le haut » qui s’approprie le changement.

Commencer petit

On le sait, les changements apportés par l’approche Agile sont nombreux. L’objectif est d’ancrer durablement de nouvelles pratiques et faire naître de nouveaux réflexes. Pour cela, il faut accorder aux individus concernés le temps nécessaire à l’assimilation et appropriation de ces nouveautés. L’idéal est donc d’avancer pas à pas plutôt que d’adopter d’un coup l’ensemble des principes et pratiques Agiles. Ou à plus grande échelle de faire basculer progressivement en approche Agile les projets de l’organisation plutôt que tous d’un coup.

Amélioration continue

On peut penser que le voyage de transformation a une destination. Mais d’une certaine façon, ce voyage ne se termine jamais en raison du principe d’amélioration continue. A partir du moment où l’on cesse d’améliorer son processus de développement d’une itération sur l’autre, on cesse d’être Agile. Le contexte d’une organisation ou d’un projet est en perpétuel changement et le processus de développement ainsi que l’organisation en soi doivent suivre. Une fois que ce principe est acquis, le changement devient naturel et indolore (car on passe à une série de petits changement plutôt qu’à un gros) pour le bien de l’organisation et des individus qui la composent.

Mesurer

Mesurer est important pour deux principales raisons. Pour savoir d’où on part, se fixer des objectifs concrets, puis savoir régulièrement où nous en sommes. Et pour « faire la preuve » de l’agilité. Parfois, il sera nécessaire de fournir la preuve de l’efficacité de la nouvelle démarche adoptée afin de lever un blocage, passer un cap, étendre l’agilité au reste de l’organisation. Volumes d’anomalies, volume d’appels au support technique, nombre de jalons non respectés (et de combien de jours), volume de fonctionnalités délivrées en fonction du temps, délais de transformation d’une idée en fonctionnalité disponible pour les utilisateurs finaux, etc. Autant d’indicateurs qu’il est possible de mesurer.

Processus de changement

Lorsqu’on s’intéresse à la conduite du changement, on tombe généralement sur un acteur quasi incontournable dans ce domaine : John Kotter. John Kotter propose 8 étapes pour mener le changement :

  1. Instaurer un sentiment d’urgence;
  2. Constituer une coalition directrice;
  3. Élaborer une vision et une stratégie;
  4. Communiquer la vision du changement;
  5. Habiliter le personnel en vue d’une action suivant la vision;
  6. Générer des gains à court terme;
  7. Consolider les gains et introduire d’autres changements;
  8. Ancrage de nouvelles approches dans la culture de l’organisation.
Ces étapes peuvent vous guider dans votre transformation Agile. La création d’un sentiment d’urgence peut par exemple s’obtenir en utilisant les événements de votre projet ou organisation (jalons décisif non respectés, surcharge des appels au support technique, fort turn-over des équipes, budget d’avenants disproportionné, fonctionnalités inutilisées, démotivation/faible engagement, etc.). Vos mesures (cf. paragraphe précédent) peuvent vous aider à faire prendre conscience du sentiment d’urgence. Vous allez ensuite identifier les individus moteurs qui partagent ce sentiment d’urgence, fédérer ces derniers en sein d’une équipe (coalition) et définir avec eux votre vision et stratégie que vous allez ensuite diffuser. Etc.

Pratiques

Projet Pilote

Expérimenter l’approche Agile sur un projet Pilote avant de généraliser sur le reste de l’organisation est une pratique courante. Il faut cependant veiller à ce que les enjeux de ce projet ne soit ni trop élevés (au point de risquer d’échouer pour d’autre raisons que le choix d’une approche Agile), ni trop modestes (au point de ne pas pouvoir s’appuyer sur son succès pour généraliser ensuite). Le choix de l’équipe est également important afin de s’assurer que cette dernière jouera bien le jeu dans l’application des principes et pratiques Agile. D’autre part, en cas de succès, les membres de cette équipe prennent généralement le rôle de « coach » ou leader du changement vis à vis des équipes qui se lanceront à leur tour. C’est aussi pour cette raison que le casting est important.

Essaimage

Basculer d’un coup toute une organisation comptant plusieurs équipes et projets, voire plusieurs centaines de personnes peut se révéler risqué. Afin de sécuriser l’ancrage des changements méthodologiques, il est recommandé de procéder par essaimage. Cela consiste à former une première équipe (de volontaires idéalement) et leur laisser 3 itérations environ pour s’approprier le processus et pratiques Agile. Puis à répartir les membres de cette équipe dans de nouvelles équipes. Ces dernières bénéficieront ainsi d’une personne sur laquelle s’appuyer en cas de difficulté. La diffusion du « courant » Agile se fait alors horizontalement pour une meilleure appropriation. Une personne sceptique aura plus facilement tendance à écouter un de ses pairs.

Backlog de Transformation

Scrum peut également s’avérer utile dans le cadre de la conduite du changement. Notamment à travers, la mise en place d’un Backlog contenant la liste des actions concrètes de transition vers l’approche Agile. Ce Backlog peut être construit et ordonnancé par l’équipe de coaching Agile et les représentants de chaque équipe. Vous pouvez ensuite, par exemple, planifier les actions au rythme des itérations et releases de votre projet.

Jeu de cartes

Exemple de Backlog de transformation Agile

Exemple de backlog de transformation Agile composé des cartes LeanPizza

Les auteurs du site LeanPizza ont mis à profit le travail de John Kotter pour faciliter le changement organisationnel vers l’Agile. La technique est simple et repose sur un jeu de cartes. Chaque carte est porteuse d’une action de « transformation » numérotée et appartenant à un thème. Par exemple, la carte n°46 du jeu de carte de transition vers Scrum est porteuse de l’action « Un meeting de Démo / Revue de Sprint est plannifié à la fin de chaque Sprint et ce dès le début du projet » et appartient à la catégorie « Démo / Revue de Sprint ». Ces cartes peuvent servir à la fois de check list et de mesure d’avancement de votre transformation. Elle peuvent alimenter votre « Backlog de Transformation ».

« Just Do It »

Trouver des raisons de ne pas adopter une nouveau changement, tel que l’adoption d’une nouvelle pratique par exemple, est plutôt facile. Si bien que, le porteur du changement doit souvent faire preuve d’une grande patience, écoute et diplomatie. Face à des personnes « sceptiques », plutôt que d’argumenter ardemment sur les bénéfices que peut apporter ce changement, proposez de simplement l’essayer. L’un des gros avantages des itérations est de pouvoir essayer un changement le temps d’une ou deux itérations et d’en faire le bilan. Libre aux acteurs du projet d’ancrer ce changement ou de revenir dessus. C’est le droit à l’essai et à l’erreur.

Communautés

La création de communautés transverses aux équipes et projets peut faire l’objet d’un bon support sur lequel s’appuyer pour diffuser et favoriser l’appropriation de nouvelles pratiques. On peut ainsi favoriser la création de communautés de pratiques (exemple : « Développement Agile ») ou de technologies (exemple : « Android » ou « Java »). Cette approche horizontale peut être complétée par un soutien venant du haut via l’allocation de budget d’animation de ces communautés (exemple : évènementiel, mise en place d’un logiciel de Réseau Social d’Entreprise ou d’un Wiki), de l’aménagement du temps de travail, etc.

Mode sous-marin

Jouer carte sur table en communiquant à l’ensemble des acteurs du projet ou de l’organisation une transformation vers l’Agile peut aussi bien faciliter les choses que les compliquer. D’un côté cette approche peut faciliter le changement car on pourra s’appuyer sur cette décision de passer en Agile pour surmonter les éventuelles résistances. D’un autre côté, on peut se retrouver face à une levée de boucliers visibles ou non qui rendront le changement difficile. Lorsque ce second scénario a plus de chance de se produire (selon le contexte), il peut être plus prudent d’avancer en sous marin en mettant en place progressivement les nouveaux principes et nouvelles pratiques.

Liens utiles

Livres

Retours d’expérience

Outillage

Jeu de carte Lean Pizza et manuel d’utilisation.