Business : Aidez-moi! Où est mon Amigo?

Quelques enseignements tirés de l’utilisation de la pratique Agile complémentaire des 3 amigos face au changement et à l’adversité.

Les «3 amigos» permettent à différentes perspectives des communautés d’affaires, de développement et de test de se réunir pour assurer une compréhension commune des User Stories au sein de l’équipe.

La pratique peut inclure plus de trois personnes. Trois à quatre amigos travailleront plus rapidement qu’une grande équipe, mais surtout, les bonnes personnes avec les connaissances et l’autorité de décision doivent être présentes. Une fois que la clarté de la User Story est claire, elle doit être communiquée au reste de l’équipe.

C’est une pratique que j’ai eu plaisir à présenter aux équipes nouvellement formées avec lesquelles j’ai travaillé, pour discuter des histoires plus complexes que nous ne pouvions pas traverser dans Backlog Refinement.

Lorsque cette pratique se déroule bien, les Scrum Masters éprouvent une lueur chaleureuse en voyant les amigos décomposer la complexité, gagner en clarté et commencer à travailler vers des critères d’acceptation bien compris.

Que se passe-t-il lorsque vous rencontrez des défis avec cette pratique sous la forme de certains comportements ou dynamiques d’équipe qui commencent à avoir un impact sur la qualité de votre produit?

Ce post explore quelques apprentissages basés sur ma propre expérience, en inculquant cette pratique au sein des équipes.

Dans une de mes vies en tant que Scrum Master, mon équipe est passée d’une situation où nous avions un Product Owner pleinement engagé qui assistait à tous les événements Scrum pertinents, à une baisse spectaculaire de la disponibilité.

Mon équipe était en train de créer une application mobile avec une couverture nationale. Les dates de sortie ont été publiées. Nos parties prenantes observaient les progrès avec un vif intérêt, mais nous n’avions tout simplement pas le temps dont nous avions besoin pour le Product Owner.

Pour réunir l’équipe, j’en ai profité pour réserver un espace hors site pour la Rétrospective. Notre Product Owner a accepté, à mon grand soulagement!

À la Rétrospective, l’équipe a vocalisé ses frustrations et le Product Owner a expliqué qu’il essayait de se familiariser avec 3 autres projets en réduisant le temps de réunion. Maintenant qu’il avait compris les exigences et la complexité de ces projets, il était heureux d’en déléguer quelques-uns à un autre membre de son équipe, pour lui permettre de revenir sur notre projet.

J’ai eu la chance que notre Product Owner ait pensé à un plan B, mais je suis quand même parti avec quelques leçons….

CONSEILS

Agissez tôt: Vérifiez régulièrement avec toutes vos parties prenantes concernant les ressources. Ne faites pas ce que j’ai fait dans ce scénario et n’agissez que lorsque la disponibilité de votre Product Owner commence à baisser!

Apprenez à connaître la communauté des propriétaires de produits: Que ce soit par le biais de réunions planifiées ou de sessions de déjeuner et d’apprentissage, j’ai trouvé qu’il était important de connaître la communauté et ses spécialités de produits. Cela vous permet de proposer des solutions pour les propriétaires de produits de secours, si vous en avez besoin pour vous soutenir et faire partie de la conversation sur les ressources bien à l’avance.

Choisissez occasionnellement un paramètre hors site pour votre rétrospective: S’éloigner du bureau même pendant une heure, permet à votre équipe de s’éloigner des distractions et leur donne la possibilité de partager leurs défis et / ou frustrations, dans un cadre informel.

Je dirigeais une équipe Scrum dans un environnement d’agence. Le projet de l’équipe était de fournir des sites Web renommés pour une marque domestique sur 14 marchés dans le monde. Nous avions 6 mois pour terminer le projet.

Les personnalisations pour les marchés individuels arrivaient rapidement et de manière épaisse. Nous avons utilisé le principe des 3 amigos pour résoudre rapidement les exigences complexes, puis les avons planifiées dans une version afin que le marché sache quand les attendre.

Au mois 2 du projet, notre testeur ne se présentait pas aux 3 sessions d’amigos pour discuter des personnalisations.

Au cours d’un café, j’ai appris qu’elle était épuisée, mais je ne voulais pas être considérée comme un membre de l’équipe qui ne pouvait pas gérer le rythme ou le volume de travail.

Ce que je pensais était un manque de motivation, vraiment pas. Cela m’a fait penser au nombre d’autres membres de l’équipe qui se sentaient également sur le point de marcher et combien de temps il faudrait avant que la qualité des versions du marché ne baisse. Il était temps de prendre un peu de recul sur les heures de travail et de rééquilibrer la balance afin qu’ils puissent fonctionner au mieux….

CONSEILS

Valeurs Scrum: Mon point de vue sur les valeurs est qu’elles sont là pour la protection et le développement de l’équipe Scrum. J’ai refait surface et j’ai eu une discussion avec l’équipe sur ce que chacune des valeurs signifiait pour eux afin qu’ils puissent former un accord de travail sur la façon dont ils voulaient fonctionner. L’équipe a commencé à s’ouvrir les uns aux autres et à de nouvelles façons de travailler. Ils savaient qu’ils devaient travailler à un rythme durable. Ces personnes surchargées de travail ont pris la parole, nous avons cartographié le travail excédentaire et présenté un dossier au directeur des comptes pour obtenir des fonds supplémentaires et intégrer des membres supplémentaires de l’équipe.

Revoyez vos estimations: Nous utilisions à peine 5% du temps sur le Backlog Refinement qui était précipité, ce qui entraînait une sous-estimation de l’effort de test. L’équipe a décidé de l’étendre à la règle de base de 10%. Ils passeraient ensuite en revue les estimations pendant les rétrospectives et conviendraient de la façon dont ils pourraient améliorer l’estimation et intégrer leurs apprentissages dans la prochaine planification de sprint.

Imaginez ma surprise et mon sentiment de terreur lorsque notre propriétaire de produit entre dans la mêlée quotidienne le premier jour d’un sprint et dit:

« Hé Nisha, c’est formidable que nous puissions ajouter quelques histoires de dernière minute pour réduire la dette technologique. »

Sans parler à personne d’autre dans l’équipe, notre responsable du développement, alias le Lone Ranger, utilisait les 3 sessions d’amigos pour convaincre le propriétaire du produit que c’était une bonne idée d’ajouter des histoires après l’équipe avait déjà convenu de la portée du prochain sprint.

Ces histoires apparaîtront comme par magie sur le Sprint Backlog et le responsable du développement convaincra l’équipe qu’il pourrait facilement gérer les histoires et les terminer avec beaucoup de temps pour les tests.

Par crainte de se retrouver du mauvais côté du responsable du développement, l’équipe a accepté. Cependant, j’ai noté des murmures indiquant qu’ils n’étaient pas à l’aise de ne pas avoir évalué l’impact sur le code sur lequel ils travaillaient ou l’effort de test.

J’ai décidé que je n’allais pas affronter notre Lone Ranger, je voulais laisser le Sprint jouer pour voir si nous pouvions respecter notre engagement. Pour encourager l’auto-organisation, je voulais que l’équipe fasse ressortir ce problème lors de la Rétrospective et trouve une solution pour les travaux imprévus.

Deux jours avant la fin du Sprint, le responsable du développement a annoncé qu’il prévoyait d’intégrer une quantité importante de code pour les histoires techniques.

Gardez à l’esprit que ce code n’a pas été révisé par des pairs et aucun de nous ne savait avec certitude combien de tests unitaires avaient été effectués. L’équipe n’en avait pas. Les objections ont commencé des testeurs et ont traversé l’équipe. Disons que ce fut un moment «Spartacus».

L’équipe a renseigné ses activités sur la chronologie rétrospective et lorsqu’il s’agit de classer les activités comme «bonnes,« mauvaises »ou« à améliorer », la majorité des« mauvaises et «à améliorer les besoins post-it» ont été trouvées par les techniciens non planifiés. histoires.

L’équipe a expliqué qu’elle souhaitait réaliser ses prévisions et pouvoir croire qu’elle ne serait pas surprise d’un travail imprévu. Le responsable du développement s’est dit préoccupé par le fait que l’impact de la non-réduction de la dette technique pourrait éventuellement conduire à une dégradation des performances.

Le résultat a été un accord raisonnable selon lequel une fois l’étendue du Sprint scellée à la fin de la planification du sprint, de nouvelles histoires ne devaient pas être introduites, sans renégociation entre le propriétaire du produit et l’équipe de développement, à mesure que l’on en apprendrait plus. Si les membres de l’équipe terminaient leur travail, ils aideraient l’équipe à terminer le travail en cours.

Personne n’a contesté la nécessité d’entreprendre des travaux pour réduire la dette technique, de sorte que l’équipe a accepté de parler au propriétaire du produit et d’accepter de réserver un pourcentage sensible de sa capacité à cet effet.

CONSEILS

Accord de travail: Lorsque vous formez un accord de travail avec l’équipe, décidez de la politique de votre équipe sur le travail imprévu. Peu importe que la politique soit adaptée ultérieurement. Avoir un point de départ est mieux que rien.

Rétrospectives: Bien dirigées, les rétrospectives peuvent avoir tellement de valeur et je travaille à améliorer mes compétences. J’ai constaté que l’observation attentive des comportements de l’équipe et des réponses aux défis pendant le sprint donne des indices précieux sur la façon dont la session peut être facilitée et les exercices que vous pouvez utiliser. Pour moi, l’objectif global est de créer un environnement sûr pour que l’équipe puisse parler librement, avec sensibilité et un sentiment de confiance afin de déclencher elle-même des actions pour surmonter les obstacles qu’elle rencontre.

« Vous improvisez, vous vous adaptez, vous surmontez »

Clint Eastwood, Heartbreak Ridge

L’application de la pratique simple des 3 amigos a soulevé des défis clés pour moi qui m’ont encouragé à former mon regard vers la dynamique de l’équipe pour tirer le meilleur parti de la pratique.

Mes propres qualités de leadership de serviteur ont été développées en créant des opportunités pour les équipes de décider comment ils souhaite relever les défis. Cela a permis un espace de réflexion et d’appropriation des remèdes proposés, ce qui les a remis sur la bonne voie pour réaliser leur statut Rockstar en apportant de la valeur à l’entreprise.

Voulez-vous écrire pour Serious Scrum ou discuter sérieusement de Scrum?