Rétrospective sur la première partie

Ce que nous avons vu

Avant de passer à la deuxième partie, faisons une petite rétrospective. Qu’est-ce qui s’est bien passé durant cette première partie du livre ? Avez-vous compris les bénéfices qu’apporte l’agilité ? Nous l’espérons sincèrement !

Récapitulons ces bénéfices dans le tableau ci-dessous :

Quelques feedbacks

Comme tout le monde a le droit à la parole durant la rétrospective, il ne faut pas hésiter à s’exprimer, c’est important pour la progression.

Certains points doivent-ils être éclaircis ?

Alors, qui souhaite prendre la parole ? Ne soyez pas timide, le but est de progresser tous ensemble et votre feedback est précieux pour qu’on s’améliore systématiquement.

- « Oui, Fred, tu veux dire quelque chose ? »

- « Moi, ce que je remarque, c’est que Scrum présente le risque de voir les fonctionnalités s’étendre indéfiniment et d’entrer en mode « Scope Creep » ; à moins qu’on définisse une date de fin de manière formelle. En plus, comme on est en agilité, côté métier, les équipes peuvent être tentées d’ajouter des fonctionnalités durant les sprints. Par ailleurs, si une tâche n’est pas bien définie, l’estimation des coûts et du temps du projet ne sera pas exacte. Dans ce cas, la tâche peut se perdre sur plusieurs sprints ! »

- « Merci pour tes remarques, Fred. On va les reprendre une par une si tu veux »

La date de fin d’un sprint, c’est la fin du sprint, on ne recule et ne change rien ! Une fonctionnalité qui n’est pas finie durant le sprint sera achevée sur le sprint suivant ; et si elle avait été estimée à 13 points, aucun de ses points ne sera comptabilisé pour calculer la vélocité du sprint. C’est injuste, mais c’est comme ça, même si elle a été finalisée à 90 % !

On comptabilise seulement ce qui est vraiment passé à l’étape DONE ! On procède ainsi pour éviter de revivre les scénarios du genre « j’ai presque fini, laissez-moi la demi-journée et je boucle l’affaire... » où malheureusement, trois jours plus tard, l’affaire n’est toujours pas bouclée. Tout est timeboxé dans Scrum afin de mieux gérer le temps.

On ne peut pas non plus reporter une Sprint Review ou une rétrospective sous prétexte...

Origine de Scrum

Dans cette première partie, nous n’avons cessé de parler de Scrum, mais au fait, d’où vient le nom Scrum ? C’est un terme qui vient du rugby, il signifie « mêlée ». De manière générale, les Japonais adorent ce sport. Le véritable esprit agile est d’ailleurs né au Japon, même si Scrum est devenu de loin la méthode agile la plus utilisée au monde. C’est en 1986 que Takeuchi et Nonaka ont dénommé Scrum comme un style de gestion de projet, et c’est seulement en 1993 que Jeff Sutherland et Ken Schwaber ont écrit le Guide Scrum.

Au rugby, on note un véritable esprit d’équipe et un profond respect des individus. Lors d’un match, tous les joueurs respectent l’arbitre et personne ne remet en question ses décisions ; le respect est une valeur primordiale et réelle dans le cœur des joueurs de rugby. Dans Scrum l’équipe Dev travaille de façon collective, concentrée au maximum sur l’objectif du sprint, exactement comme le pack (les avants de l’équipe) lors d’un ballon porté au rugby. De même, à l’image d’un demi de mêlée, le Scrum Master aiguillonne l’équipe, la réoriente dans la bonne direction quand les règles...