Article librement traduit de l’anglais : Article d’origine chez Pichler (Merci à Romain pour le pointeur)
Voici une liste de comportements qui partent d’une bonne volonté mais qui sont en fait des erreurs assez classiques lors de l’application de Scrum et qui influencent négativement la réalisation du produit, et qui de plus, lorsqu’elles sont combinées peuvent conduire à un échec cuisant du produit.
- Etre trop pragmatique dans l’application du rôle de Product Owner : Pour essayer de répartir la charge de travail sur plusieurs individus ou un comité représentatif
- Viser à maximiser la diffusion du produit : Pour essayer d’avoir un produit qui contienne un maximum de fonctionnalités et qui puisse être distribué à un maximum d’utilisateurs différents
- Ne pas savoir dire NON : Pour essayer de ne pas désappointer les utilisateurs et mettre en péril le succès du produit
- Collecter et détailler tous les besoins dans le Product Backlog lors de l’itération 0 : Pour essayer d’être exhaustif afin de réduire les incertitudes et les risques, et permettre de planifier précisément la réalisation du produit
- Ne pas définir de priorités : Car de toutes façons, toutes les fonctionnalités doivent être dans le produit
- Ne pas demander très tôt du feedback aux utilisateurs : Car de toutes façons vous savez ce qui est le mieux pour eux puisque vous leur avez posé la question il y a quelques mois
- Planifier un livraison « Big Bang » : Pour essayer de surprendre vos compétiteurs, impressionner vos clients et dominer le marché en 1 seule nuit
- Lorsque l’on approche du jalon de livraison, mettre des fonctionnalités supplémentaire « à l’arrache » au détriment de la qualité : Car ce n’est pas important de s’occuper de la « dette technique » maintenant, et de plus les utilisateurs aiment bien les produits avec plein de fonctionnalités même si elles ne marchent pas très bien, et puis il sera toujours temps de corriger les problèmes dans une version ultérieure.
- Demander au Scrum Master d’agir comme un Chef de Projet : Car il est important que l’équipe soit dirigée pour donner son maximum et peu importe qu’elle explose en vol
Pour éviter ces erreurs, regardez vos projets à la loupe et cherchez ces comportements spécifiques, documentez vous en lisant des livres, des blogs et des articles, et participez à des conférences comme AGILE GRENOBLE 2010 🙂
Bonjour Alexandre,
Je ne comprends pas trop le premier comportement : « Etre trop pragmatique dans l’application du rôle de Product Owner ». Est-ce que tu pourrais donner un exemple ?
Merci.
Bonjour Alexandre
Comme Mathieu, je ne comprends pas le premier point.
J’ai également un problème avec le point 4: Je suis d’accord pour ne pas « détailler » toutes les fonctionnalités lors du sprint 0 mais ne doivent elles pas toutes être listées? D’après moi, il faut 1. collecter toutes les fonctionnalités haut niveau, 2. les prioritiser 3.detailler en stories les fonctionnalités les plus prioritaires.
Qu’en penses tu?
Tres bien pour les autres points.
Isa