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

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

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

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

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

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

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

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

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