Je passe effectivement beaucoup de temps et d’énergie à identifier les réticences de chacun pour trouver les meilleurs arguments pour tenter de les convaincre des bénéfices de telle ou telle pratique agile, et j’agis comme si j’étais engagé dans le projet donc sans mettre de distance » avec l’équipe. Plusieurs clients m’ont dit qu’ils appréciaient particulièrement cette approche car justement j’étais différent d’un coach.

Mais alors Coach ou Consultant ?

Dernièrement j’ai lu le livre d’Alexandre Jollien, handicapé de naissance – infirme moteur cérébral, qui philosophe avec Socrate sur sa condition d’homme et surtout sur la longue période qu’il a passé en institut. Dans cet établissement, les éducateurs étaient très proches des pensionnaires mais gardaient également de la distance, par principe … comme les coachs

Cette distance a finalement creusée, entre éducateurs et pensionnaires, un gouffre infranchissable. La distance, il est vrai, peut aider le soignant à conserver sa sphère privée, à ne pas se laisser miner par les problèmes du patient. Mais si une distance raisonnable s’acquiert grâce à l’expérience, elle ne peut ni ne doit s’imposer de façon abrupte et froide. Tout cela vient d’un équilibre délicat.

Comme pour les éducateurs, les Coachs doivent faire attention a ne pas appliquer « par principe » les techniques qui leur ont été enseignées (en particulier la « posture du Coach ») et garder une approche humaniste, car sinon, comme le dit Alexandre Jollien :

Avec ce genre d’éducateur nous n’abordions jamais les vrais problèmes. Ces personnes représentaient à mes yeux des techniciens, des spécialistes, alors que j’avais expressément besoin d’une écoute amicale, d’une proximité bienfaisante qui stimulât une recherche commune de solutions.

Cette journée de formation aura lieu le jeudi 20 octobre sur Toulouse (entre Agile Toulouse le 19/10 et Agile Bordeaux le 21/10, conférences auxquelles je participerais).

Accès au formulaire d’inscription : Bulletin Inscription Formation

Description de la formation

Les jeux sérieux font désormais partie de la panoplie des bons pédagogues. Ils se basent sur l’idée qu’on apprend mieux en pratiquant (et en s’amusant!) qu’en écoutant. Dans le domaine de l’agilité, l’esprit ludique est instillé depuis longtemps dans des pratiques sérieuses avec le populaire XP Game et le Planning Poker. Dans le domaine de la définition de produit, ils ont été popularisés par Luke Hohmann au travers des Innovation Games®. Ils permettent par exemple de constituer un backlog initial permettant de démarrer les sprints ou
de prioriser un portfolio de projets. Mais ils vont bien au-delà et sont utilisables dans de nombreuses circonstances, avec des résultats extrêmement spectaculaires.

Cette formation est destinée aux personnes impliquées dans le développement de produits (Marketing, Business, MOA…, Product Owners) mais conviendra également à toutes les personnes intéressées par l’optimisation du travail en équipe ou désireuses de découvrir d’autres façons d’obtenir des résultats concrets …en particulier pour la définition de produits.

Plus d’information dans le document complet : Formation Innovation Games

Bonus

Tous les participants recevront le livre de Luke Hohmann « Innovation Games » et les 5 premiers inscrits auront en bonus le livre dédicacé de Claude Aubry « Scrum : Le guide pratique de la méthode agile la plus populaire« 

A l’ordre du jour 2 sujets :

• Bilan de 8 mois de pratique de l’agilité sur un sous ensemble du projet (l’autre partie est en Waterfall)
• Evaluation du passage du projet en mode Full Agile

Pour le 2ème sujet, j’avais choisi de lancer la réflexion sous forme de « Speed Boat » (un des 12 innovation games®) car cette approche me semblait pertinente pour identifier les écueils potentiels et les freins au passage en Full Agile.

Voici le résultat de la réflexion (les textes ont été masqués pour raison de confidentialité)

La réflexion a conduit à identifier plusieurs éléments :

• Des freins (les ancres ou les éléments qui retiennent le bateau)
• Les bénéfices attendus dans le port d’arrivée
• Les moteurs qui vont contribuer à la mise en place du changement
• Les iles … dont le statut est ambigu (freins ou moteurs ?)

Bien entendu, cet exercice n’a été que le commencement de la réflexion et ensuite nous avons commencé à traiter les écueils, un par un, en commençant par  les plus importants (et même une des iles qui nous posait vraiment quelques questions délicates). Et cette réflexion n’est pas encore terminée à ce jour.

Sinon, un petit plaisir personnel, voir le coach (moi) matérialisé sur le bateau comme un élément moteur du projet, si, si, ce sont les clients qui le disent

• Piloté par les besoins métier, via le Product Owner ou directement l’utilisateur
• Réalisé par une équipe autonome qui dispose de toutes les compétences nécessaires en son sein
• Livré par petits ensembles, visibles, de fonctionnalités opérationnelles, via des User Story, des items du Backlog, regroupés en itérations ou en flux tiré

Pour réaliser cela, il est nécessaire de faire les activités suivantes :

• Etre très proche des personnes du métier
• Etre piloté par leurs priorités
• Comprendre clairement ce qui doit être fait
• Tester vigoureusement le logiciel à tous moments
• Intégrer le logiciel régulièrement pour éviter les surprises
• Améliorer continuellement la conception pour maintenir le rythme de la production
• … et d’autres choses

Librement inspiré d’un mail de Ron Jeffries reçu à l’instant … et qui m’a fait plaisir

Je serais donc sur Paris les 29 et 30 mars prochain pour assister à la Master Class Innovation Game ® organisée par l’Institut Agile. La formation sera animée par Maarten Volders qui est un instructeur accrédité par l’organisation de Luke (j’ai bien écrit accrédité et pas certifié … car la démarche de certification, quelle qu’elle soit, n’est absolument pas agile … mais j’aurais l’occasion de vous en reparler dans un prochain billet).

J’en profite pour venir avec un ami/client qui est très intéressé par le sujet (nous allons d’ailleurs pratiquer 1 de ces jeux demain avec l’équipe de direction dont il fait partie) et je pense que l’on va bien s’amuser lors de ces 2 jours … et bien entendu j’y vais également pour apprendre plein de choses

Seul petit bémol, cette formation sera en Anglais et même si je comprends la langue de Shakespeare, je trouve qu’il est toujours plus difficile de faire passer certains messages dans une autre langue que la sienne, c’est d’ailleurs pour cette raison que je propose des formation de Product Owner en Français (prochaine session les 7 et 8 avril 2010).

MoreAgile Manifesto

Teamwork & responsibility over Individuals and Interaction
Business Value over Working software
Partnership elaboration over Customer collaboration
Prepare for change over Respond to Change

J’avoue plutôt apprécier leur approche … tout en ayant quelques craintes comme celle de voir disparaître la qualité du logiciel (working software) au profit exclusif du business (Business Value) même si je comprends bien ce qu’il y a derrière.

J’en profite pour souhaiter à tous mes lecteurs une très bonne année 2011

Comme je suis un utilisateur régulier de cette étude puisque je reprends régulièrement certains de leurs tableaux dans mes formations et présentations diverses, je vais essayer de vous décrire les différences principales avec les résultats publiés en 2009.

• 80% de participants supplémentaires (4770) pour un nombre de pays similaire (91)
• Pas de changements dans l’expérience Agiles des participants
• Ajout d’un diagramme très intéressant indiquant que 1/4 de participants pratiquent l’agilité depuis plus de 5 ans et 1/4 depuis plus de 2 ans (et moins de 5 ans)
• Pas de changement sur la prise de décision pour passer à l’agilité … c’est les chefs qui décident depuis quelques années … alors que l’on répète à corps et à cris que l’agilité est une approche bottom-up … tout un discours à revoir
• Pas de changement sur le nombre de projets agiles dans une même société, ni sur la répartition du % de la société qui pratique l’agilité
• Par contre augmentation très significative (24 % à 63 %) des sociétés qui utilisent l’agilité sur 1 ou 2 sites uniquement … j’avoue ne pas savoir pourquoi
• Scrum est toujours utilisé sur 75 % des projets agiles (avec un peu de XP – 18% – mais moins qu’avant – 25% -)
• Sur les techniques employées, le Burndown gagne une place et l’intégration continue en perd une … mais la différence est minime (67% et 65 %), la vélocité se hisse au niveau du refactoring (57%), et le Kanban fait une belle percée (18%)
• Aucun changement dans les causes d’échec des projets en mode agile, ni dans le nombre des projets réussis en agile (22% en 2009 et 2010). A noter que la méthode elle même n’est jamais identifiée comme une cause d’échec
• En ce qui concerne les barrières à l’adoption de l’agilité, les libellés des réponses ont été changé en 2010, et plus que des résistances individuelles qui apparaissent, c’est bien la difficulté de changer la culture de l’entreprise puis la résistance générale au changement qui sortent en tête.
• Pour ce qui est des inquiétudes, il est intéressant de lire que les manques techniques (planning, documentation) mis en avant en 2009 sont maintenant remplacés par la perte de contrôle et une opposition au changement des middle managers … ce que je constate bien souvent chez mes clients
• Bonne nouvelle, la constatation que l’agilité va plus vite augmente (80 % en 2009 pour 83 % en 2010) … d’accord 3% ce n’est pas beaucoup, mais c’est toujours cela
• Et le meilleur pour la fin avec les bénéfices obtenus par l’agilité qui sont similaires à à ceux de 2009, avec un seul changement notoire, le recul à la dernière place de la réduction des coûts (derrière l’agilité distribuée !), bien entendu les autres bénéfices compensent très largement cet aspect, en particulier l’augmentation de la productivité qui est de plus en plus importante

L’étude complète est disponible ICI, bonne lecture.

• Gestion des dépendances
• Utilisation des ressources
• Chemin critique

Gestion des dépendances

Dans un GANTT, les dépendances sont une choses acquises et les outils de gestion de projet traditionnels permettent de modéliser les dépendances entre les activités. Une bonne partie du temps de planification est réservé à l’identification et la modélisation des dépendances, puis ensuite à leur gestion pour tenir compte des évènements qui surviennent sur le projet (et il y en a toujours). Et bien que cette activité soit généralement l’apanage du chef de projet, elle se révèle très consommatrice de temps utile.

En agilité, les équipes vont utiliser ce temps initial (identification et modélisation) pour rendre les activités indépendantes les unes des autres et ne plus avoir à gérer celle-ci ultérieurement. Cette pratique génère donc un gain de temps substantiel durant la réalisation du projet.

J’entends souvent dire « ce n’est pas possible de casser les dépendances sur mon projet !« , mais généralement cela veut plutôt dire « j’ai l’habitude de gérer mes dépendances et je n’ai pas envie de faire autrement !« , car à chaque fois que j’ai aidé l’équipe, nous avons trouvé des solutions pour ne pas avoir de dépendances.

A titre d’exemple, je citerais le travail des équipes de Thales Avionique qui développent du logiciel embarqué et qui ont réussi à découpler le logiciel du matériel (au moins à 99,9 %) … ce que tout le monde pensait impossible !

Utilisation des ressources

Avec un outil de gestion de projet traditionnel vous pouvez obtenir facilement les courbes d’utilisation de chaque ressources, et l’on enseigne aux chefs de projets à optimiser cette utilisation ce qui revient à dire qu’il faut utiliser chaque ressource au maximum de sa disponibilité. L’idée sous-jacente est d’éviter d’avoir une ressource qui ne fait rien car c’est de l’argent perdu. Cette pratique induit beaucoup de complexité dans le planning car de nombreux couplages sont générés pour tenir compte de cette utilisation maximale.

En agile, nous nous appuyons sur la théorie des files d’attentes qui démontre clairement que pour aller vite il faut garder du mou et ne pas utiliser ses ressources à 100 % des capacités.

A titre d’exemple, il ne viendrait d’ailleurs jamais à l’esprit d’un industriel d’utiliser son parc de serveurs à 100% de ses capacités car il ne pourrait plus traiter la moindre demande supplémentaire ou l’augmentation d’un type de demande sur une période donnée. Lorsque je réalise les UAT en mode agile, je demande à une partie de l’équipe de l’équipe technique d’être présente dans la salle où se passent les tests et simplement d’attendre d’être sollicités. Il ne font rien mais sont immédiatement disponible lorsqu’une demande arrive, ce qui au bilan, est beaucoup plus efficace et moins couteux pour le projet.

Chemin Critique

Avec un PERT, vous pouvez visualiser le chemin critique de votre projet et l’on apprend au chef de projet à réduire au minimum le temps nécessaire pour parcourir ce chemin critique. Comme précédemment, cette activité génère beaucoup de couplage sur les autres activités, voir même des découpages aberrants pour gagner quelques jours sur ce chemin critique.

A propos de PERT, connaissez-vous le projet POLARIS lors duquel la technique du PERT a été initialement créée … mais en fait jamais utilisée … ce qui n’empêche pas d’être enseigné lors de toutes les « bonnes formations » de Chef de Projet !

En agile, et plus précisément en Lean, l’approche consiste à ne pas accepter l’idée d’avoir un unique chemin critique et donc de faire en sorte qu’il n’existe pas. Pour cela il faut étudier la possibilité d’avoir des alternatives au cas ou quelque chose ne se passerait pas correctement, par exemple avoir plusieurs fournisseurs pour le même besoin, ou pratiquer le « Set Based Design » qui permet de développer un éventail de solutions qui permettront de prendre les décisions le plus tard possible et d’éviter d’avoir un seul chemin critique.

Cette approche permet de toujours respecter les jalons du projet car une des solutions sera toujours disponible en temps et en heure, et même si elle s’avère plus chère au quotidien, elle génère une économie au niveau du système … c’est le principe  même d’une assurance !

Buy a Feature

Objectif : Prioriser les futures fonctionnalités du produit

Préparation : Listez les fonctionnalités que vous envisagez de mettre dans votre produit et associez un prix à chacune d’entre elles (vous pouvez demander au préalable à votre équipe technique d’évaluer l’effort de réalisation pour vous aider à mettre un prix mais ce n’est pas indispensable). Préparez également des faux billets de 1 ou 5 euros aux couleurs de votre entreprise/produit et les remettre aux participants en quantité égale, et faite en sorte que plusieurs fonctionnalités soient trop chères pour être achetées par 1 seul participant.

Activités : Ce jeu fonctionne mieux avec un groupe réduit de 4 à 7 joueurs car la discussion est essentielle. En effet, les joueurs vont devoir discuter et s’associer pour acheter les fonctionnalités chères qui leur sont réellement utiles. Plutôt que d’avoir la réponse « je veux tout », vous mettez vos participants dans l’obligation de définir les priorités des futures fonctionnalités. Les fonctionnalités achetées en premier sont bien entendu celles qui doivent être dans la prochaine release. Bien entendu, il ne faut pas qu’il y ait suffisamment d’argent au total pour acheter toutes les fonctionnalités.

PS : C’est la technique que je pense utiliser lors des mes sessions « Mes échecs avec Scrum ! » que je présenterais en France en 2011

Start Your Day

Objectif : Comprendre quand et comment vos utilisateurs utilisent vos produits

Préparation : Préparez plusieurs calendriers et imprimez les sur de grands papiers que vous mettrez sur le mur. Les périodes couvertes et le découpage temporel dépend de ce que vous souhaitez obtenir et vous pouvez vous inspirer des calendriers suivants « Jour – 24 heures », « Semaine – 7 jours », « Mois – 30 jours ou 4 semaines », « Année – 12 mois ou 4 trimestres », « Eté/Automne/Hiver/Printemps », « Vacances – Noël, Eté, Février ».

Activités : L’utilisation d’un produit dépend de plusieurs critères comme l’age des utilisateurs, leur expérience avec le produit ou avec des produits similaires et parfois de l’endroit où ils se trouvent. Pour ce jeu vous allez demander à vos utilisateurs de positionner sur les calendriers les instants où ils utilisent votre produit en décrivant ce qu’il font avec à ce moment là. L’utilisation de calendriers va obliger vos utilisateurs à penser plus large que juste de dernier moment où ils ont utilisé votre produit.

Show and Tell

Objectif : Identifier les éléments les plus importants qui ont été créé avec votre produit

Préparation : Demandez à vos utilisateurs d’amener des exemples concrets de ce qu’il font avec votre produit, ce peut-être un produit, une application, une copie d’écran, un rapport papier ou tout autre élément matériel. DE nombreuses études ont montré que les individus sont généralement fiers de pouvoir montrer ce qu’ils réalisent et ce jeu leur en donne l’opportunité.

Activités : Lorsqu’un utilisateur présentera quelque chose aux autres des participants, demandez lui pourquoi ces éléments sont importants pour lui, et quand et comment ils les utilisent. profitez également des questions qui seront posées par les autres participants pour en apprendre plus sur votre produit. Restez particulièrement attentif à tout ce qui pourrait vous surprendre, car généralement cela représente un mine d’or pour votre futur business.

Me and My Shadow

Objectif : Identifier les besoins cachés de vos utilisateurs

Préparation : Aucune préparation spécifique pour ce jeu si ce n’est de la disponibilité de l’utilisateur et de vous-même. Ce jeu rentre dans la catégorie de la « recherche ethnographique » car il consiste a observer comment votre utilisateur utilise votre produit dans son environnement réel (vous êtes son ombre) et trouver de nouvelles pistes (comme par exemple mettre le lit du bébé sur la machine à laver le linge pour qu’il s’endorme … et décider d’ajouter une ceinture pour attacher un lit bébé sur la prochaine machine à laver que vous fabriquerez )

Activités : Regardez simplement votre utilisateur agir. Régulièrement posez lui quelques questions comme « Pourquoi faites vous cela ? », « Qu’avez-vous en tête ? » et profitez en pour identifier les problèmes d’utilisation. Utilisez également un appareil photo ou vidéo pour mémoriser les moments importants, et demandez si vous pouvez avoir une copie des éléments créés avec votre produit. Demandez aux autres participants présents s’ils utilisent le produit de la même façon pour générez de la discussion et l’échange.

Pourquoi des « Jeux Innovants » ?

Pour collaborer avec vos utilisateurs de façon ludique pour mieux comprendre leurs besoins.

Choisir le bon jeu

Certains jeux donnent de meilleurs résultats suivant ce que vous cherchez à comprendre de vos utilisateurs.

• Les besoins du marché que votre produit ne satisfait pas ou ceux qui seraient idéaux pour vos clients
  • Product Box, Me and My Shadow, Buy a Feature, Give Them a Hot Tub, Remember The Future
• La façon dont vos clients utilisent vos produits et les relations entre votre produit et d’autres produits utilisés chez un même client
  • Spider Web, Start Your Day, Me and My Shadow, Show and Tell, The Apprentice
• Quels sont les fonctionnalités et services, offerts par votre produit, qui sont réellement utilisés par vos clients
  • Product Box, 20/20 vision, Me and My Shadow, Speed Boat, Start Your Day, The Apprentice, Buy a Feature
• Comment faire évoluer votre produit dans le futur
  • Remember The Future, 20/20 vision, Buy a Feature; Prune the Product Tree

Caractérisation des jeux

Chaque jeu est évalué suivant 6 critères sur 3 classements (Low, Medium, High) ce qui permet de choisir le bon jeu en fonction du contexte et de la typologie de vos clients/utilisateurs.

Les critères sont les suivants :

• Liberté d’action : Dépend des contraintes que le jeu impose à vos utilisateurs. Moins il y a de contraintes plus les résultats peuvent être surprenants, mais il est également possible que vous ayez du mal à les interpréter. Inversement, s’il y a un cadre bien établi au jeu, vous avez de bonnes chance d’obtenir les résultats attendus mais vous risquez de ne pas voir émerger l’idée géniale qui vous générera du business pour les 5 ou 10 prochaines années.
• Nombre de joueurs : Les jeux sont conçus pour des petits groupes (entre 4 et 24) mais il est possible d’utiliser certains de ces jeux avec des groupes de plus de 100 personnes.
• Effort de préparation physique : Indique la charge de travail ou la complexité de préparation et de mise en place du jeu d’un point de vue matériel (organisation de la salle, achat de matériel …)
• Effort de préparation business : Indique la charge de travail ou la complexité de préparation du jeu en ce qui concerne les éléments business que vous allez fournir à vos joueurs
• Effort de préparation des joueurs : Indique l’investissement nécessaire que devront fournir vos joueurs pour préparer leur participation au jeu, principalement du temps et des démos des produits qu’ils utilisent.
• Délai de mise en application : Correspond au temps nécessaire pour décider et mettre en place les actions suite au jeu. Cela correspond à l’effort pour dépouiller les données collectées et décider des actions à mener.

Organisation du jeu

• Objectifs et choix : Définir ce que vous souhaitez connaitre de vos utilisateurs et choisir le jeu qui vous permettra d’obtenir ces informations
• Identifier les joueurs : Lister et inviter les participants, éventuellement prévoir des récompenses pour les participants (produit gratuit, licences supplémentaires, cadeaux …)
• Préparer le jeu : Réserver la date, louer la salle, acheter le matériel nécessaire …
• Jouer : Disposer de suffisamment de personnes pour tenir les rôles suivants
  • Organisateur : Logistique, Repas, Invitations …
  • Facilitateur : Animateur durant le jeu
  • Aide : Disponible pour toute demande des joueurs
  • Observateurs : Rôle absolument indispensable – Prévoir plusieurs observateurs lors de la session de jeu
    
  • Photographe : Pour garder une trace sympathique de cet évènement
• Post traitement : Collecter et informer
  • Eléments produits : Analyser les éléments produits par le joueurs lors du jeu
  • Avis des observateurs : Analyser tout ce que les observateurs ont vu et perçu
  • Rétrospective : Idéalement avec tous les participants
  • Reporting : Ecrire un rapport pour utilisation en interne et un autre rapport qui sera remis aux participants avec vos remerciements

Après le jeu

Organiser des ateliers au sein de votre entreprise pour exploiter les données récoltées et décider des actions à mener, en particulier au niveau de votre produit.