Ne pas oublier le chemin parcouru …

cycle de RogersIl semble que l’agilité devienne de plus en plus « main stream » (en référence à la courbe de Moore) avec une majorité de personnes qui souhaite l’adopter.

Je fais ce constat non pas vraiment en constatant de plus en plus d’initiatives Agile (bien que j’ai du refuser plusieurs missions très intéressantes dernièrement ce qui indique une demande de plus en plus forte) mais plutôt en constatant le nombre d’attaques de l’agilité via des blogs ou site web (je ne ferais aucune publicité pour ces espaces qui, au delà d’amener une contradiction bénéfique, sont bien souvent rédigés comme des savates).

Du coup je me demande si nous, les early adopters, nous comportons comme il le faut actuellement et si nous n’avons pas un peu « oublié le chemin que nous avons parcouru ces dernières années » ?

Continuer la lecture de « Ne pas oublier le chemin parcouru … »

Une semaine particulière

vecteur calendrierCe n’est pas vraiment mon habitude de vous raconter ma vie au quotidien sur ce blog, et pour une fois l’envie me prend de vous raconter ma semaine passée car elle a été vraiment particulière du point de vue professionnel.

Voici ce dont je vais vous parler :

  • Un pitch de Maître Cuisinier
  • Des jeux qui font le travail
  • Un acheteur, une juriste et un chef de projet
  • Un Hackathon
  • Des racines et des Germes

Continuer la lecture de « Une semaine particulière »

L’agilité coûte-t-elle plus cher ?

Dernièrement j’ai eu plusieurs discussions avec des personnes qui considèrent que l’agilité coûte plus chère qu’une approche traditionnelle. Le sujet me semble intéressant alors je prends le temps d’en faire un article.

Tout d’abord, il faut regarder à quel moment est posée la question, c’est à dire avant le démarrage du projet ou après la mise en production.

Avant le démarrage du projet Continuer la lecture de « L’agilité coûte-t-elle plus cher ? »

Engagement … comment faire ?

Jeu des CubesA l’origine la méthode Scrum stipulait que l’équipe devait s’engager lors du Sprint Planning Meeting sur la quantité de Story qu’elle se sentait capable de terminer durant l’itération. Cet engagement, qui n’était pas écrit avec le sang de l’équipe, était néanmoins important et l’équipe devait faire tout son possible pour tenir cet engagement … pris librement et sans contrainte, il n’est pas inutile de le rappeler.

Il semble dernièrement qu’il y ait une évolution sur cette notion d’engagement de sprint. En argumentant sur le fait que tout engagement introduit un biais qualitatif (une équipe qui prend un engagement ferme sur une durée + un contenu n’a plus que le paramètre qualité comme variable d’ajustement – en agile comme ailleurs, il n’y a que 4 paramètres d’ajustement en terme de gestion de projet), il y a discussion sur le fait qu’il faille maintenir, ou pas, l’engagement de début de sprint.

J’avoue ne pas avoir de problème avec cet engagement et je pense qu’il est concevable que l’équipe donne un coup de collier ponctuel pour tenir son engagement (pris sans contrainte je vous le rappelle). Cet effort me semble compatible avec la notion de « rythme soutenable » du manifeste sous réserve que l’équipe ne doivent pas faire cet effort de façon permanente. Nous avons tous donné un coup de collier à un moment ou un autre de notre vie pour tenir un engagement que nous avions pris librement et sans pour autant trouver cela anormal.

Donc partons sur le principe que les équipes Scrum s’engagent en début de sprint, alors la question qui se pose est : Comment prendre un engagement ?

Continuer la lecture de « Engagement … comment faire ? »

« Auto-organisation » ne signifie pas « faire tout ce que l’on veut »

Auto-organisationDernièrement j’ai été confronté à plusieurs discussions sur le principe d’auto-organisation de l’équipe qui m’ont fait réfléchir à ce que cette notion véhiculait.

Je profite de cet article pour vous donner mon avis sur les 3 points suivants :

  • L’auto-organisation vue par l’équipe comme étant synonyme de liberté totale
  • L’auto-organisation structurée suivant un certain processus
  • L’auto-organisation comme technique de protection

Tout d’abord un petit rappel sur la notion d’auto-organisation des équipes Agiles. Continuer la lecture de « « Auto-organisation » ne signifie pas « faire tout ce que l’on veut » »

Consultant ou Coach ?

Lorsque j’étais à Toulouse, une personne m’a fait remarqué que je n’étais pas Coach mais plutôt Consultant car je ne dispose pas de certification officielle de Coach. Après en avoir discuté pendant 20 minutes, discussion fort intéressante d’ailleurs, il a reconnu que je me comportait plutôt comme un Coach car lorsque j’accompagne une transition agile, j’accorde beaucoup plus d’importance aux personnes qu’à la méthode agile retenue.

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 ?

Continuer la lecture de « Consultant ou Coach ? »

Formation « Jeux Agiles »

Depuis plusieurs années j’utilise des jeux dans mes formations et mes activités de coaching, et aujourd’hui nous avons décidé avec mon ami Claude Aubry de créer la première formation basée sur des jeux (i.e.: des ateliers) pour définir un produit qui plaira aux utilisateurs.

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« 

L’amélioration avec un Speed Boat

Mercredi dernier, les équipes MOA et MOE d’un projet étaient réunies à Paris pour une journée consacrée à la réflexion et l’amélioration.

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é)

Speed Boat 2

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 🙂

L’essentiel de l’agilité

L’essentiel de de l’agilité consiste à considérer que le logiciel (projet ou produit) est :

  • 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 🙂

Innovation Games® : 1ère formation en France

Innovation GameAprès avoir lu le livre de Luke Hohmann et blogué 4 fois dessus dernièrement, voici le moment de me former plus formellement aux 12 jeux proposés dans le cadre des Innovation Games®.

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).