Conduite du changement : quels INDICATEURS (KPI) de SUIVI de la TRANSFORMATION AGILE ? (Matrice)

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/TVbb7C

[@fredericpetit3474]

Super épisode ! Je partage mon expérience du coup. Il y a quelques années j'ai changé de boîte et on m'a positionné Scrum Master d'une équipe qui était déjà en place depuis plusieurs mois et sans Scrum Master. Du coup pour me faire une idée plus objective que mes propres ressentis, sur le 1er sprint j'ai tenté de mesurer l'agilité de l'équipe. Etant novice et un peu paumé, ça me semblait être la meilleure idee car cela pourrait aussi m'aider à me former pour mieux appréhender l'état d'esprit de l'agilité. Ne sachant pas par où commencer, j'ai fait, seulement pour moi, une matrice/évaluation par éléments qui me semblaient importants / fondateurs (les valeurs du Manifeste Agile, les principes du Manifeste Agile, les piliers Scrum, les valeurs Scrum). Du coup ces 4 matrices m'ont permis de jeter des premiers ressentis et de pouvoir régulièrement revenir dessus pour les rendre plus objectifs en les transformant en pratique qui pourraient être à réaliser. Bien évidemment, en faisant ce travail sur 4 matrices et pour chaque axes ... on répète vite la même chose même si c'est exprimé différemment selon les moments. A la fin du sprint, j''ai commencé à partager mon avis grâce à ces matrices. Par la suite l'équipe se l'est approprié pour n'en faire qu'une seule et en choisissant les éléments qui leurs semblaient importants. Selon moi, même sans demande de la boîte, se forcer à faire ce travail est extrêmement bénéfique pour tout le monde. Ca oblige à se poser des questions sur le sens de ce que l'on fait et amène à le prendre en compte au quotidien. A ce jour ça me semble toujours meilleur moyen de bien travailler.

[@ScrumLife]

Merci Frédéric pour ce partage.

[@zenshaoli]

Salut ! Merci pour votre matrice ! Juste une petite correction que je propose sur la ligne : "Le backlog d'itération est ordonné par priorité" Il est ordonnancé par ce que tu veux (priorité, valeur métier, risque, dépendance, effort, coût de délai...) pour maximiser la valeur, pas forcément par priorité...

[@ScrumLife]

Bonjour Jean-Christophe merci pour ton commentaire. On peut peut être en effet le formuler autrement mais la valeur, le risque, etc ne sont-ils pas des priorités ? Quand je parle de priorité je parle de celle de l’équipe. Ce qui peut d’ailleurs évoluer dans le temps. Tu entends quoi toi par priorité et qui t’a fait réagir à ça ? - Constantin

[@francois5483]

Merci pour cette vidéo très intéressante. J'ai jeté un œil à la proposition de matrice d'évolution mais je n'ai pas tout compris à son utilisation et en particulier la distinction entre les croix grises et les coches vertes (y en a une qui est mieux que l'autre?).

[@fredericdehin402]

Merci, J'ai fait rapidement une version anglaise pour mon équipe... Celà vous intéresse ?

[@ScrumLife]

Carrément, n'hésite pas à la partager sur LinkedIn par exemple et à nous l'envoyer ;) -- Constantin

[@fredericdehin402]

@@ScrumLife J'envoie vu que le partage sur Linkedin, c'est pas mon fort ... :-)

[@portoyosh]

Très intéressant, comme toujours. Ceci étant, je me permets de faire une petite remarque: au lieu de parler d'excellence technique, je pense qu'il serait plus pertinent de parler d'efficience, car on peut tout à fait envisager de faire quelque chose de façon non optimale, voir crade pour accélérer la livraison du produit / d'une feature. Tout est une question de gestion de la dette technique ;)

[@ScrumLife]

Bonjour Daniel, merci pour cet ajout. C'est une problématique intéressante que tu exposes là. À quel point considères-tu "livrée" une fonctionnalité incomplète (pas propre = incomplète, puisqu'il faudra revenir dessus) ?

[@portoyosh]

Je considère qu'une feature est livrable tant qu'elle répond à la demande fonctionnelle. Ensuite, il n'est pas obligatoire de revenir dessus à tout prix, mais seulement si les métriques attendue ne sont pas bonne (par exemple, pour les techniciens cela peut être le taux d'erreur associé à la feature qui est trop important par rapport à ce qui est attendu). Le concept est connu est sous le terme de "budget error".

[@OlivierFarlotti]

@@portoyosh dans ce contexte, est-ce que simplifier la feature a été envisagé ? Est-ce que l'équipe est au claire sur ce qu'elle appelle du "durty" ? Est-ce que ce sont des cas de test non couvert (mais qui ne plantent pas) ou du code dont on a aucune idée de comment il va se comporter ? Du coup est-ce que c'est une stratégie business ou est ce que c'est une lacune de l'équipe dans ses pratiques de code ?

[@emilieesposito]

Je suis alignée là-dessus :-) Pour info, je parle du cargo cult agile là : mixitconf.org/en/2017/cargo-cult-agile J'ai lu ton article dessus à l'instant, je vois qu'on est alignés là-dessus aussi ;-)

[@ScrumLife]

Salut Emilie ! Top de t'avoir ici ☺️

[@emilieesposito]

@@ScrumLife avec plaisir :-) fun + qualité : je kiffe ;-)