Alerte : Notre démonstration va se planter !
Par Cyrille » 22 mai 2010 (19:55) - Scrum - Méthodes agiles
Malgré la rigueur de l'équipe, l'intégration continue, les tests répétés, vous êtes à 48h de la livraison et là BOOM : vous voyez que la fin du Sprint est impossible et que donc la démonstration va être une catastrophe. Que faire ?
Réponse A : Verser du sans de poulet sur votre serveur d'intégration ou appelez votre marabout préféré :
Réponse B : Vous fermez la porte de l'open space de votre WarRoom et cassez volontairement la clef dedans pour garder toute l'équipe 48h non stop afin de relever ce défit.
Réponse C : Vous déclenchez l'alarme incendie pour faire évacuer l'immeuble et s'en servir comme prétexte
Réponse D : Vous allez voir votre product Owner et....
J'espère que si vous êtes sur cette page, vous avez pensé à la réponse D
Votre "combat" est sur la confiance et la transparence, c'est lors des difficultés que l'on voit ces 2 valeurs.
Voici le scénario que j'ai utilisé et qui s'est finalement bien terminé
A 2 Jours de la fin du Sprint alors que tous les indicateurs étaient verts, nous avions oublié de prendre en compte que tous les tests que nous avions effectué n'étaient pas représentatif de ce que nous allions présenter, pour une raison très "bête" après coup :
Ce Sprint contenait une étape de reprise de données d'un autre système alors que durant les Sprints précédent on utilisait l'application avec des données "bidons".
Lors de la présentation des difficultés au Product Owner, 2 pistes sont apparues :
- Faire une démonstration avec les anciens jeux de données
- Changer de stratégie
Les contraintes du PO ont fait qu'il voulait les données dans l'application, nous avons donc décidé (conjointement) de faire la démonstration mais
- Uniquement entre nous : Equipe, Scrum Master et Product Owner (Pas d'invité)
- Utiliser cette session de démonstration pour qualifier les bugs et les estimer.
A la fin de cette démonstration nous sommes partis sur un Sprint de 4 jours : 3 jours de tests et correction et le dernier jour pour rejouer la démonstration avant la démonstration devant le Product Owner.
En sortant de cette "fausse" démonstration l'équipe était rassurée et confiante sur ce "Challenge"
A la fin du premier jour, le pessimisme commençait à prendre le dessus : Il est "vital" pour la réussite de ce mini Sprint de s'assurer que tout le monde connait son objectif et de recentrer les "brebis galeuses" sur l'objectif.
Au final, il restait quelques petits points mineurs et la version a été bien acceptée par le Product Owner.
En conclusion : Confiance et Transparence sont 2 valeurs importantes de Scrum et c'est pendant les difficultés que vous gagnez des points de confiances.
Confiance et Transparence entre le Product Owner, l'équipe et le ScrumMaster.
La cohésion d'équipe joue un rôle important durant ces "épreuves".
Bon sprint à vous. 
Évaluer ce billet
4/5
- Note : 4
- Votes : 1
- Plus haute : 4
- Plus basse : 4

Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
Confronté plusieurs fois au même cas de figure, l'équipe a opté à chaque fois pour une solution différente :
- La première fois : réalisation de la démo sur quelques scénarii qui marchent (sélectionner telle table, prendre telles données, faire telles modifications). Par contre, on communique clairement sur ce fait auprès du PO.
- Fin du sprint sans démo et mise en place du plan d'action suivant : la veille de la démo est consacrée aux tests, correction et à la préparation de la démo
Fil des commentaires de ce billet
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
URL de rétrolien : http://www.bouzin-agile.fr/?trackback/47