Etude – Page 2 – Agilex : Agilité et Expertise

Manifeste encore plus agile

Juste pour vous faire partager cette initiative plutôt sympa pour donner un nouveau souffle au manifeste agile (en attendant Agile 2011 à Salt Lake City … là où tout a commencé !).

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 🙂

Etude VersionOne 2010 disponible

L’étude VersionOne 2010 sur la mise en œuvre de l’agilité vient de paraître et cette 5ème édition reste dans la logique des années précédentes avec des résultats similaires … quoique différents.

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.

Continuer la lecture de « Etude VersionOne 2010 disponible »

Planification et découplage

Pour aller vite et être en mesure de respecter les jalons demandés, il est indispensable de simplifier et de découpler les activités qui sont a réaliser. Malheureusement la grande majorité des techniques de planification traditionnelles conduisent plutôt à augmenter ce couplage et pour s’en rendre compte il suffit de comparer les approches traditionnelles et agiles sur 3 aspects essentiels de la planification :

Gestion des dépendances
Utilisation des ressources
Chemin critique

Continuer la lecture de « Planification et découplage »

Jouer avec les clients pour innover #4

Quatrième billet dans lequel je décris 4 jeux supplémentaires

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

Continuer la lecture de « Jouer avec les clients pour innover #4 »

Jouer avec les clients pour innover #2

Deuxième billet de cette série qui donne les raisons pour utiliser un « Innovation Game® », des critères pour choisir le jeu qui correspond à votre besoin et comment organiser et pratiquer ces jeux. Les 2 prochains billets décriront les 12 jeux.

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

Continuer la lecture de « Jouer avec les clients pour innover #2 »

Jouer avec les clients pour innover #1

Tous les acteurs en charge de la définition d’un produit (Directeurs Produit, Product Owner, Business Owner, Marketing …) souhaitent répondre aux attentes de leurs clients et proposer LE produit qui va répondre à tous leurs besoins. S’ils y arrivent, le succès commercial est assuré et tout ce qui en découle sur le plan financier pour leur organisation et eux-mêmes.

Il y a plusieurs façons de définir LE produit qui vous garantira le succès :

Avoir une idée géniale
Demander aux clients ce qu’ils veulent
Faire contribuer les clients à la définition du produit

L’idée géniale consiste à utiliser une nouvelle technologie innovante ou une façon différente des technologies existantes, mais elle n’est pas donnée à tout le monde et son apparition reste aléatoire.

Demander aux clients est une méthode qui relève du bon sens mais qui, malheureusement, ne se révèle pas suffisamment performante car bien des clients n’arrivent pas à exprimer réellement leurs besoins avec une question aussi ouverte, ou alors reste limitée à un petit périmètre qui est constitué des problèmes immédiats des clients sans vision à moyen et long termes.

La troisième option se révèle être la plus performante et parfaitement en phase avec les approches agile. Le livre de Luke Hohmann (« Innovation Game ® ») est un recueil de 12 exercices ou jeux à pratiquer avec les clients, et qui, comme le dit Luke régulièrement, sont « des jeux qui font le travail ! » – Games that make the Job!

L’objet de cet article et des 3 suivants est de vous présenter l’approche de Luke, que j’apprécie également en tant que personne et avec qui j’avais longuement discuté à l’issue de sa présentation à Chicago, et de vous décrire les 12 jeux qui sont détaillés dans son livre.

Concours de Radiateurs

Le concours du plus beau radiateur est lancé, c’est ICI : http://ultimatewallboard.com/

Ok, on dit radiateur en Français, mais vous pouvez continuer à parler de dashboard mural ou mieux de wallboard 🙂

Si vous pensez que votre wallboard agile ou lean mérite le détour, il suffit de le prendre en photo et de le soumettre au votes des juges (Allistair Cockburn, Dave Thomas, David Anderson …) ou au vote du public … comme à la télé.

Je viens de regarder la 30aine d’entrées existantes … et il y a quelques idées intéressantes.

Pourquoi pas la votre ?

PS : Merci à Eustache pour le pointeur 🙂

Manifeste Agile en Français

L’Agile Alliance vient de mettre en ligne la traduction officielle du Manifeste Agile en Français. Ce projet de traduction du manifeste a été initié par Henrik Kniberg (qui nous avait fait le plaisir de venir à Grenoble en 2009 pour un Keynote) et il existe à ce jour 13 traductions.

Cette traduction a été réalisée par le CARA et Arnaud en a été le facilitateur, en tant que Président du Club Agile Rhône Alpes, je tiens à remercier sincèrement tous ceux qui se sont investis dans ce challenge 🙂

Voici les 4 valeurs agiles en Français :

Nous découvrons comment mieux développer des logiciels
par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments
mais privilégions les premiers.

Des outils agiles

Ceux qui me connaissent savent bien que je ne suis pas un fervent partisan des outils agiles … enfin surtout pas en première approche.

J’aime bien que les équipes que je coache réalisent par elle même, avec le temps, quel pourrait être l’avantage d’utiliser tel ou tel outil. Donc dans un premier temps, et surtout en cas de premier projet pilote, je préconise l’utilisation d’outils simples (post It et tableau pour les itérations, tableur pour le reste).

Lorsque l’équipe est devenu plus mature sur l’agilité, elle sait ce qu’elle cherche à obtenir et la transition vers un outil se fait sans risque de perdre les acquis de l’agilité. Ce peut être des outils complets comme IceScrum de mon ami Claude ou the-scrum de Nicolas, ou du lourd comme VersionOne ou Rally, ou alors des outils bien spécifiques comme Cucumber lorsque l’équipe décide de passer au BDD (Behaviour Driven Developement).

Quoiqu’il en soit, si les outils vous intéressent, je vous invite à lire le résultat de cette étude sur l’utilisation des outils agiles : http://blog.klover.se/2010/08/12/agile-tool-survey-results/

Les coûts, une dérive agile ?

Dans ma stratégie de développement de mon entreprise, j’essaye de travailler pour des clients finaux et au minimum pour des SSII … surement parce que c’est un monde que je connais bien 🙂

Je n’ai rien contre les SSII sur le fond et je sais que c’est un travail difficile, mais lorsque les SSII se mettent à parler d’agilité, à part quelques unes qui savent de quoi elles parlent, pour les autres c’est du grand guignol … ou plus bassement un vil intérêt financier !

Mes clients et prospects me font écho des 2 points suivants, que je considère comme une réelle dérive et j’en détaille les raisons dans la suite de cet article :

Demande d’augmentation des coûts journaliers
Promesse de réduction des coûts globaux

Une dérive similaire a été constaté à la fin des années 90 aux USA et a conduit beaucoup de société a abandonner l’agilité suite à des échecs, souvent du fait d’un mauvais conseil. La bonne nouvelle est que ce n’était que temporaire et que ces mêmes sociétés ont retenté l’expérience à la fin des années 2000, en s’appuyant sur des coachs confirmés, avec de belles réussites.

Clients, faites donc bien attention aux miroirs aux alouettes et choisissez bien votre coach !

Catégorie : Etude