Notre version d'Agile ne fonctionne pas. Conseils?

Je travaille sur une petite équipe de 4 développeurs. Nous mettons en œuvre une version d'Agile qui semble nous fournir continuellement les mêmes difficultés, semaine après semaine, et je recherche des suggestions qui peuvent nous aider à améliorer notre processus.

L'arrière-plan:

Nous faisons généralement des sprints de 2 semaines, et à chaque sprint, nous avons tendance à sous-estimer notre travail, et nous avons des problèmes avec notre manager parce que nous sommes en retard.

Nous commençons chaque sprint en classant les histoires que notre manager crée pour nous. Parfois, il lance aussi les tâches et nous les estimons. Nous n'utilisons pas de points d'histoire. Nous utilisons le logiciel Urban Turtle pour "gérer nos sprints", qui ne sont essentiellement que des histoires et des tâches, et le burn down associé. Nous ne prévoyons pas de sortie à la fin d'un sprint.

Le problème le plus courant qui se produit est que nous planifions une tâche au début d'un sprint pour découvrir qu'elle est beaucoup plus étendue, mais toujours prioritaire, nous devons donc y travailler des heures supplémentaires. Le deuxième problème le plus courant est que l'un de nous rencontre un problème technique qui ralentit les heures brûlées, provoquant un barrage routier.

La seule suggestion qui nous est faite est d'être plus proactif dans l'ajustement de nos estimations et de fournir des mises à jour lors des standups le matin afin que nous puissions nous ajuster pour le temps supplémentaire nécessaire.

Cependant, il semble y avoir quelque chose de fondamentalement mauvais dans la façon dont nous faisons les choses. Il y a peut-être un décalage entre les attentes du manager au niveau du projet et les attentes au niveau du sprint. Parce que nous faisons ces itérations de sprint selon un plan de projet, et donc étendre un sprint ou différer des éléments fausse le plan de projet. Donc, en tant que développeurs, nous sommes encouragés à effectuer Agile en étendant les estimations lorsque cela est nécessaire, mais aussi en complétant le sprint à temps, ce qui est déroutant.

Cela ne peut pas être un problème rare, donc j'espère que ceux qui sont plus sages que moi ont une suggestion ou deux sur la façon dont nous pouvons arrêter de rencontrer ce même problème à chaque sprint. C'est frustrant.

parce que nous sommes en retard

Ce type de réflexion est votre problème. Vous n'êtes pas en retard sur le calendrier, le calendrier est trop serré. Vous devriez commencer à estimer les histoires en points abstraits plutôt qu'en heures, puis au cours de 2-3 itérations, déterminez votre vitesse. Votre vitesse est le nombre de points que vous effectuez habituellement à chaque itération, pas le nombre de points que votre manager souhaite intégrer.

Après cela, peu importe si vous sous-estimez constamment les tâches - votre vitesse en tient déjà compte.

Évidemment, cela est impossible si vous utilisez des heures au lieu de points.

Il semble que les problèmes soient l'incapacité de votre équipe à faire des estimations précises et l'incapacité de prévoir les problèmes inévitables.

Les petites tâches sont beaucoup plus faciles à estimer avec précision que les grandes tâches, alors essayez de diviser vos tâches en morceaux beaucoup plus petits.

Ne permettez à personne d'estimer une tâche, à moins qu'il ne sache exactement comment il va le faire. Pour toute tâche que le développeur ne sait pas quoi accomplir, mettez du temps dans le calendrier de CE sprint pour que le développeur fasse une enquête et une conception, et arrive à une estimation précise. Jamais moins d'une demi-journée. Mais déplacez la tâche vers le sprint suivant. Ensuite, lorsque vous arriverez à la planification du prochain sprint, vous aurez une bonne estimation. Notez que ce temps supplémentaire n'est pas perdu, car il est temps que le développeur finisse par dépenser de toute façon.

Et n'ayez pas peur de retourner voir le chef de projet et de lui dire que vous aurez besoin de plus de sprints pour parcourir la liste des tâches. Il vaut mieux le faire que de s'engager sur des cibles impossibles.

Essayez-vous d'allouer 100% de votre temps? Si oui, arrêtez de faire ça. Commencez par additionner toutes les heures que votre équipe doit consacrer au sprint. Pour ce faire, en supposant que chaque travailleur consacrera au mieux 6 heures par jour au projet. Ceci est considéré comme une "journée idéale". Ces deux autres heures? Aspiré par les réunions, les pauses, les tâches administratives, cette heure du matin où vous lisez des e-mails et planifiez votre journée, etc. Ce n'est pas "couvrir vos paris" ou "sacs de sable", c'est être réaliste.

Deuxièmement, multipliez ces 6 heures / jour par 80% . Pourquoi? Parce qu'en tant qu'êtres humains, nous craignons de prédire combien de temps une tâche prendra. Cela explique les erreurs de notre jugement. Encore une fois, pas de sacs de sable, c'est réaliste.

Vous disposez maintenant d'un nombre représentant un nombre réaliste d'heures que vous prévoyez d'appliquer directement à vos tâches. Lorsque vous faites une estimation, arrêtez d'ajouter des histoires lorsque la prochaine histoire vous mettra au dessus.

Enfin, ne laissez pas le propriétaire du produit ajouter des tâches. La planification Scrum est pour l' équipe , le PO ne fait pas partie de l'équipe qui fait le travail. Bien sûr, dans le monde réel, si le PO est plus compétent que quiconque dans l'équipe, sa contribution peut être très utile. Pourtant, si l'équipe prend la chaleur pour être en retard, l'équipe doit s'approprier exactement les tâches qu'elle fera. Votre objectif est de pouvoir répondre aux critères d'acceptation; si une tâche ne mène pas directement à cela, ne le faites pas.

Rappelez-vous, Scrum ne consiste pas à être plus productif. Il s'agit d'être plus ouvert et communicatif. Le travail prendra tout ce qu'il faut pour être fait. Scrum est là pour faciliter l'estimation, la communication avec les parties prenantes et la prise d'engagement de votre équipe.

Critères d'acceptation mal définis au début du sprint?

Les estimations initiales sont souvent trop faibles car les cartes récits ont de mauvais critères d'acceptation (le cas échéant) lorsqu'elles sont estimées. Qu'en est-il du passage au développement piloté par les tests d'acceptation (ATDD), c'est- à-dire le storytesting, pour aider l'équipe à bien comprendre ce qu'est la carte?

Des histoires trop grandes?

Une autre raison pour laquelle vous découvrez au milieu du sprint que vos histoires prennent plus de temps que prévu est peut-être qu'elles sont trop grandes. Avez-vous vu l' Agile dans un jeu de cartes flash? Ils ont une carte flash appelée "Shrink XL stories to Fit". Il donne des stratégies pour diviser les histoires comme reporter les cas marginaux, les effets secondaires, les aspects non fonctionnels ou la gestion des erreurs dans les histoires ultérieures.

Vous ne pouvez pas estimer car vous ne disposez pas d'informations suffisantes?

@sleske fait une bonne suggestion sur les pointes . Essayez d'identifier les inconnues techniques au moment de l'estimation. S'il y en a , voir si vous pouvez reporter l'histoire dans un sprint plus tard et au lieu faire un temps caissonné enquête (pic) ce sprint pour essayer d'apprendre ce qu'il faut pour être en mesure d'estimer. Ne vous laissez pas emporter et résolvez l'histoire originale - le pic est fait lorsque vous en savez assez pour estimer l'histoire.

Échec plus rapide

Et je suis d'accord avec @Patrick Hughes - envisagez de passer à des sprints d'une semaine afin que vous puissiez voir les problèmes plus rapidement.

En plus des bonnes suggestions de @Kevin et @Patrick ...

Les approches agiles ne sont pas «universelles» mais ce commentaire a retenu mon attention:

Nous mettons en œuvre une version d'Agile qui semble nous fournir continuellement les mêmes difficultés

Vous feriez mieux de commencer avec une méthodologie "par le livre" (Scrum est dominant de nos jours, il semble) - et faites EXACTEMENT ce qu'une autre équipe réussie a fait ... Faites cela pendant quelques sprints ... Et alors seulement commencez à considérer changements nécessaires pour optimiser les conditions locales.

La location d'un coach Scrum expérimenté (pour quelques itérations) peut être une véritable différence. Il est subtil de devenir agile correctement.

Je recommande d'abord de suivre le livre scrum-xp-from-the-trenches . Regardez à la page 26 le point sur les calculs de vitesse. L'idée est de définir un facteur de focus, et de dire que pour le prochain Sprint:

jours-homme disponibles * facteur de focalisation = vitesse estimée

la vitesse estimée est la somme des estimations des histoires que vous prévoyez de mettre en œuvre lors du prochain sprint.

Et après un Sprint, vous calculez le dernier facteur de focalisation Sprint comme suit:

facteur de focalisation = vitesse réelle / jours-homme disponibles

où la vitesse réelle est la somme des estimations des histoires que vous avez mises en œuvre pendant le sprint.

Ensuite, vous réutilisez ce facteur de mise au point réel pour le prochain Sprint, et après quelques Sprint, vous pourrez être plus précis avec tout ce que vous pouvez vraiment réaliser pendant un Sprint ...

Jusqu'à ce que vous obteniez vos estimations afin de raccourcir vos sprints à une semaine, de cette façon, vous reconnaîtrez le dépassement plus rapidement et pourrez réagir par petits incréments.

Passez plus de temps à l'avance lors de la conception de tâches pour obtenir une certaine marge de manœuvre pour reconnaître les effets secondaires qui sont probablement à l'origine de la saignée partout. Il se peut également que les tâches elles-mêmes soient trop longues pour une estimation agile appropriée, voir si les tâches peuvent être décomposées en étapes plus courtes qui seront plus faciles à avaler.

Mettez tout le monde à l'aise avec l'envoi d'un drapeau rouge dès qu'il a heurté un problème au lieu de rester bloqué sur un problème pendant quelques heures. Essayez de détacher l'ego et le blâme de ce processus, c'est plus facile pour certains que pour d'autres =)

Et comme @Kevin l'a évoqué, vous ne planifiez jamais vraiment à 100% directement des tâches car il y a toujours des frais généraux comme les réunions et ainsi de suite que vous ne reconnaissez peut-être pas comme des mangeurs de temps.

Lorsque tout va bien sur le plan de la planification, puis revenez à deux semaines, vous récupérerez comme par magie un peu de temps du moins de réunions.