All Posts by Lothon Florent

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

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.
2

La pratique du lean management dans l’IT

 

Qu’est ce que le lean management concrètement ? Si j’applique le cadre méthodologique agile Scrum ou une autre méthode agile, suis je en train de faire du lean management sans le savoir ? Est ce que le lean management peut compléter la valeur ajoutée d’une approche agile pour mener un projet ? Ce sont ces questions qui m’ont poussé à lire cet ouvrage intitulé « La pratique du lean management dans l’IT – Agilité et amélioration continue« . J’ai pu y trouver les réponses à ces questions que je partage avec vous ci dessous. Et bien davantage.

Qu’est ce que le Lean ?

Voici la définition donnée par le livre

« C’est un système de management qui vise tout à la fois à satisfaire pleinement les clients, tout en réduisant les coûts et en développant les collaborateurs. Les managers lean assument pleinement ces trois ambitions simultanées qui peuvent paraître paradoxales ».

Lean management et méthodes agiles

Les principales caractéristiques du lean management sont les suivantes :

  • La recherche de la satisfaction client avant tout. En allant physiquement à la rencontre de ce dernier et en recherchant inlassablement la création de valeur.
  • L’élimination des gaspillages avec 7 familles de gaspillage.
  • Une pratique agressive de la résolution de problème
  • Le refus du status quo et la conviction que la perfection n’existe pas et qu’il y a sans cesse matière à s’améliorer
  • L’obsession de la mesure pour vérifier l’amélioration concrète et apporter ainsi la motivation nécessaire au changement
  • L’importance accordée au développement des compétences de chacun. Autrement dit pour reprendre une phrase du livre « Développer l’humain avant de développer des logiciels« . Des valeurs clairement opposées au Taylorisme.
  • Le management visuel pour voir ensemble, agir ensemble et de comprendre ensemble

Le lean provenant à l’origine du secteur industriel et de l’entreprise Toyota en particulier, les auteurs du livre déclinent, exemples à l’appui, 7 familles de gaspillage dans le secteur de l’informatique. C’est l’une des parties que j’ai trouvé les plus intéressantes et utiles au quotidien. Cela permet de se forger un détecteur d’optimisations de l’efficacité pour davantage de satisfaction client et de sérénité au travail.

Les méthodes agiles ont également dans leur ADN, les principes d’amélioration continue, de recherche du feedback rapide des utilisateurs, une part importante accordée à l’humain, etc. Mais pas aussi poussée et affichée que le lean management à mon sens.

J’ai donc tendance à partager la conclusion du livre, illustrée par un contexte dans lequel une équipe agile a atteint un niveau d’efficacité satisfaisant. Mais peine à passer un nouveau cap d’efficacité malgré l’application à la lettre des pratiques et principes agiles. C’est à cet instant que le Lean Management peut apporter un complément utile.

Quelques phrases clefs du livre pour finir :

« Le manager est celui qui crée les conditions dans lesquelles ses équipes vont expérimenter, apprendre et réussir ».

« Le lean s’attache à satisfaire le client, l’actionnaire et le collaborateur. Le collaborateur développe son savoir faire et son expertise par la résolution de problèmes qui tiennent à coeur les clients et les actionnaires ».

Acheter ce livre

Scrum

Scrum

Claude Aubry, l’auteur du livre Scrum – Le guide pratique de la méthode agile la plus populaire,  fait partie des pionniers de l’adoption de l’agilité en France. A l’époque où aucun livre en français n’existait sur le sujet. C’est d’ailleurs ce qui explique la rédaction tardive de cette nouvelle fiche de la collection « J’ai lu pour vous ». En effet, mes lectures au sujet de Scrum remontent à cette même époque. Des lectures d’ouvrages en anglais donc. Depuis la sortie de sa première édition, je m’étais toujours dit que je prendrai le temps de lire le livre de Claude bien que ma connaissance de Scrum soit déjà plus qu’approfondie. Voilà qui est fait avec la 3eme édition.

Structure du livre Scrum

Si je devais diviser le livre Scrum en trois grandes parties, je dirais que :

  1. Les premiers chapitres sont consacrés à Scrum en soi. Ils détaillent chaque élément du cadre méthodologique Scrum.
  2. Les suivants viennent compléter Scrum par les différentes pratiques agiles connexes telles que celles associées à la gestion de produit ou les pratiques de développement agiles (pratiques d’ingénierie).
  3. Enfin, les derniers traitent des outils Scrum, de la spécificité des contextes projet français, de la transition vers l’agilité ainsi que de l’utilisation de Scrum à grande échelle.

Principaux atouts de ce livre

Voici les principaux atouts du livre Scrum :

  • Son exhaustivité : Claude ne se contente pas de couvrir avec exhaustivité le cadre méthodologique Scrum en soi, il aborde aussi les pratiques agiles connexes et indispensables que Scrum ne couvre pas. Ainsi que les enjeux de transition agile. Car connaître Scrum est une chose mais maîtriser sa mise en oeuvre en est une autre.
  • La prise en compte du contexte projet à la française : La France s’étant inspirée du BTP pour définir les organisations projets, la séparation Maîtrise D’ouvrage (MOA) et Maîtrise d’Oeuvre (MOE) pré-existe en général. Ce livre couvre ces spécificités.
  • Sa perspective Product Owner : Les livres traitant de Scrum sont souvent « déséquilibrés » et couvrent principalement le rôle de Scrum Master dont la responsabilité consiste à garantir le respect du cadre méthodologique Scrum et s’assurer que l’équipe de développement est pleinement efficace. Ce déséquilibre n’est pas un mal un soi et il est plutôt logique. Cependant, on apprécie dans ce livre l’expérience de l’auteur dans le rôle de Product Owner et sa sensibilité à ce rôle demeurant clef pour la réussite du projet.
  • Les anecdotes : Au delà de la description des pratiques agiles couvertes, des exemples utilisés, les anecdotes contribuent énormément à la dimension « pratique » de ce guide. L’auteur partage ainsi toute son expérience.
  • Les dessins humouristiques : Les illustrations humoristiques apportent du fun et de la légèreté à l’ouvrage.
Acheter ce livre

Lean Startup

Lean Startup

Qu’est ce que le Lean Startup ? En quoi est ce différent des méthodes agiles ? En quoi ce livre peut intéresser n’importe quelle entreprise ou organisation ? C’est à ces questions que je propose de répondre dans cette nouvelle fiche de la collection « J’ai lu pour vous ».

Qu’est ce que le Lean Startup

On pourrait dire que le Lean Startup est le fruit d’une série d’échecs. Et quand l’échec est une source d’apprentissage, c’est déjà un bon point de départ pour faire de ce livre, un véritable outil pragmatique et efficace. L’auteur qui n’est autre que l’inventeur du Lean Startup – à force d’échouer dans ses projets de startup – a fini par se tourner vers la méthodologie et le système de pensée Lean issues du milieu industriel. De Toyota plus particulièrement. Petit à petit, il a élaboré une véritable méthodologie permettant d’augmenter considérablement les chances de succès d’une startup. Nous pourrions dire la même chose de l’apport d’une approche agile à un projet. Les deux approches sont d’ailleurs très complémentaires et ont des principes communs.

Depuis sa naissance en 2008, le Lean Startup a connu un développement considérable tout comme comme les Startup Week-end consistant à créer une startup et un prototype de produit en seulement un week-end à partir d’une simple idée.

La fin des startups dépourvues de méthodologie

Les bénéfices apportés par le Lean Startup sont tels qu’on peut s’attendre à ce qu’il devienne difficile de se lancer dans la création d’une startup sans un minimum de méthodologie et d’organisation. Si je devais moi même investir dans une Startup, je ferai du respect du Lean Startup et d’une approche agile un prérequis essentiel. Mais ça n’engage que moi et je dérive un peu.

Remettre en question ses croyances

Le Lean Startup nous encourage à remettre en question les croyances suivantes :

  • La méthodologie menace l’innovation : Un entrepreneur se lançant dans l’aventure de la création d’une startup peut se dire que la méthodologie et l’organisation font obstacle à l’innovation qui elle-même est un fondement de la startup. Hors au contraire, le Lean Startup va canaliser l’innovation pour décupler son impact dans le développement de la startup.
  • Les gens vont adorer mon produit : Deux croyances peuvent nous mener droit à la douche froide. L’excès de confiance en son instinct ou idée « les gens vont adorer mon produit et y mettre le prix » ou la peur de l’échec qui peut nous pousser à consommer énormément d’énergie et d’argent à mettre au point un produit de A à Z avant le mettre sur le marché.

Tester au plus tôt ses hypothèses

Afin d’éviter la douche froide, il est nécessaire de vérifier au plus tôt les hypothèses de croissance associées aux produit réalisé. Intérêt pour le produit, comportement des utilisateurs, canaux de distribution, etc.

Lean Startup nous apprend à mettre en oeuvre une organisation et une démarche nous permettant d’apprendre le plus tôt et le plus fréquemment possible. Prenons l’exemple de Dropbox, cette solution de partage de fichiers entre plusieurs ordinateurs et plusieurs personnes. Les créateurs de Dropbox, avant même de développer la moindre fonctionnalité ont commencé par réaliser une vidéo montrant le fonctionnement cible de Dropbox comme s’il existait déjà. Et c’est seulement en constatant le succès de cette vidéo, qu’ils ont décidé de se mettre à l’oeuvre.

Voilà une anecdote qui illustre à l’extrême l’état d’esprit Lean Startup. Un état d’esprit décliné en une méthodologie éprouvée décrite en détail dans ce livre.

Faire du Lean Startup dans les entreprises

De plus en plus d’organisations, petites et grandes et de tous secteurs sont amenés à « faire plus avec moins ». Beaucoup d’entre elles évoluent dans un contexte de plus en plus complexe rendant la réalisation du « bon produit » sans cesse plus difficile. Lean Startup vient répondre à ces enjeux avec une approche pragmatique, redoutablement économique lorsqu’elle est bien utilisée et complémentaire à l’approche agile. Sur un projet agile, le Lean Startup intéressera particulièrement le Product Owner. En particulier en amont du projet mais il peut également s’avérer être utile pendant.

Enfin dans son livre, l’auteur Eric Ries, utilise énormément d’exemples pour illustrer ses propos. L’un d’entre eux concerne l’utilisation de l’approche Lean Startup pour réaliser de la transformation d’organisation. Cet exemple est décrit brièvement mais peut servir d’inspiration pour mener un projet de transformation agile qui par nature fait l’objet de beaucoup d’incertitude et par conséquent, d’hypothèses à vérifier au plus tôt.

Acheter ce livre

 

1 2 3 7