C’est parti… Nous allons effectuer notre premier sprint la semaine prochaine. En attendant j’ai commencé à remplir un Product Backlog. Nous allons gérer pendant une semaine les tâches en cours en utilisant notre petit tableau sur le framework Karma dans un premier temps. Le tableau est déjà couvert de Post-It, avec les corrections de bugs et les développements en cours. L’idée est d’abord de m’adapter et de bien me roder avant d’attaquer le Sprint Planning la semaine prochaine. je n’ai pas encore fait tous mes choix d’outils, mais le plus simple c’est un tableau…
La première bonne nouvelle pour l’équipe c’est qu’en tant que Scrum Master, je leur ai retiré l’obligation de répondre aux emails que nous recevons sur un alias. Je vais me charger de faire le proxy entre les demandes de nos clients internes, souvent des développeurs, et mon équipe de développeur. Les questions étant souvent techniques, j’ai pris conscience qu’à chaque email intempestif, celui-ci génère une perte de temps pour l’équipe, plongée dans son travail. De plus la règle était « vous vous auto-gérez ». Mais pas évident car tous n’ont pas la même charge de travail au quotidien. Nous allons essayer pendant quelques temps de cette façon. Cela ne devrait plus ralentir l’équipe. La fonction du Scrum Master est de retirer tous les obstacles (impediments en anglais) empechant le bon déroulement du sprint.
Question dont je n’ai pas la réponse : Comment gérer les bugs et les demandes de corrections « urgentes » ?
J’ai le sentiment que durant un Sprint, l’équipe doit s’immerger complètement, comme l’équipage d’un sous-marin nucléaire. Ils ne doivent recevoir de l’extérieur que très peu de stimuli. Et ils savent ce qu’ils ont à faire. Notre durée de sprint sera de 3 semaines. Cela colle avec les sorties d’un gros logiciel chez nous. Et cela convient à mon avis à la taille des développements que nous effectuons. Donc au pire, un produit peut attendre 3 semaines. C’est réaliste avec le temps nécessaire ensuite pour les autres équipes de repackager leur produit, faire passer une campagne de test QA, faire valider la correction par le support et enfin effectuer une installation chez le client… On ne travaille pas à la journée prêt, ce qui serait irréaliste avec une démarche qualité. Maintenant j’attends plutôt de commencer un vrai sprint afin de voir comment rester efficace.
L’aventure du tableau volé…
Le tableau avec notre pseudo sprint backlog a fait son effet. J’ai pris un paper-board avec quelques feutres. Après avoir tracé 3 colonnes (A faire, en cours, fait) j’ai utilisé des post-its pour les activités en cours cette semaine, afin de travailler sur cet outil avant de lancer un vrai sprint. Ce tableau est trop petit, et n’importe qui peut l’embarquer dans une salle de réunion.
Du coup, j’essaye de récuperer un énorme tableau blanc. Pour cela je dois aussi me battre avec les services généraux pour faire poser 4 chevilles dans un mur… Enfin passons.
Pour notre tableau actuel j’ai eu une désagréable surprise en revenant de notre pause déjeuner toute à l’heure avec l’équipe :
La feuille avec nos post-its a disparu ! Plus de sprint backlog !
Vous y croyez vous ?
Je serai victime du premier attentat anti-scrum…
Bref j’ai pas essayé de comprendre, me disant que le message est clair, va y avoir du sport… Ca commence fort
Quelques minutes plus tards, derrière moi, notre ergonome assez embeté s’approche discretement :
– « …Euh… je crois que ta feuille là, elle est juste cachée là derrière… c’est moi qui fait une blague
Ah là là… vivement qu’ils me fixent un vrai tableau dans le mur et que l’on puisse travailler.
Bon et vous ? Ca Scrum ou pas ? racontez-nous un peu
Je pense qu’au lieu du tableau en papier pour définir les taches il te faut un logiciel comme gantt project.
Pour gérer les bugs, qui peuvent être envoyés avec 3 degrés d’importance (low, medium, high), rien ne vaut Clearcase et Clearquest.
Comme ca tu pourra assigner la fiche avec le bug à un certain développeur.
Honnêtement, scrum va vous faire perdre votre temps.
Felix> Lorsque tu as un bug très urgent, tu le classes “Super-high” ?
Lorsque tu fais un planning Gantt, si durant le développement les personnes ont terminé avant ou après la longeur de ta case, est-ce que tu remets à jour tout le temps ton planning ?
– Nicolas –