Étiquette : Agilité

Scrum : retour aux fondamentaux

Retours sur la méthode Scrum après 6 ans d’utilisation

Les 10 et 11 Avril se déroulait la quatrième édition du ScrumDay. L’occasion pour nous de découvrir pas mal de nouveautés mais également de revenir par certains aspects sur les notions essentielles de l’agilité.

La keynote d’ouverture était assurée par Alistair Cockburn, signataire et co-auteur du manifeste agile. Les slides de la keynote se trouvent ici.

Il est revenu sur les 4 valeurs du manifeste et leur trop (souvent) mauvaises interprétations puis a introduit un concept issu de l’Aïkido qui décrit les 3 étapes de l’apprentissage :

  • Shu (守:しゅ?, « protéger », « obéïr ») — sagesse traditionnelle – apprendre les fondamentaux
  • Ha (破:は?, « se détacher », « digresser ») — casser avec la tradition — trouver les exceptions à la sagesse traditionnelle, trouver de nouvelles approches
  • Ri (離:り?, « quitter », « se séparer ») — transcender — il n’y a pas de technique ou de sagesse traditionnelle, tous les mouvements sont permis

(source wikipedia)

Ce concept est pour lui réplicable quelque soit le domaine d’application et en particulier l’agilité.

Il a ensuite zoomé sur Scrum et ce qu’il nomme le coeur de Scrum :

  1. Livrer à chaque sprint
  2. Laisser l’équipe décider
  3. Inspecter et s’adapter tous les jours, et à chaque sprint
  4. Un Scrum Master a du temps pour lever les obstacles
  5. Le métier ne s’exprime qu’à travers une seule voix (Product Owner)

Mais le plus intéressant est qu’il considère « tout le reste » comme « barnacles » (parasite) ou pire rumeur et ouï-dire :

  • Burn-down charts
  • Kanban (Not-started | Started | Done) boards
  • ScrumMaster is / is not the project manager / product owner / tech lead
  • Product Owner is / isn’t invited to the dailies
  • The “3 questions” at the daily stand-up
  • User stories
  • Planning Poker
  • Fibonacci numbers / hours / story points

Il ne veut pas dire par là que l’on doit jeter toutes ces pratiques à la poubelle mais bien qu’elles doivent être choisi par l’équipe elle même si celle-ci considère que telle ou telle pratique apporte un plus aux 5 points points qui constituent le coeur de Scrum.

Et nous dans tout ça ?

Cela fait presque 6 ans que nous « utilisons » Scrum. Nous avons mis en place toutes ces pratiques et plus, puis en avons abandonné car l’équipe ne les trouvait pas/plus adaptées :

  • Pas adaptée comme par exemple le planning poker : nous trouvions que cette pratique était trop fastidieuse et pas assez productive par rapport à la taille de notre backlog. Avec cette pratique, nous estimions environ 10 user stories en une heure alors que nous en avions 100 à chiffrer. Nous avons depuis mis en place une autre pratique qui nous correspond plus.
  • Plus adapté comme par exemple la revue de backlog : dans les premiers mois/années nous faisions une revue de backlog périodique avec l’équipe qui permettait à notre PO d’affiner les User Stories grâce au commentaires de l’équipe et de débuter une conception de haut niveau. L’expérience (culture) aidant, nous n’avons plus eu besoin de cette revue et si certains points ne sont pas clairs, nous avons la faculté de donner des réponses « à la volée » lors des démarrages de sprint (connaissance partagée).

Depuis quelques mois nous avons débuté de nouveaux produits et patatra… Nous nous sommes pris les pieds dans le tapis, sans vraiment s’en rendre compte. Nous avons adopté les mêmes pratiques et réflexes (nature) que pour notre produit principal, mais en omettant quelques détails :

  • Nouveautés produits (fonctionnel et conception)
  • Manque d’expérience de l’équipe : pas en terme d’années mais sur les produits, les rôles (PO) et l’architecture

Ces problèmes sont, bien entendu, remontés lors des rétrospectives de sprint, mais le diagnostic que nous en avons fait était assez parcellaire.

Un petit détour par la Coach Clinic du ScrumDay (merci à Fabrice Aimetti@fabriceaimetti) suite à la keynote, quelques échanges de tweets, et la lumière fut : le contexte dans lequel nous évoluons n’est plus le même, nous devons (ré)apprendre, (re)pratiquer (Shu) pour ensuite progresser dans le Ha et le Ri. L’équipe va donc devoir se réapproprier certaines pratiques qui lui permettront sur ces nouvelles bases d’acquérir l’expérience nécessaire à son évolution.

En conclusion et avec une vision plus « aérienne », nous devons constamment évoluer dans une spirale dynamique : pratique, culture, nature, pratique, culture, nature, … afin de nous permettre de revenir aux fondamentaux lorsque c’est nécessaire pour ensuite transcender et transgresser l’existant pour toujours être en mouvement. (Merci à Pablo Pernot @pablopernot)

« Notre nature est notre culture, et notre culture est notre nature » Edgar Morin. (Pablo, La Horde Agile)

eXtreme Quotation à l’Agile Tour Montpellier

Retours sur la session eXtreme Quotation à l’Agile Tour Montpellier

J’ai assisté à la session eXtreme Quotation animée par Guillaume Duquesnay (@duquesnay) et Jonathan Scher (@jonathan_scher) à l’Agile Tour Montpellier.

Je profite de ce billet pour remercier les organisateurs et les sponsors pour cette journée riche et bien remplie et le super accueil réservé aux participants.

Revenons à nos moutons…

J’étais un peu septique en allant à cet atelier. Le titre était vendeur, m’attirait même. J’y allais surtout car le Planning Poker tel que nous le pratiquons me semble lourd et je cherchais plutôt quelques astuces pour l’améliorer…

Mais là on nous promettait de « chiffrer 90 stories en moins de 20 minutes  » !

Vous trouverez une description détaillée de l’atelier ici et ici (la forme présentée à #atmtp utilisait les tailles de T-Shirt).

Au cours de l’atelier nous avons estimé le backlog de création d’un service de messagerie tel que Gmail.
Nous étions répartis en deux groupes d’environ 20 à 25 personnes (la taille des groupes mettait également à mal l’atelier). Au final nous avons bien estimé environ 50 stories en 20 minutes et malgré la méconnaissance du projet et du contexte général, la répartition s’est faite assez facilement.
Le résultat est donc vraiment positif.

Je pense que nous allons tester cet atelier à la place de notre prochain planning poker ; nous perdrons un peu de précisions sur nos estimations en point mais ce n’est en réalité pas très grave :

  • à ce moment là des estimations nous ne recherchons pas un chiffrage à l’heure près,
  • nous gagnerons beaucoup de temps de l’équipe et pourrons de ce fait en faire plus souvent, notamment pour décomposer et réestimer les user stories atteignant les tailles XL ou XXL,
  • cela permettra de créer une dynamique d’équipe que nous n’avions pas dans le planning poker.

Merci en tout cas aux deux intervenants pour la mise en avant de cette technique, qui montre encore une fois les bienfaits de l’amélioration continue.

Marshmallow Challenge ou l’importance du prototypage

Retours sur le Marshmallow Challenge

Nous avons été invité par le PMI lors d’une après-midi dédiée à l’agilité.

Suite à une présentation de l’agilité par Laurence Hanot du CARA, j’ai fait une présentation de SCRUM en 15 minutes, suivie d’un mini retour d’expérience sur son application.

Puis nous avons scindé la salle en deux ateliers, « Artistes et spécifieurs » pour Laurence et le « Marshmallow Challenge » pour Claire (@clrh) et moi.

C’est de ce dernier atelier dont je vais parler dans ce billet.

 

J’avais assisté à l’atelier animé par Pablo Pernot lors de l’Agile Tour Marseille 2011 et j’avais été surpris par le dynamisme de celui-ci (Pablo y était pour beaucoup  ).

L’objectif de cet atelier est de mettre en exergue l’importance du prototypage (itération) et de tester très tôt.

Vous trouverez toute la documentation nécessaire pour l’organisation du challenge et quelques retours chiffrés très intéressants (nous reprenons ces données dans notre présentation) sur le site du Marshmallow Challenge.

 

Je voulais revenir dans ce billet sur l’évolution de nos équipes tout au long du challenge.

Le groupe était constitué de 2 équipes de 4 personnes et 2 équipes de 3 personnes. Sans trahir la fin du billet, le différenciel de nombre n’a pas eu d’impact sur le résultat.

La première chose frappante est que dès le début de l’atelier les 4 équipes ont sorti une feuille de papier pour commencer une phase de conception.

La première équipe à avoir testé la résistance des spaghettis par rapport au Marshmallow l’a fait au bout de 4’30 (équipe 2), ce qui en soit est pas mal ; mais elle n’a pas su capitaliser sur cet avantage et est reparti dans sa phase de conception.

Les deux équipes suivantes (1 et 3) ont fait leurs premiers tests avec le Marshmallow entre 7’ et 7’30. Pour l’équipe 1 ce n’était pas vraiment un test de résistance mais un début de construction.

Ce qui est intéressant avec l’équipe, c’est qu’en ayant validé cette première phase de construction, ils ont repris une phase de conception sans se soucier réellement du temps qui passait.

L’équipe 4 a fait toute sa phase de construction de la structure à plat sur la table et a voulu la mettre debout au bout de 16’30. Bien sûr ce qui devait arriver arriva, la pyramide n’a pas supporté le poids du Marshmallow.

Au final les 4 équipes ont suivi à peu prêt le même cheminement avec une phase conception assez longue et très peu de tests.

Seule l’équipe 1 a présenté une structure à la fin des 18 minutes, en gardant celle de leurs premiers tests.

Nous avons ensuite fait une rétrospective avec chaque équipe. Le point qui est le plus ressorti de ces rétrospectives est que les membres des équipes se sont bien entendus. Finalement le résultat (et l’échec) passe au second plan car ils ont eu l’impression d’avoir suivi des phases précises mais qu’ils ont eu du mal à gérer le temps assez court.

 

Au final c’était un atelier très intéressant qui je pense a fait comprendre l’importance des itérations et des tests à tous les participants.

1370961836_doc_pdfVoir la présentation Marshmallow Challenge (PDF, 3.41MB)

L’Esprit Agile a soufflé

L’Esprit Agile a soufflé sur Marseille ce Mardi 17 Mars dans l’Amphi de l’ECM.

Ce premier évènement du genre dans la région a été une belle réussite avec un peu plus de 80 personnes présentes.
Nous remercions encore une fois tous les participants, intervenants, partenaires et bien sûr les étudiants de l’ECM avec qui nous avons organisé cette rencontre.

Equipe

Merci à Jean-Marie pour les photos

Les présentations et vidéo seront disponibles la semaine prochaine sur le site de l’Esprit Agile.

Nous espérons ne pas en rester à cet évènement ponctuel, mais fédérer des utilisateurs de méthodes agiles ou les personnes et entreprises intéressées au sein d’une association dont le but serait de favoriser les échanges et la mise en place de méthodes agiles.

Je vous invite donc à nous contacter si cette démarche vous intéresse, cela nous permettra de pousser un peu plus cette démarche.

L’Esprit Agile

ViaXoft, en partenariat avec Centrale Marseille et Marseille Innovation, vous invite à découvrir « L’Esprit Agile« , le mardi 17 Mars à partir de 17h30, à l’Ecole Centrale de Marseille.

Appréhendez les méthodologies Agiles (Scrum, XP, …), leurs spécificités, leurs apports et leurs différences par rapport aux méthodologies traditionnelles autour des Présentations et des retours d’expérience de :

Claude Aubry, Consultant, Professeur à l’Université Paul Sabatier

Thierry Cros, Fondateur de l’association XP France en 2000, Coach et formateur XP

Le danger de la réévaluation des tâches…

Concernant la réévaluation des tâches lors du Scrum quotidien.

Après quelques semaines d’utilisation de Scrum, nous avons donné la possibilité aux membres de l’équipe de faire une réévaluation des tâches lors du Scrum quotidien.

Ceci avait pour but de prendre en compte tous les dépassements de durée sur les tâches.
Mais nous avons constaté un effet pervers : la réévaluation entraînait une baisse de la vélocité car elle devenait une facilité pour les membres de l’équipe et dégageait la pression positive créée par le Sprint.
Agilité bien ordonnée commençant par soi-même, nous avons donc décidé de revenir en arrière et de ne plus réévaluer les tâches 🙂

Loading...
X