Quelques informations sur le contenu :

• Une percée de Kanban
• Un recul de Scrum
• Des problèmes d’organisation, et non de compétences, qui freinent l’agilité
• Des praticiens plus expérimentés (> 2 ans)
• Moins d’abandon de l’agilité
• Des problèmes de pompier (Agile à Grande Echelle ), de conformité aux normes et standards en vigueur et de documentation
• Excel reste l’outil préféré des agiliste

Give Them a Hot Tub

Objectifs : Utiliser des fonctionnalités hors de propos (excessives) pour découvrir des besoins réels

Préparation : Etablir une liste de fonctionnalités excessives pour votre produit (par exemple un lecteur MP3 pourrait « faire du café », ou « casser du béton » ou encore « toiletter les chiens »). Faire cela en 2 réunions en interne espacées de quelques jours pour avoir des idées sympa et vous donner le temps d’être à l’aise avec ces fonctionnalités surprenantes, car il faudra tenir le choc devant vos clients.

Activités : Le facilitateur est primordial pour cet exercice, son rôle est de présenter chaque fonctionnalités puis de demander aux utilisateurs s’ils acceptent la fonctionnalité en l’état, la refuse totalement comme quelque chose dont ils n’ont pas besoin ou la transforment en quelque chose qui pourrait leur être utile. Les bénéfices du jeu sont majoritairement récoltés dans cette action de transformation d’une idée excessive en quelque chose d’utile, et il était nécessaire de surprendre vos utilisateurs pour les faire réfléchir dans une direction qu’ils n’auraient pas imaginé.

The Apprentice

Objectifs : Créer de l’empathie avec vos utilisateurs

Préparation : Faites en sorte que votre équipe de réalisation puisse utiliser le produit qu’elle développe dans un contexte réel et non une simulation. Pour ce jeu, l’utilisateur n’est pas le joueur, mais il est mis à contribution pour permettre à votre équipe d’être en situation réelle, ce qui généralement le valorise.

Activités : Ce jeu peut se dérouler sur plusieurs jours en fonction du contexte et il est nécessaire de bien expliquer à votre équipe de réalisation l’importance de poser un maximum de questions aux utilisateurs lors du déroulement des activités. Faites un point quotidien de 20 à 30 minutes avec votre équipe pour identifier ce qu’elle a appris et ce qu’elle ressent (demandez également à votre équipe de tenir un petit journal de lerus activités)

20/20 Vision

Objectifs : Comprendre les priorités de vos utilisateurs

Préparation : Disposer de 8 à 20 fonctionnalités écrites sur des supports cartonnés (15*25 cm par exemple) au dos desquels vous écrirez les bénéfices attendus par cette fonctionnalités. Prévoir plusieurs jeux de supports si vous voulez utiliser une variante du jeu et faire jouer plusieurs groupes d’utilisateurs en même temps. Demander à votre équipe de prévoir 3 options de réalisation pour cette fonctionnalités (low, medium, High) comme par exemple pour un chronomètre, une solution en plastique (Low), en aluminium (Medium) et en acier (High).

Activités : Commencer par jouer ce jeu avec des personnes en interne (vente, service client, support technique) avant de solliciter vos utilisateurs. Le déroulement du jeu est le suivant : Prendre une carte et la mettre sur le mur, prendre une autre carte et demander à vos utilisateurs si cette fonctionnalité est plus ou moins importante que la première, puis la mettre au dessus ou au dessous (noter également le choix de la solution retenue), continuer jusqu’à épuisement des cartes. Il y aura beaucoup de discussions, ce que vous devez encourager, des changements d’options, et des tentatives pour regrouper les fonctionnalités en groupe de même priorité, ce que vous devez empêcher.

Speed Boat

Objectifs : Identifier ce que vos utilisateurs n’aiment pas dans vos produits et services

Préparation : Pas de préparation spécifique, il suffit d’avoir du papier et des stylos.

Activités : Dessinez un bateau sur le paperboard et indiquez que vous souhaitez qu’il aille très vite. Demandez alors à vos utilisateurs de dire ce qui empêche le bateau d’aller vite, dessinez une ancre par information récoltée et demandez leur de combien cette ancre ralentit le bateau. Lorsque toutes les ancres ont été posées, passez les en revue une par une avec précision pour être bien certain de comprendre ce que vos utilisateurs aimeraient voir de différent dans votre produit.

Je n’avais pas eu l’occasion de lire les éditions précédentes, c’était donc une découverte pour moi et je remercie la maison d’édition de m’en avoir fait parvenir un exemplaire gracieusement. Et j’avoue avoir eu un petit moment d’auto-satisfaction lorsque j’ai lu sur le cartouche d’envoi les termes « Blogueur Influenceur » … cela fait toujours plaisir
Le livre est très bien écrit et facile à lire, et j’ai particulièrement apprécié les avis des experts (Claude Aubry, Laurent Bossavit, christophe Addinquy, Régis Médina, Freddy Mallet et tant d’autres) que l’on trouve parsemé dans tout le livre au fil des sujets spécifiques de chaque  chapitre.

Le questionnaire proposé dès le début du libre permet d’étalonner ses pratiques de gestion de projet et de gestion de personnes … une des clés de la réussite du chef de projet. Le reste du livre décrit les différentes qualité nécessaires pour être un bon chef de projet et en particulier comment l’agilité permet d’être encore plus efficace.

Pour en avoir discuté plusieurs fois avec Véronique, je n’aime pas beaucoup la notion de « Chef de Projet Agile » que Véronique utilise car je considère que garder les termes « Chef de Projet » n’incite pas vraiment à changer radicalement de mode de fonctionnement lors d’un passage à l’agilité.

Mais véronique propose dans le livre tout un panel d’outils pour faciliter le changement dans l’entreprise et d’un point de vue personnel lors d’un passage à l’agilité alors je lui pardonne volontiers l’utilisation de ces termes et je vous incite très fortement à la lecture de son ouvrage.

J’ai été plutôt surpris de voir apparaître le manager « Agile » (avec un grand A et des guillemets) dans la liste comprenant des spécialistes GreenTech, des acheteurs, des développeurs Smartphone et des consultants en changement, mais cela me conforte dans l’idée que l’agilité est réellement en plein essor sur la région, ce qui me ravit à titre personnel et professionnel.

Pour ce qui est du contenu de l’article, je suis plutôt dubitatif, car j’associe rarement, en fait jamais, l’agilité à la « pérennité à long terme d’une entreprise ». Après réflexion je me dis que les entreprise Agile sont bien plus efficaces que les entreprises classiques et donc bien meilleure d’un point de vue concurrentiel, ce qui généralement leur garantie une pérennité à long terme.

Pour ce qui est de la solidité, je l’associe à la vitesse qui est une caractéristique des entreprises agiles. Lorsqu’une  entreprise va vite pour livrer ses clients ou réaliser un nouveau produit, le ticket d’entrée est très élevé pour une autre entreprise qui voudrait lui faire de la concurrence, car il lui faudra à la fois réaliser des produits plus performants et également les livrer très vite, ce qui n’est pas facile sans agilité. Donc l’agilité peut renforcer la solidité des entreprises.

Pour ce qui est de la mobilité, j’avoue ne pas vraiment avoir trouvé de parallèle dans l’agilité, alors je me dis que c’est peut-être 1 nouvelle valeur à mettre dans le Manifeste Agile … Mais non je blague

Cette exercice de relecture avait généré quelques polémiques, car ma vision de Scrum diffère parfois un peu de celle de Claude, et donc des échanges très intéressants et surtout très enrichissants.

Je ne peux que vous inviter à acheter ce livre qui vous donnera beaucoup d’information sur la pratique de Scrum, et cela même si vous le pratiquez déjà.

Sinon, c’est vraiment beau un livre et cela me donne une sérieuse envie de tenter l’aventure moi-même … il ne me reste plus qu’à trouver le temps … car j’ai déjà le titre et le thème

Certains projets ou méthodes sont voués à l’échec du fait de la non prise en compte de certaines caractéristiques de la personne humaine, et en particulier des modes de défaillance de l’être humain que sont :

• Faire des erreurs
• Préférer l’échec de façon conservatrice
• Inventer plutôt que rechercher
• Etre des créatures inconstantes et sujette aux habitudes

Faire des erreurs

Nous savons tous que tout le monde fait des erreurs et que nous apprenons de ces erreurs. C’est pour cette raison que les approches itératives et incrémentales sont particulièrement adaptées à notre fonctionnement. Les managers par contre oublient souvent cet état de fait et demandent à leurs équipes de faire juste du premier coup, et considère que la première estimation est un engagement ferme et non négotiable.

Si le managers ne prend pas en compte cette réalité, le projet court à sa perte !

Préférer l’échec de façon conservatrice

L’humain n’aime pas le risque et préfère souvent se tromper, car il sait que c’est de peu – retard et surcoût du projet – plutôt que de chercher à réussir – avec l’agilité – avec un risque d’erreur qu’il ne maîtrise pas (sur le même sujet, j’avais cité Ken Schwaber dans un précédent billet – Lean chez France Telecom). Si le manager risque par exemple sa carrière sur le projet, il sera conservateur et préférera le mauvais cycle en V qu’il connaît bien et dont les défauts son même accepté par son chef, plutôt qu’une méthode agile qui lui permettrait de briller en livrant un produit de qualité dans un délai plus court.

Si le coach ne prend pas en compte ce fait, la transition vers l’agilité court à l’échec !

Inventer plutôt que rechercher

L’être humain aime créer par lui même et n’aime pas réutiliser ce qui existe déjà. Cette caractéristique porte le nom NIH (Not Invented Here), ou comme Alistair aime l’appeler IHN (Invent Here Now). Cette caractérisque est souvent culturelle et renforcée par l’éducation que nous avons recue. A l’école chacun est évalué individuellement, il ne faut pas copier sur le voisin, ni discuter du devoir à la maison. Dans l’entreprise, celui qui produit beaucoup de code nouveau est bien souvent valorisé par rapport à celui qui aggrège des librairies existantes, et ce bien que le second produise souvent plus de valeur ajoutée pour l’entreprise. Certaines entreprises comme Texas Instrument ont compris cette caractéristique et mis en place des récompenses pour ceux qui réutilisent beaucoup.

Si le coach ou le manager ne prend pas en compte ce fait, l’équipe n’assimilera pas l’agilité !

Etre des créatures inconstantes et sujette aux habitudes

Nous n’aimons pas changer nos habitudes et nous avons beaucoup de mal à être constant dans l’effort. Si la résistance au changement n’est plus à démontrer : « c’est bien mais ca ne marchera pas pour mon projet », « dans ce cas là ca ne marche pas, la méthode n’est pas bonne » et autres remarques très pertinentes que j’entends en permanence. La nécessité de constance qui va avec la discipline indispensable pour réussir un projet en mode agile est elle moins visible. Nombre d’équipes abandonnent certaines pratiques agiles par manque de constance, de la même façon qu’un individu arrête un régime ou de faire du sport. Les pratiques XP permettent d’améliorer la performance des projets, c’est certain, mais elle doivent également appliquées dans la durée et c’est difficile, même si le coach est efficace.

Si le coach ou le manager ne prend pas en compte ce fait, l’équipe va s’affaisser au fil du temps et le projet baisser en qualité

Même si je pratique l’anglais régulièrement la lecture d’un livre en Français est plus reposant qu’en anglais.

L’auteur parle plusieurs fois dans son livre de définir un « but » à l’itération comme un moyen pour :

• Garder l’équipe focalisée sur ce qui doit vraiment être délivré
• Communiquer simplement à l’extérieur de l’équipe sur ce qui va être réalisé durant l’itération

Je n’ai jamais essayé cette technique et je fais confiance à Henrik lorsqu’il dit qu’elle marche pour lui, mais je me demande s’il est vraiment réaliste de définir un but dès le début du planning de sprint. Cela ressemble à du PUSH et non du PULL – c’est à dire que l’on décide à priori ce qu’il faut faire sans se préoccuper de la capacité de production de l’équipe.

Par contre je ne remets pas en cause l’utilité de définir un but à l’itération comme outil de communication externe et de focus de l’équipe, mais il me semble plus agile de définir le but une fois le planning de sprint réalisé et l’estimation des tâches connues.

La différence vient surement du fait que chez Henrik, l’équipe utilise principalement le calcul des « user points » (qui me semble être parfaitement maîtrisé) comme un outil de définition du contenu de l’itération alors qu’ici nous découpons les stories en tâches estimée en heure et nous nous arrêtons lorsque le temps disponible de l’équipe est trop faible pour prendre une story supplémentaire. Cela permet donc à Henrik de définir un but « à priori » ce que nous sommes ici incapable de faire car nous n’avons pas encore mis suffisamment de focus sur ces aspects … toujours et encore quelque chose à améliorer.

Bref la lecture de ce livre m’a fait réfléchir et progresser … encore merci aux traducteurs

L’idée derrière le livre est de démontrer la réussite ou la difficulté d’affronter des organisations fortement décentralisées (les STARFISH: les indiens Apaches, Les Alcooliques Anonyme, Al Qaeda, eMule, Wikipédia …) en comparaison de structures centralisées (les SPIDER: Inca, Major du disque …).

Pourquoi opposer Starfish et Spider, simplement parce que si vous coupez la tête d’une araignée elle meure, si vous lui arrachez une ou plusieurs pattes elle est moins efficace et peut en mourir, alors que si vous coupez une branche d’une étoile de mer, elle repousse et chez certaines variétés, la branche coupée peut donner naissance à une nouvelle étoile de mer.

Une analyse est faire sur les caractéristiques des organisations décentralisées et en particulier les personnes qui contribuent à leur développement (le catalyseur, le champion …) et leur interaction avec les cercles d’influence qui véhiculent la pensée de ces organisations. Le fait qu’il n’y ait bien souvent pas de règles établies chez les Starfish m’a fait penser au concept d’équipe auto-dirigée de l’agilité.

Le livre montre que derrière la réussite de plusieurs entreprises (Ebay, Google, Toyota …) qui semble centralisée, car elles ont un PDG, des départements etc., se cache un modèle hybride qui offre beaucoup de décentralistation (comme chez toyota ou les ouvriers se chargent eux-mêmes de proposer et mettre en place des améliorations de production)

Ce livre est écrit dans un anglais parfois difficile à lire pour un étranger (grammaire et vocabulaire assez développé)