Est-ce qu'il y a de la confiance et de la transparence dans votre équipe Scrum ? Si ce n'est pas le cas, ce n'est pas une équipe !

Le cadre Scrum a été fondé sur l'empirisme et la pensée allégée (lean thinking) et repose sur 3 piliers : la transparence, l'inspection et l'adaptation. Cela devrait être dans l'esprit de chaque membre de l'équipe, mais malheureusement, ce n'est pas si courant. Les équipes accordent trop d'attention aux cérémonies Scrum et oublient parfois ce qui se cache derrière. Tous - oui, tous les événements Scrum - existent pour donner l'occasion d'une inspection. Une fois que vous avez effectué une inspection correcte, vous pouvez vous adapter si cela est nécessaire. Cependant, une bonne inspection ne peut être menée que si l'équipe fait preuve de transparence et de confiance. Sans transparence et sans confiance, tout risque de s'écrouler. Sans transparence et sans confiance, vous ne serez pas en mesure d'inspecter - du moins pas correctement - et sans une bonne inspection, vous pouvez oublier l'adaptation. La transparence permet l'inspection, et l'inspection permet l'adaptation.

Un manque de transparence peut entraîner une diminution de la valeur et une augmentation des risques. Nous parlons ici de transparence en termes de travail et de processus. La transparence en termes des 3 artefacts que Scrum propose : le Backlog Produit, le Sprint Backlog et l'incrément. Une équipe doit constamment inspecter les progrès, les artefacts, sa façon de travailler, et c'est là que les événements jouent un rôle clé. Scrum propose 5 événements - le Sprint, la planification du Sprint (Sprint planning), le Scrum quotidien (ou Daily Stand-up), la revue du Sprint (Sprint Review) et la rétrospective du Sprint - pour aider à l'inspection. Si vous essayez d'inspecter sans transparence, cela ne fonctionnera pas. Si vous inspectez mais ne vous adaptez pas, l'inspection devient inutile. Les événements Scrum sont conçus pour provoquer le changement. Une fois que l'inspection est effectuée et qu'un besoin d'adaptation est constaté, il faut le faire dès que possible.

Vous commencez votre Sprint par une planification de Sprint (Sprint Planning). A ce moment, vous inspectez la priorité du backlog (priorisé par le Product Owner), l'objectif de l'équipe et le plan pour le Sprint que vous venez de commencer. Pendant le Sprint, l'événement de cadence de Scrum, vous avez votre Scrum quotidien (daily stand-up) (oui, quotidien signifie chaque jour) où votre équipe inspecte la progression vers l'objectif du Sprint et décide si une adaptation du plan est nécessaire. Oui, l'adaptation du plan dans ce cas peut signifier changer le Sprint Backlog. Beaucoup de gens affirment que le Sprint Backlog ne peut pas être modifié, ce qui est totalement faux. Le Guide Scrum indique que le "... Sprint Backlog est mis à jour tout au long du Sprint au fur et à mesure que l'on en apprend davantage. Il doit comporter suffisamment de détails pour que les participants puissent inspecter leur progression dans la mêlée quotidienne." À la fin de votre sprint, vous avez la revue de sprint (Sprint review), où votre équipe, avec les parties prenantes, inspecte l'incrément et le travail réalisé par l'équipe de Scrum, en fournissant des commentaires. C'est une bonne occasion d'inspecter également le Backlog de produit. La dernière occasion d'inspection - c'est-à-dire le dernier événement du sprint - est la rétrospective du sprint, au cours de laquelle l'équipe Scrum examine comment elle a travaillé pendant le sprint et identifie les actions d'amélioration.

Chaque membre de l'équipe doit garder ces pensées à l'esprit lorsqu'il participe à l'un des 5 événements Scrum, car ceux-ci sont conçus pour laisser place à l'inspection et à l'adaptation. Et l'équipe ne pourra inspecter - le plan, le backlog, l'incrément, le travail - qu'en faisant preuve de transparence.

Quelle est la prochaine inspection de votre équipe ?

Une chose dont le Product Owner doit s'assurer lors de la planification du sprint est que les membres de l'équipe soient prêts à discuter des éléments les plus importants du Product Backlog et de la façon dont ils correspondent à l'objectif du produit (engagement du Product Backlog). C'est la première occasion de faire preuve de transparence et d'effectuer un contrôle. Pendant la planification, les membres de l'équipe doivent comprendre pourquoi le Sprint est utile, ce qui peut être fait et comment le travail choisi sera réalisé. Le Product Owner, ou même une équipe Scrum, qui ne parvient pas à assurer cette compréhension commune et partagée de la valeur et des éléments qui apportent le plus au produit, se traduira par une mauvaise inspection. Et n'oubliez pas que l'inspection permet l'adaptation. Après une discussion avec le Product Owner, les développeurs sélectionnent les éléments à inclure dans le Sprint en cours, en les affinant au cours du processus. Cette inspection a pour but d'améliorer la compréhension et la confiance. Mais pour y parvenir, vous avez besoin de transparence. J'ai vu de nombreux membres d'équipe ne pas être transparents lorsqu'un élément n'était pas clair, ne pas demander au Product Owner, et donc se laisser guider par d'autres membres de l'équipe qui prenaient les devants. Cela ne manquera pas de perturber votre inspection, car la transparence est mise à mal.

Certaines équipes utilisent le Daily Scrum (ou Daily Stand-up) comme une réunion d'état. Cela peut contribuer à faciliter la transparence, mais l'inspection et l'adaptation finissent par être douloureusement oubliées. Le but de cet événement est, selon le guide lui-même, "d'inspecter la progression vers l'objectif du sprint et d'adapter le backlog du sprint." C'est clair : inspecter, puis adapter si nécessaire. "Répondre au changement plutôt que suivre un plan", selon le Manifeste pour le développement logiciel agile, est la ligne de conduite appropriée. Sauter les Scrums quotidiens, les organiser quelques fois par semaine, ne pas donner la parole à tous les développeurs et oublier l'objectif du sprint (si vous en avez un) sont quelques-uns des pièges qui pourraient tuer le pouvoir de l'inspection. Et sans inspection, vous ne pouvez pas vous adapter.

La revue de sprint n'est pas seulement une démonstration. J'ai vu de nombreuses équipes considérer la revue comme une démo (en l'appelant parfois la "Démo du Sprint"), comme une opportunité de "vendre" le produit aux parties prenantes. C'est une grave erreur. Lorsque vous travaillez avec Scrum, vous ne livrez pas de la valeur à vos parties prenantes, vous livrez aussi avec vos parties prenantes. Lors de cet événement, nous inspectons l'incrément pour voir ce qui a été fait par l'équipe. Plutôt qu'une présentation fantaisiste ou colorée (que vous jetterez probablement le lendemain), concentrez-vous sur la démonstration du travail effectué - la valeur livrée. C'est ce qui alimente l'inspection. Faites-le de manière transparente et adaptée avec vos parties prenantes, recueillez des commentaires - et n'ayez pas peur de les demander directement - et regardez le Backlog de produit pour vous aligner sur ce qui va suivre et vous adapter en conséquence.

L'une des plus grandes erreurs commises lors d'une rétrospective de sprint, même dans les équipes qui la sautent, est de ne pas exécuter les actions entreprises. Ou pire : ne pas prendre d'actions du tout. Si votre équipe n'agit pas, il n'y a pas d'adaptation. L'inspection sans adaptation est inutile.

La prochaine fois que vous vous rendrez à une cérémonie Scrum en tant que membre de l'équipe, gardez à l'esprit les avantages de la transparence et n'oubliez pas ce que vous souhaitez inspecter à cette occasion. Et, bien sûr, ce qui doit être adapté.