Formation Scrum des 21 et 22 Septembre 2011

Dernière formation planifiée à ce jour :

• 8 personnes étaient présentes,
• 2 products owners identifiés, 
• 1 chef de projet qui se voit bien devenir product owner
• Les autres personnes avaient besoin de connaitre et comprendre la méthode afin de pouvoir travailler avec des équipes Scrum, des stakeholders en somme.

Pour cette formation, je me suis inspiré du Scrum Café Bordelais : j'ai introduit le rôle d'observateur dans les ateliers. 

Les règles du jeux, décliné ensuite au niveau des Users Stories

Lorsque le product owner présente son projet (vision) et cherche à identifier des features, puis des user stories il était intéressant de voir la pertinence des questions, et le niveau de compréhension des participants qui s'affine. 
Il faut rester vigilant à ce que les discussions servent l'objectif, sinon, les participants racontent volontiers leur vie. Une fois cadré, en 1/4 d'heure, le jeux produit ses effets.  On recommence ensuite avec l'identification des premières user stories à planifier dans le(s) premier(s) Sprint(s).

Le résultat : les Backlogs

Je doute qu'un cahier des charges ou autre expression de besoin puisse être aussi efficace ( rapport temps passé/compréhension). 

Il est vrai que ces documents servent surtout à fixer les responsabilités une fois que les premiers problèmes font surface...

Scrum Café bordelais du 14 Septembre 2011

Une 50aine de participants réunis dans un amphi de l'EPSI Bordeaux,

plusieurs Serious Games intéressants.

Pour entamer la session, Philippe Launay nous a donné des précisions sur la dernière mouture de Scrum (Juillet 2011).

Rien de révolutionnaire, mais quelques précisions intéressantes. Par exemple sur le contenu de la Backlog qui devient ordonnée et non pas priorisée. Le plan de release a également disparu...

Pour en savoir plus, je vous renvoie vers le site de Fabrice Aimetti "Agilarium.fr"

NDLR : dans le cas d'une réécriture iso-fonctionnelle, tout (ou presque) est en effet aussi important, mais il faut bien commencer quelque part.

Je retiens surtout pour l'animation des ateliers la présence d'un observateur par équipe. Lorsque c'est bien fait, l'observateur apporte beaucoup de choses sur le déroulement de l'atelier et sur l' "auto-organisation" des équipes.

La session a duré un peu en longueur, succès oblige!

Bon je reviens à la prochaine session, j'ai une bonne marge de progression...

Scrum Café n°1 - organisé chez notre client

Le 15 Septembre dernier (de 12h30 à 14h00), nous organisions notre premier Scrum Café chez notre client. Nous étions une vingtaine de personnes.

Après avoir présenté notre équipe et fait un bilan sur les formations Scrum dispensées, nous avons lancé un premier atelier sur "le premier projet Scrum".

Voici ce qui a émergé des deux groupes :

Groupe 1 : 4 objectifs ordonnés :

• Améliorer la motivation des équipes
• Auto Organisation,
• Travail en binôme,
• Moins de ressources critiques,
• Faciliter l’intégration,
• Implication du client et priorisation des besoins (client)
• Simplification du process existant et le rendre plus efficace
• Améliorer la qualité des livrables sur un périmètre restreint
• un frein à Scrum
• Contraintes opérationnelles
• un élément factuel d’amélioration apporté par Scrum
• Communication au niveau de l’équipe

Groupe 2 : 4 objectifs

• Rapprochement entre l’équipe et le client
• Facilité de communication intra équipe
• Mise en lumière rapide des problèmes
• Amélioration de la qualité

En guise de conclusion, quelques points supplémentaires :

• L’importance de la démo de fin de Sprint qui incite les développeurs a faire de réels tests fonctionnels de l’application (augmentation du nombre de tests)
• La mêlée quotidienne comme élément crucial de communication au sein de l’équipe
• La Backlog de Sprint qui permet un partage des objectifs, une vision claire de ce qu’il y a à faire.
• Création d’un vrai sentiment appartenance à l’équipe.

(...) à rapprocher des 4 valeurs de l'agilité :

1. L’équipe :
• « Les individus et leurs interactions plus que les processus et les outils »
2. L’application :
• « Des logiciels opérationnels plus qu’une documentation exhaustive »
3. La collaboration :
• « La collaboration avec les clients plus que la négociation contractuelle »
4. L'acceptation du changement :
• « L’adaptation au changement plus que le suivi d’un plan »

En fin, nous avons fait une rétrospective afin de dégager les améliorations à apporter pour la prochaine réunion le 6 Octobre prochain :

• Tout le monde n'aime pas le café : prévoir du thé vert ! (à la menthe)
• Le démarrage a été difficile : respecter le time-boxing de la session et démarrer à l'heure
• Le travail en groupe était laborieux : pour les ateliers, réduire la taille de groupes,
• La salle manquait de chaises : prévoir une salle plus grande si 20 personnes,
• Après les ateliers, il maquait une conclusion : prévoir de confronter les résultats des ateliers produits par chaque groupe,

L'humour à Gilles

Super Agile fait ce qu'il peut, mais il n'y a pas de magie!

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

Formation Scrum des 7 et 8 Septembre 2011

La salle de formation est prête :

• Les Post-it géant sont collés sur les murs de la salle pour matérialiser le radiateur d'information,

• Le PC et le rétroprojecteur sont allumés et le support de formation est affiché,
• Les support papier sont distribués,
• ... il ne reste plus que le public.

Démarrage prévu à 9h30...
    => Premier objectif, : caler les horaires, le restaurant et se présenter
    => Ensuite on enchaine avec une réflexion sur l'agilité avec un exercice, puis un tour d'horizon sur Scrum.

9h35 : tout le monde est présent et la formation débute.
17h45 : fin de la première journée : un quart d'heure de retard sur le planning, c'est parfait!



Reprise le 8/09 prévue à 9h15.
A 9h20, 5 personnes présentes sur 9, on commencera à 9h30.

9h35, tout le mode est là.
On commence par une restitution des points vus la veille :

• tous les points majeurs ont été restitués : objectif atteint!

La journée continu en déroulant un sprint complet :

• Revue de Backlog, lancement de Sprint, une mêlée, un bilan de Sprint et une rétrospective.

 On continue avec la présentation du fameux "Sprint 0" en faisant le parallèle avec les phases de cadrage et de lancement du projet au sein de l'entreprise.

10h15 Pause
10h30 reprise
11h00 : exercice concret, c'est le début de notre pseudo Sprint

• Deux équipes de 4
• Chaque équipe a amené un cahier des charge de projet sur lequel ils ont travaillé et identifie des features puis des user Stories
• L'objectif étant d'aliment la Backlog produit, et de définir la roadmap et un release planning.

En fin de journée, le radiateur d'informations est rempli de features, de stories et de tâches (a faire, en cours ou terminées).

Je termine la formation en évoquant le Scrum de Scrum et la synchronisation entre les équipes, qu'elles soient Scrum ou pas. Sur ce sujet, je reste prudent, la mise en œuvre est assez récente ici et je manque d'expérience concrète et réussie pour dominer le sujet. Ça ne saurait tarder j'espère!

Scrum Café

Nous organisons un premier "Scrum Café" chez notre client 
(à Gradignan - Proximité Bordeaux -33)

Le but est de

• développer et maintenir un communauté Scrum chez notre client
• favoriser et promouvoir l'agilité dans l'entreprise
• échanger sur les pratiques Scrum et agiles 

Déroulement de la session :

• présentation des participants
• présentation sur le thème "comment choisir le premier projet Scrum"
• travail en groupe sur ce thème (Timeboxé et par équipes)
• en quoi notre projet est-il un bon candidat pour Scrum?
• travail en priority poker pour classer les idées dégagées (si on a le temps)
• Restitution / partage
• Planification des sessions suivantes
• Rétrospective de la séance

Formation des 20 et 21 Juillet 2011

(à Gradignan - Proximité Bordeaux -33)

8 Personnes formées :

• équipiers,
• product owner,
• stakeholders

Bilan de la formation, ressenti par les personnes formées

Points forts :

• Mise en pratique de la méthode aux différentes étapes
• Mise en pratique + proactivité du groupe
• Maîtrise du sujet et expérience du formateur
• Pratique et mise en application des concepts abordés tout au long de la formation + connaissance pointue du formateur qui a répondu aux questions posées
• Formation pratique avec mise en place rapide si nécessaire

Les points faibles:

• Partie théorique trop longue
• On aborde à peine les relations équipe Scrum – le reste du monde (3ème jour de formation souhaité)

Mon point de vue :

• Groupe motivé
• Différents profils Scrum : intéressant
• Double objectif :
  • former à les inscrits à Scrum
  • former un collègue Scrum et la dispense de la formation Scrum
• Je n'ai pas sût contenir le flots de question, et j'ai pris du retard la première journée
• J'ai rattrapé le retard en seconde journée
• A améliorer :
  • la maîtrise du timing,
  • placer plus de pratique dans la première journée trop théorique
  • livrer un kit de démarrage avec Backlog produit et Backlog de Sprint au format Excel (graphiques compris)

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)