Programme Valtech Agile Day, 19 Juin, Paris

Suivez le programme

L’effet Big Bang

Cela fait maintenant quelques années que j’aide les entreprises à « passer » à l’agile.

Dans cette démarche, il m’est souvent conseillé de ne pas le faire en mode Big Bang, mais en douceur. Bon, d’abord, c’est moi le consultant qui conseille, non mais, puis quoi encore.

Et là je dis niet, pas de douceur. On n’est pas là pour s’amuser, pour mettre une nouvelle méthode et faire joujou avec les développeurs, leur mettre la pression pour qu’ils développent plus vite et je ne sais quoi encore.

C’est bien pour changer les choses, arrêter de perdre du temps et de l’argent, arrêter d’avoir des chefs de chefs de chefs…  C’est former une vraie équipe autour d'une idée, d'un produit, pour attaquer le marché, pour en gagner des nouveaux ou pour innover qu’il faut de l’agilité.

J’ai été fortement désappointé (je n’ai pas voulu être grossier sur ce point) lorsque j’ai entendu dernièrement qu’une entreprise qui au bout de 4 ans de transformation trouvait encore le scrum meeting comme une augmentation du coût de gestion de projet de 15%.

Dans d’autres entreprises, je me bats pour remplacer les systèmes qualité obsolètes, qui de plus ont été mis en place à fort renfort budgétaire. Qui a déjà mis en oeuvre ISO ou CMMI ? Combien cela vous a coûté, combien êtes-vous prêt à mettre pour passer à l’agilité ? Que vous ont apporté ces méthodes, à part une multitude de  « sachants contrôleurs » non productifs. Tant qu’à mettre des process, allez jusqu’au bout et utilisez la DO178-B, au moins c’est compatible avec l’eXtreme Programing sur le 100% de code testé.
Des additions de process au lieu d’optimisation. Des réunions de 4 heures hebdomadaires de suivi de projet à 15 personnes, alors que l’équipe projet se retrouve seul le jour de la démo. A n’y rien comprendre.

C’est ce que le Lean appelle l’optimisation locale, et qu’il est fortement déconseillé de faire. (Voir Lean Primer)

Je me souviens aussi lorsque Craig Larman est venu agiliser Valtech : « Quoi! Vous n’avez pas d’intégration continue, bon, bein, mettez-la en place, et je reviendrai quand ce sera fait ». (Traduction très adapté du message original, et avec une petite touche du sud-ouest !)

Il faut faire RAZ de tout, remettre notre cerveau à blanc, recommencer à réfléchir, arrêter de subir.

J’ai fort heureusement travaillé avec une entreprise qui a su faire le pas de manière radicale parce que nécessaire à son maintient dans la course, voire à sa survie. « C’est Agile ou rien, pas de plan B ». Oh, bien sûr tout n’est pas rose, ça laisse des traces, mais les principes sont acquis, le changement est en marche et l’entreprise même remonte sur le devant de la scène, renouvelle avec les bénéfices. Et pourquoi, parce qu’ils ont pris exemple sur une de leur entité, une entité de 200 personnes avec 3 managers seulement, qui avait la meilleure rentabilité du groupe et qui pratiquait les méthodes Agiles.

Bien sûr, on ne peut changer une entreprise dans son ensemble en une seule fois. C’est là qu’une approche graduelle doit être mise en œuvre. Du projet à l’entreprise, la route est longue. Mais au moins, à chaque étape de transformation, pensez à remettre les compteurs à zéro et prônez un changement radical. Quelques projets pilotes pour appréhender la capacité de pénétration de la méthode, beaucoup d’évangélisation, souvent par capillarité des pilotes, puis une application graduelle par niveau dans l’entreprise (service, entité, entreprise). Et là rien ne vaut l’expérience, merci Valtech !
Il faut au moins du BigBang sur le périmètre de mise en oeuvre pour s'affranchir des freins et obtenir les gains réels de la méthode.

Attention la prochaine sera BigBang sinon rien. Etes-vous prêt à changer ?

Tour de Babel : Atelier en plusieurs langues

J’ai animé aujourd’hui un atelier où les participants parlaient plusieurs langues. Il y avait un américain, un canadien, une brésilienne, un allemand et plusieurs français.

D'habitude, dans ce cas, la langue utilisée est l’anglais, mais aujourd’hui, c’est le français qui a été utilisé, Oui!
Tous ont fait l’effort de parler en français. Le canadien avait un peu de mal, l’américain lui faisait la traduction lorsque nécessaire.




Il s’agissait d’un atelier de début de projet, nous avons identifié les personae.

Premièrement, j’étais étonné que pour une fois, nos amis d’outre atlantique fassent l’effort de parler notre langue, même avec difficulté, c’était un joli message de collaboration avec l’équipe.

Au-delà de la langue et de la sémantique, ce qui m’a interpellé c’est qu’au travers du « peu » de vocabulaire de nos collègues étrangers, c’est le besoin qui était challengé. A chaque mot utilisé, en cas de doute, tout le monde cherchait la traduction dans la langue originale de chacun. Une sorte de règle des 3C adaptée aux mots. Card : le mot, Conversation : la bonne traduction, donc compréhension, Confirmation : tout le monde est d’accord.

Ce qui est marrant aussi, c’est que par habitude les français lançaient leurs phrases en anglais, puis en milieu de phrase, s’en rendant compte, la refaisaient en français.

J’ai trouvé ça vraiment très instructif. Ça change finalement des réunions en franglais, où nous n’osons pas dire à nos interlocuteurs anglophones que nous avons compris le contexte, mais pas forcément les détails.

Autre point que j’ai noté, l’utilisation des personae renforce le côté spécification par l’exemple. A partir du moment où un acteur du système est personnifié, ces activités le sont aussi par des jeux d’exemple, de micro scénarios. Il a été beaucoup plus facile de leur faire écrire les histoires utilisateur ensuite.

Faire ou Etre Agile

J’avais lu ce très bon article sur l’intérêt de la mise en œuvre de l’agilité dans les entreprises IT et non IT.


Ce qu’il faut voir, c’est que pour les entreprises IT le ROI est directement dégagé par le produit fabriqué. 
L’amélioration apportée par l’agilité a donc un impact direct sur le ROI.


Dans le cas des entreprises non IT, pour qui l’informatique n’est qu’un outil dont le coût devient une charge, souvent minime dans le CA de la boite, l’amélioration de l’agilité ne peut porter uniquement sur l’optimisation du coût informatique lui-même (optimisation locale), mais sur ce que le produit fabriqué apporte à l’entreprise. L'agilité a un impact indirect sur le ROI.


Ex : un produit coûtera 2M€ a produire, dans un contexte où le coût SI total est de moins de 10% du CA. Quel est l’intérêt d’optimiser un la « façon de produire » ce produit. Ce produit par contre rapportera par an 10 fois son prix.


Ce qu’il faut, c’est optimiser la « façon de délivrer » ce produit pour déclencher le ROI induit.


L’agilité apporte une solution aux deux « façons ». Dans la première, on « fait » de l’agile, dans la deuxième on « est » agile.
Facile à dire, pas facile à faire, les intervenants n’étant pas les même. Les DSI adhérent et achètent le « faire de l’agilité ». Reste à convaincre le business d’adhérer et d’acheter le « être agile ».


A+

Feuilles de Dialogue : Un nouvel outil pour les rétrospectives

Traduction de l'article "Dialogue Sheets : a new tool for retrospectives" d'Allan Kelly parru le 3 janv sur  InfoQ:


Publié avec l'autorisation de copie/traduction d'InfoQ.


_________________________________________________________________
Feuilles de Dialogue : Un nouvel outil pour les rétrospectives

Une Feuille de Dialogue est une feuille de papier, huit fois plus grande qu'un format A4 ou format Lettre. L’année dernière des équipes agiles ou traditionnelles ont pris à l’initiative d’utiliser ces fiches pour les rétrospectives. Les équipes qui utilisent les feuilles déclarent systématiquement un intérêt renouvelé pour les rétrospectives, des niveaux plus élevés d'énergie pendant la session et un style plus inclusif engageant plus de membres de l'équipe.

Les rétrospectives avec Feuilles de Dialogues divergent de plusieurs façons des rétrospectives traditionnelles : Elles sont sans facilitateur. Les instructions sur la feuille entrainent l’équipe à réfléchir sur le passé et à en venir à leurs propres conclusions. Sans facilitateur, l’équipe doit réellement s’auto-organiser.

Mécanique de la Feuille

La feuille au format ISO A1 ou Poster US est pré-imprimée avec les instructions, citations et graphiques conçus pour piloter l’équipe et stimuler la conversation. Certaines des feuilles de rétrospectives présentent une ligne de temps que l’équipe doit remplir ; Sinon le centre de la feuille est disponible pour l’équipe. Les membres de l’équipe sont libres d’écrire des commentaires n’importe où sur la feuille et quelques équipes ont demandé d’avoir encore plus d’espace pour la prise de notes.

Entre 8 et 15 questions et orientations sont réparties autour de la feuille. Les deux ou trois premières instructions décrivent comment l’équipe peut travailler avec la feuille. Les questions suivantes sont conçues pour aider l’équipe à réfléchir. Enfin, en marge de la feuille, plusieurs citations sélectionnées stimulent la réflexion et rappellent aux membres de l’équipe les idées Agiles ou de développement logiciel en général.

Les membres de l’équipe se positionnent eux même autour de la feuille, lisent les questions à tour de rôle, facilitent la discussion et collectent les réponses. Chaque membre de l’équipe est responsable à tour de rôle d’une question au moins. Cela assure une voix à chacun et rend plus difficile la possibilité à une personne de dominer la discussion.

En règle générale, le nombre maximum de participants est huit, avec un minimum de deux. Au-delà, l’équipe est invitée à se diviser en groupes plus petits, chaque groupe remplissant sa feuille, après quoi les équipes comparent et confrontent leurs conclusions.

Le temps pour remplir une feuille dépend du nombre de personnes dans le groupe. Typiquement, une heure est suffisante, mais une équipe de huit, ou une équipe ayant beaucoup de choses à dire prendra plus de temps.

Des versions électroniques des feuilles sont disponibles gratuitement au téléchargement. La nécessité d’imprimer en grand format ces feuilles peut s’avérer compliquée. Quelques équipes n’ayant pas d’imprimante grand format les ont imprimées en A4 ou A3 puis recollées ensemble, bien que cela prenne du temps. L’impression par un imprimeur n’est sans doute pas coûteuse, mais peut l’être. Le site fourni des liens vers des services d’impression en ligne, mais vous pouvez trouver cela moins cher de le faire chez un imprimeur local, évitant les frais de port.


Résultats


Les équipes utilisant les Feuilles de Dialogue pour les rétrospectives rapportent constamment que les gens les trouvent amusantes et que le niveau d’énergie est plus haut. En partie, cela provient simplement du fait de la nouveauté mais aussi à la nature réellement collaborative des feuilles. Non seulement tout le monde peut parler mais chacun devient modérateur pendant quelques minutes.

Il est évident que la feuille donne une voix à chacun. Il est étonnant de constater aussi que les feuilles peuvent donner une voix à un groupe minoritaire au sein d’une plus grande équipe.

Une fois, une équipe a dû se séparer en deux pour remplir la feuille. Comme par hasard, un groupe s’est constitué principalement de développeurs et l’autre d’analystes métier. Après quoi, les analystes métier ont dit avoir pu discuter de ce qu’ils voulaient, dans les termes qu’ils voulaient. En comparaison, du fait du nombre plus élevé de développeurs que d’AF, l’accent, lors des rétrospectives régulières, portait sur les problèmes au niveau du code.

Pour les équipes pratiquant des rétrospectives depuis longtemps, les feuilles offrent une nouvelle façon d’aborder les sujets familiers. Ils ne résolvent pas tous les problèmes, un esprit d’ouverture et de confiance reste toujours nécessaire, et même, plus de confiance peut être nécessaire au début.

Jusqu’ici toutes les feuilles de rétrospectives respectent la Première Directive pour rétrospectives de Kerth.[1] Il peut être surprenant de voir comment une équipe agonise devant quelque chose dont la plupart des facilitateurs prennent non seulement comme du bon sens mais aussi quelque chose de sacro-saint. En effet, il a été rapporté qu’une équipe s’est amusée de la directive.

Plusieurs équipes rapportent qu’elless ont propagé les feuilles dans leur organisation, autant pour les équipes agiles que les équipes de développement plus traditionnel. Une fois, c’est le responsable des tests qui a présenté des feuilles remplies aux autres équipes pour les encourager à les essayer.


Sans facilitateur

La suppression du facilitateur lors d’une rétrospective avec Feuille de Dialogue change la dynamique de façon très intéressante, et fructifiante. Supprimer le facilitateur force les équipes à s’auto-organiser dans ce cadre. Ce qui en soit en bon, et qui enlève aussi la possibilité au facilitateur d’orienter la rétrospective en son sens ou d’empêcher la discussion sur certains sujets.

Plusieurs groupes rapportent que les discussions sont en fait plus accès sur le travail en cours de discussions. Plutôt que le faciliter soit au centre de l’action, c’est la feuille qui l’est. Plutôt que le facilitateur tienne le stylo pour saisir les résultats, c’est l’équipe qui le tien. Tout le monde est responsable de maintenir la conversation dans le sujet.

Je n’ai pas eu jusqu’à présent de retour de rétrospective à feuille de dialogue en échec du fait du manque de facilitateur. Par contre, j’ai eu plusieurs retours de personnes, ayant vu les feuilles de dialogues, ne voulant pas utiliser ce type de rétrospective, considérant le facilitateur comme essentiel.

Ce que je pense être une erreur, une opportunité manquée. Dans l’esprit d’expérimentation Agile, je proposerais à tous d’essayer au moins une fois les rétrospectives sans facilitateur et de réfléchir aux bénéfices.

Bien sûr il y a des choses qu’un facilitateur peut faire qu’une Feuille de Dialogue ne peut : Il peut diriger la recherche sur un sujet particulier, aider un individu à s’ouvrir, ajouter un exercice spécifique pour un problème spécifique ou plus. Je ne suggère pas la suppression permanente du facilitateur. Au contraire, les Feuilles de Dialogues sont de nouveaux outils dans la boite à outil de l’équipe. Ils ne sont pas obligés de les utiliser à chaque rétrospective, ils peuvent mélanger les styles et exercices.

Il y a aussi de la place pour des styles hybrides. J’ai vu plusieurs équipes entreprendre des rétrospectives avec Feuilles de Dialogue lors de mes recherches. Il n’y a pas de raison qu’un facilitateur ne puisse observer et si nécessaire intervenir. (Bien que cela véhicule un message erroné sur l’auto-organisation).

D’une autre façon, la Feuille de Dialogue peut être utilisée en première partie d’une rétrospective pour les problèmes en surface. En deuxième partie, un facilitateur peut intervenir et aider l’équipe à développer une ou plusieures conclusions particulières.


Le Futur

Il existe actuellement plusieurs Feuilles de Dialogue différentes disponibles pour les rétrospectives. L’intention était de fournir de la variété. J’explore aussi d’autres utilisations pour cette technologie. Par exemple, j’ai développé une feuille de démarrage de projet pour les équipes. En essayant les feuilles, d’autres ont aussi créé les leurs.

Le style et les exercices des feuilles sont actuellement largement inspirés des exercices de rétrospectives standardes, tel que ligne de temps, arrête de poisson, j’aime/j’aime pas, etc. Dans le temps, j’espère voir émerger de nouveaux exercices pour les Feuilles de Dialogues.

Actuellement, les feuilles ne sont disponibles qu’en Anglais. Cela n’a pas arrêté des équipes Argentines, Allemandes, Finlandaise et autres à utiliser ces feuilles. Plusieurs personnes se sont proposées pour traduire ces feuilles et j’espère cela rapidement afin de pouvoir les ajouter au site.


La fin du commencement


L’année passée a vu de nombreuses équipes à travers le monde s’essayer aux rétrospectives avec Feuilles de Dialogue et ont trouvé a) qu’elles fonctionnent, b) que les équipes les aimes. Elles ne serviront pas à toutes les équipes mais peuvent être une option que chaque équipe peut regarder.

Les PDF des feuilles disponibles sont gratuitement accessible ici.


A propos de l'auteur


Allan Kelly a presque eu tous les emplois du monde du logiciel, depuis administrateur système jusqu’à responsable du développement. Aujourd’hui il aide les équipes à adopter et approfondir les pratiques Lean et Agile. Il travaille spécialement pour des éditeurs de logiciels et aligne les produits et les processus à la stratégie de l’entreprise. Son nouveau livre « Business Patterns for Software Developper » est attendu pour début 2012.

---

[1] Voir : http://www.retrospectives.com/pages/retroPrimeDirective.html

Les Dialog Sheets de retrospectives

Dans la série rétrospectives:

Initiative très intéressante d'Allan Kelly pour les rétrospectives.
Une sorte de jeu de l'oie sauce agile.

L'objectif étant de se passer du facilitateur, ceci augmentant l'auto organisation de l'équipe selon l'auteur.
L'idée simple est de mettre en couleur et sur papier le mode de fonctionnement d'une rétrospective type de Scrum.
Plusieurs modèles existent, du plus simple au début au plus évolué après expérimentations par l'équipe.

Ça tombe bien, fin de sprint demain, j'essaye!

Le site Dialog Sheets : www.dialoguesheets.com
L'article InfoQ sur le sujet par l'auteur : http://www.infoq.com/articles/dialogue-sheets-retrospectives


PS : Au fait, bonne année 2012 à toutes et à tous! Bientôt la fin du monde il parait, rétrospectives en perspective ;-)

Meilleurs Voeux 2012