En quoi le Lean management aide-t-il les entreprises à être plus agiles ?

Depuis de nombreuses années on entend parler de la nécessité pour les entreprises d’être « agiles » face à la complexité croissante de notre environnement business, de ses évolutions rapides et imprévisibles, et face aux besoins des nouvelles générations. Mais comment augmenter le niveau d’agilité d’une entreprise ? Le Lean management propose des réponses pragmatiques.

Marc Legru, Associé d'Operae Partners

Les 3 principes du Lean Management

Le Lean management est à la fois un système de production (ce qu’on appelle le TPS, Toyota Production System) et un système de management (le Toyota Way) basé sur :

  • L’apprentissage par la méthode scientifique de résolution de problème
  • Le respect de la capacité des personnes à réfléchir par elles-mêmes et de leur droit à réussir dans leur job

Le Lean management est ainsi basé sur plusieurs pratiques qui contribuent à l’agilité de l’entreprise, voici comment :

  • Être agile, oui mais pour qui ? dans quel but ? La réponse est claire pour le Lean : il s’agit d’être agile pour satisfaire pleinement les besoins des clients – internes ou externes, quelle que soit la façon dont ces besoins évoluent. Il est donc essentiel de bien comprendre ce que valorisent ces clients. Pour ce faire, le Lean utilise des techniques comme la Voix du Client (explicitée plus loin), l’analyse des réclamations et la visite sur le terrain des utilisateurs, là où ils utilisent votre produit ou service.
  • Être agile c’est arriver à ce que les managers et collaborateurs n’aient plus à faire certaines tâches qui n’apportent pas de valeur ajoutée aux clients et qui alourdissent leur activité et donc réduisent le temps disponible pour les tâches à valeur ajoutée. C’est ce qu’on appelle les gaspillages et en Lean, on les classe par familles pour faciliter leur identification sur le terrain.
  • Être agile c’est être capable, en quelques minutes de changer le type de produit ou de service que l’on délivre, et donc d’avoir une capacité de production flexible. Le Lean management apporte différentes techniques pour reconfigurer rapidement un poste de travail, par exemple la technique dérivée du SMED.
  • Être agile c’est avoir développé la capacité de l’entreprise à reconcevoir efficacement ses produits ou services en fonction des succès et échecs constatés avec les produits ou services existants. Le Lean management se décline ainsi dans l’ingénierie : c’est le Lean engineering.
  • Être agile passe aussi et surtout par la capacité de chacun, à son poste de travail, de savoir réagir aux situations imprévues. Donc d’une part à être pleinement autonome dans la résolution des problèmes à son propre niveau, et d’autre part à être en capacité à prendre soi-même des initiatives pour répondre immédiatement aux imprévus, et sans avoir à demander à son supérieur hiérarchique à chaque fois. Pour développer ces capacités chez chacun des collaborateurs, la base fondamentale du Lean management est la formation à la méthode scientifique de résolution de problème c’est à dire au PDCA (Plan Do Check Act), formation qui se fait sous forme de coaching par le manager ou dans un premier temps par un coach Lean.

Je vous propose de faire le focus sur 2 techniques fondamentales dans l'approche lean : écouter vos clients et résoudre les problèmes de manière efficace avec la méthode scientifique.

Ainsi être agile c’est donc d’abord donner du sens et des objectifs d’agilité principalement pour mieux satisfaire ceux – qu’ils soient utilisateurs internes ou en bout de chaîne – qui bénéficient de la valeur délivrée par l’équipe, ce que l’on appelle en général « les clients ».

Pour satisfaire pleinement ces clients encore faut-il les avoir bien identifiés et ensuite comprendre leurs besoins et ce, en permanence.

Concrètement, imaginons que vous avez bien identifié vos clients. Si vous utilisez la « Voix du Client », la méthode du Lean management pour mieux comprendre leurs critères de satisfaction, vous allez interviewer une personne qui a reçu récemment un produit ou un service, à propos de ses attentes dans l’idéal et de ce qu’il a réellement obtenu. Ses attentes peuvent être classées en 5 familles :

  • Donnez-moi exactement ce que je veux, c’est-à-dire le produit ou le service avec toutes les caractéristiques voulues par le client.
  • Quand je le veux, ni trop tôt ni trop tard.
  • Où je le veux, c’est-à-dire à un endroit précis pour un produit tangible, ou au format désiré s’il s’agit d’un bien immatériel.
  • Soyez fiables c’est-à-dire fournissez-moi un produit ou un service qui fonctionne du premier coup et dans la durée.
  • Ne me faites pas perdre mon temps, je veux obtenir le produit ou le service avec le moins d’intervention de ma part.

Pour chaque famille d’attente, vous allez ainsi obtenir les pistes d’amélioration du point de vue du client et donc des opportunités pour être plus agile !

Une autre technique à la base du lean management est la méthode scientifique de résolution de problèmes. Je vous propose de vous en présenter les premières étapes.

Quelle est la pratique la moins partagée ? C’est retourner sur le terrain et mieux observer. Cela semble facile en théorie, mais la pratique est tout autre. En effet, il est facile de ne voir que ce qui correspond à ce que l’on pense déjà et de passer à côté du vrai problème. On peut résumer cela par la phrase suivante : "quand on regarde rapidement une situation on ne trouve que ce qu'on cherche". Il faut avoir regardé une situation assez longtemps pour aller au-delà de nos idées et préjugés. Une telle attention change tout car une des grandes difficultés dans la résolution de problèmes est d’identifier correctement le « point de cause », ce qui est nécessaire pour avancer efficacement dans la résolution. Le point de cause est l’endroit précis où le processus concret ne se comporte pas comme il le devrait. Il est souvent caché par d’autres événements, mais aussi par les a priori de l’observateur qui ne regarde alors pas là où il faut ou comment il faut. Le point de cause est pourtant souvent la clé qui permet de commencer à comprendre le problème.

Une fois que le point de cause est identifié, la pratique suivante de la résolution de problèmes est l’identification des facteurs à l’origine du problème. Cela implique de tester ses hypothèses une par une. Pour établir une liste de départ de ces hypothèses de facteurs, le manager ou le coach peut utiliser la technique des 4M et utiliser les familles de facteurs suivants :

  • D’abord la main-d’œuvre : le collaborateur est-il bien formé ? Est-il présent aux bons moments ?
  • Puis la machine et les outils : l’équipement fonctionne-t-il comme prévu ?
  • Ensuite les matériaux et inputs : les éléments et inputs utilisés sont-ils conformes ? Les données d’entrée sont-elles fiables ? Complètes ?
  • Enfin la méthode : la méthode employée est-elle la bonne ? Est-elle claire ? Bien appliquée ? Sommes-nous dans le bon cas de figure ? Avons-nous bien compris le contexte ?

La pratique du test d’hypothèses une par une est essentielle non seulement à la résolution du problème mais également au développement des personnes.

En testant chaque facteur, l’employé apprend à distinguer les facteurs qui ont un impact sur le processus et ceux qui n’en ont pas. Les deux informations lui permettent de se bâtir un modèle mental précis de la manière dont le processus se comporte en pratique.

Pour cette raison, il faut éviter si possible les plans d’expérience et les analyses statistiques trop élaborées, qui restent mystérieuses aux yeux des collaborateurs. E n effet construire sa propre méthode d’investigation systématique et de contrôle des facteurs fait entièrement partie du développement de l’expertise individuelle.

En conclusion, le Lean management fournit un ensemble de principes et pratiques pour permettre à chacun de développer sa capacité à mieux produire et de manière réactive, au service des clients.

Et vous, que faites-vous pour rendre agiles vos équipes ?

9

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.

2

Créez le bon produit avec Scrum et Lean Startup

Par Thomas Thelliez, agiliste, créateur de startups et blogueur.

Découvrez dans cet article une méthode avant-gardiste issue du monde des startups, compatible avec SCRUM qui serait plus que bénéfique aux entreprises traditionnelles afin de valider de façon précise l’intérêt que portent leurs futures audiences à leurs applications.

Lorsque l’on travaille dans une entreprise depuis de nombreuses années, on a tendance à connaître son métier et les process qu’il implique sur le bout des doigts. Cependant, il est parfois difficile de prendre du recul sur les métiers des départements voisins (marketing, DSI, communication). Je dirais même plus, ces départements sont parfois tellement cloisonnés dans certaines sociétés, qu’on ne prend pas forcément la peine de s’intéresser aux métiers et aux besoins des autres.

Pourtant, bien souvent, les projets digitaux ressortent grandis par une communication fluide et une connaissance partagée entre les départements. Connaissance permettant par exemple aux DSI, aux départements marketing et aux parties prenantes de s’assurer ensemble de la bonne direction prise dès le départ d’un projet.

Après avoir créé 2 sociétés innovantes et avoir eu l’opportunité de travailler sur des projets SCRUM au sein d’entreprises traditionnelles, je partage avec vous mon expérience et j’explique, dans cet article, comment l’entreprenariat m’a permis d’être plus efficace lors de la création de projets digitaux.

Ouverture d’esprit


En devenant chef d’entreprise, j’ai dû me former, découvrir, apprendre sur le terrain et à force d’expérience, j’ai acquis les bases du marketing, du commerce, de la communication, de la finance, de la gestion RH, etc. En l’espace de 5 ans, j’ai eu l’immense opportunité de m’ouvrir l’esprit à tous ces domaines qui, auparavant, lorsque je travaillais chez des grands groupes au sein de DSI, ne représentaient pour moi que des noms des départements voisins au sein de l’organisation.

L’ouverture d’esprit que m’a offert l’aventure entrepreneuriale m’a permis de transformer radicalement ma vision d’un produit et des projets. J’ai pu découvrir les tenants et les aboutissants du marketing et comprendre les impacts et les répercutions qu’il avait sur le produit. La façon dont je présentais des projets à mes différents interlocuteurs a considérablement changé également.

Avant de passer par cette phase entrepreneuriale, je sous-estimais l’importance d’une harmonie entre le marketing, la communication et les différents acteurs gravitants et agissants sur la vie d’un projet digital.

Ouvrez votre esprit

Vivre les deux situations m’a permis de mieux comprendre les conflits d’intérêts que l’on rencontre parfois dans des sociétés de taille conséquente. L’intérêt du département marketing est différent de l’intérêt du département communication qui sera différent de l’intérêt de la DSI sur un seul et même produit. Ces points de vue ne sont pas toujours correctement partagés entres les différentes entités malheureusement.

Voici un petit exemple très stéréotypé (veuillez m’en excuser) de divergence d’intérêt : Imaginons qu’une entreprise se lance dans le développement de sa première application mobile.

  • Le département marketing souhaite offrir une application mobile à ses clients pour les fidéliser davantage et leur pousser (notification push) plus facilement des informations contextualisées concernant de nouveaux services ou promotions.
  • Le département communication voit dans cette même application mobile, un nouveau canal de prédilection pour échanger avec la communauté grandissante autour de la marque.
  • Le département digital est quant à lui ravi de franchir, grâce à cette application, un nouveau pas vers la digitalisation et d’innover sur la plateforme devenue en 2016 incontournable: le mobile.
  • Enfin, la DSI a comme challenge de monter en compétences sur les technologies mobiles et de transformer son SI afin de répondre aux futurs développements multi-canaux.

Se basant sur ce constat, personne ne se met fondamentalement à la place de l’acteur essentiel que je n’ai volontairement pas encore cité, qui est ni plus ni moins : l’utilisateur final (souvent le prospect ou « client »). Vous allez me dire, l’expression de besoin a été rédigée pour fournir à ces futurs utilisateurs des services adaptés, et que ses fonctionnalités sont censées répondre précisément à des besoins précis récoltés en auditant ou sondant des clients existants.

Malheureusement, les utilisateurs sont souvent laissés pour compte afin de satisfaire les intérêts des différents services. Les applications livrées aux utilisateurs pâtissent de cette mauvaise communication entre départements, elles souffrent de plus généralement d’un manque d’ergonomie ou d’une complexité (expérience utilisateur) sans commune mesure.

La méthode “Lean Startup” m’a appris que pour qu’un projet d’application soit un succès, il est primordial de partager et d’échanger avec l’utilisateur final. Et cela, avant et pendant le processus de développement.

J’en viens donc désormais à vous présenter cette méthode très appliquée chez les startups qui est hautement compatible avec un projet SCRUM, encore très peu répandue au sein des entreprises et qui permettrait à coup sûr de valider la pertinence et l’intérêt entre la demande et la solution.


Découverte de la méthode Lean Startup

La méthode “Lean Startup” est très en vogue dans l’écosystème des startups (à ne pas confondre avec la variante plus connue dénommée “Lean Management”). La méthode “Lean Startup” est utilisée afin de valider au plus tôt la pertinence d’un projet et potentiellement de le faire pivoter dans la bonne direction. La question fondamentale à laquelle la méthodologie permet de répondre est la suivante :

Votre produit résout-il un problème qui vaut la peine d’être résolu ?

Cette méthode pousse à se concentrer avant tout sur le problème, pas sur la solution et donc pas directement sur le produit. Concrètement, en parallèle des sprints agiles, le Product Backlog SCRUM va être alimenté en se plaçant toujours au plus prés des utilisateurs finaux et non au plus près d’une expression de besoin figée et provenant du marketing ou maîtrise d’ouvrage.

J’insiste fortement sur ce point, les méthodes agiles sont connues pour apporter une souplesse et une flexibilité grâce à des itérations. Cependant, une fois que vos sprints agiles sont mis en place, la souplesse et la capacité de pivoter de votre produit ne dépendra au bout du compte plus ou moins que de l’enrichissement ou de la priorisation des stories dans votre Product Backlog. La méthode Lean Startup peut être redoutablement efficace pour vous aider à alimenter et modifier efficacement votre backlog au fur et à mesure des sprints.

Pour mesurer l’importance du problème ou de la souffrance que vivent les utilisateurs, la méthode Lean recommande de parler avec eux, de rencontrer l’audience ciblée le plus possible et le plus souvent possible.

Rencontrez et parlez avec votre audience, dès que vous le pouvez, pour comprendre ce qui leur complique le plus la vie durant leurs activités, quelles qu’elles soient. Ne demandez pas à vos interlocuteurs ce qu’ils veulent mais essayez de mesurer ce qu’ils font et ce qui leur rend la tâche difficile.

Solutionnez votre probleme
Henri Ford Industriel

Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient dit vouloir des chevaux plus rapides.

Avec cette citation, il voulait dire que personne ne lui a dit: “J’ai besoin d’une voiture” mais il a déduit le problème sous-jacent: les gens souhaitaient se déplacer d’un point A à un point B plus rapidement qu’à cheval.

Essayez d’interviewer le plus de personnes que vous pouvez (20-30 minutes chacun) Itérez et mettez à jour votre discours si nécessaire durant cette période lorsque vous leur présentez brièvement le projet. Ne parlez pas trop. Laissez les gens parler plus que vous et notez tout ce qui pourrait vous aider à identifier un ou des problèmes majeurs. Documentez vos résultats immédiatement après chaque entretien tant que vos pensés sont fraîches. A l’issue de ces entretiens, la ligne directrice ou les fonctionnalités manquantes à votre future application en découleront sans difficultés vous permettant ainsi d’alimenter votre backlog régulièrement.


En quoi Lean Startup peut profiter aux entreprises traditionnelles ?

Les entreprises sont des usines, des poids lourds dont les rouages et les procédures en font parfois des tortues en ce qui concerne l’innovation. Cette lourdeur procédurale ne permet pas souvent aux équipes innovantes et équipes projets d’aller à la rencontre de leurs utilisateurs, d’aller, littéralement, sur le terrain, de découvrir ou redécouvrir la REALITE de leurs métiers.

Les startups ont, quant à elles, cette faculté, grâce à leurs petites tailles et leurs procédures et structurations quasiment non-existantes, d’être au plus près de leurs audiences.

Combien de sociétés, finissent par avaler, racheter des jeunes pousses qui révolutionnent les marchés par leurs innovations ?


Se mettre dans la peau des utilisateurs grâce aux “Personas”

Vous allez me dire, et j’en conviens, que lorsqu’on développe un projet SCRUM à destination de prospects au sein d’une société bien structurée qui n’est depuis longtemps plus au stade de startup, on a rarement l’occasion, ni même parfois la permission, d’aller discuter et rencontrer les utilisateurs finaux sur le terrain. Voici, ci-dessous une technique qui permet de pallier légèrement à cette contrainte :

Elle consiste à se mettre dans la peau des futurs utilisateurs : il s’agit de la technique dite des “Personas”. Utilisée par bon nombre d’agences de design, cette méthode débute par un atelier où l’équipe conçoit 4, 5 profils types d’utilisateurs. L’exercice consiste à catégoriser et segmenter votre future audience en profils, en les triant par âge, catégorie sociale, sexe, fonction etc.

En fonction du secteur d’activité de votre entreprise ou de votre offre, posez vous les questions suivantes pour chacun des profils correspondants à votre audience :

Quels sont leurs objectifs principaux ? Les challenges auxquels ils font face ? etc

Voici ci-dessous, 3 “personnas”/profil type possibles :

  • Sylvie Michu, 42 ans, mariée, 3 enfants, assistante de direction, utilise peu son smartphone et télécharge peu d’applications.
  • Hugo Thuriaux, 23 ans, célibataires étudiant en histoire de l’art, utilise son smartphone plusieurs fois par jours, addict des plateformes sociales.
  • Jean Dumontreux, 38 ans, marié, 2 enfants, consultant en finance, souvent en déplacement, utilise son smartphone entre ses rendez-vous et durant ses déplacements.
Definissez vos personas

Encore une fois, désolé, pour ces exemples plein de stéréotypes mais vous avez ainsi compris l’essentiel de la méthode. Grâce à cette technique, vous pouvez désormais dans chaque cérémonie agile ou atelier de conception fonctionnelle de votre future application, vous placer, vous et vos collaborateurs, dans la peau de ces personnages fictifs, un par un.

Vous serez ainsi au plus près de vos utilisateurs potentiels lorsque vous concevrez votre application et vous pourrez ainsi appliquer les pratiques du “Lean Startup” sans sortir de votre bureau.

Vous remarquerez très vite que cet exercice vous aidera à penser “usage” et “ergonomie” en premier lieu. Grâce à cela, vous augmenterez considérablement l’adoption et la rétention de vos utilisateurs dès la sortie du produit.


Le Lean Startup Canvas pour sécuriser les bases du projet

Plus tôt dans l’article, j’ai cité les conflits d’intérêt qui subsistent généralement entre les différents acteurs et départements vivants autour d’un projet. Voici ci-dessous, un bon moyen d’éviter les tensions en déterminant très tôt une définition commune du projet partagé par toutes les entités et départements de votre organisation.

L’idée est de rassembler, autour d’une même table, les principaux acteurs de chacun des départements au travers d’un atelier/workshop de 3 heures et de les faire travailler sur la création d’un “Lean Canvas”.

Le Lean canvas, utilisé par tous les pratiquants de la méthodologie “Lean Startup”, se compose d’une page et aide à décrire et définir toutes les facettes d’un projet digital. Les aspects communication, déploiement, commercialisation sont pris en compte, ce qui donne à tous les acteurs du projet une vision claire et partagée du futur produit. Avec un Canvas, vous pouvez décrire, concevoir, challenger, inventer et pivoter votre idée de projet quand vous le souhaitez, en quelques minutes.

L’intérêt de la définition du Lean Canvas est qu’il vous force à répondre à des questions et points clés, qui sont principalement les suivants:

  • La proposition de valeur (Unique Value Proposition)
  • Les fonctionnalités principales (Features)
  • Le problème sous-jacent (Problems)
  • Le marché (Markets)
  • La solution (Solution)
  • Les canaux de distributions (Channels)
  • Les sources de revenus (Revenue Streams)
  • Les typologies de clients ciblés (Customer Segment)
  • Les risques externes (External risks)
  • Les indicateurs clés (Key performance indicators/Key metrics)
  • Les coûts de structure (Cost structure)
  • La barrière à l’entrée (Unfair advantage)

Comme vous pouvez le constater, pour répondre à ces différentes questions, tous les acteurs du projet son requis. Les différents départements seront ainsi aménés à partager leurs points de vue et leurs intérêts. Cet atelier de réalisation du Canvas sera le moyen parfait pour fédérer les équipes et éviter des futurs conflits ou incompréhensions liées à une mauvaise communication. Pour rendre cet atelier plus ludique, je vous conseille d’imprimer le canvas en format poster et de le coller sur un mur ou alors de le redessiner en grand sur tableau blanc. Chaque groupe pourra y accoler des posts-it, tout comme sur un Kanban Agile et exposer ses pensées et idées au reste de l’auditoire.

Lean canvas

De plus, le format léger du Canvas (une seule page) vous permettra, à l’issue de l’atelier, de facilement le partager ou de mettre à jour vos hypothèses à n’importe quel moment. Cette caractéristique est primordiale, elle vous offre de la flexibilité. Si les discussions et les échanges avec votre audience vous amènent à pivoter légèrement votre projet, la mise à jour du Canvas sera aisé.

Lean canvas template

Conclusion

Si vous êtes arrivés jusqu’ici dans l’article, vous l’aurez compris, la communication entre les différents départements est déterminante pour donner le plus de chance de succès à un projet. La communication avec sa future audience est également clé pour valider l’intérêt que portent vos futurs utilisateurs à votre projet.

Cela vous permettra à la fois, de minimiser les risques d’échecs mais aussi d’offrir le niveau maximum de satisfaction à l’audience ciblée.

La méthodologie “Lean Startup” est une cousine pas très lointaine des méthodes Agiles, elle est hautement compatible avec la souplesse et la dynamique qu’apporte l’agilité à tout projet. Ainsi, mixer les bonnes pratiques de l’une et de l’autre est un très bon moyen de donner le plus de chances de réussite à votre projet.

Ceci étant dit, je vous souhaite à tous, de très bons projets futurs.

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

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

Une lecture aussi enrichissante que distrayante

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

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

Continuer à lire

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

2

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.
1 2 3 8