Mot-clé - scrum

Fil des billets - Fil des commentaires

Un tableau brulant

badges_flammes.jpg

Un scrum master de mon entreprise a commandé des magnets personnalisés super fun pour rendre les risques et les urgences encore plus visibles.

Je trouve le principe des aimants mieux que des bouts de post-its découpés, qui finissent par se fondre dans la masse des post-its. J'en profiterai pour vous parler d'autres bombes utilisées sur nos murs.

Lire la suite

Comment vous estimez-vous ?

Miroir déformant

Miroir déformantLes problèmes de délai sont récurrents dans les projets. La capacité des équipes à effectuer des estimations dépend beaucoup de la connaissance que l'équipe a du projet, ainsi que des technologies impliquées.

D'autres facteurs moins souvent évoqués entrent en jeu : le rapport à l'échec, l'humilité, l'intérêt du challenge et l'estime de soi.

J'aimerais évoquer avec vous ces trois façons si différentes que j'ai rencontré, de prédire ses capacités.

Lire la suite

Manager et/ou développer ?

Developer

DeveloperLe développeur d'une autre équipe m'a dit un jour : "Ah non, le scrum master n'est pas censé coder." Il avait l'air vraiment choqué. Je lui ai demandé pourquoi, et il m'a répondu que cela enlèverait de la responsabilité aux équipes. Que c'était intrusif' ? Oui.

Etonnée, je me suis tourné vers les personnes de mon équipe pour avoir leur avis. Elles ont répondu : "Bah... toi, tu veux coder ?"

Paradoxalement, quelques mois auparavant, j'évoquais lors d'un one on one [1] la difficulté que j'avais à récolter du feedback au quotidien. Pour le développeur, je (le scrumMaster) devais être totalement interchangeable avec un autre développeur et pouvoir faire une story de A à Z sans problème. Pour lui, un scrum master code quasiment aussi facilement et régulièrement qu'un développeur.

Lire la suite

Des pratiques à reprendre

burndown_avsp.jpg

burndown_avsp.jpgJ'ai une demi heure pour parler de ma dernière mission. J'y ai vu des pratiques excellentes, dont je suis certaine de la valeur, et d'autres qui m'ont plus troublée.

Les pratiques extras

  • Les standards sont le bien. Il y a un tableau avec un post it par standard, construit peu à peu par l'équipe
  • L'auto gestion et le lead par l'équipe. Toutes les décisions sont prises par l'équipe, suite à un vote. Le processus de décision est plus lent et il peut y avoir des clashs mais au final, il y a plus de conviction. Un consensus mou ne permet pas de valider une décision. Par ailleurs, si le client a un lien plus régulier avec le scrum master, c'est à toute l'équipe que les mails sont envoyés et n'importe quel membre de l'équipe répond directement à ses questions. Quasiment tout le monde fait des propositions d'améliorations du coup.
  • Le binomage systématique. Meilleure qualité du produit, moins de rework, plus d'apprentissage et meilleure ambiance.

Lire la suite

Voter avec ses mains

doigts.jpg

Parmi les goodies de l'agile tour Paris 2010, il y avait des cartes de planning poker d'Octo. J'en avais déjà eu aux XPDays 2009 mais j'ai apprécié le cadeau car je n'en avais pas assez. Je me rappelle le plaisir que j'ai eu la premiere fois à utiliser des cartes pour évaluer les complexité des  […]

Lire la suite

Gérer les imprévus

orage.gif

orage.gifEn Scrum, le périmètre des stories engagées est figé une fois que l'itération a commencé. Dans la réalité, il y a toujours des tâches qui surgissent et qui trop critiques pour attendre l'itération suivante avant d'être traités.

En fonction de la place que prennent ces perturbations, les équipes s'organisent au coup par coup. Certaines les intègrent comme une story dans l'itération, d'autres les échangent contre une autre par exemple. Faisons un tour sur quelques pratiques.

Lire la suite

Rétrospectives manquées

La conférence Agile France 2010 mettait la rétrospective à l'honneur en incluant les cartes des alchimistes agiles dans le sac de bienvenue. En dépit de tout ce qu'elle apporte, il faut veiller à ne pas l'idéaliser car elle aussi peut bogguer. Je vous propose de faire un tour sur quelques problèmes classiques.

Lire la suite

Une bouffee d'air avec la rétrospective

Avez-vous déjà remarqué en revenant dans une pièce, que l'air ne sentait pas si bon? Vous y étiez pourtant depuis des heures et n'aviez rien remarqué. Vous étiez occupés. C'est après être sorti de la salle pour prendre l'air que cela vous saute au nez.

La rétrospective en Scrum s'apparente à cette bouffée d'air frais : il faut sortir pour mieux voir et découvrir qu'il est décidément temps d'ouvrir la fenêtre.

Lire la suite

Tools used for agile projects : the survey's results !

depouillement.jpg

depouillement.jpg

It all began when I wanted to have feedbacks on agile tools. By "agile tool", I mean more backlog management than continuous integration. Forums are full of information but they are messy, so I created a survey on my blog. I am very greatful to all the people who took part of it : many thanks to the 204 voters !

But

Soon enough, some limits appeared :

  1. Voting is easy. A company can easily send an email to its customers to ask them to vote. This is not really a problem, but it may not reflect the reality (what about the company who aren't aware of the survey or just don't care) ?.
  2. Someone asked me what to do when you were using several tools... (There was only one possible choice in the survey).
  3. The meaningless option "Other" was getting bigger and bigger, despite my efforts to be exhaustive. I finally created a post to invite people to tell me when the option was not available, but I guess it was too late and / or not convenient enough
  4. A widespread tool does necessarily fit your needs. X may be perfect for a distributed team in a multinational but not for my open source project. Surveys make valuable information disappear.
  5. Drawbacks are also missing. We don't know when a tool has been dropped and why.

Lire la suite

Les formules à volonté

Formules à volonté

Formules à volonté

Un copain m'a dit une fois que ce qui l'énervait dans les méthodes agiles, c'était justement l'agilité. Ce pass à volonté pour changer d'avis toutes les deux semaines était trop exploité. A force de faire des incréments, il trouvait que le produit final n'avait plus de cohérence, qu'on s'en rendait compte tardivement, et qu'il fallait tout recommencer. A côté de ça, faire des développements sur un module une fois, de le jeter, deux fois, de le jeter, au bout de 10 fois, c'était usant et de moins en moins motivant, surtout qu'ils n'en voyaient pas le bout. Comme dans un jour sans fin. ;-)

Cela me fait penser à un autre pote quand on quittait une fête, qui n'avait plus faim et était allé quand même chercher un morceau de pain parce que "c'était gratuit" (pas parce qu'il était fada de pains).

Lire la suite

Soat à l'agile conférence

Agile Conference 2010

Nous tiendrons deux sessions à l'agile conférence (ex-XPDays) les 31 Mai et 1er Juin : un atelier fun et une conférence geek. Survivre sur la lune avec la NASA ou l’importance de travailler en groupe L'idée de l'atelier est de démontrer que pour résoudre un problème, 1111 est bien plus fort que  […]

Lire la suite

Plus on est nombreux, plus c'est du gachis ?

La première fois que j'ai entendu parler de binômage, j'ai réellement cru que c'était un mythe. Quelque chose dont on parle, mais qui n'existe pas dans la vraie vie. D'ailleurs, on constate que si de nombreuses pratiques agiles arrivent à prendre dans les entreprises, le pair programming a plus de mal à prendre sa place.

Quel gâchis de mettre plusieurs personnes sur un travail !!!! On m'a dit "sisi, ça fait gagner du temps". Ben non. Il faut expliquer à l'autre son point de vue, se mettre d'accord, on met du temps avant de commencer à produire...

Axel et moi organiserons justement à l'Agile Conférence un atelier sur la valeur ajoutée du collectif par rapport à l'individuel. En théorie, on accepte facilement cette idée, mais dans la pratique nous sommes beaucoup plus frileux. L'atelier va, on l'espère, vous prouver le contraire. C'est une nouvelle toute fraiche, je viens juste voir la sélection sur le site, nous sommes très contents !

Lire la suite

Which agile tool are you currently using?

I started a survey the 20th February 2010, to get benefits from people's experience and see which tool was preferred to conduct agile projects. I'm planning to let it go for more or less 3 months, to give it some time.

The idea was to have a clearer vision of the answers of the question Any recommended tools for Agile and Scrum based software development ? and Open Source scrum project management tool ? in LinkedIn forums.

There is a "Other" option but it would be better to avoid it. If the tool you're using is not mentioned, feel free to add a comment to this post, I will add the option in the survey. Unfortunately, the "Other" option has often been chosen these last days.

Lire la suite

Livre collaboratif

Vous avez remarqué comme ce sont toujours un peu les mêmes questions qui sont soulevées dans les hubs, listes, forums, conférences agiles?

  • comment gérer les réticences au changement ;
  • comment gérer les problématiques d'architecture ;
  • comment gérer un projet au forfait de manière agile ;
  • comment gérer une grande équipe (scrum de scrums) ;
  • comment gérer des équipes distribuées ;
  • comment gérer les perturbations / bugs urgents ;
  • quel logiciel utiliser dans un projet agile ;
  • etc.

Lire la suite

Mesurer pour quoi faire?

Balanced Scorecard

Weinberg évoque dans dans Quality Software Management une idée reçue implicite au sujet des métriques : pouvoir mesurer les choses nous donne l'impression de pouvoir les maitriser.

A quoi servent les métriques?

  • à faire des suppositions sur l'avenir, à prédire;
  • à évaluer les gens : l'équipe, le management;
  • à voir les problèmes. Et selon l'esprit de l'entreprise, à réprimer ou à chercher les causes du problème. Elles servent alors aussi à nous améliorer.

Au niveau du management, les métriques permettent de prendre des décisions. Elles donnent aussi aux personnes du terrain une vision plus macro, plus large des évènements.

Lire la suite

Episodes de vie

J'aurais du tiré plusieurs fois une même leçon de certains épisodes de ma vie, mais il m'a fallu du temps pour réellement l'intégrer. Savez-vous de laquelle il s'agit?

Ecole primaire, 1991-92.

J'avais mis tout mon coeur dans ce dessin. Un peu de crayon de couleurs, un autre petit tracé par là. Tiens je vais accentuer les contours en noir pour faire bien. Encore un coup de feutre ici. Une fois à court d'inspiration, je tiens la feuille et la contemple. C'est moche.... Je regarde l'oeuvre de mon voisin. Il n'a utilisé qu'un crayon à papier. Son dessin est magnifique. Comme pour en rajouter une couche, au moment de commenter les dessins, la prof dit : "certains ont fait beaucoup beaucoup d'efforts, malheureusement... (silence)". Je suis sure qu'elle m'a regardée à ce moment là.

Lire la suite

Un mauvais ouvrier a toujours de mauvais outils

Vive les crayons

Nous voulions que la maitrise d'ouvrage soit autonome dans l'écriture des spécifications, et pour cela, qu'ils sachent en écrire avec Fitnesse. Hop c'est parti. Nous nous mettons à trois devant un écran (deux développeurs + webmarketing). Il s'agissait de définir le sens d'un "tri pertinent", en proposant plusieurs scénarios. Nous nous jetons sur l'outil Fitnesse, illustrons les tris attendus par des exemples. Le client hésite. Nous changeons le tri de nouveau. Au bout de 5mn et 23 couper-coller, on commence à avoir mal à la tete et le client dit "Attendez, je vais écrire les objets sur un papier, ce sera mieux pour voir ce qu'on a à trier". On le regarde méditer et là, ce ciseau sur la table m'appelle. "Eeeh si on découpait ta feuille?" Les changements d'avis sont devenus beaucoup plus simples à gérer. Une fois le client 100% convaincu de ce qu'il voulait, nous avons pu nous concentrer sur Fitnesse.

C'est un aspect que j'aime beaucoup dans Scrum : le retour des feutres, de la feuille de papier, des ciseaux. Ces objets palpables, que tout le monde peut voir sans avoir à allumer un PC. Nous nous concentrons sur l'essentiel plutôt que sur la compréhension de l'outil.

Cet attachement au concret, au parlant pour tout le monde fait que je ne me suis jamais intéressée aux outils agiles. Un tableau blanc, des feutres, des post its et un tableur pour le backlog suffisent. Et puis ce n'est pas l'outil qui va rendre une équipe plus agile. "Un mauvais ouvrier a toujours de mauvais outils", n'est ce pas? Il vaut mieux déjà savoir faire sans.

Un référentiel d'outils agiles

Pour autant, je pense maintenant qu'un logiciel pourrait m'être utile pour :

  • rechercher des stories;
  • gérer un historique;
  • ne pas avoir un backlog de 10km;
  • pouvoir éditer des stories en simultané (plutot que committer un Excel ou utiliser google docs);
  • avoir un burn down chart automatique;
  • changer facilement le statut d'une story, en particulièrement une story à reporter;
  • avoir des statistiques automatiques, sur le réalisé/accompli par exemple;
  • créer des ids automatiquement pour les stories.
  • [Ajout du 26 Mai] avoir un generateur des stories (id+libellé) sur des cartes, au format post-its, pour ne plus avoir à effectuer cette tache à la main. Ils pourront ainsi directement etre aimantés sur le tableau et faciliter le découpage en taches en début de sprint.

Une user story doit aussi être classable dans une catégorie ou avec des tags.

Lire la suite

Jeu du Miroir de Blanche Neige et les Sept Nains

J'avais tellement hâte d'aller aux XPDays que plus j'y pensais, plus je me disais que j'allais être déçue.

Eh bien en sortant de la première session de Pascal Van Cauwenberghe et Portia Tung, plus rien ne me faisait peur : toutes les autres sessions pouvaient être décevantes, l'atelier Blanche Neige et les Sept Nains m'avait fait les deux jours.

Qu'est ce qui m'a tant plus dans cette session? Le jeu du miroir, et pourtant j'étais sceptique. Portia commence par nous bercer en nous lisant l'histoire de Blanche Neige version Tarantino. C'est ainsi que nous sont présentés les profils des personnages et leurs caractères : "colèrique", "savant", etc.

Le jeu consiste à tirer 3 personnages au sort et de trouver pour chacun une personne de notre vie qui nous fait penser à lui. En se demandant pourquoi, nous pouvons apprendre des choses sur nous mêmes : Je trouve qu'il est comme cela parce que moi même je suis comme cela. En dernier lieu, nous devons déduire une action qui nous fera remédier à notre "défaut".

PersonnageHumain : nom + raisonsSur soi-mêmeActions
Prof
- savant
- axé sur les solutions
- arrogant



Timide
- attentif aux besoin des autres
- calme
- n'aime pas les conflits



Dormeur
- distrayant
- facilement distrait
- difficile à motiver



Lire la suite

Soirée "Introduction à Scrum par la pratique"

Scrum par la pratique

Si XP n’évoque pour vous qu’un système d’exploitation et qu’un agiliste vous fait penser à un gymnaste, c’est que vous êtes passés à coté de LA méthodologie de gestion de projet des dernières années. La soirée 3T du 25 juin s’attachera à familiariser les plus novices avec les méthodes agiles, en présentant quelques un de ces principes. C'était la mise en bouche de la soirée sur Scrum que j'ai donné le 25 Juin à Soat.

Pourquoi un game?

L'idée était de présenter Scrum aux novices de façon ludique, un peu comme l'XP Game. Ce qui m'embétait dans l'XP Game c'est que l'on ne touche pas assez du doigt certains principes comme l'amélioration continue avec les retrospectives d'une part, et les stories n'ont aucun rapport les unes avec les autres, d'autre part je tenais à partager des choses apprises sur le terrain. Je voulais qu'ils échouent pour mieux comprendre.

Scrum par la pratique

J'ai donc adapté le jeu de Lego for Extended Scrum Simulation. Quelques slides exposent quelques principes agiles puis on passe à la partie pratique : le projet Agiville. Mon but n'est pas de faire des experts agiles en 2h mais de leur faire vivre une expérience, qu'il rencontrent des problèmes pour pouvoir les résoudre. Au pire, qu'on s'amuse :-)

Lire la suite

Haut de page