Catégories
Start-up et applications

Scrum et SAFe: quatre conseils pour les Scrum Masters

Alors que le développement de logiciels Agile continue de s'imposer dans tous les secteurs, ainsi que les pratiques et les outils DevOps, l'amélioration de la fourniture de produits et de services est de plus en plus au centre des préoccupations de nombreuses entreprises. S'assurer que les objectifs commerciaux et les exigences des clients sont satisfaits est la clé de la livraison de logiciels. Cela nécessite une planification et une organisation détaillées de toutes les équipes travaillant pour atteindre ces objectifs. Alors que la collaboration et les équipes interfonctionnelles deviennent la nouvelle norme, l'orchestration et la planification doivent également être collaboratives.

Le Scaled Agile Framework (SAFe) établit une cadence de planification et d'incréments, qui doivent être orchestrés et gérés à différents niveaux. Gérer cette planification au niveau qui concerne directement les équipes de développement fait partie de notre rôle de Scrum master.

CONTENU CONNEXE:
Comment démarrer avec SAFe
Mise à l'échelle de bas en haut

Les Scrum Masters agissent comme des ponts entre les équipes de développeurs, les objectifs commerciaux et ce qui peut être attendu et réalisé de manière réaliste. Nous devons veiller à surveiller les obstacles auxquels les développeurs sont susceptibles de faire face, mesurer le niveau de compréhension des objectifs commerciaux et gérer les éléments qui peuvent nuire à leur capacité à les atteindre. Une communication efficace est essentielle, tout comme une capacité à gérer les tâches quotidiennes de développement logiciel.

Pour comprendre notre rôle et les défis auxquels nous sommes confrontés, voici quatre domaines clés pour les Scrum Masters:

1. Tenez-vous en aux cérémonies

Pour nous, les quatre cérémonies Scrum (planification de sprint, réunion quotidienne, revue de sprint et rétrospective de sprint) sont essentielles, et nous devons nous assurer qu'elles ont lieu et sont suivies par tous les responsables de l'atteinte des objectifs. Cela signifie travailler avec des développeurs individuels pour les aider à s'approprier des tâches, c'est-à-dire des histoires définies par la méthodologie Agile, et leur fournir le soutien dont ils ont besoin.

S'assurer que les tableaux JIRA sont à jour et préparer les prochaines itérations nous oblige à travailler en étroite collaboration avec les propriétaires de produits, en les encourageant à traiter les arriérés de tâches, en revisitant les priorités et en les remettant en question lorsqu'il s'agit de réévaluer la feuille de route du produit. Le pointage de l'histoire est une partie essentielle de l'établissement des domaines qui nécessitent le plus d'attention. Nous devons nous assurer que les objectifs du sprint sont atteints et que les histoires en cours de progression ne sont pas seulement celles qui sont plus intéressantes ou amusantes, mais plutôt celles qui nous poussent à fournir une fonctionnalité.

2. L'importance de la communication

L'établissement du poids d'une histoire est un élément clé de la planification quotidienne car il permet aux équipes de se parler et permet une évaluation plus dynamique et transparente des priorités. Cela aide les développeurs, les Scrum masters et les chefs de produit à arriver à une compréhension mutuelle d'un projet, centrée sur la livraison d'une fonctionnalité.

La structure Agile donne la priorité à la collaboration plutôt qu'à la hiérarchie. Une communication efficace est donc une compétence clé pour les Scrum Masters. Nous devons bien comprendre les objectifs commerciaux et les exigences des clients et nous assurer que les équipes de développeurs en tiennent compte à mesure que nous progressons. Mais il y a bien sûr des défis à surmonter.

Travailler en Agile, c'est être capable de s'adapter au changement si nécessaire. Les développeurs sont motivés par leurs histoires, mais ne doivent pas être déterminés dans cette approche, car le point final atteint notre objectif de sprint et fournit ce que les clients veulent. La principale mise en garde à ce principe fondamental, cependant, est que nous ne devons pas rendre parfait l'ennemi du grand, ni même le grand ennemi du bien. C'est pourquoi une communication transparente en interne est essentielle.

3. Repousser pour pousser

Si un changement est demandé pendant un sprint, nous devons évaluer la capacité des équipes, ainsi que l'importance du changement. Dans un monde idéal, il n'y aurait pas de nouvelles exigences introduites lors d'une itération, mais c'est rarement le cas. Le changement de dernière minute est plus une attente qu'un inconvénient, nous devons donc intégrer l'imprévu à notre planification.

Les Scrum Masters n'aiment pas incorporer les changements de dernière minute à la volée, préférant à la place pousser de nouveaux changements dans l'incrément suivant. C'est là que nous devons travailler avec les chefs de produit pour décider des «éléments indispensables» pour une certaine fonctionnalité, ce qui nécessite à nouveau une compréhension approfondie des exigences des clients, car une solution viable peut souvent les satisfaire avant que l'idéal ne soit possible.

Lorsque nous commençons à implémenter des fonctionnalités, nous apprenons également de nouvelles contraintes et dépendances qui nous ralentissent, ce qui peut nécessiter un recentrage des priorités. Nous pouvons, par exemple, avoir besoin de la validation de l'architecte pour fusionner le code et pour les pull requests qui nous permettent de le déployer. Mais les architectes n'ont généralement pas les mêmes contraintes de temps qu'une équipe Scrum, car ils se concentrent sur l'incrément entier, plutôt que sur les délais de sprint auxquels les développeurs travaillent.

Relever ces défis est une partie essentielle de nos réunions rétrospectives. Dans SAFe, nous sommes en mesure de le faire au niveau de l'équipe à chaque itération avec des rétrospectives Scrum, ainsi qu'à la fin des ateliers Incréments de programme avec Inspect and Adapt (I&A). Ceux-ci nous aident à identifier où les problèmes peuvent avoir causé des goulots d'étranglement et à établir de meilleurs processus à l'avenir.

4. Comprendre l'état d'esprit du développeur

Travailler en Agile signifie que les développeurs sont responsables de la façon dont leur code fonctionne dans l'environnement de production. La révision du code n'est pas la seule responsabilité du contrôle qualité, car une histoire n'est «terminée» que lorsque le code est déployable.

Parlant d'expérience de première main, écrire et vérifier du code est ce que les développeurs veulent faire, car ils sont axés sur les objectifs et aiment atteindre les jalons et progresser le long des feuilles de route des produits. Mais comme la définition de «terminé» se rapporte au code qui est prêt pour les utilisateurs finaux, il n'y a pas de transfert à d'autres équipes, QA ou autre. Cela signifie que les développeurs doivent toujours travailler avec l'hypothèse que leur code sera déployé.

C'est là que la mentalité DevOps est cruciale, car les équipes partagent la responsabilité de l'expérience de l'utilisateur final et comprennent pleinement leur propre partie intégrante de la chaîne de valeur lorsqu'il s'agit de la livraison. Ceci est habilitant pour les développeurs et est également avantageux pour les flux de travail Agile.

En tant que maîtres Scrum, la réduction du travail en cours est un élément clé de notre rôle, c'est pourquoi un état d'esprit DevOps, mettant l'accent sur la collaboration et l'appropriation totale du travail, informe comment nous interagissons avec et organisons les équipes et les tâches.

Un autre point d'attention important que nous avons, est de réduire autant que possible le nombre d'objectifs pour un sprint donné. Idéalement, avoir un seul objectif, sur lequel tous les membres de l'équipe peuvent contribuer, augmente la livraison de valeur (seulement réalisée lorsque les histoires sont faites) et contribue à établir / (re) renforcer l'esprit d'équipe.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *