Auteur : Eric Lannemajou

Quelques petites réflexions autour du WSJF

Eric Lannemajou5 commentaires

L’histoire et la théorie

WSJF ou Weighted Shortest Job First rendu populaire grâce au framework Agile à l’échelle SAFe permet entre autre de prioriser les fonctionnalités à développer et est défini de la manière suivante dans SAFe :

Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs

La formule mathématique pour prioriser les éléments est la suivante :

Regardons maintenant rapidement les composantes du coût du retard qui est la somme de 3 éléments : la valeur utilisateur/métier, le coût lié aux contraintes de temps, le coût évité grâce à l’information (risque et opportunités) apportée par la fonctionnalité. Pour simplifier, on part alors du principe que plus on met de temps à mettre une fonctionnalité sur le marché (ou entre les mains de l’utilisateur final) , plus il devient urgent de livrer celle-ci afin de ne pas bloquer les autres items à développer.

Sans chercher trop longtemps sur le net, vous pouvez trouver ici un excellent article qui explique la provenance de cet outil ainsi qu’une vidéo ci-dessous de Don Reneirtsen son inventeur expliquant le coût du retard.

Le WSJF répond au premier principe Lean Agile de SAFe qui consiste à prendre des décisions se basant sur une vue économique. Vous pouvez utiliser le WSJF pour motiver toutes vos décisions concernant les fonctionnalités à réaliser, du moins c’est ce que dit la théorie. Mais en pratique ?

Les réflexions autour de la mise en pratique

Voici en vrac quelques réflexions et constats sur les ateliers WSJF :

  • La simplification par la suite de Fibonnaci dans le coût du retard
  • La simplification du délai de mise en oeuvre par la charge de développement
  • La fausseté des chiffres
  • Les biais cognitifs
  • La satisfaction client
  • Les fonctionnalités techniques

La simplification par la suite de Fibonnaci dans le coût du retard

Lorsque Don Reinersten a défini le coût du retard, il l’a envisagé avec une vision économique et c’est en toute logique que chacun des éléments du coût du retard s’exprime en devise financière et qu’ils peuvent donc être facilement additionnés puisqu’on effectue une opération sur des nombres ayant la même unité de mesure. On est ici dans une estimation absolue et non dans une estimation relative (on n’estime pas les éléments les uns par rapport aux autres). Donc pas de problème dans la théorie.

Mais en pratique, il est très difficile de pouvoir estimer le coût du retard en espèces sonnantes et trébuchantes. Heureusement qu’un certain framework à l’échelle a pensé à tout et propose de simplifier les valeurs du coût du retard en estimant de manière relative chacune des composantes de ce dernier. On va donc pour chacune des 3 composantes rechercher l’élément le plus petit et estimer les autres de manière relative par rapport au premier en utilisant la suite de Fibonnaci simplifiée (1,2,3,5,8,13,20,40). Voici un exemple avec deux fonctionnalités pour vous expliquer :

Valeur utilisateur/métier :

  • Fonctionnalité A : valeur estimée 1000 € c’est la plus petite de la liste donc elle prendra la valeur de référence 1
  • Fonctionnalité B : valeur estimée 100 000 €, elle est 100 fois plus importante que A donc avec la suite de Fibonnaci simplifiée elle sera probablement à 40.

Valeur du coût lié aux contraintes de temps :

  • Fonctionnalité B : perte de 10 € par semaine où la fonctionnalité est absente. C’est la plus petite et prend la valeur de référence 1.
  • Fonctionnalité A : perte de 1000 € par semaine où la fonctionnalité est absente. C’est 100 fois plus important que la fonctionnalité B donc on attribuera probablement la valeur 40 à cette fonctionnalité.

Valeur liée à l’information apportée par la fonctionnalité : A = B = 1

Coût du retard :

  • Fonctionnalité A : 1 + 40 + 1 = 42
  • Fonctionnalité B : 40 + 1 +1 = 42

On a donc le même coût du retard pour les deux fonctionnalités et si on s’arrête là, on ne peux pas prendre de décision sur cette valeur. Alors que si nous étions resté sur des considérations purement économiques , nous aurions probablement choisi de réaliser la fonctionnalité B avant A. On voit ici que le changement d’échelle entre les composantes amène à additionner des éléments qui n’ont finalement pas la même grandeur car exprimés en relatif. Au passage, les résultats perdent leur unité.

La simplification du délai de mise en oeuvre par la charge de développement

Le dénominateur est normalement le coût de mise en oeuvre de la fonctionnalité souvent simplifié par le coût de réalisation. Si on reste sur une évaluation économique, on a donc un coût du retard exprimé en devise par unité de temps (ex 500 €/semaine) et en dénominateur un coût qui correspond à un délai. Donc en multipliant le temps de réalisation par le coût du retard nous aurions le coût du retard pour le délai de mise en oeuvre. Vous suivez toujours ?

Prenons un exemple :

  • Une fonctionnalité A me fait perdre 1000€ par jour où elle n’est pas mise à disposition des utilisateurs. Si il faut 15j pour la mettre à disposition des utilisateurs alors je perdrai 15 000 euros (1000 * 15). Si au contraire il ne faut que 2j pour la mettre à disposition, je ne perdrai que 2000€.

Donc plus le délai de mise à disposition de la fonctionnalité est petit, moins je perds d’argent.

L’ambiguïté est encore une fois apportée par la simplification : le fait qu’une équipe puisse développer la fonctionnalité en 1 semaine ne signifie pas qu’elle pourra être mise à disposition dans le même délai. J’ai déjà rencontré des équipes programmes qui devaient attendre plusieurs mois pour voir livrée une fonctionnalité de quelques jours parce qu’elles n’avaient pas la main sur la priorisation de l’équipe de réalisation. Et je vous passe le fait que la suite de Fibonnaci simplifiée va encore rendre l’opération encore plus fausse. Vous pouvez trouver d’autres justification ici

La fausseté des chiffres

Nous avons donc des résultats complètement faux et ils sont faux car :

  • Une estimation est fausse de base et donc tous les chiffres fournis sont faux
  • L’opération mathématique est fausse car on ne tient pas compte des ordres de grandeur

Pourtant les chiffres et les mathématiques nous invitent à penser que ces résultats sont d’une exactitude implacable. Un petit peu comme dans les sondages. Un petit biais cognitif ici ? Au passage, j’en profite pour dénoncer le fait que certaines personnes pendant l’atelier savent très bien tirer parti de ces approximations pour infléchir les résultats vers les fonctionnalités qu’ils souhaitent voir développées en premier. Avec ces constats, je rappelle souvent aux participants que les résultats du WSJF ne sont pas une vérité immuable et que ce n’est qu’un outil d’aide à la décision.

Les biais cognitifs

Voici 2 biais cognitifs parmi les nombreux biais qui peuvent se manifester dans une séance de WSJF :

Le biais des coûts irrécupérables : l’exercice a pour vertu de se baser sur une vision économique et de contrer le biais des coûts irrécupérables; le biais des coûts irrécupérables est celui qui nous pousse à continuer à investir dans un élément même si il n’apporte plus de valeur parce que nous avons trop investi dedans :

  • Exemple : vous attendez un bus depuis 10 min et il n’arrive toujours pas, le tableau des horaires indique un retard de 20 min supplémentaires. Vous continuez à attendre à cause des 10 min que vous avez déjà dépensé au lieu de choisir un autre moyen de locomotion qui pourrait vous amener plus vite à votre destination.

En effet, imaginons qu’une fonctionnalité a été développée à moitié à la fin d’un incrément (cf SAFe). Il y a de fortes chances que lorsqu’on va recalculer le WSJF pour cette fonctionnalité, le délai de mise à disposition chute et donc que la fonctionnalité remonte mathématiquement dans la priorisation. Si cette fonctionnalité métier pour une raison ou une autre perd de la valeur utilisateur/métier alors le numérateur baisse et le résultat fera descendre le résultat du calcul.

Le biais de conformité : l’atelier doit permettre à tous les acteurs présents de s’exprimer librement lors du poker planning des items. après un premier tour de vote, on peut voir apparaître un biais qui force les personnes qui n’ont pas vraiment d’avis à se ranger dans le camp de la majorité.

La satisfaction client

Bon, faisons fi du calcul et des biais, vous obtenez une liste d’items ou de fonctionnalités priorisées et vous vous dites donc que vous allez donc prendre les premières et les développer pour le Minimum Marketable Produit (produit minimum répondant au besoin utilisateur). Mais au final, qu’en est-il de la satisfaction client ? Est-ce que les fonctions produisant un effet wahou sont effectivement dans cette liste ? Comme on aurait pu les trouver à l’aide du diagramme de KANO ? Pas certain que la valeur utilisateur du coût du retard ou la valeur liée à l’information ait inclus cet aspect. Qui par la même sera très difficile à chiffrer…

Les fonctionnalités techniques

Autre difficulté rencontrée : que faisons nous lorsqu’un item à prioriser n’apporte pas directement de valeur au client ? Dans le cas de fonctions purement techniques par exemple ? Problème de découpage vous me direz ? Mais parfois des API Back Office doivent être développées et mises à disposition avant que les services consommateurs puissent être disponibles. Dans ce cas, c’est la composante liée à l’information qui porte la valeur du composant. Encore une fois, cette valeur est difficile à estimer… Le WSJF va permettre grâce aux différentes composantes du coût du retard, de redonner du poids à tous les items qui ne sont pas visibles de l’utilisateur (comme les items techniques) mais qui sont néanmoins nécessaires à toutes les autres fonctionnalités.

Le WSJF, cela fonctionne !

Donc au final, nous avons des items difficiles à estimer, des estimations fausses, des opérations fausses…Et pourtant cela fonctionne quand même le WSJF ! Oui cela fonctionne ! Alors comment ? Et Pourquoi ?

Briser les silos et transmettre la stratégie de l’entreprise!

Le WSJF est selon la théorie une instance de décision et sa vertu réside surtout dans le travail préparatoire sur les items et des personnes effectuant ce travail. En effet, nous allons pendant ce travail préparatoire à la recherche des coûts, faire collaborer les personnes du marketing avec les architectes, les développeurs, les sponsors… Ces personnes vont se retrouver ensemble dans des séances de WSJF qui peuvent parfois durer plusieurs heures alors qu’elles n’auraient peut être pas pu avoir cette occasion d’échanger. Le format de l’atelier doit en théorie permettre à chacun de s’exprimer librement… Ces échanges et recherches autour de la valeur sont aussi le moyen de faire passer des informations sur la stratégie de l’entreprise !

Le consensus et l’alignement !

Tout le monde va se retrouver dans un même atelier et choisir de s’aligner autour d’une liste d’items. Que celle-ci soit juste ou fausse, importe moins que l’alignement et le consensus autour de cette dernière. Le consensus est obtenu après plusieurs échanges; charge quand même à l’animateur de faciliter les débats : à la vue des approximations, inutile de débattre plusieurs heures pour trancher entre une valeur de 1 ou 2 même si on passe du simple au double. L’exercice d’alignement fait prendre conscience à tous les acteurs, des enjeux et contraintes de chacun. La DSI prend connaissance des enjeux métiers et contraintes de temps liées au marché et le métier à son tour est informé des contraintes liées à la réalisation des fonctionnalités.

Donc le véritable sens ou but des séances de WSJF seraient moins de prioriser des items que de faire collaborer des personnes entre elles et de les faire commencer à s’aligner sur des objectifs . Du moins c’est mon interprétation de l’exercice !

Encore une suggestion avant de terminer, pourquoi ne pas intégrer dans le coût du retard une composante indiquant le coût carbone de la fonctionnalité ? Je pense que cela pourra bientôt être fort utile. Qu’en pensez-vous ?

Remerciements : Merci à Anne Doublier, Maud Guyot et Yann Tisseyre pour leurs retours et aide sur cet article.

Ressources :

Publicité

Apprendre à découper des user stories en jouant

Eric LannemajouLaisser un commentaire

Découper une user story est un des problèmes souvent remonté par les équipes qui travaillent en SCRUM. Vous pouvez trouver sur internet plusieurs articles qui définissent le format d’une user story et je vous renvoie notamment vers le blog de Oeil de Coach– comment rédiger des user stories comme hulk pour en savoir plus. Le site de SAFe (en anglais) indique aussi ce format ainsi que plusieurs axes pour découper une story selon :

  • les étapes du workflow
  • les règles métier
  • l’effort majeur
  • simple/complexe
  • la variation dans les données
  • les méthodes sur les données
  • les opérations
  • les qualités du système
  • les scénarios, uses cases
  • les études techniques ou spikes

Ces différents axes sont visualisables ici sous la forme d’un poster mais le découpage selon ces critères reste toujours un peu compliqué.

Mike Cohn qui est l’auteur de plusieurs livres sur les user stories, se base quant à lui sur 5 axes qu’il a décrit sur son blog à travers l’acronyme SPIDR :

  • S pour Spike : les études techniques ; si une user story vous paraît compliquée et que vous ne savez pas comment la réaliser, vous pouvez toujours effectuer dans un premier temps une étude technique ou fonctionnelle afin de récupérer des informations qui vous aideront par la suite à évaluer sa complexité.
  • P pour Paths : les chemins ou les différentes façon de faire une activité ; si vous avez par exemple une story qui vous précise que l’utilisateur souhaite acheter un objet avec différents moyens de paiement, vous pouvez préciser dans une première story les étapes du paiement par carte bleue, dans une deuxième les étapes relatives à un autre moyen de paiement comme le virement, dans une troisième…et ainsi de suite.
  • I pour Interfaces : les différents navigateurs web, le hardware…
  • D pour Data : les différents types de données ; si vous avez une story par exemple sur l’affichage du nom et du prénom d’un utilisateur, vous pouvez choisir de la découper pour afficher le nom dans une première story et le nom et le prénom dans une deuxième. Les deux stories sont alors indépendantes et vous pouvez donc choisir celle à implémenter en fonction de la priorité et du budget que vous avez.
  • R pour Rules : les règles métier ; vous pouvez choisir d’implémenter le cas le plus simple et créer des user stories complémentaires pour gérer les règles supplémentaires…

Pour vous aider à découper vos stories, vous pouvez jouer à Elefant Carpaccio crée par Alistair Cockburn, l’un des signataires du Manifeste Agile. Ce jeux nécessite une disponibilité de 1h30 à 2h. Mais si vous avez moins de temps, je vous propose de partir des axes de split de Mike Cohn ci-dessus et d’apprendre à découper les stories en jouant à split my story. Le jeu permet dans un premier temps de se familiariser avec les axes de SPIDR puis dans un second temps de créer vos propres stories découpables. N’hésitez pas à me poser des questions si vous souhaitez avoir davantage d’informations et merci de me donner vos feedbacks afin de continuer à améliorer le jeu 😉

NB : sur conseil de Jérôme Carfantan, je rajoute ce lien vers le jeu Split Poker de SOAT. Merci Jérôme.

Ressources du jeu

splitmystory-cardsTélécharger
splitmystory-cards_axes_with_iconsTélécharger
splitmystory-diplomaTélécharger
splitmystory-rules_v1.1Télécharger

Liens et références :

La rétrospective : amélioration continue et systémique

Eric LannemajouLaisser un commentaire

220px-PDCA_Cycle_FR.svg

La rétrospective est le rituel SCRUM d’amélioration continue des équipes qui se base sur cette représentation communément connue à tort (cf cycle de Shewhart) sous le nom de roue de Deming ou PDCA : Plan, Do, Check, Act (Planifier, Développer/Réaliser, Contrôler/Vérifier et Ajuster/Améliorer en français). J’ai rencontré des équipes qui avaient tendance à négliger ce rituel, le trouvant trop long ou le sacrifiant sur l’hôtel de la productivité lorsque celles-ci n’avaient plus le temps de réaliser les fonctionnalités du produit ou encore lorsque leur performance n’était plus à la hauteur de leur engagement. Plusieurs raisons peuvent expliquer le fait que les équipes ne perçoivent pas la valeur de la rétrospective et parmi celles-ci, nous pouvons énumérer les suivantes:

  • L’équipe n’a pas compris le sens du rituel
  • Les actions issues de la rétrospective sont trop grosses pour être facilement réalisées
  • Les solutions apportées sont perçues comme des pansements
  • Les actions ne sont pas suivies dans le temps
  • (…)

Je pourrais encore continuer cette énumération mais je souhaite surtout porter votre attention sur les deux premières qui sont le sens de ce rituel et la taille des actions.

Le sens de la rétrospective

La rétrospective est donc le rituel SCRUM dédié à l’amélioration continue d’une équipe. Mais pour être plus précis, ce rituel va chercher à modifier la façon dont l’équipe travaille. En changeant sa façon de travailler, l’équipe va donc agir sur le système. Mais pourquoi s’intéresser au système et non aux individus ? 

Une première partie de la réponse pourrait être qu’une équipe est définie par les relations entre les individus. Lorsqu’une personne rejoint une équipe, cela influence les relations entre tous les membres de l’équipe. Il en est de même lorsqu’un membre de l’équipe la quitte. Pour approfondir sur le sujet, vous pouvez lire « Coaching d’équipe » d’Alain Cardon (polarisation, circularité, rôles délégués…) coaching_equipeou encore vous référer au modèle de Tuckman qui explique les différents états d’évolution d’un groupe. On comprend donc qu’il va falloir agir sur les relations entre les personnes en considérant l’équipe comme un tout, comme un système. Modifier la relation entre deux membres de l’équipe aura des répercutions sur les relations de tous les membres de celle-ci.

Deming dans son expérience des « Red Beads » nous donne un deuxième élément de réponse. L’expérience est la suivante :  dans un bac, mélangez 3200 billes blanches qui représentent les résultats attendus avec 800 billes rouges qui modélisent les défauts.  Convoquez plusieurs personnes dont les rôles sont les suivants :

  • Les employés, au nombre de 6,  dont la tâche est, à l’aide d’une planchette de bois percée, de récupérer 50 billes du bac en s’arrangeant pour avoir le moins de billes rouges possible dans l’échantillon.
  • Les inspecteurs, au nombre de 2, dont la tâche est de compter les billes rouges présentes sur la planchette de bois.
  • L’inspecteur général qui motive et contrôle le travaille des troupes
  • Le scribe ou comptable qui enregistre les résultats et effectue le total des essais des employés.
  • Des actionnaires qui investissent dans l’entreprise.

Faîtes leur alors jouer un jeu de rôle avec un processus très précis de récupération des billes dans le bac en effectuant une certaine pression sur les employés. Les meilleurs employés, qui remontent le minimum de billes rouges, sont récompensés et les moins bons sont licenciés.

Deming reproduit dans cette démonstration, ce qui pourrait se passer à l’échelle d’une entreprise. Parmi les nombreux constats et leçons que nous pouvons retirer de cette expérience :

  • Les performances ne dépendent pas des employés mais du rapport du nombre de billes rouges et blanches. En effet, un employé qui avait de bons résultats peut ensuite avoir des résultats moins bons alors qu’il s’y prend exactement de la même manière pour extraire les billes.
  • Rien ne sert d’essayer de jouer sur la motivation des employés ou encore en agissant sur une cause locale en leur indiquant de manière précise comment récupérer les billes. C’est le système qui impose les résultats obtenus.

Mais surtout,  l’expérience ne dépend pas des personnes choisies pour celle-ci. Et c’est là que cela devient intéressant. En effet, pour pouvoir améliorer la façon de travailler, il faut agir sur le système, de façon globale.

Ce point de vue est aussi partagé par Peter Senge dans la « cinquième discipline« . La cinquième discipline de Peter Senge

Dans les enseignements du jeu de la bière, ce dernier nous indique que la structure influence le comportement : « Des personnes différentes placées dans une même structure tendent à produire des résultats similaires… Plus souvent qu’on ne le croit, ce sont les systèmes qui produisent leurs propres crises, et non les forces extérieures ou des erreurs individuelles. » La structure ici, est une structure systémique; c’est en fait la dynamique de relations au sein d’un groupe et qui influence son comportement. Dans un système, l’effet de vos décisions dépasse les limites de votre propre position, votre succès dépend de tous les acteurs du système. Néanmoins, des petites actions locales peuvent permettre de modifier le système de façon globale. La méthode des petits pas est aussi connue par le concept japonais KAIZEN est la fusion de 2 mots KAI et ZEN qui signifient « changement » et « meilleur ».

Mais pourquoi faire des petits pas et non pas de grands changements ?

  • Parce qu’on se sent moins impuissant à réaliser de petites actions : Face à de petites actions, on se sent moins impuissant et le sentiment d’angoisse lié à l’échec est moindre. On évite les réactions du genre : « C’est trop dur, je n’y arriverai jamais »
  • Parce que ceci génère une satisfaction rapide : il est plus facile de réaliser de petites actions que des actions longues et compliquées. Le résultat associé aux petites actions se voit souvent assez rapidement. Ceci renforce la maîtrise et génère de la satisfaction.
  • Parce qu’on apprend plus vite : les petites actions sont moins coûteuses à mettre en place, le risque associé est donc moindre. Si vous vous trompez sur une action sur laquelle vous avez dépensé peu d’énergie, vous serez davantage disposé à revenir en arrière pour pivoter. Un exemple à l’échelle d’un produit est le MVP (Minimum Viable Product)
  • Parce que les petites actions génèrent moins d’opposition : C’est l’histoire de la grenouille qu’on ébouillante selon Peter Senge : Si on plonge une grenouille dans une marmite d’eau et qu’on augmente petit à petit la température de l’eau, celle-ci s’ébouillantera en restant dans l’eau. A contrario, si vous la plongez dans une marmite bouillante, celle-ci fera tout ce qu’elle peut pour en sortir. En systémique, les petites actions déclencheront à priori des boucles de rétroactions  de type régulateur moins importantes que les grosses. En simplifiant l’explication de ces effets régulateurs, on peut définir ceux-ci comme des actions engendrées par le système et visant à rétablir l’équilibre ; c’est à dire que ces actions auront des effets inverses à celles que vous avez engagées.
  • Parce que les petites actions peuvent faire boule de neige : toujours en systémique, les petites actions peuvent produire un effet d’amplification. Le rapport entre l’énergie dépensée et le résultat sera encore plus important et ceci augmentera encore davantage la satisfaction.

Les boucles de rétroactions de type régulateur (actions contraires) ou amplificateur (boule de neige) peuvent souvent être accompagnées d’un effet retard ; c’est à dire que les effets de celles-ci ne sont visibles qu’après un certain délai. Lorsque vous réalisez des actions de rétrospective, il est parfois bon d’attendre un peu ou de répéter l’action suffisamment avant de tirer des conclusions trop hâtives et de pivoter.

Le Scrum master et les équipes doivent garder en tête que la rétrospective est leur chance de rester acteurs du changement et de faire évoluer le système de manière globale. Ceci est rendu possible grâce à de petites actions et aux mécanismes systémiques de régulation et d’amplification.

Liens et références :

Agile Playground #44

Eric Lannemajou1 commentaire

Xebia hébergeait mardi soir le 44 ème Agile Playground, dernier rendez-vous avant la pause estivale. Toujours pas mal de choix et de bonne humeur au rendez-vous. Après le traditionnel accueil de Regis Schneider concernant la motivation et IMG_1151[2]les clés du Meetup, nous avons commencé par un ice breaker : les triangles isocèles. Pour cet ice breaker, chaque personne doit noter son nom sur deux post-it et tous les post-it sont pliés et rassemblés ensemble de façon à ce que les noms soient cachés. Chacun pioche alors deux post-it et doit former un triangle isocèle avec les deux personnes piochées au hasard. Afin de pouvoir reconnaître les personnes ayant inscrit leur nom sur les post-it, nous avons formé un cercle ou chacun a énoncé son nom à voix haute. Ce jeu rappelle un peu  » Movers and Shapers  » que Olivier My nous avait fait jouer lors d’un précédent rendez-vous, qui explore les dynamiques de groupe et qui permet aussi de sensibiliser aux principes de systémique. Les triangles isocèles permettent, à la différence de cet ice breaker,  de retenir deux prénoms de l’assemblée.

Pour le plat de résistance, nous avions le choix entre un atelier sur la spirale dynamique et un atelier utilisant des « Liberating Structures ». J’ai pour ma part choisi de participer au premier et j’ai appris que nos comportements sont influencés par le milieu culturel dans lequel nous vivons et que nous réagissons selon des niveaux d’existence. Nous naviguons parmi ces derniers et passons de l’un à l’autre lorsque nous atteignons  les limites de ceux-ci. (voir ci-dessous)

Pour le jeu, nous avons, en équipe, associé des cartes de croyance, de valeurs, la peur de base, des traits de fonctionnement sociaux, des apports sociaux, des structures sociales… aux niveaux, selon la perception du monde et la quête des personnes de ces derniers. Voici les corrigés ci-dessous :

 

IMG_1156[1]

Les animateurs Georges Rizk et Patrick Manoukian nous ont ensuite montré comment les principes du Manifeste Agile pouvaient correspondre à ces différents niveaux. Ceci m’a alors rappelé la conférence d’Andrea Provoglio (ici) sur les différents styles de leadership que j’avais pu suivre lors d’un événement chez VISEO au mois de mai dernier.

Nous avons alors essayé un « 1, 2, ping, 4, pong » et j’ai terminé la soirée en jouant à un jeu de carte sur les projets Agiles, « Scrumind » qui se base sur les principes du « mille bornes », mais en collaboratif. J’ai aimé la possibilité qu’offre le jeu de pouvoir utiliser des anecdotes et problèmes concrets de la vie professionnelle pour bloquer les membres du  projet et les empêcher de délivrer de la valeur.

Encore une belle soirée pleine d’information, de collaboration et de bonne humeur. Encore merci aux animateurs et à tous les participants !

 

Liens et Références

Réduire la dette émotionnelle à Agile France avec Marilyn Kol

Eric LannemajouLaisser un commentaire

IMG_1056

J’étais à Agile France jeudi et vendredi dernier et c’est dans une salle de 25 personnes mais avec à peu près du triple de participants que Marilyn Kol nous a raconté comment gérer la dette émotionnelle d’une équipe Scrum. Selon Marilyn, chaque équipe, en plus de sa dette technique bien connue des développeurs et des Scrum Masters, devrait porter attention à une dette émotionnelle. Si on n’y prend garde, celle-ci pourrait s’amplifier au cours du temps et prendre des proportions ingérables. Cette dette qui tire son origine des conflits (opposition d’idées ou d’opinion réelle ou perçue comme telle entre deux groupes ou deux personnes) et irritants entre les membres d’une équipe, peut déraper jusqu’à atteindre le niveau 5 irrémédiable de « la guerre mondiale » où tous les membres de l’équipe sont en guerre. Mais il existe des solutions pour empêcher que le climat à l’intérieur d’une équipe ne se dégrade à ce point et Marilyn, forte de son expérience professionnelle, nous a prodigué quelques conseils.

Parmi ceux-ci, le premier est de reconnaître et d’assumer les problèmes. Ceux-ci peuvent, dans un premier temps, s’exprimer à travers le langage corporel des différents protagonistes lors des rituels Scrum et notamment lors du daily scrum. Vous pouvez identifier les signaux non verbaux à condition que vous soyez à minima empathique; que vous puissiez lire et détecter les émotions des personnes sans que celles-ci n’affecte les vôtres. Une fois le problème rendu visible vous pourrez essayer de résoudre collectivement celui-ci.

Afin de mieux cerner le problème, et dans le cas où celui-ci relève d’après vos hypothèses d’un malentendu ou de difficultés de communication, vous pouvez utiliser ou proposer l’écoute active; celle-ci consiste à écouter l’autre pour le comprendre et non pour essayer de lui répondre. Ensuite, vous pourrez reformuler afin de vous assurer de la problématique ou encore questionner les antagonistes avec la technique des 5 pourquoi afin de trouver les causes racines. Si vous pensez que vous avez plutôt à faire à une divergence d’opinion, de point de vue ou si le problème concerne des émotions, voici ci-dessous quelques outils qui vous seront fort utiles.

Afin de désamorcer un conflit, vous pouvez inviter les membres de votre équipe (si vous êtes Scrum Master) à se servir de la communication non violente (CNV).  Celle-ci détaille un protocole de communication en 4 étapes :

2018-06-15 22_43_41-Amazon.fr - Les mots sont des fenêtres (ou bien ce sont des murs) - Marshall B.

  • O pour observation, on relate les faits
  • S pour exprimer ses sentiments vis-à-vis de ces faits
  • B pour exprimer ses besoins
  • D pour formuler une demande

Vous pourrez retrouver plusieurs mises en situation dans le livre de Marshall Rosenberg; les mots sont des fenêtres (ou bien ce sont des murs).   Selon Marilyn, les personnes ont souvent du mal à utiliser ce protocole au début. Aussi n’hésitez pas à insister, parfois lourdement, en montrant l’exemple dès que possible (« lead by example »…). Afin de rendre votre intervention encore plus efficace, vous pouvez remplacer les questions en « pourquoi » par des questions en « en quoi ». Par exemple, au lieu de demander : « Pourquoi es-tu en retard au daily Scrum ? », vous pourriez reformuler par « En quoi est-ce difficile pour toi de venir à l’heure au daily Scrum ? ». Enfin, si vous sentez que quelqu’un est en retrait ou fait la moue à la sortie d’une réunion, vous pouvez, par exemple, utiliser quelques soupçons de psychologie positive : « C’est cool, la réunion a bien remotivé l’équipe! »

Dernier chapitre de la présentation. Marilyn nous a partagé quelques outils afin d’améliorer la communication d’une équipe et permettre à ses membres de mieux se comprendre :

  • L’atelier sur les valeurs : chaque personne va définir individuellement ses valeurs, partager aux autres leur signification ainsi que leur réaction si cette valeur était trahie. Puis, les valeurs communes vont être regroupées afin de former celles de l’équipe.

J’ai facilité un atelier de team building il n’y a pas très longtemps où j’ai fait construire à l’équipe un poster avec les valeurs. Je trouve intéressant dans l’atelier ci-dessus, que chacun exprime le sens qu’il donne aux mots et partage les limites qu’il ne souhaite pas voir dépassées. Marilyn nous indique que cet atelier peut être donné lors de la construction de l’équipe ou lors de l’arrivée d’un nouveau membre.  Selon elle, cet événement génère une nouvelle équipe.

Vous pouvez retrouver les différents stades de formation d’une équipe dans le modèle de Tuckman (article que je vous ai récemment partagé sur LinkedIn).

  • L’atelier sur les moving motivators issus du Management 3.0 et qui permettent d’identifier les facteurs intrinsèques de motivation; c’est-à-dire ceux qui apportent du plaisir par eux même.
  • La rétrospective Lego ou chaque personne doit construire sa manière de travailler privilégiée; seul ou en équipe ? Introverti ou extraverti ? Attention, un introverti n’est pas quelqu’un qui n’aime pas les gens mais qui puise son énergie lorsqu’il est seul.
  • Le MBTI qui permet de définir les personnalités selon 4 axes :
    • comment te ressources-tu ?
    • comment prends-tu tes décisions ?
    • comment recueilles-tu les infos ?
    • comment gères-tu le monde extérieur ?
  • IMG_1068[1]La rétrospective Empathy Map 
  • La rétrospective « Turn the table » afin de démontrer aux différents membres d’une équipe qu’ils se connaissent mieux qu’ils ne le pensent et qu’ils sont plus empathiques qu’ils ne le croient.

Pour les 5 dernières minutes, Marilyn a rapidement abordé les schéma ci-contre pour nous expliquer qu’il faut souvent creuser plus profondément que les comportements pour comprendre une situation.

La qualité de la mise en forme, le storytelling et l’énergie de Marilyn nous a tenu en haleine pendant toute la session.  L’ovation finale de la salle était amplement méritée.

 

 

Liens et Références

Qu’est-ce qu’un Scrum Master ? (Agile en Seine 2017)

Eric LannemajouLaisser un commentaire

Voici un retour un peu tardif sur les conférences de Agile en Seine du 20 septembre 2017 et notamment sur la présentation de Romain Couturier sur « Qu’est-ce qu’un Scrum Master ?« . J’ai réalisé un petit dessin qui centralise ce que j’ai retenu et je l’ai publié sur linkedIn dans un POST. Mais comme il est parfois difficile de retrouver les informations dans le flux dense du réseau social, je republie ce dernier ci-dessous 😉

20170920-scrummaster

Je vous propose aussi de pouvoir approfondir le sujet avec l’article de Jean Claude GrosJean, « Le ScrumMaster n’est pas un Coach Agile« 

 

L’estimation et la planification agile

Eric Lannemajou1 commentaire

L’une des valeurs du manifeste Agile est de favoriser l’adaptation par rapport à un plan établi. Cette valeur est parfois mal interprétée et ne signifie pas qu’il ne faut pas planifier. Mike Cohn nous explique dans Agile Estimating and Planning les raisons pour lesquelles il est nécessaire pour une équipe Agile de planifier.51I7-xMCQDL._SX408_BO1,204,203,200_

Dans mon expérience, j’ai rencontré plusieurs équipes qui se demandaient comment il fallait planifier et surtout comment estimer les stories. Faut-il estimer en point, en jours idéaux, avec la suite de Fibonnaci ? L’estimation du travail est souvent source de tension ou de conflit entre l’équipe de développement et les commanditaires du projet ou encore avec le Product Owner. Mais avant de se poser la question du « comment? », j’invite les équipes à revenir sur le « pourquoi? ». Pourquoi estimer ? A quoi et à qui cela sert ?

Mike Cohn nous explique ces raisons dans Agile Estimating and Planning. Un plan doit permettre de :

  • guider les décisions des investissements à réaliser.
  • savoir si un projet est sur le point de livrer des fonctionnalités que les utilisateurs attendent.
  • connaître le nombre de ressources disponibles pour travailler sur ce projet pendant une période définie.

Planifier est souvent difficile et les équipes peuvent tomber dans les deux extrêmes de ne pas planifier du tout ou de trop planifier. Planifier est une activité difficile et le cône d’incertitude ci-dessous nous démontre combien il est difficile d’estimer le projet dans les premières phases de ce dernier. A la définition du projet, l’incertitude est de 60% et il faut attendre le design détaillé pour réduire cette incertitude à 10%. Ce qui explique donc que plus de 2/3 des projets dépassent le coût estimé initialement.

coneOfUncertainty

Mais alors si cela est si difficile de planifier un projet, pourquoi effectuer cette activité ? Et bien tout d’abord pour :

  • réduire le risque : les discussions qui servent à estimer le projet permettent de mettre en lumière les potentiels risques du projet.
  • réduire l’incertitude : un des risques les plus importants d’un projet n’est pas de ne pas sortir dans les temps mais bien de développer des fonctionnalités qui ne répondent pas aux besoins des utilisateurs. Ce risque peut être atténué via une planification agile continue qui permet de récupérer les retours utilisateurs au fur et à mesure du projet.
  • aider à prendre de meilleures décisions : l’estimation du coût d’un projet et de sa valeur métier nous permet de décider si le projet doit être lancé.
  • établir la confiance :  les fréquentes livraisons de fonctionnalités permettent d’établir la confiance entre le client et les développeurs. Les estimations deviennent de plus en plus fiables au cours des itérations et permettent de prioriser les fonctionnalités en se basant sur l’estimation fiable de l’équipe de développement.
  • transmettre de l’information : un plan ne garantit pas la livraison d’un périmètre à une date précise mais permet néanmoins de fixer un niveau d’attente et l’approche pour arriver à satisfaire cette attente.

Maintenant que nous savons à quoi sert la planification et l’estimation agile, nous pouvons insister sur le « comment ». Certaines équipes estiment leurs stories en point de complexité/d’effort alors que d’autres les estiment en jours idéaux. Les jours idéaux sont des jours où chaque membre de l’équipe consacrerait 100% de son temps de travail dans la journée à la story sans être dérangé par d’autres activités professionnelles.

Les partisans du chiffrage en points mettent en avant que ce type de chiffrage :

  • permet aux équipe multi-fonctionnelles de pouvoir avoir une mesure commune.
  • est constant dans le temps, ne dépend pas du niveau de capacité ou de compétence de la personne qui va réaliser la story.
  • est une pure mesure de taille et ceci permet donc de pouvoir chiffrer par analogie, de manière relative. De plus, comme cette mesure est complétement abstraite, les équipes ne devraient pas être tentées de comparer cette estimation avec du temps passé.
  • est plus rapide grâce notamment à la possibilité de comparer de manière relative par analogie avec des stories de référence.

Enfin, les jours idéaux varient d’une personne à une autre. Cependant,  il est plus facile d’expliquer un chiffrage en jours idéaux aux personnes extérieures à l’équipe et pour une équipe qui débute, ce mode de chiffrage est plus facile à appréhender.

L’action de planification pour une équipe agile s’effectue à plusieurs horizons et plusieurs niveaux d’abstraction. L’action de planifier revient à se fixer des objectifs sur une période donnée et à les réviser tout en décalant des objectifs plus long terme. Pour une équipe qui travaille en SCRUM, l’équipe va fixer un objectif de release avant le premier sprint et réviser ce dernier au fur et à mesure des sprints. En effet, la release va être initialement estimée et planifiée puis revue à la fin de chaque itération pour évaluer comment le périmètre associé à la date évolue. L’action ici sur le périmètre du sprint a une influence sur le périmètre de la release. On parle ici de planification en couches successives ou en oignon.

Le dernier point détaillé par Mike Cohn que je souhaiterais partager est celui du niveau de détail de l’estimation et de la planification. A quel moment et niveau de détail faut-il arrêter de planifier ? Cette question peut aussi se poser dans un projet en cycle en V et j’ai déjà par le passé fait l’amère expérience de trop planifier un projet. Ce problème se présente par le fait de planifier de toutes petites tâches et donc de planifier tout le temps. Planifier devient alors l’activité principale et l’information portée par ce niveau de détail n’apporte pas assez de plus-value au projet. Mike Cohn nous explique ce travers avec le petit exemple suivant : « si vous vous demandez combien de cookies j’ai mangés l’an dernier, vous avez plusieurs options pour répondre à cette question :

  • Estimer le nombre de cookies au hasard
  • Demander à mes proches, mes amis, ma famille
  • me suivre pendant une journée, compter combien je mange de cookies et extrapoler sur un an.

Cependant, si votre but est de savoir si vous pouvez m’offrir ou non, une boîte de cookies, alors vous n’avez pas besoin d’avoir une mesure ultra précise et il n’est donc pas nécessaire d’effectuer trop de recherches. Dans ce cas précis, la première solution pourra convenir. Quand on planifie, il faut donc toujours se demander dans quel but afin d’évaluer le niveau d’effort et de détail que nécessite cette planification.

Je vais vous décrire une situation que j’ai déjà rencontrée et qui peut s’avérer être un parfait exemple d’une planification peu « agile ». Lors d’un projet avec un centre de service, j’ai travaillé avec une équipe qui chiffrait les stories en points en utilisant la suite de Fibonnaci. L’équipe n’était pas dédiée et le nombre de point d’une story, convertie par un coefficient donnait directement le nombre de jours et donc le coût de la story. L’équipe allouait un nombre/capacité de points différent à chaque itération qui représentait donc directement le nombre de jours pendant lesquels l’équipe allait travailler sur le produit. Cette situation peut aboutir à plusieurs effets pervers :

  • Comme l’équipe estime une capacité ou un coût de story fixe et que celui-ci représente le nombre de jours de travail sur la fonctionnalité, il n’est plus possible de lisser entre les stories d’un même sprint.
  • Comme l’équipe estime avec la suite de Fibonnaci et que les stories sont directement converties en jours/homme, une story légèrement supérieure à 8 passe à 13, ce qui n’est pas du tout le même coût : le commanditaire se sent lésé.
  • Comme les développeurs estiment chaque story et prennent un engagement sur chacune d’elles, ceux-ci ont tendance à se protéger et réhausser leur chiffrage.
  • Comme l’équipe n’est pas dédiée et que la capacité change à chaque itération, on perd la possibilité d’apprendre au cours des sprints.
  • Le fait de ne pas estimer de release et de changer la capacité à chaque itération supprime toute possibilité de planification.

Cette situation aboutit donc à une forte tension entre le commanditaire et l’équipe de développement. Sans compter que ceci rajoute aussi de la pression sur les développeurs qui doivent prendre un engagement à la story. Ce pattern qui favorise un rapport contractuel et impose une facturation à la story est selon moi anti-agile.

Liens et Références :

La découverte des utilisateurs à Agile France

Eric LannemajouLaisser un commentaire

Juste quelques mots pour revenir sur mes deux jours à Agile France et partager sur les ateliers et présentations auxquels j’ai assisté. Comme d’habitude les conférences proposées sont toutes très attractives et une des difficultés est de choisir. Cette année, j’ai orienté ma préférence sur les ateliers sous forme de jeux et ceux qui traitent du besoin utilisateur. Je vais donc aborder ci-dessous l’atelier-jeu sur « À la découverte de vos clients » animé par Pascal POUSSARD et Grégoire QUENTIN et la présentation « Design Sprint, 18 mois + tard : joies, détresses, bonnes pratiques«  par Paul DEPRE.

Commençons par « À la découverte de vos clients« . Le décor est posé! Dans une équipe de 5 personnes, nous devons réaliser un logiciel sur smartphone à la suite d’un e-mail envoyé par un manager et qui s’est récemment mis au tir à l’arc. Cette application sera « la bible de l’archer ». Le jeu va se dérouler sous la forme de plusieurs itérations ou sprints au cours desquels l’équipe va devoir choisir les éléments à développer en déposant les cartes fonctionnalités sur une feuille A3 modélisant un écran d’application mobile (écran unique pour faciliter l’atelier). A la fin de chaque sprint, les animateurs calculent un nombre d’utilisateurs connectés selon la pertinence de l’application développée par rapport au besoin. Le but premier du jeu, est d’avoir à la fin du sprint le maximum d’utilisateurs connectés ou du moins, plus d’utilisateurs que les 4 autres équipes qui participent au challenge.

Voilà donc le début du premier sprint et chaque équipe reçoit :arrow-37061_1280

  • La copie papier d’un e-mail de la commanditaire du produit.
  • Des fonctionnalités sous forme de cartes recto/verso ayant chacune un coût associé en point de capacité (d’autres fonctionnalités seront distribuées dans les sprints suivants)
  • Une carte fonctionnalité libre pour nous laisser exprimer notre créativité.
  • Un nombre de jetons représentant la capacité de l’équipe de développement à réaliser les fonctionnalités. Cette capacité distribuée à chaque sprint pourra augmenter simulant ainsi la montée en compétence de l’équipe.
  • Une feuille A3 représentant l’écran d’un smartphone sur lequel les équipes vont pouvoir déposer les fonctionnalités à chaque sprint.

Quelques minutes plus tard, l’équipe fait valider son application par l’animateur qui lui indique le nombre d’utilisateurs connectés. Nous avons obtenu 23 utilisateurs pour le premier sprint. On est loin des 1000 utilisateurs possibles de la feuille. Faisons encore quelques sprints pour voir si nous ne pouvons pas nous rapprocher du besoin des utilisateurs et augmenter ainsi le nombre de connectés!

Au fil des itérations, les animateurs dévoilent différentes techniques d’étude du besoin en se basant sur la théorie aussi bien que sur leur expérience. Au premier sprint, Pascal POUSSARD nous explique le concept de « pitch vision » en prenant l’exemple de Ridley Scott qui aurait pitché « Alien » comme étant « Les Dents de la mer dans l’espace »…Nous allons aborder lors des différents sprints, les Personas, l’étude marketing, les interviews utilisateurs, l’AB-testing… jusqu’au concept de pivot comme surprise finale. L’application à développer ne ciblera finalement pas les archers mais devra permettre des rencontres amicales.

Après deux heures bien rythmées et pas mal de bonne humeur,  ce jeu m’a permis de revoir plusieurs techniques d’étude du besoin utilisateur et nous prouve encore une fois l’importance de bien connaître les utilisateurs avant de se lancer dans la réalisation. L’application simulée sur feuille A3 peut être considérée comme un MVP, nous permettant de tester la motivation des utilisateurs, comme nous aurions pu le faire lors d’un design sprint…

La transition est toute trouvée pour aborder la présentation de Paul DEPRE sur le2017_07_03_22_58_08_Amazon.fr_Sprint_How_to_Solve_Big_Problems_and_Test_New_Ideas_in_Just_Five_Da design sprint. Après 18 mois de pratiques du design sprint et plus de 30 sprints pour plusieurs sociétés, Paul  nous partage ses recettes et ses déboires en repartant d’abord de la définition théorique et du livre de Jake Knapp « Sprint : how to solve big problems and test new ideas in just five days ». Un Design Sprint, c’est donc :

  • un problème ou une idée à tester/valider
  • une équipe de 8 personnes maximum
  • 5 jours d’ateliers

Premier conseil capital, ne jamais oublier le décideur ou un de ses représentants dans l’équipe qui réunira aussi un designer et un sprint master; personne qui va faciliter le sprint.

Parmi les retours positifs ou les joies, Paul nous indique apprécier la vitesse d’exécution ou le rythme imposé par la méthode, même si le Sprint ne dure pas 5 jours mais plutôt 2 semaines. Le fait d’arriver à un prototype à la fin du Sprint et de pouvoir le faire tester est aussi un facteur de satisfaction. Enfin le format invite les personnes à sortir de leur quotidien dans la bonne humeur, apporte des bénéfices indirects en créant des interactions et des liens entre les personnes dans un terreau propice aux échanges…

Parmi les détresses ou les difficultés rencontrées, le premier est de mal définir le challenge ou le problème auquel le sprint doit répondre, d’avoir envisagé un périmètre trop vaste et donc de ne pas pouvoir fournir un prototype concluant à la fin du sprint. Pour éviter ce problème, Paul nous conseille de faire précéder le sprint par une phase de préparation en amont. De même, afin de faire adhérer rapidement les participants à la méthode pour commencer les ateliers du premier jour sans perdre de temps, il sera astucieux de préparer celles-ci avant le sprint. Le fait d’obtenir peu de retours des personnes qui testent le prototype ou d’avoir un prototype qui ne répond pas à la problématique, sont autant des facteurs qui peuvent entraver le succès de la démarche…

Il n’existe pas de recette miracle pour éviter ces problèmes mais quelques bonnes pratiques et comportements permettent néanmoins de les anticiper ou de diminuer leurs effets. Soyez pédagogue, expliquez la méthode et le déroulement du Sprint avant la première journée; vous gagnerez ainsi un peu de temps pendant le sprint. Soyez agile avec la méthode en adaptant celle-ci au contexte, en choisissant vos ateliers et en préparant une phase amont de design thinking. Formez-vous et devenez un maître dans l’art des tests utilisateurs… Recrutez ces derniers le plus tôt possible, dès la première journée.  Préparez un guide pour les tests mais laissez une certaine latitude aux testeurs. Vous pouvez par exemple, les laisser parler en laissant des blancs dans les interviews. Autre conseil, débriefez à chaud afin de ne rien oublier et consignez les résultats des tests dans un tableau de management visuel.  Enfin, accompagnez les utilisateurs en fin de sprint, ne les laissez pas sans nouvelle une fois les tests terminés. Vous pouvez même effectuer des recommandations pour terminer…

Si vous souhaitez en savoir davantage, vous pouvez participer à cette présentation à Agile en Seine le 20 septembre prochain, regarder cette vidéo de MIXIT 2017 : « Comment sauver la princesse… et si le Design Sprint m’était conté ? » ou encore lire cet article de blog de Paul DEPRE qui détaille son expérience sur le design sprint.

Liens et Références :

Et si on supprimait l’entretien annuel ? Solution et mise en place

Eric LannemajouLaisser un commentaire

J’ai décrit dans l’article précédent quel était le problème de l’entretien annuel et pourquoi celui-ci ne motivait les employés qu’à court ou moyen terme. Je vais dans cet article vous présenter la solution (la présentation ici) que j’ai proposée pour le concours et qui reprend quelques principes du management 3.0. Celle-ci s’articule selon les 3 axes suivants; la bienveillance, l’apprentissage et l’innovation. Mais pour que cette dernière puisse s’appliquer avec succès, il est nécessaire qu’elle soit alignée avec les valeurs de l’entreprise, les ressources humaines, le management et il est indispensable de donner du sens à sa mise en place. Pour être efficace sur le long terme, la solution doit satisfaire les motivations intrinsèques des employés ou les ancres motivationnelles telles que décrites dans la théorie des facteurs clés de la motivation. Voici donc les 3 piliers de la solution :

La bienveillance

« Le plaisir attaché à la bienveillance ne peut devenir l’objet d’un calcul égoïste, ce plaisir n’est attaché qu’à l’affection désintéressée. » Victor Cousin ; La philosophie écossaise (1862)

En se basant sur le management 3.0, j’ai proposé de mettre une cagnotte virtuelle à disposition des employés, que chacun d’eux peut distribuer à des collègues afin de les remercier pour un acte ou une action. Les personnes peuvent ainsi collecter des points de bienveillance et celle qui arrive en tête du classement à la fin d’une période donnée, a la possibilité de tirer au dé le fait de pouvoir échanger ses points contre une somme d’argent définie à l’avance ou un ensemble de services. Lors de la période en question, le classement est affiché sur un écran (exemple de disposition ci-contre) afin de rendre publique les remerciements attribués à chacun. 2017-02-22-00_05_46-bienveillanceCet outil permet donc de satisfaire le désir de reconnaissance, le désir d’appartenance, le fait de travailler avec des collègues bienveillants et l’engagement sociétal et humain basé sur le bien-être des autres. Comme expliqué dans l’article Gamification 3.0, le caractère aléatoire de la récompense permet de limiter l’accoutumance et son montant doit aussi être fixé afin d’éviter que la motivation pour celle-ci ne vienne se substituer à la motivation pour les tâches à effectuer. Ces paramètres sont à définir lors de la mise en place de la solution par la population concernée. Pour imager l’utilisation de cet outil, prenons l’exemple d’un employé qui effectue des heures supplémentaires pour terminer son travail ou pour aider un collègue. Celui-ci pourra recevoir des points de son manager direct ou de ses collègues pour son effort ou pour l’aide apportée. Il n’y a pas de hiérarchie dans ce système et tout le monde est traité également.

Pour ceux qui penseraient que la solution instrumentalise la bienveillance, je réponds qu’un compliment et un remerciement ont toujours un effet bénéfique lorsqu’ils sont sincères.

L’apprentissage

« I never lose, I either win or learn » , Nelson Mandela

Toujours selon le management 3.0 et toujours basé sur une cagnotte virtuelle. Chaque employé va pouvoir attribuer des points à différents événements pour qualifier le niveau d’apprentissage lié à l’événement. Cet événement peut être de différentes nature :2017-02-22-00_07_53-apprentissage

  • un échange informel avec un collègue
  • une présentation
  • une formation
  • un échec
  • chaque occasion qui permet d’apprendre…

Les points distribués aux événements vont s’accumuler sur la période de référence et être mesurés à l’aide d’une jauge. Lorsque le nombre de points dépasse un certain niveau fixé à l’avance, alors ceci débloque une récompense collective afin de célébrer le fait d’avoir appris. La récompense peut être par exemple une soirée sponsorisée par l’entreprise. Cet apprentissage et cette connaissance permet aux collaborateurs de se développer et de progresser dans son travail. Les points attribués à un événement sont affichés publiquement via un écran et donc contrôlés par tous. Ceci permet d’éviter les attributions abusives.

L’Innovation

« Toute personne qui n’a jamais commis d’erreurs n’a jamais tenté d’innover. » Albert Einstein

Pas de cagnotte virtuelle ici mais la possibilité de proposer des projets à la société qui seront étudiés par un groupe de personnes tirées au 2017-02-22-00_10_14-innovationsort parmi les employés. Ceux-ci ont la charge de déterminer la viabilité du projet et la responsabilité de remonter ce dernier à des instances dirigeantes afin d’allouer des fonds et des ressources pour la réalisation de ces derniers. Plusieurs sociétés ont déjà mis en place différentes techniques pour provoquer et soutenir l’innovation; chez Google, du temps est alloué pour l’innovation et plusieurs entreprises favorisent aussi l’intraprenariat. Je n’ai pas défini de solution spécifique ici et laisse la liberté aux employés de choisir une solution au cas par cas. Si plusieurs projets sont susceptibles d’être financés, alors le sponsor ou les équipes dirigeantes peuvent trancher et prioriser les projets. Cet outil permet aux employés de satisfaire leur besoin de challenge et d’innovation.

Et la progression des salariés ?

Ces trois axes permettent de renforcer le sentiment d’appartenance et l’autonomie des collaborateurs mais ne remplacent pas le management ou les ressources humaines. On peut même se demander comment ces trois axes si ils motivent les employés leur permettent de progresser. En fait le système garde une trace  (informatique) factuelle de la progression et des actions du salarié dans l’entreprise. Celui-ci peut effectuer une demande d’augmentation et les ressources humaines peuvent se fier à ces faits pour décider ou non de récompenser le salarié. Ces informations sont une aide à la décision comme l’est l’entretien annuel mais il ne remplace pas une intervention humaine. Les collaborateurs ne sont plus jugés sur leurs résultats mais sur leur comportement qui va à moyen terme générer des effets positifs sur l’entreprise.

La solution ne permet pas de déterminer des objectifs pour les collaborateurs car chacun est responsable de se fixer ses propres objectifs et moyens de progression. Cette décision appartient à chaque employé et chacun d’eux peut se montrer force de proposition concernant son plan de carrière.

La mise en place de la solution

Enfin pour terminer, la mise en place et la gestion de la solution fait partie intégrante de la solution. Celle ci représente un projet ou l’aventure qui va permettre de fédérer les employés ou les collaborateurs d’une entité afin de construire une solution qui leur ressemble et à laquelle ils adhéreront.

Voici les grandes lignes de la mise en place du système :

  1. Mettre en place un écosystème bienveillant et donner du sens.
  2. Trouver un sponsor pour soutenir la mise en place de la solution et un groupe de personnes motivées pour la porter.
  3. Déployer la solution petit à petit en validant les hypothèses avec des MVPs (cf MVP et Design Sprints).
  4. Faire évoluer la solution au fur et à mesure afin de la garder toujours alignée avec les motivations des employés.
  5. Suivre la motivation et l’engagement des employés avec des indicateurs.

Comme déjà évoqué, le système n’a pas pour but de remplacer les ressources humaines ou les managers. La solution indique juste des directions et décrit des outils pour motiver les employés. Afin que sa mise en place se traduise par un succès, il est nécessaire que les valeurs de l’entreprise soient clairement définies et se retrouvent alignées avec les 3 axes précédemment décrits. Il faut ensuite clairement expliquer la démarche dans laquelle s’inscrit cette substitution de l’entretien annuel afin de pouvoir trouver un sponsor qui la portera au sein de l’entreprise ou qui permettra du moins de l’expérimenter sur un groupe de personnes restreint.

La seconde étape consiste à trouver des personnes motivées pour s’occuper de mettre en place, de lancer le système. Ce premier groupe de personnes pourra par exemple, réfléchir à la définition du système : les nombres de points, la durée d’une période de référence, les indicateurs, les seuils… expliquer et communiquer autour de la solution… Il est toujours plus facile de trouver des personnes motivées que d’essayer de convaincre des collaborateurs qui ne croient pas dans la solution à cause de la courbe du changement qui demande beaucoup de temps et d’énergie. De même, afin de s’assurer que le système sera adopté par les futures employés, il peut être mentionné lors des entretiens d’embauche afin d’évacuer toute ambiguïté.

le système peut être mis en place simplement et de manière progressive, sur le périmètre et sur les groupes d’employés concernés :

  • La solution peut comporter peu de fonctionnalités pour commencer et être déployée en utilisant des fichiers partagés entre plusieurs employés. Puis celle-ci pourra évoluer et s’enrichir grâce à divers ateliers et MVP qui testeront les hypothèses effectuées sur la motivation et l’engagement des employés. Avant de construire un système ou une application informatique qui permette de garder une trace objective des différentes actions, le système pourra par exemple être mis en place avec des fichiers partagés (ex Google doc).
  • Il n’est pas obligatoire de déployer les 3 outils de manière simultanée. la solution concernant la bienveillance peut par exemple être utilisée tout en gardant l’entretien annuel dans un premier temps afin de s’assurer que la démarche fonctionne
  • Toute l’entreprise n’a pas besoin d’adopter la solution en même temps. Celle-ci peut être appliquée sur un service ou département pour se propager ensuite aux autres entités de l’entreprise. De même chaque groupe de personnes peut déployer sa propre version du système. Les seuils, les périodes de temps, la quantité de points n’ont pas besoin d’être identiques entre les différents groupes.

Tous les employés doivent s’approprier le système, se sentir impliqués, en garder le contrôle pour l’adapter. C’est la raison pour laquelle je propose que chacun s’occupe de gérer et de faire évoluer le système à tour de rôle afin de responsabiliser le plus grand nombre. Un groupe de personnes sera donc tiré au sort pour s’occuper de gérer la solution pendant une période donnée. Ce groupe pourra améliorer le système en mode Lean en validant simplement des hypothèses sur la solution avec des MVP et en évaluant des indicateurs sur celle-ci. Si la solution n’est pas adoptée par les employés, il n’est pas utile de la garder.

Enfin le système se base sur la bonne foi de ceux qui y participent mais garde un historique de toutes les actions et comportements positifs. Il récompense l’attitude et non directement les résultats car ce sont bien les attitudes positives qui auront à court ou moyen terme des effets sur les résultats…

J’ai été heureux que mon dossier ait été sélectionné et d’avoir pu le défendre chez ANEO lors d’une soutenance même si celui-ci n’a malheureusement pas retenu l’attention du Jury. J’attends maintenant la possibilité de partager de nouveau sur cette solution et suis curieux de connaître les gagnants du concours lors d’une prochaine soirée chez ANEO…

Et si on supprimait l’entretien annuel ?

Eric LannemajouLaisser un commentaire

C’est le défi que s’est lancé ANEO , une ESN libérée d’environ 200 personnes. Afin de pouvoir récolter le maximum d’idées, l’équipe « rémunération » a lancé un concours en décembre dernier pour faire appel à l’intelligence collective. La question semble assez simple « comment remplacer l’entretien annuel dans le processus de rémunération ? ». Les termes du concours consistèrent dans un premier temps à soumettre un dossier et dans un deuxième temps, après sélection, à soutenir ce dernier devant un jury composé de dirigeants, associés, directeurs RH, directeurs de projets…d’ANEO.

J’écris aujourd’hui quelques lignes sur le sujet car j’ai participé au concours et pu soutenir mon dossier devant le jury et je souhaitais partager mon expérience ainsi que les idées que j’ai défendues; celles-ci sont dans la lignée des articles sur la motivation que j’ai rédigés précédemment. J’étais donc enthousiaste pour participer au concours et partager mes idées et convictions avec des personnes intéressées par le sujet. J’ai donc envoyé un document décrivant une solution et c’est celle-ci que je vais présenter dans une série de deux articles traitant du problème et de la solution proposée.

J’ai articulé ma démarche en 3 étapes :

  • La première est l’étude du problème : pourquoi l’entretien annuel ne fonctionne-t-il pas ? Quel était sa finalité ? Pourquoi avait-il été mis en place ? Pour qui ? Quelles sont les motivations des employés ?
  • La seconde est la solution : Que pouvons-nous proposer pour répondre aux besoins des employés ? Pour les motiver ?
  • La dernière qui fait partie de la solution et que je considère comme la plus importante est comment mettre en place les éléments développés dans le point précédent.

Intéressons nous donc pour commencer à l’entretien annuel. Cette pratique s’est largement développée à la fin du siècle dernier et consiste à rencontrer l’employé une fois par an afin :

  • d’évaluer les réalisations sur l’année de l’employé.
  • d’évaluer l’atteinte des objectifs définis lors de l’entretien annuel précédent.
  • d’évaluer les compétences et qualifications.
  • de définir de nouveaux objectifs SMART pour l’année à venir.
  • d’envisager une augmentation de salaire ou/et un changement de qualification.

En se basant sur les points précédents, on peut donc définir que l’entretien annuel serait un outil qui sert, à motiver ou remotiver l’employé en lui demandant ce qui lui a plu dans son travail et ce qu’il aimerait faire; en le récompensant pour ses actions. Afin de préparer cette réunion, on demande à l’employé de remplir  un dossier pour aider la personne qui le rencontre, à évaluer/définir les points ci-dessus avec lui. Dans une version un peu différente de l’entretien annuel, les collaborateurs (hiérarchique ou subordonnées) de cet employé sont aussi interrogés pour donner leur avis; on appelle ce genre d’entretien, l’entretien 360°.

Or la très tristement célèbre étude Gallup, même si elle date de 2012 fait état d’un désengagement de plus de 90% des salariés français vis à vis de leur entreprise. Si on considère que l’un des buts de l’entretien annuel est d’engager et de motiver les employés pour l’année à venir, on ne peut pas affirmer que c’est un succès. D’ailleurs, plus personnellement et en écoutant autour de moi, j’ai pu constater dans de nombreuses entreprises que l’entretien est souvent une formalité administrative qui au mieux permet de motiver les employés à court terme grâce à une augmentation et au pire les stresse et les démotive quand il n’ont rien reçu.

L’entretien annuel ne fonctionnerait donc pas ? Les augmentations de salaire ne seraient donc pas un facteur de motivation suffisant ?

Plusieurs chercheurs et scientifiques se sont penchés sur la questions et ont mené des expériences pour connaître l’impact d’une récompense monétaire sur les tâches ou travaux à exécuter. La première expérience est celle des cubes Soma menée par Edward DECI en 1969 et décrite dans le livre de Daniel Pink « la vérité sur ce qui nous motive« .  La conclusion de cette expérience est que la motivation par l’argent peut diminuer l’intérêt pour l’activité pour laquelle elle est utilisée. La seconde expérience qui est l’expérience de la bougie et qui été menée par Sam Glucksberg démontre que l’incitation par l’argent peut être contre-productive dans les activités faisant appel à la créativité. D’une manière plus générale, Daniel Pink par plusieurs exemples, nous apprend que la carotte et le bâton peuvent :

  • annihiler la motivation intrinsèque
  • réduire la performance
  • empêcher la créativité
  • décourager la bonne conduite
  • inciter à tricher, à simplifier et à agir contrairement à la morale
  • engendrer une accoutumance
  • favoriser un raisonnement à court terme

Cependant, dans certains cas précis cette source de motivation peut s’avérer efficace : pour toutes les tâches mécaniques qui demandent peut de réflexion et dont la productivité est en rapport directe avec la rémunération.

Si l’argent n’est pas la motivation principale des employés, nous pouvons alors nous demander quels sont les éléments qui sont des sources de motivation et d’engagement pour ces derniers. Encore une fois, de nombreux chercheurs ont creusé la question et les expériences ont permis de définir différentes théories. En voici quelques unes qui ont retenu mon attention :

2017-02-20-10_21_06-20170213-concours-aneo-presentation-pdf-adobe-reader

  • Le Taylorisme : c’est l’organisation scientifique du travail. La motivation est la conséquence du salaire et ne tient pas compte des motivations intrinsèques.
  • Le Behaviorisme : lorsqu’on exerce un stimuli sur un individu, alors on obtient une réaction. Cette théorie est plus connue par son application de la carotte et du bâton.
  • La Pyramide des besoins de Maslow : Chaque individu va chercher à assurer ses besoins : besoins physiologiques, besoin de sécurité, besoin d’appartenance, besoin d’estime et besoin de s’accomplir.
  • La théorie de l’autodétermination : les besoins majeurs pour un individu sont : le besoin d’appartenance, le besoin de compétence et le besoin d’autonomie dans ses choix et actions. A partir de ces derniers, on peut définir deux catégories : les besoins intrinsèques, profonds et les besoins extrinsèques qui résultent d’une action extérieure comme une récompense.
  • La théorie des facteurs clés de motivations que j’ai déjà abordé dans l’article suivant :etatmotivationnel Où est la motivation au travail ? Yves Duron et Zwi Segal décrivent différents facteurs de motivation et définissent un état motivationnel qui est le croisement entre l’engagement et la motivation; l’engagement envers l’entreprise et la motivation envers leur travail. Ce qui donne le cadran ci-contre. L’idée ici est donc de garder les employés le plus longtemps possible dans le cadran de l’histoire d’amour où l’engagement envers la société est à son maximum et où la motivation envers son travail est aussi à un niveau élevé. Le cadran histoire d’amour est en réalité plus petit que les 3 autres.

La motivation des employés dépend aussi de l’époque où il sont nés et des avancées technologiques liées à celle-ci. On évoque ainsi différentes générations : Les baby boomers, les générations X, Y, Z qui ont des aspirations qui diffèrent. La générations Y ou digital native dont les membres sont nés entre les années 1980 et 1990, à la recherche de sens et les représentants de la génération Z qui arrivent dans la vie active,  constitueront bientôt 40% des employés. Quel est donc le système ou la solution qui pourra motiver ces derniers ?  La réponse dans un prochain article 😉

Liens et Références :