Inspirée par la conférence de Samuel Chaptal lors de l'Agile Tour de Toulouse 2020, voici un résumé de 5 plaintes type et comment y répondre ou les adresser pour mieux y faire face ?

Samuel a débuté sa conf en nous invitant à prioriser les plaintes que l'on aimerait voir traitées lors de la conférence. J'ai repris dans cet article un mix entre mes points de vue et les siens que je trouvais pertinents.

Soyez l'exemple. Montrez vous même l'exemple en faisant bouger les choses en mettant en place de nouvelles choses, en expérimentant.

Apprenez à coacher votre équipe à passer d'intentions à de petites actions précises à réaliser dans un temps court. Enfin revenez sur ces actions, suivez-les.

Hacker votre environnement. Arrêtez de penser que votre environnement vous emprisonne pour apporter du changement, expérimentez. Si c'est ce que vous pensez, demandez-vous comment vous pouvez le hacker ? Trouver un moyen de détourner les contraintes, prenez le comme un jeu. Je ne dis pas que c'est évident pour autant :)

Acceptez de commencer par un backlog léger. Il sera forcément imparfait au début.

Commencez en ayant une Définition of Ready légère pour tout l'équipe.

Restez simple.

Prototypez, proposez des expérimentations. Déléguez. Si par exemple, en tant que Product Owner, vous vous sentez dépassé, demandez du soutien à votre équipe dans l'écriture ou à minima la relecture des User Stories. L'équipe Scrum entière est responsable de la bonne compréhension des User Stories.

"Je passe ma vie en réunion au lieu de faire du dev et c'est de la faute de Scrum."

Je peux comprendre cette plainte, et elle est à l'encontre de l'état d'esprit Scrum, et de son approche empirique. Les solutions se trouvent en équipe.

Les cérémonies Scrum ne devraient pas vous pendre plus de 5h/semaine dans le cas d'uns sprint de deux semaines (15min/jour en Stand-up Meeting soit 1h15/semaine ; 1h30 à 2h d'affinage ou de sprint planning meeting ; 1h de démo tous les 15j et 1h30 de rétro tous les 15j)

Passez du temps à la conception et à la rédaction des User Stories en revanche.

Une estimation est une estimation, et par définition sera fausse car elle pleine d'inconnues.

Mais alors pourquoi faire des estimations ?

N'estimez pas pour estimer mais pour vous aider à vous engager à l'échelle de l'équipe sur un nombre de User Stories dans un sprint.

Une estimation est relative. Vous ne saurez jamais exactement le temps qu'une user story va vous prendre. Un estimation est un support de discussion avant tout et ce, à partir d'un référentiel d'autres User Stories préalablement estimées.

L'estimation vous amène à des échanges au sein de l'équipe sur la réalisation technique.

Vous pourriez estimer pendant votre Sprint Planning ou votre session d'affinage pour avoir les bonnes discussions en équipe puis jeter vos estimations à la fin de votre Sprint Planning pour vous tenir à un engagement d'équipe sur un nombre de user stories uniquement.

Oui vous rencontrerez des problèmes de conception et c'est ce qui va vous permettre d'avancer, de vous poser les bonnes questions.

"Ça fait moins d'une journée que je suis sur le dev de la nouvelle user story et je suis déjà bloqué. Ce n'est pas possible que l'on n'ai pas anticipé ce point. On est vraiment nuls"

Acceptez l'imperfection pour commencer. Il n'y a qu'en essayant de produire quelque chose qui fonctionne que l'on va se rendre compte des obstacles. Acceptez de commencer des développement sans avoir tous les paramètres techniques. Rappelez-vous que vous êtes dans une approche empirique, soit une approche d'apprentissage par l'expérience.

Nous ne sommes pas tous condamnés à faire du Scrum. Si vous ne vous y retrouvez pas, si Scrum ne vous correspond pas, ne vous condamnez pas à faire du Scrum en équipe. Ce ne sont jamais les approches méthodologiques qui font le succès d'un projet, mais l'humain.