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 :

1. Demande d’augmentation des coûts journaliers
2. 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 !

Lire la suite »

Revue sur l’agilité

L’AAE Ensimag (Association des Anciens Elèves de l’Ensimag) vient  de publier sa revue bi-annuelle sur le thème de l’agilité (téléchargeable ICI).

Avoir été le rédacteur en chef de cette revue a été une bonne expérience pour moi, avec quelques challenges comme la définition d’une ligne éditoriale cohérente, la recherche de sujets en phase avec cette ligne, l’appel aux rédacteurs d’articles et le suivi de la fabrication.

Aujourd’hui je suis vraiment fier du résultat obtenu et je remercie tous les contributeurs pour la qualité de leurs articles.

Au sommaire :

• Qu’est-ce qui fait courir les agilistes ? Laurent Bossavit
• Le défi de l’agilité par Messaoud Oubechou
• SCRUM – retour d’expérience chez Orange par Jean-Michel Ortholand
• Agilité et logiciel avionique critique chez Thales par Pascal Fortin et Nicolas Blanpain
• Retour d’expérience : Agilité distribuée par Stéphane Mercier et Emilio Gutter
• Spécifications exécutables par Radhouane Gourchene
• Découverte de l’Agilité par Valentin Brossard

Dites-moi ce que vous en pensez en laissant un petit commentaire sur ce blog

Message personnel pour les anciens ENSIMAG :

Merci de payer votre cotisation 2010

pour que nous puissions continuer à éditer des revues de cette qualité.

AGILE évalue CMMI

La semaine dernière je me suis fait un petit plaisir en m’offrant une formation CMMi pour moi tout seul

Pourquoi ? Simplement par curiosité intellectuelle et envie d’ouverture, et surtout parceque je voulais faire une évaluation agile de CMMi (Lire plus bas) pour essayer une approche inverse à ce que l’on peut lire un peu partout, c’est à dire la traditionnelle évaluation CMMi de l’Agilité qui démontre que l’Agilité est pas mal … mais doit mieux faire pour être au niveau de CMMI … grrrr …..

CONTEXTE

Il s’agissait plutôt d’une journée de discussion ouverte à 4 sur le thème CMMi et Agilité et le groupe était constitué d’un assesseur CMMi certifié, de 2 préconisateurs de l’approche CMMi et moi-même.
Je connais ces personnes depuis plusieurs années et j’apprécie leur ouverture d’esprit, leur capacité de dialogue et leur intérêt pour l’agilité … même si c’est par le bout de la lorgnette CMMi

ORIGINES

Coté approches, pas de révélation, elles sont différentes.

CMMi part du principe que les projets sont répétables et qu’il est donc possible de définir un process formel qui, s’il est suivi à la lettre, contribue fortement au succès du projet. D’où l’émergence de CMMi dans les grandes structures institutionnelles avec beaucoup de projets similaires.

AGILE considère que chaque projet est unique ou presque et que l’approche empirique est la meilleure façon d’atteindre l’objectif qui n’est généralement pas connu avec précision au début du projet. Si un cadre structurant existe bien, l’équipe doit se l’approprier et l’améliorer en permanence sans avoir besoin de justifier les décisions proses auprès de directions méthode ou qualité.

SURPRISE

A ma grande surprise, j’ai appris que selon Humphrey Watts, grand ponte du CMMI, cette approche est déjà AGILE puisque, en complément de l’approche organisationnelle (Les Process Area du CMMI), elle dispose du TSP (Team Software Process) pour le fonctionnement en équipe et du PSP (Personal Software Process) pour l’amélioration de l’efficacité personnelle.

En y regardant de plus près, le TSP comporte de nombreuses caractéristiques communes avec l’agilité (But commun pour l’équipe, Implication de toute l’équipe sur les décisions, Négociation des activités, Coopération, Feedbacks …) mais doit s’appliquer, selon l’approche de Watts, dans un process traditionnel par étapes qui n’est donc pas du tout agile.

Pour ce qui est du PSP, j’avoue ne pas avoir vraiment tout compris mais ce que je garde en mémoire c’est qu’il faut une discipline de fer pour le mettre en œuvre (pour soi même) et qu’il s’inscrit également dans une démarche traditionnelle par étape.

EVALUATION

L’évaluation Agile de CMMI a été conduite en utilisant les 4 valeurs et les 12 principes décrit dans le manifeste agile et n’engage que les 4 personnes qui ont fait l’exercice.

BILAN

Donc au bilan, sur 16 points AGILES évalués :

• 4 points en opposition totale
• 6 points non traités par CMMi
• 2 points partiellement traités par CMMi
• 4 points couverts correctement par CMMi

Et vous, qu’en pensez-vous ?

20 causes d’échecs d’un projet

Trouvé sur le site www.chef-de-projet.org, suite à une présentation faite par l’Espace Numérique de l’Isère hier soir, sur le thème « Réussir son projet informatique : comment avoir les bons réflexes et éviter de se tromper ? ».

Sans remettre en cause le bien fondé ou pas des informations présentent sur le site, j’essaye d’étudier dans cet article, comment l’agilité permet, ou pas, d’éviter ces 20 problèmes.

Au bilan : 17 RESOLUS et 3 OUVERTS .. et VIVA AGILISTA !!!

Pour plus de détails … Lire la suite »

Lean Engineering Chez THALES

Pour ceux qui sont encore dubitatif sur l’application des approches Lean et Agile dans le développement de logiciel embarqué critique, voici un moyen de vous faire basculer du bon coté de la Force Agile.

Regardez la vidéo, trouvée par hasard sur DailyMotion, des équipes valentinoises de Thales qui mettent en application avec succès les approches Lean et Agile.

En plus ILS SONT BEAUX … bon d’accord, je ne suis plus crédible

Enquête CNISF

Très belle enquête du CNISF (Conseil National des Ingénieurs et Scientifiques de France) en 2009 – Télécharger PDF -

Environ 42 000 ingénieurs de toutes disciplines ont répondu à cette enquête dont les résultats sont consignés dans un document de 100 pages (eh oui, prenez votre temps pour le lire).

Énormément d’informations utiles dans ce document comme la répartition des flux de sortie des ingénieurs par région qui donne la région Rhône Alpes en 2ème position derrière Paris (tiens donc, cela me rappelle le résultat du sondage du French SUG).

Beaucoup de données également sur l’intérêt que portent les ingénieurs à leur entreprise, et en particulier les critères qui les font rester … ou qui les feront partir.

Lire la suite »