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
  

• 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

  

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 :

http://emmanuelchenu.blogspot.com/2009/02/niko-niko.html.

http://www.cascrum.dibus.org/2011/03/29/projet-marguerite-le-niko-niko/

Ê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
  

2 formations en Juin et 2 en Juillet 2011

2 Formations en Juin :

• la première session avec 11 personnes
• la seconde session avec 8 personnes

2 Formations début Juillet :

• une session avec 8 personnes les 4 et 5 Juillet (à Gradignan - Proximité Bordeaux -33)
• une session avec 10 personnes les 6 et 7 Juillet (à Gradignan - Proximité Bordeaux -33)

Pour chaque session dispensée :

- première journée théorique (rôles, chronologie et planification en Scrum, découpage du produit) et quelques exercices sur un cas d'école
- le second jour est consacré à dérouler un cycle Scrum sur les projets propres aux personnes formée.

Bilan : 37 personnes

-> Le public a beaucoup d'attentes et les questions pratiques n'arrêtent pas!
-> La dernière session a été extra :

• J'avais trois Product Owner, un Scrum Master, des équipiers et quelques managers; j'ai donc créé trois groupes de travail avec un PO dans chaque.
• Les POs ont put s'exercer à leur rôle avec de vrais équipiers
• Le Scrum Master a pu mettre en œuvre et éprouver son rôle

-> A la fin de la chaque journée de formation je leur fait faire une rétrospective afin de trouver des améliorations à la formation et pour identifier ce qui leur plut : ça marche bien!

-> Ils ont aimé :

• la grande part de pratique accordée la seconde journée
• mon retour d'expérience et les conseils pratiques

-> ils n'ont pas aimé :

• les anglicismes

-> je dois améliorer :

• la présentation du cas pratique "d'école" jugée trop sommaire
  • Je compte leur fournir un dossier de conception générale
• malgré les relectures, quelques fautes d'othographe restent dans le support théorique
• la présentation du niveau de détail requis pour les User Stories
• idem pour les critères d'acceptation

-> A part les pratiques qui restent à consolider, ils ont retenu l'essentiel : les valeurs de l'agilité et les principes (Manifeste Agile)