Laurent Carbonnaux : Coaching Agile

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

2012-01-05T08:19:00.002+01:00

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

2012-01-04T22:20:00.004+01:00

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

2012-01-04T22:05:00.000+01:00

Scrum Nigth chez Valetch 7/12

2011-12-07T15:32:00.001+01:00

Scrum Nigth du French Scrum User Group (tiens, pourquoi pas La Mêlée Nocturne du Groupe des Utilisateurs Français de Scrum; FSUG ou GUFS, that is la question)

La Scrum Nigth se tiendra ce soir 7 décembre dans les magnifiques locaux de Valtech, 103 rue de Grenelle à Paris.

Au menu :
"Adoption ludique et soirée dédiée aux sessions participatives autour de Scrum."
Et dans l'esprit rugby, une troisième mi-temps

Le détail des sessions:
http://www.meetup.com/frenchsug/events/37782582/

Installer GIT en un clin d'oeil en mode SaaS sur le Cloud

2011-12-07T09:52:00.001+01:00

Installer GIT en un clin d'oeil en mode SaaS sur le Cloud

Nouvel article Valtech dans Programmez.com, de mes amis Hervé Desaunois et Cyril Aigoin avec Robin Collet, Damien Flament, Thierry Weissbeck et Lois Collet

Journée HTML5 et mobilité

2011-11-03T19:21:00.000+01:00

Que vous soyez décideur, chef de projets, architecte logiciel ou développeur, vous trouverez le séminaire qui correspond à votre profil :

• HTML5 / CSS3, le Web de demain ?

Matin : 9h30 – 12h45 // COMPLET

Ce séminaire vous permettra de juger du potentiel des technologies HTML5, CSS3 et des nouvelles API JavaScript. Bref un grand tour des possibilités, depuis les balises sémantiques jusqu'aux animations CSS3 en passant par les WebSockets et Web Workers.

• Mobilité, que vous réservent HTML5 et Microsoft ?

Après-midi : 14h30 - 17h30

Avec l’émergence fulgurante des smartphones, la mobilité est devenu un enjeu majeur des développements actuels : tous les jours sont annoncés de nouveaux téléphones, de nouvelles tablettes ou une technologie dédiée.

• Apprenez à coder HTML5 et/ou Windows Phone sur mobile

Soirée : 18h30 - 21h00

Venez développer votre première application mobile avec les ingénieurs Valtech. Au cours de cette rencontre, vous découvrirez tout ce qui est nécessaire pour coder une application sur ces 2 plateformes dans une ambiance technophile et conviviale.

Nous serons heureux de vous accueillir pour cette journée de 3 séminaires gratuits à Toulouse.

Détail et Inscription : http://www.valtech.fr/fr/index/news/html5-mobilite-toulouse.html

AgileTour Toulouse : Histoire d'une transformation Agile

2011-10-20T23:36:00.001+02:00

Voici en ligne la présentation faite par Lionel Molas et moi même à l'Agile Tour Toulouse 2011, le 19 octobre.
Un grand MERCI à l'organisation SigmaT pour cette session très professionnelle.
Un grand MERCI aussi à Valtech, sponsor GOLD de l'édition, sans qui je ne serais rien ;-)
Et bien évidement en énorme MERCI à Lionel et Thierry de m'avoir accompagné dans cette aventure, qui n'est pas terminée.

Agile Tout Toulouse 2011, l'affiche

2011-10-05T23:38:00.000+02:00

Agile Tour Toulouse 2011

2011-10-05T22:58:00.002+02:00

Message de la SigmaT, organisatrice de la session Toulousaine de l'Agile Tour :

Bonjour à tous,

La SigmaT est heureuse de vous annoncer la quatrième édition de
l'Agile Tour Toulouse qui se tiendra le mercredi 19 octobre 2011 au
Centre de Congrès Diagora, à Labège.
L'Agile Tour Toulouse a pour objectif d'être une journée de formation,
d'échange, de partage d'expérience, de réflexion et de rencontre
autour de l'agilité.

La manifestation est ouverte à un large public désireux de découvrir
les bénéfices ou de renforcer ses connaissances dans le domaine de
l'Agilité. La cohabitation des expériences et des compétences, la
convivialité de l'organisation favorise la discussion entre les
acteurs pour faire de cette journée un temps fort à vocation
applicative pour chacun. Managers, Enseignants, DSI, Responsables RH,
Architectes, Chefs de projet, Responsables qualité, Acheteurs,
Développeurs trouveront ainsi des réponses pratiques à des problèmes
concrets.

Cette année nous avons souhaité orienter le programme suivant trois
axes majeurs :
* initiation : une série de présentation et d'ateliers permettant
d'appréhender l'agilité et l'intérêt que cela peut avoir. Ce parcours
s'adresse à tous les curieux qui veulent savoir ce qu'est cette
"agilité" dont on parle un peu partout en ce moment.
* humain et social : mise en place des équipe et des projets,
retours d'expériences. Ce parcours s'adresse aux DSI, gestionnaires de
projet, managers ou chefs de projet.
* ingénierie : les techniques pratiques qui permettent de bien
réaliser le bon produit. Un parcours riche qui intéressera autant les
développeurs que les responsables de produit.

Une quatrième série regroupe des sessions abordant des sujets très
divers comme les rapports entre agilité et CMMI ou un intéressant
retour sur des cas dans lesquels Scrum n'a pas marché.

Évidemment, vous pourrez, à votre guise, composer votre programme
personnel en mixant les sessions des différents parcours.
De larges pauses, entre chaque session, vous permettront d'échanger
plus longuement avec les orateurs et les autres participants.

Cette conférence sera aussi l’occasion de participer au lancement du
club des Utilisateurs de l’agilité en Midi-Pyrénées.
L'agilité est maintenant "mainstream" et questionne les Utilisateurs.
Ce club - commission de l'association indépendante SIGMAT - a pour but
de réunir toute personne engagée en agilité côté Utilisateur et ou
Manager. Pourquoi ? Pour échanger des expériences, travailler ensemble
à des sujets concrets tels que "contrat agile", "SSII et agilité" ou
"rôle du Client".
Le Club pourrait ensuite fonctionner sous forme de réunions régulières
dans le cadre de l'association SIGMAT.

Détails et inscription sur le site http://www.agiletoulouse.org

à bientôt
--
antoine, pour l'équipe d'organisation de l'agile tour toulouse

A-TDD avec Robot Framework

2011-09-17T09:48:00.000+02:00

A-TDD with Robot Framework de Craig Larman et Bas Vodde.
Traduction disponible ici.
Original disponible sur le site de RobotFramework.

La racine carrée de la somme des carrés

2011-09-16T00:07:00.002+02:00

Houa, ça fait peur!

C'est juste une méthode utilisée pour calculer les buffers de contingence. (Schedule buffer). La marge de temps couvrant les risques.

Ça ne date pas d'aujourd'hui, mais comme je n'avais rien trouvé sur le sujet en Français, alors voilà.

Apparu dans le livre "Agile Estimating and Planning" de Mike Cohn en 2005.

Le but étant de savoir comment garantir un planning avec suffisamment de fiabilité. Mike Cohn propose d'ajouter un buffer de temps (et aussi un buffer de fonctions, Feature Buffer).

Question : Comment calculer ce buffer.
Réponse : La racine carrée de la somme des carrées des différences.

Mouais, pas trop avancé avec tout ça. C'est pourtant simple.

Imaginez une liste de fonctions à produire: F1, F2, ...
Vous estimez la charge moyenne de chaque fonction. En point fibonacci et planning poker bien entendu ;-). Cette estimation est considérée comme une valeur moyenne, fiable à 50%.
Ensuite, re-estimez le plus mauvais cas, en prenant en compte tous les risques éventuels. Lors du planning poker, on pourrait garder la valeur la plus forte votée. Vous pouvez considérer cette estimation fiable à 90%.

Ensuite, vous prenez votre excel préféré et :

Fonction	50% (a)	90% (w)	(w-a)²
F1	3	5	4
F2	5	8	9
F3	2	5	9
F4	5	13	64
F5	8	13	25
F6	1	1	0
Somme	24	45	111

(a) = average, moyenne, (w) = worst, plus mauvais cas

La somme des carrés des différences faisant 111, la racine carrée est égale à 11 (arrondie)
Le buffer à considérer est donc de 11.
Le total de l'estimation est donc de 24 + 11, soit 35. 10 points de moins que le total des estimations à 90% de fiabilité.

Tout ça c'est des mathématiques, et par définition les estimations étant fausses, ça n’empêche pas de continuer à réfléchir.

A la prochaine.

Intérêt de l'automatisation des tests

2011-08-25T22:50:00.000+02:00

Suite à la lecture du billet sur l’intégration continu, un internaute voulait savoir comment vendre l’intérêt de l’automatisation de tests. Voici la réponse que je lui ai faite :

D'abord, on va parler argent, puisque c'est pour vendre!

Il faut voir pourquoi l'automatisation ne doit pas être vu comme un surcoût.

Dans un cycle de développement classique (V, cascade, RUP), il n'y a qu'une phase de livraison en fin de développement. De une à 4 par an, souvent.

Dans un cycle itératif (Agile, Lean), il y a un livraison possible au minimum à chaque fin d'itération : de 12 à 24 fois par an.

Le coût de l'automatisation est donc divisé de 6 à 24 fois.

Et de plus de 220 fois (nombre de jours ouvrés) pour ce qui est des tests unitaires passés au minimum 1 fois par jour.

Pas négligeable quand même.

Ensuite, les approches Test Driven (TDD, TDR, A-TDD) sont réputées pour diminuer le taux d'erreur et d'insatisfaction.

Taux d'erreur = bugs

Taux d'insatisfaction = incohérence aux réels besoins métiers, pas forcément à la spec

Leur automatisation garanti donc ce contrôle en continu. Et vous avez raison, aide au contrôle des effets de bords et à la fiabilisation.

Ces tests apportent aussi une "documentation" efficace du produit pour la maintenance de celui-ci:

Un nouveau développeur ou une nouvelle équipe sur un produit aura plus d'assurance de compréhension, de maintenabilité et de pérennité qu'en lisant la spec détaillée. Là aussi, gain économique si les charges sont favorisées sur les tests unitaires plutôt que sur de la doc inutile.

Côté fonctionnel, c'est un peu différent:

Pour moi, les tests fonctionnels sont là pour valider le produit au sens métier.

Si vous utilisez les pratiques TDR et/ou A-TDD, c'est extrêmement efficace et souvent peu coûteux de les automatiser.

Pour faire court, en A-TDD la spécification fonctionnelle est remplacée par des scénarios de tests. Leur automatisation est supportée par de nombreux outils (QTP, robotframework, ...).

Sinon, il est tout à fait possible d'automatiser des scénarios de tests "standards", mais leur maintenance peut s’avérer plus coûteuse, s'ils n'ont pas été pensés pour : Factorisation des cas de tests, double écriture des tests, par le métier dans un outil, puis par les développeurs dans l'automate de test.

Je conseille fortement dans ce cas l'utilisation d'outils dit "keyword driven", tels que robotframework, qui permettent d'utiliser le même outil pour les deux mondes.

Leur automatisation favorise donc effectivement la non régression et peuvent être utilisés sur des tests de performances et de montée en charge.

Le jour où le word s’arrêtera de tourner

2011-08-24T19:51:00.001+02:00

Ras le bol des documents.

On se surcharge de travail pour simplement fournir une preuve en cas de contrôle. Les plans projets, les doc de specs détaillées, les plans de gestion de conf, .... Quel développeur a déjà lu ces types de documents, non pas parce qu’il le devait, mais qu’il en avait besoin, pensait y trouver l’information.

L’information est nécessaire.
La capitalisation de l’information est nécessaire et indispensable, bien sûr. Je ne remets cela en cause d’aucune manière. C’est juste l’outil qui me hérisse le poil. Word c’est pour écrire des bouquins, pas des logiciels. Seul derrière son écran, pas en collaboration avec les collègues.

Ne pas confondre la réflexion et la persistance de la réflexion.

Un document a un propriétaire : l’auteur. Si le lecteur y trouve des incohérences, des erreurs ou seulement veut l’amender de sa propre expérience, il ne le fera pas, sauf contraint bien sûr.

On me rétorque à chaque fois qu’il faut documenter pour les générations futures. D’abord, il n’y a cas ne pas changer d’équipe à chaque fois qu’on fait une nouvelle version du produit, ça c’est dit ! Penser produit pas projet. Et puis, quand je reprends une application développée par d’autres, je préfère de loin avoir des tests unitaires me garantissant que je ne vais rien casser qu’une documentation dont je ne sais même pas si elle est à jour.

Moi je préfère le wiki !

Avec des pages courtes, un sujet par page.

Une organisation par liens, comme le net. Pas d’organisation au format document (chapitre, sous chapitre…), préférer des pages organisant les liens par séquence d’exécution ou de lecture, d’apprentissage … Utiliser les balises pour simplifier la recherche et l’organisation.

Autoriser et favoriser toute l’équipe à participer, modifier, commenter, amender.

Tout comme le code, refactoriser vos pages de temps en temps. Si vous avez peur de supprimer une page, baliser la « obsolète » quelque temps.

Et pour ce qui est des « générations futures », le wiki a tout ce qu’il faut, export, sauvegarde, impression…

Amis agilistes, à vos wiki!

Lean Primer

2011-08-24T18:15:00.000+02:00

Lean Primer de Craig Larman et Bas Vodde.
Traduction de Fabrice Aimetti et moi même.
Disponible ici ou sur le wiki de Fabrice.

AgileTour Toulouse 2011 : Inscriptions ouvertes

2011-08-17T15:35:00.000+02:00

Ça y est, c'est parti.

L'inscription en ligne pour l'Agile Tour Toulouse 2011 est ouverte.

Cette année c'est 20€ pour les frais de repas (entre autre).

Paiement par carte bancaire.

Valtech est sponsor Gold sur cette édition locale.

J'y présenterai avec mon collègue Lionel Molas, un retour d'expérience sur "Agile à l'échelle".
Comment démarrer un projet en Agile, avec 70 personnes au début, 9 équipes, 3 sites, en 1 semaine et faut que ça tienne 2 ans quand même.

La surprenante vérité sur ce qui nous motive

2011-06-21T23:01:00.001+02:00

C'est juste excellent

Vu 5 812 063 fois, 41 884 aiment, 271 n'aiment pas!

Merci à Raj Mudhar pour le lien.

SigmaT 18 : Retour d'expérience "Webinage"

2011-06-14T19:01:00.000+02:00

""""""""""""""""""""""

Jeudi prochain, le 16, aura lieu, à partir de 18h30, le 18ème séminaire d'information sur les méthodes agiles.

Voici le pitch de la session Retour d'expérience réussi de Scrum pour le projet innovant Webinage :

''L'un des postulats des méthodes agiles est l'acceptation du changement. Le développement d'un produit innovant dans le cadre d'un projet de startup exige un alignement permanent entre les fonctionnalités proposées et les attentes des utilisateurs. Dans ce cadre là, l'agilité apparait toute indiquée. Cette session s'intéressera donc à l'application des méthodes agiles au service de l'innovation avec le retour d'expérience d'un an de la société Webinage.''

Le séminaire est gratuit et se passe à la Maison des Associations, au rez de chaussée, salle polyvalente module 2 au rez de chaussée. On entre directement par la porte de gauche.

Aucun problème pour se garer. Pour ceux qui viennent en métro, c'est la station Saint-Agne.

""""""""""""""""""""""
Pour les inscriptions :
  http://www.sigmat.fr/dotclear/index.php?post/2011/06/08/Pitch-du-retour-d-exp%C3%A9rence-du-SigmaT18
Pour les infos
  http://davidbrocard.org/node/110

  http://www.aubryconseil.com/post/SigmaT18-a-la-Maison

Vélocité vs Qualité : Rien ne sert de courir, il faut partir à point

2011-06-14T18:56:00.000+02:00

Ne pas vouloir augmenter la vélocité sans confirmer la qualité.
Lors d’une transformation Agile, au début, les équipes n’ont pas encore mise en œuvre toutes les pratiques Agiles à leur disposition pour garantir la bonne marche du projet et la qualité du produit.

Il est fortement déconseillé de vouloir augmenter la vélocité, et en sous-main la productivité, tant que l’équipe n’a pas en sa possession les éléments de base pour le faire proprement.

En Agile pour encadrer le niveau de qualité, nous utilisons la Definition of done (DoD, Définition de Fini).
Hors la DoD évolue avec le temps. Il est impensable de mettre en œuvre toutes les pratiques Agile en place dès le début du projet. Il faudra des formations, de l’apprentissage, de l’expérience, … en clair du temps.
Ce n’est qu’à partir de la stabilisation de la DoD, que l’on pourra améliorer la vélocité.

La vélocité est une estimation relative qui tient plus compte du « quoi faire » plus que du comment le faire. Un ratio vélocité/jours.hommes n’a pas de sens dans ce contexte.
Si l’on cherche à augmenter la vélocité avant une stabilisation de la DoD, ce qui se passe le plus souvent est la réduction de la celle-ci entraînant la dégradation de la qualité. En contrepartie, il est plus utile de dégrader la productivité en apportant des pratiques garantissant la qualité sur le long terme. Je sais ça peut choquer !

Il sera temps après stabilisation de la DoD, de regarder quels sont les « gaspillages » à éliminer, seul manière d’augmenter la vélocité proprement tout en garantissant la qualité.

Mike Cohn : Quel type de projets est le plus adapté à l’Agilité.

2011-06-09T08:21:00.002+02:00

Traduction du billet de Mike Cohn paru le 16 Janv 2011.

_____________________________________________

On m'a récemment demandé quel type de projet est le plus adapté pour une approche de gestion de projet agile et je voudrais ici m’expliquer. À mon avis, les projets les plus appropriés pour agile sont ceux qui ont des délais agressifs, un haut niveau de complexité, et un haut niveau d’innovation (singularité).

Nous devons utiliser la gestion de projet agile lorsque nous faisons quelque chose de nouveau, ou du moins nouveau pour l'équipe qui le construit. Si c'est quelque chose que l'équipe a déjà faite à plusieurs reprises, l'équipe n'a probablement pas besoin d'une approche agile. À mon avis, c'est là que certaines des analogies avec l’industrie entrent en jeu. Si nous construisons la même voiture jour après jour, nous apprenons très vite toutes les façons de construire cette voiture. Nous n'avons pas besoin d'une approche agile parce que la nouveauté de la situation est faible.

Nouveauté seul ne signifie pas que nous devrions utiliser un processus agile. Je suis allé à mon restaurant chinois préféré pour le déjeuner aujourd'hui. J'ai commandé un plat "triple extra épicé et avec piments mexicains (jalapenos)." C'était probablement la première, seule et unique fois qu’on leur passait cette commande et qu'ils cuisinaient ce plat de cette façon là.
Le cuisinier l’a merveilleusement bien préparé et comme je pouvais voir ce qui se passait en cuisine, j’ai bien vu qu’ils n'avaient pas besoin d'un standup meeting ou même de TDD pour faire mon repas. (J'ai quand même remarqué un kanban là-bas, peu importe ;-) ). Ainsi, en plus de la nouveauté, le projet a besoin d'un certain degré de complexité.

Un dernier élément, je crois, nécessaire à la mise en œuvre d’agile sur un projet est l'urgence. Les pratiques de timebox et d’itération d'une approche agile sont conçues pour maintenir l'intensité et se concentrer sur l’avancement du projet. S’il n'y a aucune urgence sur un projet, ces pratiques sont inutiles.

Voyons donc comment ces trois facteurs -urgence, complexité, nouveauté – se combinent sur divers projets, à commencer évidemment par les projets informatiques. Il ne pouvait pas en être de meilleurs. Les projets informatiques étant notoirement complexes. Chaque projet informatique est une nouvelle entreprise à part entière. Et dans le monde d'aujourd'hui, il ya presque toujours un sentiment d'urgence.

Mais penchons-nous sur une autre situation où nous sommes souvent impliqués, tout en parlant de Scrum: Le mariage. Au moins 2 fois par an, j’entends parler d'un couple utilisant Scrum pour organiser son mariage. Il y a toujours un backlog de mariage : acheter le gâteau, choisir le photographe, envoyer des invitations, choisir la robe, etc. Quel est le lien entre l’organisation d’un mariage et les trois facteurs cités précédemment ?
L'urgence? Voyons. Il ya toujours un date et elle est généralement assez fixe. La complexité? Eh bien, ce n'est pas comme un projet informatique, mais il a sa propre complexité, souvent renforcée par les exigences non fonctionnelles telles qu'un budget fixe, qui est assis à côté de qui, quel type de cuisine va-t-on servir, la nécessité de faire jouer le groupe de musique du cousin Ira lors de la réception, etc. Nouveauté? Yep. La plupart des gens ne s’est pas mariée assez souvent en grande pompe pour que la planification d’un tel événement soit une seconde nature.

Ainsi, la gestion de projet agile est la plus appropriée pour tout projet urgent ayant une complexité et une nouveauté significative, ceci incluant les projets informatiques et les mariages. Reste la question de savoir si le premier baiser des mariés, à la fin de la cérémonie est un élément du backlog de produit ou fait partie des critères d’acceptance du produit lui même.
_____________________________________________

Burndown + Niko-Niko

2011-05-19T13:39:00.000+02:00

Toujours dans la série des rétrospectives, un point intéressant est de suivre la tendance.

Le Niko-Niko:

Le Niko-Niko, pratique Lean utilisée en interne des équipes, permet de suivre l’état du ressenti journalier de chaque membre de l’équipe.

Cette pratique présentée par Emmanuel Chenu, a pour objectif « de vérifier la corrélation entre la santé de l'équipe, la santé du projet et la qualité du logiciel »

Une pastille de couleur est placée sur le calendrier en fin de journée par chacun et de manière anonyme.

Une pastille verte indique que le développeur a passé une bonne journée sur le projet.
Une pastille jaune représente une journée neutre.
Une pastille rouge marque une mauvaise journée.

Niko-Niko : Emmanuel Chenu

Le Burndown + Niko-Niko:

Dans un cadre Agile à l’échelle, il peut être utile de suivre le ressenti de chaque équipe en fin de sprint. L’objectif est d’avoir une tendance synthétique des rétrospective de chaque équipe sur une échelle de temps. L’échelle de temps étant celle des sprints, nous utilisons le burndown et comme dans le Niko-Niko, chaque équipe pose en pastille de couleur en fin de sprint.

Cette vision synthétique des rétrospectives d’équipe décrie une tendance. Cette tendance aide à montrer les risques de déraillements, tant émotionnels que sociaux et productifs : Rythme soutenable, motivation, ambiance d’équipe, collaboration, vélocité. Le burndown étant l’outil qu’affectionnent tout particulièrement les product owners et autres area product owners et scrum masters, c’est un bon moyen pour leur faire passer un message.

Burndown de release + Niko-Niko

Rétrospective : Happy - Unhappy

2011-05-17T13:20:00.003+02:00

Après le ROTI, le RACI et la rétrospective par vote multiple, aujourd’hui je vous propose une pratique de rétrospective rapide pour les réunions de type présentation : Happy – Unhappy
Sur trois critères, efficacité, durée et utilité, les participants notent leur ressenti sur une échelle de satisfaction.

Charge à l’organisateur de la réunion d’en tirer les conclusions !

Prochain billet : Niko-Niko

Un grand MERCI à Thierry Cavrel pour cette idée ;-)

Institut Agile : Référentiel des concepts, pratiques et compétences

2011-05-16T22:08:00.000+02:00

Pour tous ceux qui ne connaissent pas encore les méthodes Agiles et pour qui la langue de Shakespeare est un canal infranchissable, l'Institut Agile propose en Français un référentiel des concepts, pratiques et compétences Agiles.

A mettre sur votre table de chevet, (vous n'avez pas encore d'iPad!?)

http://referentiel.institut-agile.fr/

Rétrospective à vote multiple

2011-05-16T19:10:00.003+02:00

Dans la série Rétrospective, je vous propose aujourd’hui l’utilisation du « Vote multiple ».

Je l’utilise pour les rétrospectives de sprint ou lors de l’élaboration de la liste des obstacles en démarrage de projet. C'est un format « remue-méninges ».

Déroulement sur 1 heure par sprint:

Chacun « crache » les plus et les moins sur des post-its (ou les obstacles)

1 post-it par plus / moins
Les plus sur post-its vert
Le moins sur post-its roses, j’en ai pas de rouges
Durée : 5 minutes

Chacun présente ces post-its, et les place sur le mur en commençant à regrouper par thème

Durée : 20 minutes

Terminer le regroupement par thème

Durée : 5 minutes

Vote multiple

Chacun a un certain nombre de points, 5 la plus part du temps
Chacun répartit de 1 à 5 points sur les thèmes qu’il souhaite traiter en priorité
Durée : 2 minutes

Définir les actions :

Définir trois actions au minimum à prendre en compte dans le sprint suivant
Les actions sur des post-its bleus
Les items « plus », n’entraînent souvent pas d’action, ils doivent quand même faire l’objet d’une attention particulière dans leur prolongation.
Durée : 28 minutes, si j'ai bien fait le calcul

Tout l'équipe participe.

Le Scrum Master anime la rétrospective et contrôle le temps.

Rétrospective à Vote Multiple

Prochain billet : Happy - Unhappy

L'arroseur arrosé

2011-05-16T14:48:00.000+02:00

Tiens, ça t'apprendras!

Valtech Toulouse recrute

2011-05-10T10:03:00.002+02:00

Valtech Toulouse recrute.

Nous recherchons des consultants confirmés/seniors, 3 à 7 ans d’expérience. Plus particulièrement des personnes ayant une double compétence : mobilité + Java et/ou .Net

Envoyer moi vos CVs!

laurent.carbonnaux@valtech.fr