Page 2 of 3

Un Agile Health Check pour accompagner l’amélioration continue

Avec les coachs SQLI, nous voulions proposer aux équipes que nous accompagnons un outil afin qu’elles puissent se challenger sur leurs pratiques agiles, mais aussi trouver par elles-mêmes des axes d’amélioration.

Après quelques réflexions personnelles et un travail collaboratif, nous en sommes arrivés à construire un set de 11 cartes autour de 4 axes :

  • la collaboration
  • l’inspection et l’amélioration
  • la livraison de valeur
  • le moral de l’équipe.

Pourquoi ce Health Check ?

Nous sommes partis du constat que de nombreuses équipes que nous accompagnons appliquent des frameworks agiles (avec rituels, artefacts, rôles) sans pour autant avoir compris ou encore acquis le « mindset » agile.

Nous voulions donc leur proposer un moyen de prendre de la hauteur par rapport à ces frameworks et de s’interroger sur quelques principes agiles, ainsi qu’aux bénéfices qu’ils peuvent en retirer.

Qui peut être intéressé par ces cartes Agile Health Check ?

Les équipes qui cherchent à améliorer leur manière de travailler en agile afin d’en retirer un maximum de bénéfice.

D’une manière générale, tous ceux qui veulent accompagner une équipe à se questionner sur son état d’esprit et ses pratiques agiles afin de trouver des axes d’amélioration.

Ces cartes peuvent également servir à un coach qui commence à accompagner une équipe afin de prendre connaissance du contexte et d’identifier des besoins d’accompagnements pour l’équipe.

Ce que nous voulions ?

  • Revenir aux valeurs de base de l’agilité et aux bénéfices que l’on cherche à en retirer
  • Amener les équipes à prendre du recul sur leurs pratiques agiles
  • Permettre aux équipes de se questionner et de trouver elles-mêmes des axes d’amélioration

Ce que nous ne voulions pas en faisant cet Health check ?

  • Notre crainte en créant ces cartes était qu’elles deviennent un moyen d’évaluer les équipes, voire même de les comparer. Nous avons donc volontairement choisi de ne pas avoir de système de notation. Nous avons préféré proposer une échelle de satisfaction de l’équipe sur la base de smileys. Nous sommes cependant conscients que ce qui sera fait de ces cartes dépendra de la volonté des personnes qui les utiliseront…
  • Nous ne voulions pas non plus les interroger uniquement sur les frameworks agiles. Ces derniers peuvent être utilisés, à tort, comme des boites à outils pour faire la même chose qu’avant sous une forme différente (nouveaux rôles, nouveaux rituels mais sans pour autant adopter l’auto-organisation, la collaboration, l’acceptation du changement, …). Nous voulions donc nous affranchir des frameworks pour adresser plutôt l’état d’esprit.

Comment sont structurées les cartes ?

Inspirés de Heart Of Agile qui revient aux bases de l’agilité, nous avons structuré nos cartes en 4 thématiques :

  • Collaboration
  • Livraison
  • Inspection et amélioration
  • Moral de l’équipe

Sur chaque carte, le recto présente une question générale sur un principe de l’agilité et le verso propose des questions pour aller plus loin sur cette thématique.

Nous proposons 4 niveaux d’évaluation de la satisfaction de l’équipe (pas de note).

L’équipe peut ainsi s’évaluer sur chaque sujet présent sur les cartes puis discuter de l’évaluation et surtout chercher des axes d’amélioration.

Voici un exemple de carte :

Vous pouvez télécharger les cartes en français et en anglais.

Bien sûr, ces cartes évolueront sûrement dans le temps, au grès des retours et des expériences que nous aurons eus.

Nous vous proposerons prochainement un article avec un retour d’expérience sur différentes façons d’animer des ateliers avec ces cartes.

Quand « se former » rime avec « apprendre à coacher »

Article publié sur le blog interne SQLI

Voilà un très joli parcours de formation que six coachs agiles toulousains viennent de boucler fièrement. Fraichement certifiés « Coach personnel et professionnel » depuis le 19 juillet, Laurent Delas, Marc Dezafit, Elsa Greder, Anne-Christelle Nourdin, Marion Olives et Aurélie Viars nous racontent.

Pourquoi suivre cette formation ?

« Nous exerçons principalement avec la casquette « coach agile » mais nous avions tous un peu de mal à développer cette posture de coach. Nous étions plus au quotidien des formateurs, consultants, « experts » agile et nous voulions développer la facette « coach » au sens large. »

Comment cela s’est-il déroulé ?

« Cette formation, reconnue RNCP, est un engagement de sept mois, car elle se compose de 10 jours de formation en présentiel (deux semaines très riches et intenses), assortis de 300 heures de formation personnelle : deux coachings de 10 séances chacun à réaliser sur environ 4 mois (non sans difficulté au début…), rédaction d’un mémoire, téléconférences, lecture de livres, entrainements de coaching qu’il a fallu cumuler à nos activités au quotidien.

L’accompagnement régulier d’un coach expérimenté, au travers des séances de supervision, permettait de questionner notre pratique et de nous donner des éléments pour progression.

Enfin, le passage de la certification elle-même a nécessité de réviser les sujets théoriques qui sont des bases essentielles pour mieux conduire les séances de coaching. »

Quels sont vos objectifs à terme ?

« Il s’agit tout d’abord d’adopter une posture de coach dans nos missions, et dans un second temps, de pouvoir se positionner sur des missions de coaching individuel, à savoir accompagner des personnes dans l’atteinte de leur objectif professionnel ou personnel, au travers d’une dizaine de séances de coaching. »

Quel bilan en faites-vous ?

« C’est avant tout une montée en compétence importante et une aventure enrichissante.

Mais, comme toute formation, il sera essentiel de pratiquer et de questionner cette expérimentation pour développer une réelle posture de coach professionnel.

De plus, cela été très formateur de travailler ce sujet en dehors de notre domaine d’expertise qu’est l’agilité.

Enfin, c’est super d’avoir fait cela en équipe, cela nous a donné un objectif commun qui a favorisé l’entraide et la cohésion. »

 

Toutes nos félicitations à cette belle équipeque plus rien n’arrête, car ils visent déjà la certification de « Coach Praticien Senior » (Master Coach).

Alix HOWARD DUGUE

On veut créer de la valeur

En général quand je dis ça comme ça, ça fait sourire :).

Les informaticiens doivent se dire « oui elle est gentille, elle n’invente rien, tout le monde veut créer de la valeur ».

Sauf que messieurs-dames les informaticiens, je ne sais pas pourquoi vous êtes les seuls à qui il faut expliquer ça. L’informaticien(ne), très poli, peut me demander « bon d’accord mais c’est quoi la valeur pour le client ? ».

La valeur est créée quand les clients sont contents.

Tout « bon » chef de projet vous le dira : le client ne sait pas ce qu’il veut. Et puisque le client ne sait pas ce qu’il veut, on va se protéger de son indécision et en lui faisant valider des spécifications.

D’ailleurs un « bon » chef de projet est celui qui se bat le mieux.

C’est donc une guerre, le développement logiciel.

On entend alors :

  • « monsieur le client, ce que vous demandez n’est pas du tout conforme avec la demande initiale » -> changement
  •  « monsieur le client ce n’est pas ce que nous avions convenu dans les spécifications » -> changement

Et qui dit changement dit facturation supplémentaire, et le chef de projet est content.
L’objectif avoué est donc de faire valider les spécifications et de ne pas produire de bugs en face de ces spécifications. Au passage si on a pu facturer cher les changements c’est super.

Et bien pas du tout.

En agile on dit bienvenue au changement, le changement est une opportunité, une chance d’arriver au bon produit.
La réaction normale au changement devrait être :

  • « super ! ça sera mieux comme ça ! »

 

Rendez vous compte que l’on demande aux clients de valider des spécifications. Le client ne sait pas faire ça ! Le client sait parler de son besoin, pas des spécifications.

Par exemple : prenons mon plombier, lors d’une visite de chantier de ma maison.
Il me demande « Madame, je les mets où les lavabos ? »
Moi je n’en sais rien du tout, et je le lui fais savoir.
Il m’emmène dans la salle de bain et me dit « Vous vivez comment là dedans ? »
Là c’est facile je sais répondre : « On aime bien avoir de la place sous la douche, pour mettre les affaires sèches à proximité. Puis on aime bien être tous devant le miroir pour prendre des photos du brossage de dents c’est rigolo. »
Pendant que je parle il déduit que la table supportant les 2 lavabos doit être à xxx cm du mur 1 et à xxx cm du mur 2.

Nous avons fait une conversation sur mon besoin, et de cette conversation a émergé la spécification.
Mon plombier n’est pas allé me chercher un « plombier spécifieur » pour écrire une spécification qu’il m’aurait faite valider, puis il aurait fait appel à un « plombier développeur» qui aurait réalisé le produit.
Celui qui réalise (le plombier) est le mieux à même de discuter pour savoir comment répondre à mon besoin : nous avons cette conversation ensemble, lui et moi.

 

Les informaticiens sont informaticiens. Les plombiers sont des plombiers. Les plombiers savent que leurs clients ne sont pas plombiers. Pourquoi les informaticiens ne savent ils pas que leurs clients ne sont pas informaticiens ?

J’entends trop souvent « le client ne sait pas ce qu’il veut » : c’est faux. C’est surtout qu’on ne parle pas le même langage, et qu’on ne pose pas les bonnes questions.
Au lieu de « monsieur le client, que voulez vous comme écran ? » , il faut demander « monsieur le client, comment doit on améliorer votre vie ? ».

On doit lui demander quelle valeur métier on doit créer, et avoir une conversation avec lui à ce sujet.

J’ai l’impression que nous autres les informaticiens nous sommes hautains, conscients de notre supériorité face à cet outil, l’informatique, qui est censé être connu de tous et dont nous sommes les experts (les magiciens).

Ou alors on ne se rend pas compte que notre métier dépasse le cadre strict de l’informatique, et que l’on doit chercher à comprendre quelle est la valeur à créer.

 

La question du comment est la question de la spécification.

Bien sûr il y a des spécifications en agile, ne commettez surtout JAMAIS l’erreur de les enlever.
En agile on raconte des histoires pour comprendre le besoin : en tant que xxx je veux xxx afin de xxx.

Afin de : c’est la question de la valeur à créer.

Raconter des histoires, avoir une conversation sur le besoin pour faire émerger la spécification, cela donne du sens aux développeurs. Cela leur permet de comprendre quelle valeur il faut créer et de ne pas se retrouver à la fin à entendre un client pas content dire « non ce n’est pas un changement, c’était implicite ».

L’objectif contractuel de respecter les spécifications doit être remplacé par des objectifs métiers : la valeur doit avoir été créée là, là et là.

 

La question est simplement : quel est votre besoin ? que voulez vous faire ? pourquoi devons nous faire ceci ?

L’objectif est de rendre les gens contents, de réaliser des applications parfaites où les utilisateurs ne passent pas leur temps à chercher la fonction x ou y. Le client doit pouvoir utiliser l’application comme quand j’utilise le lavabo : c’est mon bon produit.

 

On veut changer le monde : le rendre plus heureux pour tous. 

L’objectif est de changer la vie de nos utilisateurs. Avant ils n’avaient pas cette application : pourquoi doit on la faire ? Quelle valeur doit on créer cette fois ci ?

 

L’agile est une démarche disciplinée de création de valeur.

 

 

 

L’agile ce n’est pas du Design To Cost

J’entend parfois « l’agile, c’est du Design To Cost ! »: je ne suis pas d’accord. Il y a une ressemblance peut être mais aussi une grosse différence entre les deux. Je m’explique.

 

Pourquoi fait-on des projets en agile ? Pour rendre les gens contents tout simplement, pour changer le monde à chaque fois qu’on livre un nouveau produit.

Un projet c’est avant tout un budget et une douleur. Sans budget pas de projet (on estime dans ce cas que la douleur n’est pas si importante), sans douleur pas de projet (on a un budget mais on n’est pas assez riche pour lancer des projets dont on n’a pas vraiment besoin).

Donc quand on lance un projet, c’est qu’on a des utilisateurs à rendre contents. Ces utilisateurs, ils faisaient comment avant qu’on se décide à lancer le projet ? Ils étaient embêtés et ils attendaient qu’on les satisfasse.

 

Souvent la question qu’on leur pose est : « Vous avez combien comme budget ? » (question 1)

Une autre question est tout simplement (ou tout bêtement) : « On doit rendre les utilisateurs contents comment ? Ils devront pouvoir faire quoi avec ce nouveau produit ? » (question 2)

 

Je constate souvent la question 1 : c’est du Design To Cost (un produit pour un coût donné, en français Conception à coût objectif).

La question 2 c’est la maximisation de valeur métier : c’est de l’agile.

 

Le mieux est de poser les deux questions ensembles, dans ce cas le budget se traduit par une simple contrainte budgétaire maximale à l’intérieur de laquelle on priorise.

La démarche agile est la suivante :

  1. on priorise par rapport à la valeur
  2. on ne consomme pas tout tout de suite.

 

Si on pense uniquement Design To Cost, on consomme tout ce budget tout de suite, en une fois, on fige donc tout un périmètre pour un budget. Est-ce que c’est agile ça ?

En gros on se dit « j’en voudrais pour 100 € ! », et on remplit pour 100 €.

L’important est de ne pas oublier la progression itérative dans la limite de ce budget maximum.

Entendez bien cette contrainte maximale : ne remplissez pas tout pour ce montant, sinon on aura tout consommé et donc tout figé, ce qui empêchera de prendre du feedback et donc de créer de la valeur.

 

Dans la question 1 on est efficient : on fige tout pour un montant, on essaie d’être le plus productif possible avec un budget donné, et donc on évacue tout ce qui n’est pas directement productif (l’innovation, l’exploration et le risque).

Dans la question 2 on est efficace : on veut découvrir ce qui va plaire à l’utilisateur : était ce bien ce produit qu’il fallait faire ?

 

Par exemple, je vous livre telle quelle une remarque récente de mon fils : « maman j’ai dépensé tout mon argent de poche ! ». Moi j’ai fait la tête, je ne partageais pas son enthousiasme.

Il est allé dans une librairie et a dépensé au mieux ses 35 €. L’exercice a consisté à prioriser les mangas entre celui qu’il veut absolument (catégorie 1), celui qu’il veut parce qu’il suit la série (catégorie 2), celui qu’il veut parce qu’on lui a conseillé (catégorie 3), celui qu’il veut pour tester (catégorie 4). Avec le budget qu’il avait il a sélectionné les mangas. Conclusion : il en a acheté 5 (2 de la catégorie 1, puis 1 de chaque catégorie).

La suite est évidente : 2 mangas ne lui plaisent pas tant que ça et il regrette de les avoir achetés.

Il était tellement content d’avoir dépensé tout son (mon !) argent !

 

Il a appris que si il avait dépensé moins (moins que le budget maximum) il aurait pu continuer à dépenser correctement son (mon !) argent.

En clair : il n’a pas minimisé son encours et il n’a pas livré souvent.

Il aurait dû se satisfaire de quelques mangas (3 ?), les lire et selon son évaluation améliorer ses décisions pour ses prochains achats.

Il y a un lien direct entre la taille de l’encours et la satisfaction utilisateur : si on minimise l’encours, on accélère le débit donc on livre souvent et donc on recueille des retours plus souvent et on améliore plus souvent.

 

Le Design To Cost maximise l’encours puisqu’on remplit tout pour un montant, maximiser la valeur c’est minimiser l’encours.

 

Maximiser la valeur c’est maximiser les chances d’être content grâce aux retours obtenus à chaque livraison.

Arrêtons de croire que l’on est obligé de tout faire ou de tout dépenser, on ne récoltera pas de retours dans ce cas ou on sera déçu.

 

Le budget maximum est un indicateur. Il traduit une sorte de vision du produit, un niveau de satisfaction à atteindre qui doit aider à prioriser.

 

Le Design To Cost n’est pas agile.

Le Design To Cost a une ressemblance avec l’agile car il commence une conversation : pourquoi ce budget maximum ? Il peut traduire la valeur que l’on veut produire et le ROI, c’est une vision qui doit être expliquée.

 

Quand la bienveillance booste la performance de la communication

La communication

La communication est un art que l’on peut qualifier de complexe, pourtant il repose sur des leviers extrêmement simples, de bon sens. Le plus gros effort a fournir est celui de son positionnement, de son attitude dans la conversation car nous aurons toujours les résultats de ce que nous venons consciemment chercher.

« Comment faut-il que je te parle pour que tu comprennes? »
« Euh… déjà, moins fort! »

Savoir exprimer son point de vue

Je vais illustrer mon propos d’une situation vécue récemment.

Dans une entreprise où les projets sont nombreux, les locaux plutôt anciens et au format box pour 1 ou 2 :
Le PO (Product Owner, représentant du client) exprime le souhait de voir le plateau dans de nouveaux locaux plus spacieux, mieux aménagés, plus enclins à recevoir une équipe agile colocalisée.
Le Client exprime son refus, car il est impossible de trouver ou d’aménager les locaux.
Le PO explique toute la gène occasionnée par l’aménagement actuel et les aspects positifs d’un regroupement des personnes dans un même lieu.
Le Client exprime à nouveau et plus fort son refus.

De là, chacun va camper sur ses positions, n’ayant pas le sentiment d’être compris et le ton monte sans aucun progrès.

Je me permets alors de couper cette conversation stérile pour demander au Client :
« Si tu pouvais le faire, serais-tu OK? »
Le Client répond : « Oui bien sûr, je comprends bien que les salles disponibles ne sont pas facilitantes pour la communication. Aujourd’hui, il est très compliqué de se procurer des espaces adaptés et je ne peux garantir d’y arriver, ni même de trouver un interlocuteur pour faire avancer ce sujet. »
Le PO fait signe de comprendre la situation et ouvre la voie à d’autres solutions plus simples et une mise en place moins urgente, l’équipe pourra faire avec tant que la recherche de solution reste active.

Le problème est-il résolu?

Tout dépend de quel problème on parle.

Le problème de salle est toujours présent. Donc Non.

Le problème relationnel empêchant la résolution du problème de salle, Oui, dans la mesure où nos deux interlocuteurs sont convaincus que l’un et l’autre ont pu partager leur point de vue.

Le problème des salles existe toujours. Néanmoins, le process de résolution est enclenché. Ce qui était impossible est maintenant qualifié, conceptualisé et ouvre la voie à des solutions alternatives. En l’occurrence, il est aujourd’hui envisagé d’abattre des cloisons. Toujours complexe, l’impossible est devenu envisageable.

Dans les communications conflictuelles, je constate souvent que le problème va être identifié à la personne qui l’exprime, alors qu’une démarche constructive permettrait aux interlocuteurs de se placer côte à côte face au problème.

Positionner le problème au centre de la communication, reviens à le poser en filtre entre les interlocuteurs

Placer la recherche conjointe de solution au coeur de la discussion permet de positionner le problème comme l’élément observé, chacun peut participer à la construction de la solution

Quels leviers ?

Cette démarche constructive est souvent de simplement permettre l’expression de ses besoins, de son point de vue (les collines est un exercice que je décrirai dans un prochain article) et que l’autre soit en capacité d’entendre.
Dans notre exemple, le Client aurait pu immédiatement valider la compréhension du besoin et partager son manque de confiance dans la réalisation des souhaits dû au contexte. Le PO aurait pu recentrer la conversation sur ce qui l’importait vraiment, la prise en considération de sa problématique.

Conclusion

Chacun est capable de porter ces actions, pour autant que l’objectif soit en conscience d’apporter des réponses au problème ensemble et pas de se décharger d’un problème connu comme complexe ou d’apporter ses propres solutions.

Dans cet esprit, il est plus aisé d’accepter que l’intégralité de la demande ne sera pas traité parce qu’il est plus facile de juger ensemble de la complexité de sa réalisation. Dans un premier temps, partageons l’analyse de la situation comme un socle sur lequel nous pourrons ensuite construire ensemble notre solution.

En partageant la mise en oeuvre, on partage plus facilement la responsabilité du résultat.

François LAUGIER

sources d’images : CC Pixabay, CC by SA François LAUGIER