Affichage des articles dont le libellé est retour d'expérience. Afficher tous les articles
Affichage des articles dont le libellé est retour d'expérience. Afficher tous les articles

vendredi 28 février 2014

Rétrospectives agiles



La rétrospective en agile (ou pas d'ailleurs) est le moteur de l'amélioration continue.
Les méthodes agiles proposent la mise en oeuvre de rétrospectives a chaque temps fort du projet :

  • à la fin d'un Sprint, d'une itération
  • à la fin d'une version,
  • à la fin du projet


La forme la plus classique pour l'animation de cette cérémonie est la suivante :
L'animation est réalisée par le Scrum Master ou le Facilitateur
Chaque membre de l'équipe formalise sur un post-it et pour la période donnée

  • ce qui s'est bien passé (+),
  • ce qui s'est mal passé (-),
  • ce qui est à améliorer (/>)


On rencontre également souvent une forme légèrement différente dans laquelle on ajoute ce qui reste mystérieux.

Chaque post-it est alors placé sur un tableau dans une case correspondante. Le facilitateur prends alors chaque élément, le lit à haute voix et reformule afin d'être certain d'avoir bien compris le sens de cette contribution. Il rassemble également les post-its par paquets afin de regrouper les éléments qui ont un sens équivalent.
A ce premier niveau l'important est de créer un partage et éventuellement des débats sur des points de vue différents.
Une fois ce premier débrief réalisé l'équipe choisi UNE amélioration qu'elle devra mettre en oeuvre durant la prochaine période.

Sur le papier, c'est très bien, mais dans la durée il arrive parfois que ce format devienne une routine et l'équipe fini par s’essouffler et la rétrospective peut vite devenir une routine.

Il y a quinze jours, un collègue Scrum Master (Olivier Picaud) m'en faisait justement part et cherchait une autre approche de la rétrospective afin de "restimuler" son équipe, qu'elle fasse preuve à nouveau de créativité et d'imagination afin de relever les nouveaux défis à relever et problèmes à surmonter.

Je lui ai donc proposé le format en "étoile de mer"
Quelques références en ligne sur ce modèle :

http://www.areyouagile.com/2013/05/lart-de-la-retrospective/



http://ayeba.wikispaces.com/La+r%C3%A9trospective+en+%C3%A9toile+de+mer



C'est donc le format qu'il a utilisé pour sa dernière rétrospective, et le résultat fut très satisfaisant. L'équipe s'est véritablement lâchée, dans le bon sens du terme et les matériaux récoltés on été très riches. Cela se voit :




Ce qu'Olivier me faisait remarquer également, c'est qu'en lisant cette étoile de mer dans le sens horaire, elle raconte une histoire : c'est l'histoire du Sprint, et ça a du sens! 

Ce qu'il faut retenir, ce qu'il ne faut jamais laisser s'installer une routine au sein de l'équipe, surtout pas lors des rétrospective! Ce moment est trop important pour cela.
Variez les formes, renouvelez-vous. Vous pouvez animer un "Speed Boat" (Innovation Game)  à certains moments, et n'hésitez pas à chercher sur internet de nouveaux formats dès que vous sentez que le format que vous utilisez s'essouffle. Changer de format, c'est changer de regard, c'est se poser les questions sous un autre angle, et donc exercer son regard critique!

jeudi 13 février 2014

Rétrospective Annuelle et Innovation Games : plans d'actions

Une fois la rétrospective animée, et les résultats collectés, que faire de cette matière brute et comment l'utiliser?

Notre démarche fut la suivante : 
1 - réaliser une synthèse de chaque atelier et des retours du mur de feedback
2 - regrouper les problèmes identifiés par thème et en établir une liste 
3 - attribuer une valeur à chaque problème
4 - attribuer une complexité de résolution à chaque problème
5 - calculer le ROI (valeur/complexité) à chaque problème pour les prioriser
6 - dresser un plan d'action pour les 3 problèmes les plus importants
7 - identifier pour chaque plan d'actions la liste des problèmes adressés




Ce matin, j'ai donc présenté à l'équipe l'ensemble du travail de consolidation, la démarche et les plans d'actions. 

L'équipe a retrouvé dans notre synthèse les éléments qu'ils avaient remonté. Du coup, nous avons eu une bonne adhésion de l'ensemble des acteurs sur les plans d'actions à mettre en oeuvre.

Le plus gros est donc à faire!

lundi 6 janvier 2014

Rétrospective Annuelle et Innovation Games

Animer une rétrospective avec des Innovation Games

En cette fin d'année j'ai été missionné pour animer la rétrospective annuelle de notre support technique.
Habituellement cette réunion est unidirectionnelle : le manager présente un PPT à son équipe et relate les événements marquants de l'année.

Cette forme a vécu et l'équipe a proposé une nouvelle version plus interactive, plus vivante et plus constructive.

Reposons le décor 

Il s'agit d'une équipe constituée d'experts techniques - DBA, développeurs ... Le gros de l'équipe se trouve localisée en région Bordelaise - même bureau- mais quelques membres sont répartis sur d'autres sites - Aix-en-Provence, Nantes ... . 
Le client principal est le pôle Internet, mais il y a aussi un département GED et un département Intranet. Quelques membres de l'équipe sont de nouveaux arrivants, d'autres sont arrivés en cours d'année et certains sont présents depuis la création du service il y a 3 ou 4 ans.
L'équipe était initialement positionnée sur la résolution des problèmes de production, puis a essayer de se recentrer sur des activités plus en amont afin d'anticiper les problèmes et de ne plus subir les choix réalisés par d'autres tout en ayant une augmentation conséquente de ses effectifs et de son périmètre.

Faire un bilan est devenue plus qu'une nécessité, un élément vital!

C'est là que les Innovations Games nous ont apporté une solution.

Au programme

Une présentation des faits marquants de l'année sur le thème de la voile illustrée par un tour du monde en équipage. Un parallèle est fait entre les valeurs de l'équipe et les valeurs véhiculées par le sport - rugby et voile- .

  • Un mur de feedback placé prés de la porte de sortie de la salle pour collecter les retours après chaque atelier.
  • Un atelier Vision Box afin que chacun contribue à la constitution de la vision idéale de ce qu'est cette équipe : son rôle, ses forces, son périmètre - 4 équipes
  • Un repas convivial tous ensemble,
  • Un atelier Remeber The Future pour se projeter dans trois scénarios idéaux à l'horizon 2018 - pour laisser un peu de place à l'imaginaire et au progrès que pourrait faire l'équipe et l'entreprise - 3 équipes
  • Un atelier Speed Boat pour identifier dans le contexte actuel les forces et les freins de l'équipe en vue d'un objectif idéal à court terme - tous ensemble
  • Débriefe du mur de feedback pour chaque atelier puis débriefe des retours plus globaux (la journée, l'équipe... complètement ouvert en fait!)
  • Un ROTI de la journée pour finir ( des 4 et des 5 : ça fait plaisir!)


Durant cette journée, j'ai pris quelques 222 photos - très utiles pour se remémorer l'ambiance et les attitudes - et des vidéos lors de la présentation des travaux des différentes équipes constituées pour les jeux  - très riches d'enseignement également car le discours est également riche en enseignement.
Pour chaque équipe de travail et chaque atelier il y avait un observateur/facilitateur, également membre de l'équipe. Mon rôle était celui de facilitateur, animateur des jeux, et time-keeper.

Bilan en images

Bon assez de Bla Bla, voici quelques unes des photos réalisées, c'est parlant:

Rétrospective : introduction

Les valeurs du sport comme métaphore

Atelier Product Box

Product Box : L'organisation des thèmes

En pleine création

Des échanges animés

La "vente" de la "Box"

Les quatre box produites

Le mur de feedback s'alimente par atelier

Un repas tous ensemble c'est ^lus convivial

Remember the future : la timeline en cours de construction 1

Remember the future : la timeline en cours de construction 2

Remember the future : la timeline expliquée au reste de l'équipe

Le Speed Boat : tous ensemble

Le mur de feedback se rempli

La mascotte échouée prés du bâteau de l'équipe

Speed Boad : Le débriefe des ancres et des vents

En conclusion : 

Une journée ou tous les participants 

  • ont été très actifs, 
  • ont passé une journée agréable, 
  • ont eu le sentiment d'être une seule et même équipe
  • ont partagé leurs réussites et leurs problèmes


Beaucoup de matière a été récoltée et en plus d'un compte rendu des ateliers, nous avons synthétisé une vingtaine de problèmes. Ces problèmes ont été ordonnés par importance et valeur - merci Fibonacci - ce qui nous a permis de définir les 3 problèmes les plus importants et pas trop complexes à traiter en priorité.

Parmi ces problèmes, le premier est le manque de vision commune et partagé des missions de l'équipe et de son périmètre. 
Une fois réglé il est fort possible que d'autres problèmes disparaissent d'eux-même.


mercredi 4 septembre 2013

Management visuel et amélioration continue

L'organisation des POs

En début d'année je vous publiais un post sur notre mise en oeuvre de Kanban au sein de notre équipe de "PO". Notre objectif était de mieux suivre notre flux de production des US afin d'être en mesure d'alimenter convenablement nos équipes Scrum, de visualiser les goulets d'étranglement et d'améliorer la communication au sein de l'équipe.

Aux mêlées des POs participent : 

  • Les POs - 8 personnes,
  • Les Chefs de Projet - 5 personnes : exerçant parfois le rôle de PO,
  • Les Coordinateurs Fonctionnel - 2 personnes : identifient les impacts entre projet et coordonnent les évolutions fonctionnelles par version (vision macro),
  • Les experts métier/testeurs - 2 personnes : aident les POs à la conception fonctionnelle et renforcent leur capacité de test de fin de Sprint. Leur feedback sur la logique métier et le fonctionnel est très précieux,
  • Un représentant de l'équipe de graphistes / intégrateurs Web,
  • Deux architectes techniques

Lors de nos mêlées, nous tenons le 1/4 d'heure sans dépassement, il arrive même qu'elle soit finie avant la fin du temps. Personnellement, je trouve que nous sommes trop nombreux et que l'on n'optimise pas la communication, mais en même temps cela fonctionne et globalement nous en tirons tous des éléments importants. En attendant que nous trouvions un meilleur mode de fonctionnement, nous continuerons donc nos mêlées quotidiennes à 20 personnes... 


Après 6 mois d'utilisation, nous avons abandonné notre tableau de suivi de la production des US : le suivi au niveau des US trop fin entre la livraison de la dernière version et le lancement des devs de la nouvelle version,

  •  les équipes surchargées n'ont plus pris le temps de mettre à jour le tableau trop d'info tue l'info : le tableau devenais illisible tellement il comprenait d'US (nb US >100)
  • pour chaque équipe Lors d'une rétrospective nous avons donc décidé d'abandonner ce format pour un autre, mieux centré sur nos problématiques. 

Nous avons mis en oeuvre un tableau affichant la roadmap des projets permettant visualiser les dépendances qui peuvent exister entre projet. 

L'objectif est donc de pouvoir augmenter notre réactivité lors des changements de planification et ainsi de mieux maîtriser notre gestion du périmètre. La roadmap est enrichie de différentes affiches sur sa gauche : Fiche de vision A3 Toyota du projet, tableau de présence/absence....






Pour l'instant tout le monde a mis en oeuvre ces changements sur son projet et nous allons suivre cette amélioration de près afin d'en mesurer les gains et les difficultés rencontrées. 

Reste à faire en sorte que nos mêlées se focalisent aussi sur ces points.




mardi 22 janvier 2013

Une mise en oeuvre de Kanban pour l'IT - itération 2

La première version de notre tableau est terminée. Depuis deux semaines, nous avons commencé la mise en oeuvre :


  • Initialisation de la backlog des Features
  • Harmonisation des backlogs produit 
  • Mêlées quotidiennes façon "Scrum"
  • Refactoring du tableau Kanban des activités
  • Tableau des problèmes et actions pour le facilitateur
  • Initialisation des burnups d'activités par projet, et consolidation des résultats



Ce que nous ne faisons pas encore :

  • Tracer les dates d'entrée / sortie dans notre système
  • Suivre les indicateurs induits par les mesures de temps de passage
  • Limiter le WIP (travail en cours par activité)


Voici nos tableaux :

Tableau des problèmes / actions du facilitateur

Tableau des Features pour l'établissement de la Roadmap produit



tableaux de suivi de la production des US

BurnUp d'activité des tableaux Kanban et BurnUp de produit des équipes Scrum 








jeudi 20 décembre 2012

Une mise en oeuvre de Kanban pour l'IT - itération 1


Après un travail de quelques semaines (en délais, pas en charge), nous avons identifié le fonctionnement d'une équipe d'une dizaine de Product Owner alimentant plusieurs équipes Scrum (25 personnes) pour la réalisation de l'espace Internet de l'entreprise.

Ce travail a permis de définir les différentes phases du processus actuel permettant de créer la Backlog Produit utilisée par les équipes Scrum, et d'identifier les points d'amélioration qui pourraient amener plus d'agilité.

Un des objectifs est de forcer les Product Owners à ne pas travailler un cahier des charges en stock avant de le donner à fabriquer, mais plutôt de partir d'une "Vision Produit" avec la liste des fonctionnalités.

Cette liste est ordonnée en prenant en compte le ROI (la valeur métier divisée par la complexité de réalisation).

Les fonctionnalités seront ensuite détaillées par un travail sur les exigences, puis détaillées en User Stories.


A l'issue de cette première phase, nous avons conçu deux tableaux Kanban qui se suivent :




Le premier tableau (en jaune) correspond à des "features" Scrum (MMF - Minimal Marketable Features - en Kanban).


Le second tableau  (en bleu) correspond au redécoupage des "features" Scrum en "User Story".
 

En début d'année nous commencerons la mise en oeuvre de la méthode sur deux projets pilotes avant de généraliser la démarche à l'ensemble des projets.

Les tableaux comprennent la définition de Terminé pour chaque étape du processus ainsi qu'une limite du travail en cours (WIP - Work In Progress) dans chaque phase du processus.

Il nous reste encore à définir les cadences d'injection des éléments, à mettre en place les mêlées quotidiennes, à choisir une fréquence de réunion pour faire le point sur le fonctionnement de l'équipe et d'améliorer le processus.

La suite dans de prochains posts....

mardi 18 septembre 2012

Les chaises non musicales

Le support d'animation de la session :

Dans la salle, nous avons placé autant de chaises que de participants, plus une. L'objectif pour l'équipe était d'empêcher l'organisateur de prendre place sur la chaise vide.





Voici le tableau des résultats présentant les temps de chaque itération :




Les détails du jeu sont décris dans la présentation.
Le jeu s'est déroulé en plusieurs itérations, et l'équipe disposait de 10 minutes entre chaque itération afin de s'auto-organiser
Afin de capitaliser le déroulement du jeu, nous avions deux observateurs, Cécile et Rémy.
Cécile a pris des notes, des photos et des vidéos. Voici son compte rendu :
  • It 1 : discussion stratégie : max 5 intervenants :
    • les idées fusent mais pas de prises de décision de celles qu’on retient
    • 1 minute restante annoncée : pas de stratégie « validée »
    • => Résultat : 6 s
  • It 2 : quasi les mêmes intervenants :
    • toujours des idées qui fusent dont certaines mêmes pas entendues
    • timing demandé à Olivier
    • départ du jeu avec une nouvelle stratégie «votée » en dead line
    • pas de communication dans le jeu
    • => Résultat : 7.7 s
      vidéo réalisée)
  • It 3 :
    • bonne écoute
    • décision d’un observateur
    • nouvelle stratégie
    • pas de gestion du timing : toujours Olivier qui les informe
    • => Résultat : 1.2 s
  • It 4 :
    • les groupes de discussion se forment => plus du tout d’écoute
    • personne ne pense à l’observateur
    • recherche d‘amélioration de la stratégie : 2 rôles mis en place (cercle intérieur et extérieur)
    • pas de gestion du timing
    • => Résultat : 6 s
  • It 5 :
    • l’observateur est écouté
    • Olivier propose la communication dans le jeu => idée écartée une nouvelle fois
    • recherche d‘amélioration de la stratégie
    • toujours les groupes chacuns dans leurs coins
    • proposition d’un test, mais non réalisé
    • pas de gestion du timing
    • en dead line : on fait quoi ?
    • => Résultat 13.5
  • It 6 :
    • idem précédemment
    • un intervenant (Rodolphe) annonce qu’il y a plusieurs conversations !
    • => 10 s
Rémy a observé les comportements et les a classé en "comportements adaptés (CA)" et "comportements inadaptés (CI)"

Qu'avons nous appris?

  • La simplicité
  • La confiance
  • Le travail d'équipe
  • les itérations
  • L'auto organisation
  • La rétrospective
  • L'esprit d'équipe
  • Le Time Boxing
Evaluation ROTI, 16 votes pour 19 participants

mardi 4 septembre 2012

Mêlée : retour aux fondamentaux

Notre équipe accueil deux nouveaux équipiers, et bientôt nous serons 7.

Lors de la dernière rétrospective de Sprint nous avons choisi comme amélioration de revenir aux fondamentaux de la mêlée : 

  1. qu'ai-je fait hier 
  2. quels problème ai-je rencontré 
  3. que vais-je faire



  • A la question "qu'ai-je fait hier", il convient d'indiquer le reste à faire sur les tâches non terminées.
  • A la question  "quels problème ai-je rencontré" il est important de ne rien dire si il n'y en a pas eu. Si on en a eu, il ne faut pas rentrer dans les détails, il seront discutés hors mêlée. Le but est de trouver le ou les interlocuteurs au sein de l'équipe qui qui nous aiderons à débloquer la situation.
  • A la question "que vais-je faire", simplement prendre et lire à haute voix les post-its qui correspondent aux travaux que vous souhaitez/devez faire aujourd'hui.  


Si on veux garder l'attention de toute l'équipe et encore plus des nouveaux arrivants tout en ne dépassant le 1/4h, il ne faut pas s'étendre sur les sujets. Nous avons la possibilité de détailler au PO ou membres les plus concernés plus tard dans la journée. Cela peut éventuellement donner lieu à la création  d'une tâche non planifiée que l'on ajoute pendant la mêlée. 

Premier bilan à 6 équipiers nous avons traité toutes nos activités en 9 minutes. Si on continue comme ça, tout ira bien.

Notre tableau de suivi après la mêlée de ce matin :

Tableau de suivi des tâches, Sprint 44

vendredi 27 juillet 2012

Manager, Leader, Coach, qui suis-je?

Je vous propose la lecture de l'article de Philippe Launay sur le site du Scrum Wine Bordelais.

Philippe est Team Coordinator chez AGFA Healthcare, il est l'initiateur et le principal animateur de Scrum Wine Bordelais, membre de la Scrum Alliance, CSPO (Certified Scrum Product Owner) et CSP (Certified Scrum Professional)


Un retour d'expérience très intéressant :
https://sites.google.com/site/sugbordeaux/project-updates/managerleadercoachquisuis-je

vendredi 29 juin 2012

Mission de coaching

Depuis début Mai j'ai commencé une mission de coaching agile chez un nouveau client.

A fin juin, après une formation à Scrum, et plusieurs journées de collaboration nous avons mis en place l'organisation du projet sur des voies agiles. Tout n'est pas parfait, mais nous progressons.

Un wiki projet pour travailler et valider les travaux suivants

  • définition des exigences avec le métier
  • maquettes d'écran conçues par un ergonome
  • scénarios de navigation
  • afficher la roadmap et le release plan
  • centraliser les documents projet


Une Backlog Produit a été commencée bien avant mon arrivée pour travailler avec le métier. Elle est déjà trop détaillée mais nous ferons avec.

Un tableau Kanban pour

  • suivre l'avancement de l'expression des exigences 
  • suivre les travaux et de recette
  • mesurer les temps de passage des fonctionnalités dans le wokflow
  • fluidifier les travaux du Product Owner, de la MOA et des utilisateurs
  • s'assurer que l'équipe de développement ait assez de User Stories prêtes à chaque Sprint

Une liste des problèmes et des urgences
  • pour connaitre les problèmes
  • suivre leur résolution
Tableau de suivi Kanban et de suivi des erreurs (initialisé)
Graphique de suivi du tableau Kanban (projection)

BurnUp de Produit et vélocité de l'équipe Scrum (projection)



Le Sprint 0 est prévu pour le mois d’août,
En septembre, après les vacances (si tout va bien ...) nous commencerons les premiers Sprints


mercredi 25 avril 2012

Vision Box pour les Scrum Café


Une vision Box pour les Scrum Cafés organisés chez nos clients

La boite est réutilisable à chaque session, il suffit de changer un post-it!



En la réalisant conjointement avec des Personas, je me suis posé de nouvelles questions. L'exercice est très intéressant et les membres de l'équipe ont fait part de leur remarques de suite.

Cette technique issue de l'Agile-UX (Agile User Experience) tend à capitaliser les expériences utilisateurs. A vrai dire, je voulais commencer par les Personas, mais je me suis rendu compte qu'il serait plus profitable de les réaliser en même temps.

Une fois la box et un premier Persona terminée et c'est comme un déclic : on comprend mieux les spécificités du produit, et c'est tellement facile d'en parler, l'utilisateur est comme présent pour jouer son rôle...

Les Personas donnent vie aux utilisateurs et sont un puissant outil de communication dans l'entreprise. De même pour la "Vision Box" vous incite à mettre en valeur ce qui va attirer vos utilisateurs, ce qui va leur donner confiance dans le produit et qui fera la différence par rapport aux autres.

Je vous recommande la lecture des blogs de Jean-Claude Grosjean :


lundi 12 septembre 2011

L'amélioration continue et le radiateur d'informations

Un démarrage rapide :
Lorsque nous avons commencé à travailler en Scrum, nous nous sommes équipés du minimum vital :
Un tableau des tâches à base de paper-board et de gros scotch marron

Notre premier radiateur d'informations / tableau des tâches


Progressivement, nous avons amélioré (merci à Pierre), nous sommes passés au tableau aimanté avec post-its imprimés. La(es) Backlog(s) sous Excel ayant évolué aussi.

Radiateur d'informations :
Petit à petit on a amélioré la présentation et la fabrication des post-its
 
 Tâches et Stories en cours + BurnDown et BurnUp


Les tâches et Stories en cours + les indicateurs de base

Dernière amélioration visible : une gestion des risques agile / indice de confiance

Burndown, Burnup et indice de confiance Scrum

Estimation en points VS heures/jours, vélocité de l'équipe

La vélocité en Scrum : 


La vélocité représente la capacité d'une équipe Scrum à terminer des Stories (histoires). Cette capacité est estimé en points et non en heures ou jours.


Estimer en points VS heures / jours :

Lorsque l'on estime une fonctionnalité en jours on se retrouve forcément face à un dilemene. Il nous faut prendre en compte qui réalisera la tâche, car dans une équipe on peut avoir des experts qui réaliseront les tâches rapidement, alors qu'un débutant ou un nouveau dans l'équipe mettra plus de temps.

De la même manière, une même histoire simple (ex. :un écran de synthèse) sera plus longue à réaliser en début de projet qu'à la fin. Pour autant sa complexité (l'effrot nécessaire) sera la même. 

Retour d'expérience :

Ce n'est sans doute qu'un sentiment personnel, mais il m'est beaucoup plus naturel et simple d'estimer en points de complexité que d'estimer en jours comme j'ai eu à le faire dans les projets précédents. Cela est d'autant plus facile que cette estimation est collégiale, et qu'elle se fait à partir d'une suite (type Fibonacci).

samedi 9 juillet 2011

Gestion des risques sur les User Stories

Le Niko-Niko sert à mesurer l'humeur de l'équipe après chaque journée de travail. En principe des pastilles de couleur sont placées sur le radiateur d'informations (tableau des tâches) de l'équipe.
Chacun exprime anonymement s'il a passé une journée agréable, difficile ou exécrable. Je me suis inspiré de cette technique pour proposer une amélioration au cours du dernier Sprint (qui fini mardi) :
Contexte :
Lors de la rétrospective de notre dernier Sprint, l'un des équipiers à demandé à ce que nous enrichissions notre backlog d'un champ supplémentaire afin d'identifier les risques pour chaque User Story.
J'ai alors fait remarqué que nos User Stories n'étaient déjà pas assez correctement décrites, et les critères d'acceptation plutôt vagues (plutôt exprimés en terme de format de document que contenu), et que nos réunions de lancement de Sprint avaient de plus en plus tendance à s'allonger (depuis l'arrivée de deux nouveaux équipiers et le départ d'un autre).
J'ai alors proposé de s'inspirer du Niko-Niko afin que chacun s'exprime avant ou après la mêlée quotienne en posant une pastille de couleur sur les Stories pour lesquelles il perçoit un risque.
En faisant cela nous avons un double indicateur :
  • de confiance sur le Sprint, valorisé en points Story
    • ->un graphe est produit à coté du BrunUp et du BurnDown
    • Indicateur de confiance sur la tenue du Sprint
  • de confiance sur chaque Story, qui porte le poids de chaque vote individuel
    • -> un graphe est produit pour chaque Story indiquant le nombre de vote
    Radiateur d'informations - indicateurs de risque
Dès le premier jour, l'équipe s'est approprié l'outil, et un rapide débrief avec le Product Owner ou les équipiers (en son absence) après la mêlée nous a permis de prendre des mesures afin de réduire le risque. Au cours du Sprint (le 25ème), nous avons placé plusieurs pastilles sur une Story (pas encore ouverte), ce qui a motivé le PO - convaincu - à la retirer sans avoir a argumenter plus.
Pour l'instant on trouve l'indicateur
  • facile à utiliser,
  • déclencheur d'échanges que nous n'avions avant,
  • déclencheur de décisions importantes pour la tenue des objectifs des Sprints
Pour plus de détails sur la technique du Niko-Niko, je vous invite à consulter les sites suivants :

vendredi 8 juillet 2011

Être agile, c'est quoi?

Scrum et l'agilité :

Vous trouverez sur mon site un retour d'expérience sur Scrum, la méthode agile la plus connue en matière de
développement logiciel; une méthode:
  • qui organise le travail équipe
  • qui est une adaptation du Lean Management
  • qui favorise la collaboration au sein de l'équipe, ce qui permet d'avoir régulièrement et fréquement
    un logiciel qui fonctionne

Comment nous pratiquons Scrum ?

Contexte et dérogations à la méthode :
  • Nous pratiquons Scrum depuis un an et demi, chez le client, mais ne développons de logiciel
  • Nous décrivons des processus, apportons de l'assistance et de l'expertise aux différents projets
    (nous fabiquons tout de même des "artefact" et pouvons planifier nos travaux, mais pas en release)
  • Nous donnons des formations aux équipes de développement sur les outils et frameworks "maison";
  • Depuis peu, on forme aussi à Scrum, et c'est moi qui m'en charge - d'ou le site aussi un peu ;-)
  • Nous sommes une équipe mixte composée d'internes (client) et de prestataires (l'égalité entre
    équipiers en souffre, pas toujours évident à gérer)
  • Nous n'avons pas de Vrai Scrum Master (un et un seul). Nous sommes tous impliqués dans l'application de la méthode, nous participons tous à la production. Celà nous pose des soucis :
    • le rôle partagé mais pas clairement identifié
    • il est difficile d'être juge et partie, mais avec la plus forte des volonté
    • les intérêt du client, de l'équipe, et de notre société (Société de Services Informatiques) ne
      sont pas toujours en adéquation
  • Nous avons par contre un seul et unique Product Owner qui alimente et priorise sa Backlog et
    ça c'est bien
  • Nous avons des Sprint à durée fixe : 3 semainesChaque Sprint commence par un lancement de
    Sprint et la revue du Backlog est faite avant
  • Nous terminons toujours par un bilan du Sprint puis une rétrospective
  • Nous essayons de TimeBoxer le plus possible, mais on doit s'améliorer beaucoup en la matière
  • Toutes nos Stories d'un Sprint sont estimées par l'équipe (sans intervention intempestive du PO)
  • Toutes nos Stories sont découpées en tâches de réalisation, estimées en heure
  • Nous mettons à jour quotidiennement le BurnDown affiché dans le bureau Scrum

En quoi sommes nous agiles?

  • Nous concentrons nos efforts sur ce qui a le plus d'importance pour le client
  • Nous planifions nos travaux et nos tâches
  • Nous suivons quotidiennement nos indicateurs et les analysons lorsqu'ils semblent "étrange"
  • Nous améliorons notre manière de travailler à chaque fin d'itération (toutes les 3 semaines)
  • Nous échangeons beaucoup par oral pour clarifier certaines User Stories (ou tâches) avec le PO ou le
    reste de l'équipe