Régulièrement, des personnes viennent me voir pour me dire que compte tenu de la taille réduite de l’équipe (2 personnes), elles n’ont pas l’intention de mettre en place l’ensemble des cérémonies Scrum (les réunions comme les « Daily stand up » ou « Demo »)
Même si cela ne me plait pas vraiment, en général je laisse filer car je n’ai pas vraiment d’arguments à leur opposer et je ne connais pas vraiment les risques qu’ils encourent à se comporter comme cela. Bien entendu, si la taille de l’équipe est de 3 ou plus, j’évoque les besoins de synchronisation, de prioritisation et de communication pour inciter ces personnes à mettre en place toutes les cérémonies Scrum. Mais s’ils ne sont que 2, je suis généralement moins convaincant car moins convaincu.
J’ai donc décidé d’expérimenter par moi même « Scrum for 2 » puisque je suis en charge d’un nouveau projet où nous sommes 2 dans l’équipe (je rassure ceux qui me connaissent, il n’a rien de technique).
Je suis le Product Owner, Laurent est le Scrum Master et l’équipe de réalisation est constituée de Laurent et Moi 🙂
Nous allons appliquer la méthode « in the book » ce qui me permettra de mieux appréhender la plus value apportée par chaque cérémonie et avoir plus d’arguments à opposer à ceux qui veulent faire sans.
Bref, c’est une action à suivre …
Salut
Hum… J’ai une question sur le sujet des méthodes Agile mais sans rapport avec ce billet : puis je ?
Allez, je me lance 😉
En fait, la question est toute simple mais pourtant « centrale » : les méthodos agile sont contre le planning en amont et des spécifications tôt dans la vie du projet.
Pourtant, comment procéder autrement pour permettre la décision de lancer ou non un projet ? Les décideurs ont besoin d’un coût (approximatif certes) et de la portée fonctionnelle qui sera développée…
Doit on pour autant en revenir aux méthodes traditionnelles d’estimation de projet ? Y a t il d’autres alternatives ?
merci d’avance
++
Joseph
Pour moi la question est mal formulée car elle n’implique pas le client.
La bonne question qu’il faut se poser est « Comment puis-je satisfaire mes utilisateurs? » et une façon d’y répondre est de dire « En mettant rapidement à disposition des mes utilisateurs un produit répondant à leurs besoins principaux afin de récolter leurs feedbacks et améliorer le produit régulièrement »
Les méthodes Agiles permettent d’obtenir la satisfaction du client plus surement que les méthodes traditionnelles.
Pour répondre un peu plus précisément, je dirais que l’estimation du coût et de la portée fonctionnelle est un investissement pour l’entreprise, et que de toute façon les résultats obtenus sont incertains (voir totalement faux) et qu’il est préférable d’utiliser cet investissement pour produire quelque chose, calculer la vélocité de l’équipe et bâtir un « release plan » sur des données un peu plus fiables. Bien entendu cela n’est pas incompatible avec quelques travaux d’architecture et la définition d’un périmètre en amont, mais il est indispensable de borner ces tâches sur une durée très courte (2 ou 3 semaines) et de bien comprendre que les résultats obtenus ne sont que des estimations et en rien des ENGAGEMENTS
Une très bonne lecture sur ce sujet: « Agile Estimating and Planning » de Mike Cohn (ISBN: 0-13-147942-5)
Salut Alex,
merci pour ce blog toujours aussi riche.
A quand des nouvelles de Scrum for 2 ?
Très bientôt 🙂