Category Archives for "Non classé"

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

Les chiffres du Millésime 2016

Que 2017 vous comble ainsi que vos proches 🙂

Je profite de cette nouvelle année qui démarre pour partager avec vous des chiffres qui me donnent le sourire car ils témoignent du chemin parcouru depuis que je me suis lancé dans cette nouvelle aventure et de l'ampleur du mouvement agile. Un mouvement agile autant propice à la performance des entreprises qu'au bien être de ses collaborateurs, c'est plus que jamais ma conviction.

Chiffres arrêtés au 31 décembre 2016 :​

5834 Abonnés à la newsletter L'Agiliste (contre 2143 en janvier 2016)
393894 Pages vue sur L'Agiliste en 2016 (soit 83,6% d'augmentation par rapport à 2015)
270 Participants à nos SPOC sur la gestion de projet agile
4,6/5
Note des SPOC

Note moyenne attribuée par les participants au SPOC d'initiation à la gestion de projet agile avec Scrum et à celui consacré à l'apprentissage du rôle de Scrum Master ou Manager Agile

6163 Inscrits à la première édition du MOOC Entreprise Agile
4,1/5
Note du MOOC

Note moyenne attribuée au MOOC Entreprise Agile par les participants

Et pour voir au delà des chiffres de L'Agiliste, en voici deux autres issus de l'enquête annuelle menée par VersionOne sur l'adoption de l'agilité dans le monde. Ces chiffres sont issus de la dernière enquête menée en 2015.

95%
Pratiquent l'agilité

95% des entreprises sondées dans le monde utilisent des méthodes agiles

34%
Avec plus de 50% du personnel

34% d'entre elles les utilisent avec plus de la moitié de leur personnel

Score* 2015 de recherches Google France sur les mots clefs "Scrum" et "Cycle en V" 

Scrum - 65%
Cycle en V - 10%

Score* 2016 de recherches Google France sur les mots clefs "Scrum" et "Cycle en V" 

Scrum - 69%
Cycle en V - 10%

* Pourcentage de recherche faites sur la France par rapport à la région du monde qui fait l'objet du maximum de recherche sur le même terme

Si dessous, une autre illustration sur le long terme de l'écart d'intérêt dans les recherches google France qui ne cesse de se creuser entre Scrum (gestion de projet agile) et Cycle en V.

A bientôt,
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.​

2

MOOC L’entreprise agile

Un MOOC pour faire passer les organisations dans l’ère du digital

La révolution digitale, couplée à la mondialisation, rendent le monde de plus en plus complexe et donc incertain pour les entreprises, qui doivent également composer avec les nouvelles attentes des jeunes générations de collaborateurs.

Dans cet environnement, il s’agit pour elles de réaliser le bon produit au bon moment, malgré les imprévus, qui ne manquent pas d’arriver : innovations technologiques permanentes, cadres réglementaires mouvants, écosystème concurrentiel dynamique etc. A cela s’ajoute la difficulté, voire l’impossibilité à cerner précisément le besoin du client en amont du projet, qu’il soit interne ou externe.

Les méthodes agiles offrent une réponse adaptée : apparues au début des années 1990 dans le cadre de projets de développement avant de s’étendre à d’autres contextes. L’approche offre de nouveaux leviers de réussite et permet d’intégrer le client tout au long du processus, tout en offrant la souplesse nécessaire pour aboutir à une solution sur mesure par rapports à ses réelles attentes. Tout en réduisant les risques du projet au plus tôt, en créant des opportunités de réduction du délai de mise sur le marché ainsi qu’un environnement de travail motivant pour un engagement maximal des employés. Ça peut paraître trop beau pour être vrai, mais c’est une réalité pour beaucoup d’entreprises désormais. Un atout considérable sur la concurrence “non agile”.

Pour passer à l’échelle, ces pratiques et d’autres, ainsi que l’état d’esprit associé se doivent d’être diffusées à tous les niveaux hiérarchiques de l’entreprise et dans différents services bien au delà des équipes informatiques : une transformation d’ampleur, qui implique pour les collaborateurs de changer leurs habitudes et leur mode de fonctionnement classique. C’est cette transformation que le MOOC “L’entreprise agile” de Unow, en partenariat avec Onepoint et L’Agiliste, a pour ambition d’accompagner.

MOOC “L’entreprise agile” - Lancement le 14 novembre

Qu’est ce qu’une entreprise agile ? Quel est le rôle du manager ? Quels sont les outils permettant davantage d’agilité au sein des équipes ? Comment entraîner l’ensemble de ses collaborateurs vers plus d’agilité ? etc. Ce MOOC Entreprise Agile, proposé par Unow en partenariat avec le groupe One Point et L’Agiliste, qui débutera le 14 novembre prochain, entend bien répondre à l’ensemble de ces questions.

Pour en savoir plus : MOOC Entreprise Agile

9

5 idées reçues sur la gestion de projet agile

Les idées reçues à propos de la gestion de projet agile ou des méthodes agiles ne manquent pas et peuvent vous éloigner des bénéfices que vous pouvez en attendre. Avouez que ce serait dommage. A l'issue de cet article, vous pourrez vous faire votre propre idée.

Idée reçue n°1 : L'Agilité est une mode

Si l'on considère les méthodes agiles comme de simples méthodes, on peut se dire que c'est juste une mode qui passera. Après tout, des méthodes, on en a vu défiler. En réalité, les méthodes agiles sont bien plus que cela. D'une part, elles véhiculent des valeurs et principes fondamentaux - de management notamment - qui font d'elles un véritable état d'esprit, et d'autre part elles font l'objet d'un véritable changement de paradigme. A tel point qu'une ne devrait pas parler de gestion de projet pour qualifier cette approche mais de gestion de produit.

Le conditionnement du "mode projet" nous pousse à nous focaliser - parfois jusqu'à l'obsession - sur des critères de succès relevant du respect du délais, budget, périmètre... et qualité quand on ne la sacrifie pas au profit des premier critères. Et le produit alors ? Et la satisfaction des utilisateurs ? En mode agile, on se centre sur le produit et le but du jeu ne consiste pas à couvrir tous les besoins exprimés dans un cahier des charges initial qui sera tôt ou tard en déphasage avec le principe de réalité (cf. réelles attentes des "vrais" utilisateurs, évolutions réglementaires, nouvelles idées de fonctionnalités découvertes en cours de route, imprévus techniques, etc). Il consiste plutôt à satisfaire les utilisateurs et enjeux business associés avec le minimum de fonctionnalités.

On ne peut donc pas parler d'un effet de mode pour qualifier un tel changement de paradigme. D'autre part le mouvement agile est un mouvement de fond qui remonte à 2001, année de parution du manifeste agile, voire au delà, puisque la publication du cadre méthodologique agile le plus utilisé, Scrum, remonte à 1993. Un mouvement qui prend toujours plus d'ampleur malgré quelques dérives (certifications bidons, formateurs sans réelle expérience en gestion de projet agile, pratiques de développement agiles négligées, etc).

Idée reçue n°2 : L'Agilité, c'est l'anarchie

Cette idée reçue provient souvent d'une lecture un peu trop hâtive du manifeste agile décrivant les 4 valeurs et 12 principes communes aux différentes méthodes agiles.

4 valeurs qui consistent à privilégier les hommes et leurs interactions par rapport aux processus et aux outils car les projets sont devenus trop complexes pour interagir uniquement à travers des outils ou processus. A privilégier la réalisation d'un produit utilisable plutôt qu'une documentation exhaustive ou pléthorique, à privilégier la collaboration avec les clients plutôt que la négociation contractuelle et enfin l'adaptation au changement plutôt que le suivi d'un plan. Mais le manifeste ne s'arrête pas là, il ajoute : Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Autrement dit sur des projets agiles, il y a bien sûr des processus, Scrum en est un (très simple mais c'est un processus), des outils (il existe désormais pléthore d'outils de gestion de projet agile), de la documentation (il faut bien à minima capitaliser les connaissances requises pour la maintenance du produit et sa pérennité), des contrats (il existe même des contrats agiles "gagnant/gagnant") ainsi que des plans macro et beaucoup de planification (planification à 3 niveaux : long, moyen et court terme pour s'adapter aux changements).

J'ajouterai, que la gestion de projet agile exige bien plus de discipline et de rigueur que l'approche classique. A titre d'exemple, l'équipe d'un projet agile doit être capable de produire de nouvelles fonctionnalités potentiellement livrables aux utilisateurs à la fin de chaque itération dont la durée est très courte. 2 semaines en moyenne.

Idée reçue n°3 : L'Agilité, c'est pas pour les gros projets

Autre idée reçue liée au fait que les méthodes agiles et Scrum en particulier préconisent généralement une taille d'équipe inférieure à 10 personnes. Pour des raisons d'optimisation de "coûts" de coordination notamment. Une limitation qui n'est pas issue de la théorie mais de l'empirisme. Seul véritable moyen de parvenir à une méthodologie pragmatique adaptée aux réalités du terrain. Bien que cette recommandation de taille s'applique à une équipe, rien n'empêche de faire travailler plusieurs équipes de moins de 10 personnes. Il existe même des frameworks éprouvés de gestion de projet agile à grande échelle.

Idée reçue n°4 : L'Agilité, c'est uniquement pour les projets de développement logiciel

Nul doute que les méthodes agiles proviennent du secteur du développement logiciel. Cependant, on voit désormais Scrum (par exemple) utilisé sur des projets industriels, hardware ou encore dans l'éducation. Pour une raison simple, c'est que Scrum n'est qu'un cadre méthodologique léger et adaptable à toutes sortes de contextes projets. Il nous laisse toute liberté d'y intégrer les pratiques et techniques propres à notre contexte. Au point de nous déstabiliser au début car on a l'habitude d'attendre d'une méthode, la réponse à tous les problèmes et tous les cas de figure. Scrum est un cadre méthodologique, pas une méthode.

Idée reçue n° 5 : L'Agilité, ça marche qu'avec des bons et si tout le monde joue le jeu

Bien amenée, les méthodes agiles peuvent satisfaire aussi bien le top management que les acteurs de terrain. Car il se trouve que pour bénéficier des 8 leviers de réussite de la gestion de projet agile, il faut émanciper et respecter les acteurs de terrain : confiance, soutien, auto-organisation, rythme soutenable. Le manager quant à lui (ou chef de projet), généralement en surcharge, sera déchargé de certaines activités pesantes telles que les aspects planning et organisation du travail pour se concentrer sur la gestion des ressources, le leadership et le coaching des membres de son équipe pour développer leur potentiel, les faire grandir.

Mais si tout le monde ne joue pas le jeu ? L'important est surtout d'avoir un noyau dur de personnes prêtes à tenter l'aventure et un "sachant" agile déterminé à introduire l'agilité, notamment à travers le coaching des acteurs. Le niveau de compétences techniques des membres de l'équipe n'a pas davantage ou moins d'importance que sur un autre projet. De toute façon, tout le monde aura l'occasion de développer ses compétences.

Conclusion

Finalement, la seule véritable incompatibilité avec l'agilité serait une culture en conflit avec celle de l'agilité. Autrement dit avec les 4 valeurs et 12 principes du manifeste agile. Et là encore, il faut bien se dire que la culture d'une organisation peut évoluer. Il faudra peut être commencer par un premier projet pilote avec un sponsor fort qui adhère à la culture agile, a bien perçu les gains à tirer de l'agilité et saura démontrer ces gains en cas de succès du pilote pour faire basculer par la suite le reste de l'organisation.

​Et vous, voyez vous d'autres blocages liés à l'adoption des méthodes agiles ?

Déposez un commentaire en bas de cette page.

Déjà 1000 abonnés, ça se fête !

Déjà plus de 1000 abonnés à la newsletter

Nous sommes désormais plus de 1000 personnes à partager un intérêt commun pour les méthodes agiles au travers de la Newsletter de L'Agiliste. Ce qui - je ne le cache pas - me fait extrêmement plaisir, compte tenu de la raison d'être de ce site. J'ai créé L'Agiliste, dans le but de partager avec un maximum de monde ces méthodes agiles qui ont définitivement changé ma façon de mener et vivre un projet.

L'Agiliste 3.0 + Un Webinaire Gratuit

Pour fêter cet événement, j'ai décidé de m'attaquer à une nouvelle refonte totale du site L'Agiliste. Afin de rendre ce dernier encore plus utile et agréable à consulter. Et ce, sur n'importe quel appareil. J'ai encore un peu de travail, mais il y a de bonnes chances pour qu'il soit en ligne avant la fin du mois.

Et ce n'est pas tout. J'ai également prévu d'animer un webinaire (séminaire en ligne) gratuit dans lequel je vais vous expliquer en quoi, CONCRÈTEMENT, les méthodes agiles et Scrum en particulier démultiplient les chances de réussite de mes projets, quels qu'ils soient. Ce sera aussi l'occasion de répondre personnellement à vos questions. Le créneau prévu pour ce webinaire est celui du mardi 15 septembre de 18h à 19h.

Bref, surveillez votre boite mail et bloquez votre agenda 😉

Vous n'êtes pas encore inscrit à la newsletter ? L'inscription est dans la colonne de droite (ou plus bas si vous êtes sur votre smartphone).

Nouveau site de CaptainSPOC

Pour rappel, dans le but de réaliser des formations agiles innovantes et à la pointe, j'ai décidé de m'associer à CaptainSPOC. Une startup pionnière et leader en création de formations de nouvelle génération. Or l'équipe de CaptainSPOC a également refondu son site qui recense ses formations au format SPOC (Small Private Online Course).

Dont mes 2 formations agiles :

Je vous recommande chaudement de visiter le site CaptainSPOC. Et de visionner en particulier la vidéo de 3 minutes de la page d'accueil qui vous explique de façon illustrée en quoi ces formations d'un nouveau genre améliorent la vie des apprenants et la transformation des entreprises à l'heure du digital.

SPOC : 3 minutes pour tout comprendre (Vidéo)

Il reste des places...

J'en profite pour vous préciser que le programme de formation & coaching d'initiation à Scrum et de découverte des méthodes agiles qui démarre le du 21 septembre est confirmée. Puisque nous avons dépassé le nombre minimum de participants. Et il reste des places. Profitez en maintenant.

A très bientôt,
Florent

Faisons connaissance pour vous apporter davantage

Bonjour,

Aujourd’hui, je souhaite en savoir plus sur vous pour vous apporter davantage.

Dans la rédaction des contenus de L’Agiliste, j’ai toujours été guidé par l’idée de rédiger les articles que j’aurai aimé trouver sur internet pour avancer dans mon travail au quotidien. Mais c’est une approche très subjective. Je passe sans doute à côté de vos besoins à vous. Ce qui est bien dommage étant donné que la raison d’être de ce site a toujours été de vous aider en partageant mes connaissances et expériences. Et contribuer ainsi au déploiement de l’agilité en France et des valeurs qu’elle véhicule.

J’ai donc préparé un questionnaire que je vous invite à remplir.

J’ai bien conscience que vous êtes probablement quelqu’un de très pris. Surtout en période de « rentrée ». C’est pourquoi je vous remercie d’avance pour votre temps.

Remplissez le questionnaire ici présent.

Amicalement
Florent

Soyez productif, jetez votre BlackBerry

Soyez productif, jetez votre BlackBerryJe ne sais pas si c’est aussi votre cas, mais ces deniers temps, j’entends beaucoup parler de recherches de gains de productivité. Et d’un autre côté, nous n’avons jamais été autant interrompus dans notre travail au quotidien. Par les emails notamment.

Sur un projet informatique, la communication par email peut être un vrai fléau. Bon nombre d’entre nous ont perdu l’habitude d’une conversation face à face ou par téléphone qui serait bien plus efficace. Dans une organisation qui ne donne pas le droit à l’erreur, l’email est le moyen de se « couvrir », de « tracer » les décisions. Tracer les choses n’est pas un mal en soi à condition que l’email ne soit que le compte rendu synthétique d’une véritable conversation. Quoi qu’il en soit, la communication par email est porteuse d’erreurs d’interprétation, d’oublis, de retards liés au mode guichet, de tensions.

Tout cela m’a donné l’idée d’un article. Et pour élargir l’audience, je l’ai proposé au magazine le Journal Du Net (JDN) qui l’a immédiatement publié. Il a pour titre « Soyez productif, jetez votre BlackBerry ». Il vous propose d’expérimenter un comportement différent vis à vis de ces interruptions causées par les emails. J’ai fait de mon mieux pour le rendre le plus direct, concret et pragmatique possible. J’espère donc qu’il vous sera utile.

Je profite de ce message pour vous annoncer que je souhaite me lancer dans un nouveau projet dont je ne connais pas encore les contours exacts. Dans les semaines ou mois qui suivent, je solliciterai sans doute votre avis sur la question a travers un court sondage. Ce sera l’occasion de mieux se connaître 😉

Je vous souhaite de bonnes vacances si vous en prenez prochainement.

Amicalement
Florent

1

Retour d’expérience d’un projet Agile SNCF

Ce retour d’expérience de 2009 concerne l’un des plus grands projets de mobilité d’Europe du moment qui consistait à réaliser une application mobile d’aide à la conduite pour les agents de conduite de la SNCF (une sorte de TomTom ferroviaire pour faire simple). Les délais accordés à la réalisation de la solution étaient extrêmement ambitieux en plus des enjeux techniques et fonctionnels.

Contexte du projet

Objectifs client

  • Equiper 16 000 utilisateurs d’une application mobile d’aide à la conduite.
  • Développer l’image de modernité.
  • Etre plus efficace, plus souple, plus réactif.

Enjeux projet

  • Equipe MOE : 15 personnes.
  • Taille du projet : 10 années homme.
  • Durée : 8 mois (délais très agressifs).
  • Méthodes Agiles utilisées : Scrum & XP.
  • Durée des itérations : 3 semaines.
  • Type de contrat : Forfait.
  • Intégration de 5 Systèmes d’Informations.
  • Utilisateurs finaux particulièrement exigeants.
  • Exigences de fiabilité élevée (vies humaines en jeu).

Outils utilisés

  • Outils Scrum (Tableau des tâches, burndown chart).
  • Intégration continue avec alarme sonore (Cruise Control).
  • Planning Poker (estimations de charge).
  • Outillage Atlassian : revue de code, Wiki, Bug Tracker, Tableau des tâches virtuel.
  • Selenium.

Résultats obtenus

  • Relation de confiance établie très tôt avec le client (cf. transparence et visibilité).
  • Conception lissée sur toute la durée du projet avec implication des utilisateurs finaux.
  • Délais et budgets respectés.
  • Rythme de travail soutenable.
  • L’application en soi est conforme aux attentes fonctionnelles.

Degré d’agilité : Nokia Test

Avons nous une approche itérative ?

  • Les itérations doivent être timeboxée à moins de 4 semaines : ok itérations fixées à 3 semaines.
  • Les fonctionnalités doivent être testées et fonctionner à la fin de chaque itération : ok.
  • L’itération doit démarrer avant que les spécifications soient exhaustives : ok.

Appliquons nous Scrum ?

  • Vous savez qui est le Product Owner : Au démarrage, le product owner n’a pas pu être clairement identifié. Le Scrum Master a donc joué plus ou moins le rôle de Product Owner Proxy. Au bout de plusieurs mois, a force de sensibilisation et de patience, le rôle de Product Owner a fini par naître côté MOA.
  • Il y a un Product Backlog priorisé en fonction de la valeur métier : Dès le démarrage, nous avions bien un Product Backlog mais la priorisation par valeur métier s’est révélée compliquée. Il a fallu attendre plusieurs mois avant que l’ordonnancement en fonction de la valeur ajoutée se mette en place.
  • Le product backlog contient les estimations établies par l’équipe : oui.
  • L’équipe génère les Burndown Chart et connaît sa vélocité : oui.
  • Il n’y a pas de directeur de projet (ou autre responsable) perturbant le travail de l’équipe : Le Scrum Master a du préserver l’équipe des interruptions et pressions externes (directeur de projet, client).

Retour d’expérience détaillé

Choix de l’approche Agile

La décision d’adopter une approche Agile, s’est faite assez timidement et sans la nommer de peur de bouleverser trop d’habitudes parmi les acteurs du projet (d’autant plus qu’il s’agissait d’un premier essai à la fois pour le client et pour notre équipe). C’est pour cette raison notamment qu’aucun Product Owner n’a été désigné clairement au début. Le choix s’est porté sur une telle approche en raison des délais hors normes du projet et de la complexité du métier. Il fallait commencer à développer tôt avec rigueur, donner un maximum de visibilité au client dès que possible et offrir de la souplesse d’ajustement sur le besoin. L’approche Agile répondait et a répondu parfaitement à ces besoins.

Base contractuelle

Nous avons établi le Product Backlog (PB) en amont du projet en fonction de notre connaissance du besoin. Nous avions au préalable participé à la phase expérimentale du projet, cet exercice n’a donc pas été trop compliqué (2 jours environ). Dans d’autres circonstances, nous serions sans doute parti du cahier des charges ou d’interviews client. Par précaution, nous avons rempli une colonne « hypothèses/couverture » du tableau du PB pour chaque exigence (User Story) de façon à se protéger compte tenu du caractère forfaitaire du contrat. Exemple : « en tant que conducteur je peux consulter mon planning afin de… » donne « hypothèse/couverture : 2 écrans simples, 1 complexe, alimentation des informations de planning par le SI amont ». A partir de cette base, le contenu du PB a bien entendu changé en cours de route, nous avons donc procédé au principe de troc : le client ajoute une exigence en échange du retrait d’une exigence de même coût moins importante qui n’a pas encore été réalisée. Cette approche a permis de gérer les changements sans douleur, sans modifier le budget ou délais du projet et sans avenant.

Conception

La conception fonctionnelle a été lissée sur toute la phase de réalisation du projet. Moyennant tout de même un sprint 0 (un peu plus long que les autres) consacré à la mise en place de l’environnement de développement et d’intégration, des outils, des socles de développement et des bases de l’architecture. La conception fonctionnelle, bien que lissée a toutefois fait l’objet d’un mini « cycle en V » au sein de chaque itération. La première semaine était globalement ainsi découpée : 2 premiers jours d’ateliers de conception avec les utilisateurs finaux et AMOA, 2 jours de rédaction des spécifications/maquettage, 1 jour de relecture/validation des spécifications. Pendant cette première semaine, les développeurs non impliqués dans le travail de conception fonctionnelle et de rédaction réalisaient des développements (anticipés donc) sur des User Stories relativement mûres en termes de besoin. Evidemment, cette approche n’était pas idéale, mais avait le mérite de « rassurer » les décideurs. L’objectif du lissage de la conception était cependant atteint et a donc rendu possible un démarrage des développements très tôt. Ce qui a fortement contribué à affiner le besoin tout en tenant des délais particulièrement ambitieux. Plusieurs mois plus tard, nous avons pu renoncer à ce mini cycle en V pour réaliser les fonctionnalités de bout en bout au fil de l’eau de chaque sprint avec une livraison de la documentation mise à jour à la fin de chaque sprint.

L’effet démo

Chaque itération s’est terminée par une démonstration faite au client sur un simple PDA de développeur pour la partie mobile et sur un PC pointant sur l’URL de notre serveur d’intégration pour la partie web de l’application. Nous n’avions pas grand chose à montrer sur les premières démonstrations mais ce fut une belle expérience. Un simple écran d’accueil peut avoir beaucoup de valeur en démonstration, il structure la suite. Les feedbacks ont donc été précieux. Le client a pu se rassurer en voyant que les choses avançaient dans le bon sens et nous aussi. Parfois il faut courrir après les pré-requis, les décisions, les choix du client, etc. la démonstration a un effet très positif là dessus, en voyant que les choses avance, le client s’implique, il se projette dans l’usage de l’application, il affine son besoin, etc. Rares ont été les feedbacks coûteux en termes de prise en charge, c’est l’avantage quand on découpe le temps en itération courtes, on a peu de chance de mal interpréter un besoin creusé 2 à 3 semaines avant. Cette visibilité offerte au client à travers ces démonstrations a permis d’établir très tôt une relation de confiance précieuse mettant ainsi de l’huile dans les engrenages du projet.

Equipe

En termes de management, nous avons fait le choix d’appliquer à la lettre les principes Agile. Fini le « chef de projet » qui décide, dirige et contrôle. Nous avons donc supprimé toute hiérarchie au sein de l’équipe et appelés « coach » les profils expérimentés. Très peu d’ordres ont été donnés à l’équipe de développement, le Scrum Master avait pour principal objectif d’aider cette dernière à atteindre ses objectifs en la protégeant des évènements extérieurs perturbants et en levant les obstacles au plus tôt. Chacun a peu a peu trouvé sa place, s’est responsabilisé, participé aux décisions du projet pour finalement aboutir à une équipe auto organisée. J’ai plusieurs fois été agréablement surpris par les choix pertinents faits par l’équipe, par les actions d’amélioration proposées en rétrospectives (dont certaines ne me seraient jamais venu à l’esprit). Il est clair que l’équipe est souvent la mieux placée pour faire certain choix tant fonctionnels que techniques de part sa connaissance et maitrise des contraintes. L’autre surprise a été de voir naître si vite un esprit d’équipe à toutes épreuves que je n’avais jamais connu sur mes projets précédents, il est indéniable que les mêlées quotidiennes, le travail en binôme, les rétrospectives, favorisent et cultivent cet esprit si précieux pour la réussite du projet.

L’équipe était constituée de 70% de membres novices en .NET et développement mobile avant leur arrivée sur le projet. 40% des membres de l’équipe étaient des développeurs juniors.

La mêlée (Scrum)

La mêlée est vraiment capitale, c’est un moment de communication intense, d’écoute, de décisions, de révélation des obstacles, de coordination, de renforcement de l’esprit d’équipe,…

Ce sujet mérite un paragraphe à part entière voire plus. Les 2 premiers mois, nous étions aux alentours de 7 personnes, les conditions étaient idéales. L’équipe a cependant mis du temps à vraiment tirer parti de la mêlée, à se l’approprier. Les débuts étaient très scolaires, chacun répondant mécaniquement aux 3 questions à tour de rôle en s’adressant au Scrum Master plutôt qu’à l’équipe. Peu à peu les choses ont commencé à se fluidifier, à se personnaliser. Jusqu’à l’heure de la mêlée.

Lorsque l’équipe a atteint sa taille maximale (15 personnes) nous avons poursuivi de la même façon sans trop déborder niveau timing. Etant donné que le tour prenait pas mal de temps tout de même, nous avons tenté de faire 2 équipes (donc 2 mêlées) mais on ne peut pas dire que ce fut concluant. Pour 2 raisons à mon sens. D’une part parce que l’équipe était plutôt sur dimensionnée par rapport au périmètre à couvrir (difficulté que nous aurions pu surmonter cf. « axes d’améliorations »), du coup il était difficile de faire 2 équipes suffisamment indépendantes. D’autre part, parce que j’ai séparé l’équipe juste avant de partir 3 semaines en congés (soit une itération) en me disant que c’était l’occasion de tester l’autonomie de l’équipe mais je pense que ça faisait trop d’un coup. Nous sommes donc revenu au mono scrum, puis l’équipe s’est réduite.

Travail en binôme

Sans appliquer les principes XP de Pair Programming à la lettre (Programmeur + co pilote et échange du clavier,…) nous avons eu recours au travail en binôme. Dans 2 cas de figure principaux : la montée en compétence des nouveaux entrants (d’autant plus que beaucoup d’entre eux n’avaient jamais développé en .NET) et pour les développements pointus. Concernant les revues de code, nous avons préféré utiliser l’outil Crucible de la suite Atlassian qui permet de faire des revues de code à distance sans déranger le travail de l’autre (que l’on soit relecteur ou relu). Le travail en binôme a clairement contribué à faire rapidement monter en compétences des profils novices en .NET. Nous avons utilisé tardivement la technique du dojo de développement qui s’est révélé être un excellent moyen créer un esprit d’équipe, de capitaliser les astuces de développeurs (raccourcis de l’IDE par exemple), d’uniformiser le code, de faire monter en compétence les juniors.

Difficultés rencontrées

L’essentiel des difficultés concerne celles liées à l’adoption d’une approche Agile par un client, une équipe, un management non initiés. Etant le seul en début de projet formé et convaincu par la pertinence de cette approche dans le contexte du projet, j’ai du faire face à mes propres peurs et celles des autres. J’ai rapidement compris pour quelle raison, l’une des valeurs Agile est le « courage ».

L’équipe par exemple a du pas mal bouleverser sa façon de travailler en développant par exemple verticalement plutôt que par couche, en se réunissant tous les jours pour parler de ses activités, en déplaçant les post-it au quotidien, en se confrontant au graphique d’avancement (burndown chart) et aux réactions du client en démonstration, en adoptant des nouveaux outils (comme l’intégration continue), etc. J’ai observé le phénomène connu d’une période d’enthousiasme ou de doute (selon les individus) suivie d’une période de perte de repères plutôt chaotique (un mal nécessaire) suivie de la période de stabilisation (les nouveaux repères sont en place). Aujourd’hui je pense pouvoir dire que plus personne ne souhaite retravailler à l’ancienne.

Mon management (au sens « mes responsables ») a lui aussi du s’adapter à cette nouvelle façon de travailler. Plutôt sceptique au début, puis peu à peu convaincu. Le plus dur a été de faire un peu oublier les aspects contractuels et les excès de planification/anticipation à trop longs termes. J’ai du également servir de bouclier pour préserver l’équipe des pressions du management en réponse aux retards parfois constatés en cours de route (cf. burndown chart de chaque itération). L’ambiance a souvent été électrique mais la fin est globalement heureuse.

En tant que Scrum Master ayant poussé cette approche, je dois dire que ça n’a pas été facile tous les jours au début. Les enjeux du projet, le fait d’entraîner avec soi une équipe, son management et le client dans une aventure dont on ne connait pas le chemin exact à l’avance génère peurs et solitude. C’est une lourde responsabilité. J’avais beau avoir potassé et expérimenté les méthodes Agile auparavant, la pratique au quotidien avec de gros enjeux est une autre histoire. Mais je ne regrette rien (ni même mes quelques nuits d’insomnie), le jeu en vaut clairement la chandelle. Quoi de plus gratifiant qu’une équipe qui prend plaisir à travailler, qui donne le meilleur d’elle même, qu’un client satisfait qui veut continuer à travailler avec vous ?

Certains projet « pilotes Agile » échouent en raisons des difficultés que j’ai évoqué plus haut (et d’autres). On recommande donc souvent de faire appel à un Agiliste ayant déjà fait ses armes. Je suis assez d’accord avec ce point de vue, même si je trouve qu’apprendre de ses propres essais et erreurs est plus formateur. Lorsque les enjeux sont importants, il faut sans doute faire preuve d’humilité et s’en remettre à des personnes expérimentées (sans perdre la main pour autant bien sûr, il s’agit juste d’être à l’écoute des conseils donnés et de les appliquer soi même). Surtout si on rechigne à lire les nombreux ouvrages ou blogs sur le sujet bourrés de cas d’utilisation « vraie vie » des méthodes Agile.

Sur un plan technique, l’une de nos difficultés a également été de monter une Intégration Continue (IC) pour les développements Mobile. En effet nous ne sommes pas parvenu à aller au delà de la simple compilation du code. L’exécution des TU ne peut pas se faire ailleurs que sur un PDA, or les outils d’IC du marché ne couvrent actuellement pas ce besoin (en tout cas avec Windows Mobile). Nous avons bien sûr essayé de développer une IC maison mais le résultat ne fut pas probant. C’est vraiment regrettable car la majorité du périmètre du projet se situe sur le PDA.

Pour conclure ce paragraphe, je dirais qu’il est primordial d’y aller doucement (petit à petit) dans l’adoption des pratiques Agile afin d’éviter l’indigestion voir le rejet. Tant vis à vis de l’équipe que du management ou du client. De la même façon, mieux vaut expérimenter une approche Agile sur une équipe avant de s’attaquer à l’ensemble des troupes.

Outils utilisés

En fonction de notre budget, nous avons opté pour la suite « Atlassian » en termes d’outillage logiciel :

  • Wiki confluence : dans ce wiki nous avons centralisé un ensemble d’informations à partager au sein de l’équipe (procédures d’installation d’un poste de dev, de récupération du code source à partir du SVN, bonnes pratiques de développement, tutoriaux rapides d’utilisation des outils maison,…). Nous avons ensuite utilisé le wiki pour communiquer avec le reste du monde (AMOA, client,…) en maintenant par exemple une page résumant le contenu de chaque version livrées, le planning global,…
  • Outil de suivi des défauts JIRA : nous avons également utilisé JIRA pour le suivi des défauts détectés en interne et utilisé l’outil du client pour les défauts détectés par les testeurs AMOA/MOA. JIRA nous a également servi pour le suivi de l’avancement des tâches de développement. Chaque développeur ajustait chaque soir son « reste à faire ».
  • Outil Agile GreenHopper : GreenHopper nous a permis d’intégrer dans JIRA un tableau virtuel des tâches (en plus du tableau physique) et de générer automatiquement en temps réel le burndown chart.
  • Outil de revue de code Crucible : voilà un bien bel outil (sous forme de plugin JIRA) connecté au gestionnaire de version qui permet de faire des revues de code à distance sans déranger le travail de l’autre (que l’on soit relecteur ou relu)
  • Selenium pour les tests d’IHM web

Par la suite nous avons fini par se passer de Green Hopper pour revenir exclusivement au tableau des tâches physique et un tracé « artisanal » des graphiques d’avancement. Avec Green Hopper, les interactions humaines étaient réduites et les « reste à faire » des tâches pas toujours renseignées malgré les relances et sensibilisations.

Transformation du site "L'Agiliste"

Bonjour,

Si vous êtes un habitué de ce site, vous avez sans doute constaté des changements ces derniers mois. En effet, le site a fait peau neuve. J’espère que vous appréciez ou apprécierez le nouveau design, la nouvelle organisation du contenu, la nouvelle ergonomie ainsi que les récentes publications. Concernant l’organisation, il y a principalement 3 zones de contenu :

Parmi les publications récentes, vous pouvez notamment trouver un article d’introduction au leadership tribal et un autre sur la Livraison Continue. Quant à l’ergonomie, je vous invite par exemple à utiliser les filtres dynamiques appliqués aux catégories sur la page « J’ai lu pour vous ». Mais ce n’est pas tout. J’ai également fait un peu d’introspection pour savoir pourquoi j’ai créé ce site et quelles valeurs fondamentales me guident. C’est ce que vous pouvez découvrir dans la page « A propos ». Ce qui m’a poussé à jouer la transparence sur les fréquentations du site.

Je tenais aussi à vous faciliter la vie en vous offrant la possibilité d’être averti par flux RSS ou email des nouveautés. Par ailleurs, chaque page contient des outils de partage de lien via Facebook, Twitter, LinkedIn ou Google. Les commentaires sont enfin ouverts sur la partie blog (je n’ai pas encore réussi à les ouvrir sur les articles) et un bouton « imprimer » figure en bas de chaque contenu.

Je profite également de ce billet pour préciser que nous sommes en train de finir la traduction du livre « An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture » de Michael Sahota. A mes yeux, ce livre a un rôle important à jouer en cette période de fragilité de l’Agilité. L’enjeu culturel étant le principal défi à relever. Dès qu’il sera dispo, je posterai un nouveau billet. Cette traduction m’a d’ailleurs donné envie d’écrire à mon tour un livre… Affaire à suivre 🙂

Si vous souhaitez être automatiquement avertis lors de nouvelles publications, je vous invite à vous inscrire ci dessous. Rassurez vous, votre adresse email ne sera pas détournée et vous ne serez pas spammé. Je déteste ça moi aussi. Par ailleurs, si vous avez des suggestions de sujets à traiter ou d’améliorations, n’hésitez pas à vous exprimer en déposant des commentaires en dessous ou via le formulaire de contact.

[subscribe2]

Sur ce, je vous souhaites bien du plaisir dans vos lectures, sur vos projets et dans votre vie perso bien sûr.

A bientôt
Florent