La semaine dernière nous avons donné avec Fred un cours en Master Miage I à l’université décomposé en 3h de Travaux Dirigés (session obligatoire) et 3h de cours magistral (session facultative). Sur la base des feedbacks des étudiants de l’année dernière, nous avons cette fois ci commencé par le TD qui comprenait 2 jeux : « Artistes et Spécifieurs » et « XP Game », puis le lendemain nous avons fait le cours théorique.

Une chose est certaine, les étudiants se sont réellement amusés lors des jeux mais du coup j’avais un doute sur ce qu’ils avaient réellement assimilés durant ces 3 heures.

Fred a alors pris la craie (et oui nous sommes dans une classe) pour faire un rapide mind map sur la base des mots que les étudiants avaient mémorisé (cf. ci contre)

Ces résultats ont donc conforté notre approche par le jeu car la majorité des valeurs agiles se retrouvent sur ce dessin (pour info : MMS = M&Ms car nous en donnons durant les jeux) ce qui signifie que les messages importants sont bien passés.

Lors du feedback final, un étudiant nous a même dit que c’était une des rares fois ou tous les élèves étaient présents pour un cours théorique facultatif … preuve du succès de l’exercice

Claude m’avait hébergé et nous avons du nous lever tôt pour arriver avant tout le monde et donner la dernière main à la préparation.

Après une ouverture de la conférence par Thierry Cros et les mots de sponsors, j’étais tout de suite dans le bain pour présenter une expérience réussie de Product Owner sur un mode un peu décalé puisque j’ai utilisé les fables de Jean De La Fontaine pour illustrer mes propos (session que je referais à Grenoble le mois prochain). La salle était plutôt bien remplie et les questions nombreuses en fin de session … avec même quelques questions sur la contractualisation agile et les échecs en mode agile.

Ensuite j’ai assisté à une présentation faite par Sogeti qui annonçait avoir réussi un Projet Agile avec un Product Owner absent. J’étais curieux et un peu inquiet. J’avoue avoir trouvé ce que je redoutais, c’est à dire une présentation fade de la méthode SoAgile qui prétend reprendre les bonnes pratiques de l’agilité et proposer une solution packagée aux clients. Malheureusement cette SSII, ou tout au moins son représentant, n’a rien compris aux valeurs de l’agilité et utilise les pratiques dans le mauvais sens … je n’ai pas pu rester silencieux et j’ai donc posé des questions embarrassantes … ce qui m’a rassuré c’est que je n’étais pas le seul dans la salle à le faire, ouf !

Ensuite j’ai rendu une courte visite à Claude Aubry et Thierry Cros qui finissait le jeu du bottleneck avec un débriefing sur la TOC avec les participants qui semblaient tous très heureux d’avoir joués.

Pour la pause de midi … visite au RestoU local avec bon nombre de participants …  c’était la règle à Toulouse

Je n’ai pas pu voir les 2 premières sessions de l’après midi car j’ai préféré discuter avec les organisateurs locaux dont plusieurs demandaient pourquoi Grenoble était sorti de l’Agile Tour cette année … j’ai expliqué les raisons et j’ai l’impression que certaines sont partagées à Toulouse … à suivre.

J’ai également été « happé » par 2 personnes qui travaillent pour Airbus sur les aspects système (donc non logiciel) et qui se demandait comment utiliser l’agilité dans leur contexte. Je pense leur avoir donner l’envie d’aller plus loin et de faire les efforts nécessaires pour mettre en œuvre Scrum dans leur contexte spécifique.

Ensuite petite visite à David Brocard qui proposait des idées pour « Trouver des fournisseurs agiles ». Pour la première de sa session David a été un peu juste sur le timing car il a un peu trop développé les techniques de construction du Product Backlog et donc il a manqué de temps pour développer les critères de choix du fournisseur. Malgré cela la session était très intéressante et comme idée d’amélioration je lui ai proposer d’utiliser quelques cas concret pour illustrer ses propos.

La session à ne pas rater était manifestement celle de Claude Aubry, Antoine Vernois et Fabrice Aimetti : « Scrum et Kanban, tirer le meilleur des 2″ (dont ces 3 là font parti des traducteurs). Antoine est arrivé avec un Tee-Shirt noir sur lequel était marqué SCRUM et il a commencé à expliquer comment marchait Scrum, puis Fabrice à repris la main avec son Tee-Shirt KANBAN en expliquant les bienfaits de son approche et en lançant quelques piques à Scrum. Puis enfin Claude à joué les médiateurs et lorsqu’il a oté son pull est apparu un Tee-Shirt noir marqué SCRUMBAN. Le reste de la pièce de théatre s’est joué sur le même ton, Scrum contre Kanban et ScrumBan en médiateur. Vraiment GENIAL !!

Ensuite direction le Pub pour une bière avec les organisateurs et la journée était fini.

Un vrai et grand bravo à l’équipe Toulousaine pour son enthousiasme et cette journée de qualité

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/

Et nous voilà reparti pour une nouvelle année avec plein de nouveautés

si, pour de nombreuses personnes qui comme moi ont des enfants scolarisés, l’année démarre en Septembre
.
.
.
.

• Des changements chez Agiletoyou avec des forces vives supplémentaires … Yeah !
• Des nouveaux challenges comme la mise en place d’une contractualisation agile pour les marchés publics … Pas facile !
• Plusieurs conférences en Septembre où je suis orateur … Chouette !
  • 14 Septembre à Lyon : 3ème matinale Agile organisée par le Cluster Edit – Piloter l’Agilité
  • 15 Septembre à Paris : Université d’été Daylight – Lean + Casino Game (jeu du Kanban)
  • 30 Septembre à Annecy-le-Vieux : Salon Progiciel organisé par Thésame – Lean + Casino Game (jeu du Kanban)
• La finalisation de la conférence AGILE GRENOBLE 2010 le 23 novembre à Grenoble sponsorisée par l’Agile Alliance, la METRO et de nombreuses sociétés de la région … Encore un effort !

Je vous donnerais plus de détail au fil du temps sur ces évènements mais je vous souhaite à tous une bonne reprise et beaucoup d’agilité pour la période à venir.

Les points clés de ce succès sont :

• L’utilité du nouveau produit et l’innovation technologique
• La tenue des jalons très courts et un coût final inférieur au budget initial
• Le fonctionnement en « équipe » avec une implication très forte des utilisateurs finaux.

Le choix d’une réalisation en mode agile a donc fortement contribué à ce succès car elle a permis :

• D’établir une réelle collaboration entre MOA et MOE
• D’obtenir une implication active des utilisateurs (toutes les 2 semaines pour donner du feedback sur l’incrément de produit réalisé)
• De faire émerger une équipe de réalisation performante et fortement proactive
• De piloter via une métrique simple et fiable : La vélocité !

C’est vrai que je ne cours pas après les prix, mais quand même, cela fait vraiment plaisir quand cela arrive, alors autant le célébrer un peu

• Une présentation+atelier sur les métriques pilotées par le comportement (Behaviour Driven Metrics) que j’animerais avec Manu
• Les bonnes pratiques du Product Owner mise en œuvre sur un projet qui a très bien réussi

Ce sont des créations faites spécifiquement pour cet évènement, souhaitez moi bonne chance

Voir ci-dessous pour plus de détails

Behaviour Driven Metrics : Même les chiffres peuvent être agiles !

Nous proposons dans cette session de décrire une nouvelle approche que nous appelons BDM (Behaviour Driven Metrics) ou établissement de métriques pilotée par le comportement.

Selon les auteurs de « The Balanced Scorecard », Robert S. Kaplan et David P. Norton, 1996, « Vous obtenez ce que vous mesurez », il nous faut des objectifs pour avancer mais nous avons également une tentation bien humaine à n’en faire que le juste nécessaire.

La compréhension correcte de cet aspect comportemental est fondamentale pour définir des métriques qui donne du sens aux individus et ne sont pas que des chiffres empilés les uns derrière les autres.

Lors de cette session vous découvrirez une approche basée sur le comportement pour évaluer des métriques agiles et vous serez également sollicités en petits groupes pour appliquer cette approche sur des cas concrets que vous proposerez.

La fable du Product Owner et du MOA

Il était une fois … un MOA devenu Product Owner sur un projet réalisé en mode Scrum. Tiré d’un cas réel, cette histoire d’une transition réussie est présentée sous forme d’une fable humoristique et non comme un retour d’expérience.

La session couvrira à la fois les pratiques agiles du Product Owner (Valeur Métier, Product Backlog, Release Plan …) mais également les changements de comportement vis-à-vis des utilisateurs et de l’équipe de réalisation.

Un focus particulier sera porté sur les métriques agiles présentées par le Product Owner en Comité de Direction, sur l’utilisation d’une roadmap agile et sur le déroulement des UAT (ou tests utilisateurs).

Après quelques jours de réflexion, j’ai proposé le questionnaire suivant :

• Votre besoin fonctionnel est-il parfois incomplet au T0 du projet ?
• Identifiez-vous de nouveaux besoins en cours de réalisation ?
• Attendez-vous longtemps pour voir une première version ?
• Avez-vous des difficultés à vous faire comprendre de la MOE ?
• Voyez-vous vos planning dériver avec le temps ?
• Vous demandez-vous parfois ce que fait la MOE ?
• Découvrez-vous beaucoup de bugs en fin de cycle ?
• Souhaitez-vous augmenter votre productivité ?

Si vous avez répondu OUI à l’une de ces questions, alors les méthodes Agiles peuvent vous aider à mieux faire car

• La possibilité de changer le besoin fonctionnel est intégré structurellement dans la méthode
• Une version démontrable est livrée régulièrement (tous les 2 ou 3 semaines)
• Les échanges entre MOA et MOE sont permanents et riches d’enseignements
• La prédictibilité de la MOE est basée sur le travail réellement terminé et non sur une estimation de la progression
• La visibilité est totale et permanente sur toutes les activités
• Les tests sont faits en continu pour éviter les effets « Big Bang » de fin de cycle
• Les gains de temps sur l’ensemble du cycle (de l’expression de besoin au déploiement) sont très significatifs

Avec quelques recommandations pour passer à l’Agilité

• Se former, car même si la méthode semble simple, c’est plus complexe qu’il n’y parait
• Se faire accompagner, car c’est plus difficile qu’il n’y paraît et les bénéfices seront obtenus plus rapidement
• Démarrer au plus tôt en mode Agile, c’est-à-dire dès la collecte des besoins, car tous les acteurs sont concernés et pas seulement la MOE
• Accepter et mettre en œuvre les changements induits par la méthode (réunions en présentiel, disponibilité en continu …)
• Comprendre que l’agilité est avant tout un état d’esprit et non juste une « autre méthode »

Qu’en pensez-vous ?

• Chuck Norris est Scrum Master et Product Owner en même temps
• Chuck Norris peut faire des sprints de 6 mois
• Chuck Norris porte des TimeBoxer short
• Chuck Norris ne déplace pas les postIt sur le tableau, il bouge le tableau
• Chuck Norris n’estime pas, il sait
• Chuck Norris s’appaire tout seul
• Chuck Norris est autoriser à arriver en retard au Stand Up
• Chuck Norris s’assoie lors du Stand Up
• Chuck Norris a tout terminé à la fin du Sprint Planning Meeting
• Chuck Norris n’estime pas les User Story, mais les User Story le respecte
• Chuck Norris écrit d’abord le code et jamais les tests
• Chuck Norris ne craint pas les bugs, mais les bugs le craignent
• Chuck Norris ne connait pas le Kanban, il n’a pas de limite
• Chuck Norris ne tire pas, il pousse
• Quand Chuck Norris dit « c’est terminé », alors c’est vraiment terminé
• Chuck Norris ne déploie pas, il développe directement sur les machines de production
• Chuck Norris sait que pour établir un burn-down, il faut du Napalm
• Chuck Norris n’a pas de burn-down, tout est brulé autour de lui
• Chuck Norris ne répond qu’à 2 questions lors du Stand Up … il ne connait jamais de problème
• Chuck Norris n’a pas besoin de prioriser le Product Backlog
• Chuck Norris réalise plusieurs User Story en parallèle
• Chuck Norris n’utilise pas le Développement Piloté par les Tests. Chuck Norris pilote lui même
• Chuck Norris est le Product Backlog
• Chuck Norris est Scrum Master certifié sans avoir le certificat
• Chuck Norris n’a pas besoin d’Acceptance Test. Chuck Norris accepte ou pas !
• Chuck Norris n’a pas besoin de rétrospective. Le process Chuck Norris est parfait
• Chuck Norris écrit des tests qui passent avant d’avoir écrit le code
• Chuck Norris gagne toujours au Poker Planning

Et je rajouterais

• Chuck Norris n’a pas de plan de release. Chuck Norris sait ce qui est à faire
• Chuck Norris a une vélocité de 50 000 points
• Chuck Norris termine le Product Backlog à chaque itération

D’autres idées ?

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 …

Axe 1 Organisation du projet

• Piège 1 Le problème est mal défini et mal délimité –> RESOLU. Incrément de produit et feedback régulier garantissent la fourniture du produit attendu par le client
• Piège 2 Les exécutifs refusent de voir la réalité –> OUVERT. Même problème en agile si les décideurs n’adhèrent pas
• Piège 3 Les plannings sont réalisés à la petite semaine, sans impliquer les acteurs de terrain –> RESOLU. Toute l’équipe participe et les utilisateurs finals sont impliqués
• Piège 4 Les plannings sont trop rigides et imposent des coupes franches improvisées –> RESOLU. Le périmètre est variable avec un timeboxing strict des itérations.
• Piège 5 Les estimations à la bonne franquette deviennent les objectifs à tenir –> RESOLU. Les estimations en « Story Points » évitent la pression sur les charges
• Piège 6 Les budgets sont trop verrouillés –> RESOLU. La notion de « business value » permet de faire les bons choix en terme de budget et de coût de réalisation.donne une réelle solut… mais s’il n’y a même pas le budget pour la release 1 … rien à faire !
• Piège 7 Le projet n’est pas en phase avec les budgets alloués –> RESOLU. L’approche itérative et incrémentale permet de livrer une version du produit dans le budget et de plus je suis convaincu que que l’agilité permet de réduire les coûts

Axe 2 Coopération étendue, team building

• Piège 8 Les responsabilités sont trop mal définies ou changent constamment –> RESOLU. La réduction du nombre de rôles simplifie grandement le problème. Pour ce qui est du changement constant … les agilistes adorent cela
• Piège 9 Les équipes ne sont qu’un ensemble d’individualités –> RESOLU. La communication et l’interaction des personnes est une valeur de l’agilité mise en oeuvre avec toutes les méthodes.
• Piège 10 Les acteurs du projet sont déplacés et réaffectés à tort et à travers –> OUVERT. C’est un problème de management et non de gestion de projet.
• Piège 11 Un manque de participation des autres parties prenantes –> RESOLU. Les démos impliquent fortement toutes les parties prenantes de façon très régulière (toute les 2 à 4 semaines)
• Piège 12 L’absence de véritable communication entre les exécutants et les managers du projet –> RESOLU. Il n’y a plus de « Managers du projet » et le « Product Owner » est totalement intégré dans l’équipe de réalisation.

Axe 3 Assisance à l’anticipation

• Piège 13 Les enjeux mal précisés évoluent et bouleversent les priorités –> RESOLU. La gestion des priorités est un des points forts des méthodes agiles
• Piège 14 Les ressources sont inappropriées ou mal utilisées –> RESOLU. L’approche agile consiste à délivrer de la « business value » et non d’occuper les ressources comme dans les méthodes traditionnelles.
• Piège 15 Les exécutants ont perdu de vue les objectifs initiaux –> RESOLU. Les objectifs sont redéfinis régulièrement et partagés avec toute l’équipe
• Piège 16 L’instrument de mesure est inadéquat…–> RESOLU. Le suivi par la mesure des délais et des coûts n’est pas pratiqué en agile, d’autres indicateurs sont utilisés
• Piège 17 Le balisage du projet ne permet pas une appréciation concrète de l’avancement… –> RESOLU. L’avancement agile est basé sur une réalité (nombre de points produits) et non des estimations en % d’avancement

Axe 4 Intégration

• Piège 18 Les aspects techniques du projet sont privilégiés aux dépens des besoins fonctionnels –> RESOLU. Tous les besoins sont listés dans un seul et unique document, et sont priorisés par une seule personne.
• Piège 19 Le chef de projet cherche à reproduire ce qu’il fait habituellement aux dépens des besoins propres de l’entreprise –> RESOLU. Le chef de projet traditionnel n’existe plus, l’équipe est autonome et en amélioration constante grâce aux rétrospectives régulières.
• Piège 20 Le budget initial ne tient pas suffisamment compte des besoins propres de l’intégration –>OUVERT. La partie déploiement et formation de tous les utilisateurs n’est pas réellement adressé par les méthodes agiles (manque parfois de vision système comme dans le Lean)