Finir tôt, accélérer plus vite

Des équipes stables: Maintenir des équipes stables et éviter de mélanger les personnes entre elles. Les équipes stables ont tendance à connaître leur capacité, ce qui permet à l'entreprise d'avoir une certaine prévisibilité.Le cadre Scrum s'articule autour d'une équipe de trois à neuf membres. Les petites équipes simplifient les voies de communication et permettent une saturation de la communication. Cependant, le fait d'avoir une petite équipe ne signifie pas qu'elle sera performante. Si les membres sont souvent retirés de l'équipe pour travailler sur d'autres projets ou s'ils ne sont pas en mesure de participer régulièrement aux rituels, la vélocité de l'équipe en souffrira. Les praticiens ont réalisé qu'ils avaient besoin non seulement de petites équipes, mais aussi d'équipes stables.

 

Météo d'hier: Dans la plupart des cas, le nombre de points d'estimation réalisés au cours du dernier sprint est le prédicteur le plus fiable du nombre de points d'estimation qui seront réalisés au cours du prochain sprint.La météo d'hier permet aux équipes de construire un journal de sprint plus précis, ce qui limite la possibilité pour l'équipe d'obtenir trop de points d'estimation et de mettre le sprint en danger. Les équipes stables connaissent leur capacité, ce qui leur permet d'utiliser la météo d'hier.

Une fois que les équipes stables ont établi un journal de sprint réaliste à l'aide de la météo d'hier, elles commencent leur sprint. De nombreux facteurs peuvent entraîner l'échec d'un Sprint. Les quatre modèles suivants sont conçus pour répondre aux écueils les plus courants du sprint.

 

L'essaimage: Concentre l'effort maximal de l'équipe sur un élément du carnet de commandes du sprint afin qu'il soit réalisé le plus rapidement possible. La personne qui s'occupe de cet élément est le capitaine de l'équipe. Chacun doit aider le capitaine s'il le peut et personne ne peut l'interrompre. Dès que le capitaine a terminé, la personne qui prend la responsabilité de l'élément prioritaire suivant du carnet de commandes est le nouveau capitaine.

Lorsque les équipes ont du mal à terminer les sprints, c'est généralement parce qu'elles ont trop de travail en cours et qu'elles ne se concentrent pas sur l'achèvement des éléments du Backlog de produit qui ont la plus grande valeur pour l'entreprise. Le Swarming aide les équipes à faire passer les éléments à "Done" rapidement, augmentant ainsi la Vélocité. La météo d'hier permet aux équipes d'essaimage d'augmenter la vélocité parce que l'équipe construit un journal de sprint réaliste.

Modèle d'interruption: Prévoir un temps pour les interruptions et ne pas le dépasser. Établir trois règles simples qui amèneront l'entreprise à s'auto-organiser pour éviter de perturber la production :

1. L'équipe crée une réserve pour les éléments imprévus sur la base des données historiques. Par exemple, 30% du travail de l'équipe en moyenne est causé par du travail non planifié qui arrive dans le sprint de manière inattendue. Si la vélocité de l'équipe est en moyenne de 60 points, 20 points seront réservés pour le tampon d'interruption.

2. Toutes les demandes doivent passer par le Product Owner pour être triées. Le Product Owner accordera une faible priorité à certains éléments s'ils n'ont pas de valeur perçue par rapport au plan d'entreprise. De nombreux autres éléments seront reportés à des sprints ultérieurs même s'ils ont une valeur immédiate. Quelques éléments sont critiques et doivent être réalisés dans le sprint en cours, le Product Owner les place donc dans la mémoire tampon d'interruption.

3. Si la mémoire tampon commence à déborder, c'est-à-dire si le Product Owner met un point de plus que 20 points dans le Sprint, l'équipe doit automatiquement abandonner, le Sprint doit être replanifié et la direction est informée que les dates de livraison seront dépassées.

Le modèle d'interruption, comme le Swarming, permet aux équipes de terminer leurs sprints parce qu'elles ont développé un processus pour traiter le travail trouvé.

Code de nettoyage quotidien: Corriger tous les bogues en moins d'une journée. L'objectif est d'avoir une base de code complètement propre à la fin de chaque journée.Si une équipe ne crée pas quotidiennement un code propre, elle peut perdre beaucoup de temps à revenir en arrière pour corriger les bogues. Il est possible de limiter les erreurs en intégrant le contrôle de la qualité dans le processus de développement, de manière à ce que les problèmes soient découverts et corrigés à leur point d'origine. Des recherches menées dans la Silicon Valley par Palm, Inc. en 2006 ont montré qu'un bogue qui n'est pas corrigé le jour même de sa création peut prendre jusqu'à 24 fois plus de temps à être corrigé trois semaines plus tard.

En créant quotidiennement un code propre, l'équipe limitera les interruptions plus tard dans le Sprint ou dans le Sprint suivant, lorsque l'erreur est plus difficile à corriger. L'idée est qu'une fois qu'une erreur a été détectée, analysée et corrigée, elle ne devrait plus jamais se reproduire. En éliminant les erreurs et en améliorant le processus quotidiennement, les équipes peuvent s'améliorer continuellement, augmentant la qualité avec la vélocité correspondante.

Procédure d'urgence: Lorsque le taux d'alcoolémie est élevé, essayez une technique utilisée couramment par les pilotes. Lorsque des problèmes surviennent, exécutez la procédure d'urgence conçue spécifiquement pour ce problème. Ne retardez pas l'exécution en essayant de comprendre ce qui ne va pas ou ce qu'il faut faire. Dans un avion de chasse, vous pourriez être mort en moins de temps qu'il n'en faut pour comprendre ce qui se passe. Il incombe au Scrum Master de s'assurer que l'équipe exécute immédiatement la procédure d'urgence du Scrum, de préférence au milieu du sprint, lorsque les choses ne tournent pas rond.

Étapes de la procédure d'urgence(ne faire que ce qui est nécessaire)

1 Changer la façon dont le travail est effectué. Faire quelque chose de différent.

2 Obtenir de l'aide, généralement en confiant le travail en retard à quelqu'un d'autre.

3 Réduire le champ d'application

4 Abandonner le sprint et replanifier

5 Informer la direction de l'impact sur les dates de diffusion

Les équipes stables utilisant la météo d'hier préparent l'équipe au succès en l'aidant à se mettre en état de préparation. L'essaimage, le modèle d'interruption, le nettoyage quotidien du code et l'arrêt de la ligne aident l'équipe à faire face aux obstacles au fur et à mesure qu'ils se présentent au cours du sprint. Les trois derniers schémas tirent parti des schémas précédents et permettent à l'équipe d'atteindre un état hyperproductif.

Scruming le Scrum: Identifier l'obstacle le plus important lors de la rétrospective du sprint et l'éliminer avant la fin du prochain sprint. Pour éliminer l'obstacle le plus important, mettez-le dans le carnet de sprint comme une histoire d'utilisateur avec des tests d'acceptation qui détermineront quand elle sera terminée. Ensuite, évaluez l'état de l'histoire lors de la revue de sprint, comme n'importe quelle autre tâche.Si l'équipe est en mesure de capitaliser sur Scruming the Scrum, elle devrait créer au moins une amélioration de processus par sprint. Cela contribue à augmenter la vélocité 10% de chaque sprint. Si l'équipe utilise la météo d'hier, elle a de bonnes chances de terminer son sprint plus tôt car elle aura un obstacle de moins qui ralentira sa vélocité.

Mesure du bonheur: Le bonheur est l'une des meilleures mesures car il s'agit d'un indicateur prédictif. Lorsque les gens pensent à leur bonheur, ils se projettent en réalité dans l'avenir. S'ils ont l'impression que l'entreprise est en difficulté ou qu'elle fait fausse route, ils seront malheureux. Ou s'il y a un obstacle majeur ou un système frustrant auquel ils doivent faire face, ils seront mécontents.Un bon moyen de prendre le pouls de l'équipe est de savoir si elle est heureuse.

Le Scrum Master pose seulement 2 questions :-

Êtes-vous satisfait de l'entreprise ?

Êtes-vous satisfait de votre rôle ?

Les membres de l'équipe sont invités à évaluer leurs sentiments sur ces questions sur une échelle de 1 à 5. Ces chiffres sont conservés dans une feuille de calcul et suivis au fil des semaines. Chaque fois que la moyenne change de manière significative, il est important d'en parler et de voir comment l'équipe peut être plus heureuse. En surveillant le niveau de satisfaction de l'équipe, le Scrum Master peut anticiper les baisses de vélocité et procéder à des ajustements.

Les équipes qui finissent tôt accélèrent plus vite: Les équipes prennent souvent trop de travail dans un sprint et ne peuvent pas le terminer. L'échec empêche l'équipe de s'améliorer. Il faut donc réduire la charge de travail lors d'un sprint. Maximisez vos chances de réussite en utilisant le modèle de la météo d'hier. Ensuite, mettez en œuvre les quatre modèles qui réduisent les obstacles au sein du sprint, ce qui permettra de gérer systématiquement toutes les interruptions et vous aidera à terminer plus tôt.

En cas d'achèvement rapide, tirez sur le prochain Product Backlog, ce qui augmentera le Yesterday's Weather pour les sprints à venir. Pour augmenter la probabilité d'accélération, appliquez la méthode Scrum pour identifier votre kaizen lors de la rétrospective. Placez le kaizen dans le backlog du sprint avec les tests d'acceptation pour le prochain sprint comme priorité absolue.En utilisant les modèles sous-jacents du FEAF, les équipes stables construisent un journal de sprint réaliste, puis se mettent en essaim.

L'atténuation des interruptions et la gestion des circonstances imprévues aident les équipes à terminer plus tôt. Lorsque l'équipe termine tôt, elle peut alors retirer davantage d'éléments du carnet de commandes. Ce faisant, la vélocité augmente, ce qui accroît la base de référence de la météo d'hier. Par conséquent, l'équipe obtiendra plus de points pour le sprint suivant, ce qui accélérera le processus. Si les équipes sont capables d'exécuter ces schémas de manière cohérente, au fil du temps, elles atteindront un état hyperproductif.