L'équipe ne parvient pas à atteindre ses objectifs de sprint

Nous sommes une petite entreprise de logiciels avec un seul produit.

Nous utilisons Scrum et nos développeurs choisissent les fonctionnalités qu'ils souhaitent inclure dans chaque sprint. Malheureusement, au cours des 18 derniers mois, l’équipe n’a pas encore fourni les fonctionnalités qu’elle s’était engagées à faire pour un sprint.

J'ai lu beaucoup de messages / réponses disant que "le logiciel est fait quand c'est fait, pas plus tôt, pas plus tard ... ça n'aide pas de mettre de la pression sur l'équipe, de mettre plus de gens dessus, ... "J'ai reçu les mêmes commentaires d'un des développeurs sur ma question, à savoir comment améliorer le taux de réussite des sprints. Oh, et oui, nous utilisons des rétrospectives .

Ma question est fondamentalement:

Quand est-il juste de chercher le problème de la qualité des développeurs?

Je commence à penser que si vous arrivez à choisir votre propre travail / fonctionnalités et échouez toujours à chaque sprint: - vous n'êtes pas en mesure de superviser la complexité de votre propre code; - ou le code est si complexe que personne ne peut en surveiller la complexité.

Est-ce que je manque quelque chose?

Vous devriez d'abord demander «qui s'en soucie»?

Terminer les sprints est une bonne chose, et dans certaines entreprises, le parent Scrum est un cookie. Mais le test ultime est de savoir si la société atteint ses objectifs.

Ce qui précède est facétieux. Si la société réussit sans jamais terminer le contenu prévu d'un sprint, vous pouvez également utiliser Kanban à la place: vous triez l'arriéré, vous travaillez sur l'essentiel et vous ne vous souciez pas tellement des itérations définies.

L'une des valeurs des itérations définies est de favoriser l'amélioration des processus (ou d'éliminer les personnes moins performantes dans certaines mentalités). Vous n'obtenez pas cela maintenant. Ainsi, vous pouvez soit adopter le reste du processus qui améliore le processus (et éventuellement terminer les sprints), soit vous pouvez décider que vous aimez ce que vous avez.

Est-ce que je manque quelque chose?

OUI!

Vous avez passé 18 mois - ou quelque part dans les environs de 36 sprints avec rétrospectives, mais vous ne pouviez pas résoudre le problème? La direction n'a pas tenu compte de l'équipe, et leur direction n'a pas tenu les responsables de ne pas tenir compte de l'équipe?

Il vous manque le fait que votre entreprise soit totalement incompétente .

Alors, comment y remédier. Vous (le dev) arrêtez de vous engager dans tant de travail. Si les histoires sont si volumineuses que vous ne pouvez pas le faire, vous devez alors les décomposer en morceaux plus petits. Et ensuite, vous devez tenir les gens responsables d'avoir accompli ce qu'ils disent qu'ils vont faire. S'il s'avère qu'ils ne peuvent obtenir qu'une minuscule fonctionnalité à chaque sprint, alors déterminez pourquoi et améliorez-le (ce qui peut impliquer le remplacement du développeur). S'il s'avère qu'ils ne peuvent pas trouver un moyen d'engager une quantité raisonnable de travail, vous les virez .

Mais avant cela, je regarderais la direction qui laisse les choses aller si longtemps, et comprendra pourquoi elle ne fait pas son travail.

J'aimerais vous suggérer de faire un petit changement et d'essayer Kanban pendant quelques semaines à la place de Scrum . Cela fonctionnera peut-être mieux pour votre équipe.

Alors que Scrum stimule la productivité en limitant le temps de travail disponible dans un sprint, Kanban en augmente la productivité et la rapidité en limitant le nombre de problèmes actifs et simultanés. L'estimation du temps ne fait plus partie du processus. ( source )

En un mot, qu'est-ce que le Kanban?

Kanban est également un outil utilisé pour organiser le travail dans un souci d’efficacité. À l'instar de Scrum, Kanban encourage le travail à être scindé en morceaux maniables et utilise un tableau Kanban (très similaire au tableau Scrum) pour visualiser ce travail au fur et à mesure de son déroulement. Lorsque Scrum limite le temps imparti pour effectuer un travail particulier (au moyen de sprints), Kanban limite le travail autorisé dans n'importe quelle condition (seul un nombre aussi important de tâches peut être en cours, un nombre limité -faire une liste.)

Comment SCRUM et Kanban sont-ils identiques?

Scrum et Kanban permettent tous les deux de décomposer et d’achever des tâches complexes et volumineuses. Tous deux accordent une grande importance à l'amélioration continue, à l'optimisation du travail et du processus. Et les deux partagent le même intérêt pour un flux de travail hautement visible qui garde tous les membres de l'équipe au courant des opérations en cours et des événements à venir.

Voir le reste du détail de ce lien

Ma question est fondamentale: quand est-il juste de rechercher le problème de la qualité des développeurs?

Il n'y a pas assez d'informations dans votre message pour répondre à cette question. Il n'y a aucun moyen de savoir s'ils échouent parce qu'ils sont incompétents ou s'ils échouent parce qu'ils s'engagent à faire plus de travail que ce qui est raisonnable.

Si je suis un développeur incroyablement doué, membre d'une équipe de développeurs extrêmement doués, et que nous ne parvenons pas à terminer X stories en deux sprints (ou 36!), Sommes-nous incompétents? Ou alors, est-ce qu'on craint juste à l'estimation? Cela dépend si les histoires ont été "créer un écran de connexion" ou "envoyer un homme en toute sécurité à mars".

Le problème commence par de mauvaises histoires et / ou de mauvaises estimations

L'estimation est difficile. Vraiment dur. Les êtres humains en raffolent. C’est pourquoi Scrum nous demande de scinder le travail en blocs qui ne devraient pas prendre plus d’un jour ou deux, et d’assembler de petits groupes de ces blocs que nous sommes certains de pouvoir terminer en peu de temps. . Plus les blocs sont grands et plus la période est longue, moins nos estimations sont précises.

Comment sont vos magasins? Sont-ils bien écrits, avec de bons critères d'acceptation? Sont-ils chacun assez petit pour le faire en quelques jours? Sans histoires bien écrites (ce qui est la faute de toute l'équipe de développement, y compris du propriétaire du produit), l'équipe ne peut pas faire de bonnes estimations.

Le problème est aggravé par de mauvaises rétrospectives

Ce que vous faites mal, apparemment, c'est que vous ne tirez pas parti des rétrospectives. Cela fait 18 mois que vous ne résolvez pas ce problème, soit l'équipe ne le remarque pas, soit ne le résout pas dans ses rétrospectives.

Chaque rétrospective se termine-t-elle par au moins un élément d'action à prendre par l'équipe, afin de faire mieux lors du prochain sprint. Chaque rétrospective inclut-elle des éléments d'action du sprint précédent pour voir s'ils ont été réalisés et s'ils ont été efficaces?

La solution n'est pas de blâmer, mais d'apprendre

La première étape devrait être d’arrêter de chercher le blâme et de commencer à travailler pour améliorer l’équipe. Votre équipe n'est probablement pas incompétente, mais mauvaise en estimation et en planification. Forcer l’équipe à terminer un sprint, même si cela signifie qu’elle choisit une histoire et termine une semaine plus tôt. S'ils ne peuvent pas faire cela, alors soit ils sont incompétents, soit les récits sont trop complexes. La réponse à cette question devrait être évidente.

Une fois qu’ils sont en mesure de terminer l’histoire, ils sauront avec une certitude raisonnable qu’ils peuvent réaliser un nombre X de points d’histoire dans un sprint. Des mathématiques simples aideront à répondre à la question de savoir s’ils peuvent faire plus d’histoires ou non.

L'amélioration continue est la solution

Une fois qu'ils ont terminé une histoire dans un sprint, il est temps de voir s'ils peuvent en faire deux. Faire mousser, rincer, répéter. Quand ils commencent à échouer aux objectifs du sprint, vous avez trouvé la limite de leurs capacités d'estimation. Retournez au nombre de points d'histoire de l'histoire précédente et restez-y pendant un moment.

À tout moment, prenez les rétrospectives au sérieux. S'ils ne terminent pas un sprint, déterminez pourquoi et agissez en conséquence. Ont-ils trop d'inconnues? Ont-ils le mauvais mélange de compétences? Comment étaient leurs estimations? S'ils estimaient qu'une histoire était composée de X points, cela nécessitait-il une charge de travail relativement égale à celle d'histoires de prieuré valant X points? Sinon, utilisez-le pour ajuster les points des histoires à venir.

Vous dites que vous "utilisez des rétrospectives". Mais que fait réellement l'équipe dans ces rétrospectives? Comme vous avez passé 18 mois sans aborder cet aspect de votre processus, je suppose que la réponse est: rien de très utile.

Pour moi, la rétrospective est la partie la plus importante du processus. Jetez ou changez tout ce que vous voulez sur Scrum (avec l'accord de l'équipe lors d'une rétrospective, bien sûr), mais engagez-vous à prendre régulièrement le temps de parler de la façon dont le processus fonctionne pour tout le monde, de partager ce qui a fonctionné et ce qui n'a pas fonctionné. pas travailler, et proposer des idées pour améliorer. Continuez d’essayer d’améliorer votre processus petit à petit à chaque sprint et, tôt ou tard, vous pourrez obtenir quelque chose qui fonctionne assez bien.

Dans votre cas, ce processus ne semble pas fonctionner. Étant donné que les objectifs de sprint ne sont pas atteints, il est prudent de se concentrer de manière rétrospective sur les raisons de cette situation. De toute évidence, l'équipe a pris trop de travail pour le sprint. Mais pourquoi ont-ils fait cela?

• Ont-ils sous-estimé la complexité du travail?
• Est-ce que la direction leur a demandé de faire plus de travail que l'équipe ne le pensait?
• Ont-ils eu trop d'interruptions / urgences qui ont empêché des ressources de mener à bien le travail prévu?
• Ont-ils rencontré des goulots d'étranglement qui ont retardé l'achèvement des travaux (par exemple, l'attente d'actifs d'une équipe de conception externe)?
• Et même: un ou plusieurs membres de l'équipe étaient-ils incapables de faire le travail?

C’est le genre de questions que l’équipe aurait dû se poser à chaque sprint au cours des 18 derniers mois. Puis, armés des réponses, ils peuvent proposer des améliorations de processus suggérées pour un essai pour le prochain sprint. Ceux-ci pourraient inclure:

• Faites moins de travail lors du prochain sprint (duh!)
• Soyez plus prudent dans vos estimations
• Dites à quiconque fait pression sur nous pour que nous fassions plus de travail, car nous en faisons déjà plus que ce que nous pouvons accomplir pour le moment.
• Gérez mieux les interruptions et ajustez la quantité de travail lors du prochain sprint pour faire face aux urgences inévitables
• Corrigez les goulots d'étranglement ou planifiez ceux que vous ne pouvez pas éviter
• Ne confiez pas les histoires à des membres de l'équipe qui ne peuvent pas les accomplir (et déterminez séparément la réponse de la direction à une situation avec un membre de l'équipe peu performant, de la formation au mentorat en passant par le renvoi)

C’est le genre de conversation qui aurait dû se produire à chaque sprint des 18 derniers mois. Il ne s'agit pas de faire pression sur l'équipe ou d'ajouter plus de ressources, mais d'utiliser vos rétrospectives pour améliorer votre processus de manière continue. Cela ne se produit clairement pas ici.

On pourrait penser qu’au 15e sprint avec des buts manqués, l’équipe en aurait discuté à maintes reprises dans sa rétrospective, au point qu’elle avait décidé de ne prendre que les objectifs de sprint les plus minimes possibles, dans le seul but d’en obtenir un complet. Au 25e sprint inachevé, je ferais juste un sprint avec un seul changement de chaîne et rien d'autre. Si l'équipe ne parvient pas à gérer cela dans un sprint, les problèmes sont encore pires que vous ne le laissiez paraître.

Pour être clair, comme plusieurs l'ont déjà indiqué, les objectifs du sprint sont des prévisions et non des engagements imparables, et les objectifs manquants ne sont pas en soi une indication autre que celle de faire des prévisions inexactes. Une grande équipe peut rater des tonnes de buts parce qu’ils sont de mauvais prévisionnistes, alors qu’une terrible équipe peut tout faire pour ne pas offrir de valeur réelle. Mais si vos prévisions sont erronées dans la même direction pendant 18 mois consécutifs, cette partie de votre processus ne fonctionne pas. Utilisez vos rétrospectives pour corriger le processus afin que vos prévisions soient raisonnablement proches de la réalité de ce que l'équipe peut réaliser à chaque sprint.

"le logiciel est terminé quand c'est fait, pas plus tôt, pas plus tard."

Cela est vrai, mais pour chaque tâche sur laquelle vos développeurs commencent à travailler, est-ce que tout le monde dans votre organisation comprend la définition de Fait pour chaque tâche?

L' estimation semble être l'un de vos plus gros problèmes , mais les développeurs ne peuvent fournir une estimation réaliste que lorsqu'ils disposent d'une "définition du fait" sans ambiguïté et clairement spécifiée. (Ce qui inclut les problèmes de processus de l'entreprise - par exemple, la documentation utilisateur, les lots de travaux sur une version officielle, etc.)

Il n’est pas surprenant que la surestimation pose problème, étant donné que la plupart des développeurs voient que l’estimation du temps requis pour effectuer une tâche est la plus difficile qui soit.

Cependant, la plupart des développeurs ont tendance à avoir une idée raisonnable (quoique optimiste ) de la quantité d' effort qu'ils sont capables de déployer, pour une période donnée.

Le problème réside souvent dans le fait que les développeurs ont du mal à créer un lien entre une tâche et le nombre total d'efforts requis pour traiter des informations incomplètes, en particulier s'ils sont contraints de fournir toutes les réponses à une tâche très complexe. .

Cela conduit naturellement à ce que les estimations de temps deviennent déconnectées de la réalité et qu'elles perdent de vue des éléments tels que le processus de construction et la documentation utilisateur.

La déconnexion a tendance à commencer au tout début lorsque la tâche est décrite; et il est généralement composé par une personne non technique qui dresse une liste d'exigences sans avoir la moindre idée de l'ampleur des efforts nécessaires.

Parfois, les membres de la haute direction spécifient des tâches et ignorent complètement les problèmes de processus de l'entreprise; Il n'est pas rare que la haute direction pense que la définition de tests, la création d'une version officiellement publiée ou la mise à jour d'un document utilisateur se déroulent comme par magie, sans effort ni temps. Champs obligatoires.

Parfois, les projets échouent avant même qu'un développeur ait écrit une ligne de code car quelqu'un, quelque part, ne fait pas son travail correctement.

Si l’équipe de développement n’est pas impliquée dans la définition des exigences ni dans la définition des critères d’acceptation, il s’agit alors d’un échec de la direction, car cela signifie que les connaissances insuffisantes du code et des problèmes techniques ont imposé à l’entreprise un ensemble d’exigences incomplet, et laissé le projet ouvert à la fausse interprétation, au fluage de la portée, au placage à l'or, etc.

Si l'équipe de développement est impliquée dans la définition et l'acceptation des exigences, il pourrait s'agir d'un échec de l'équipe, qui est chargée de clarifier les détails (et les critères d'acceptation - par exemple, "à quoi ressemble le produit livrable? Quand est-il effectué ?" ) L’équipe de développement doit également dire NON lorsque d’autres problèmes de blocage se posent ou si une exigence est tout simplement irréaliste.

Donc, si les développeurs sont impliqués dans la capture des exigences:

• L’équipe at-elle l’occasion de s’asseoir avec le chef de produit pour clarifier les exigences / la définition de done?
• L'équipe pose-t-elle suffisamment de questions pour clarifier les exigences implicites / supposées? À quelle fréquence répond-on à ces questions de manière satisfaisante?
• L'équipe demande-t-elle des critères d'acceptation (définition de done) avant de fournir une estimation?
• Dans quelle mesure les critères d'acceptation sont-ils généralement capturés pour chaque tâche? S'agit-il d'un document vague avec peu de détails ou décrit-il une fonctionnalité tangible et une formulation qu'un développeur pourrait traduire sans ambiguïté en un test?

Les chances sont que la productivité de votre équipe n'est pas un problème; votre équipe est probablement en train de déployer tous les efforts possibles pour le développement. Vos vrais problèmes pourraient être un ou plusieurs des éléments suivants:

• Exigences incomplètes et vagues.
• Les exigences / tâches qui sont trop grandes au départ.
• Mauvaise communication entre l'équipe de développement et la direction.
• Un manque de critères d'acceptation clairement définis avant que les tâches ne soient confiées à l'équipe.
• Spécification incomplète ou vague / ambiguë des tests d'acceptation. (c.-à-d. définition de fait)
• Temps insuffisant alloué pour définir / convenir des critères d'acceptation.
• Les développeurs n'ont pas pris le temps de tester le code de base existant ou de corriger les bogues existants
• Les développeurs ont testé le code de base existant mais n'ont pas soulevé les bogues en tant que problèmes de blocage avant de fournir une estimation des exigences.
• La direction a vu les problèmes / bogues et a décidé qu'il n'était pas nécessaire de corriger les bogues avant d'écrire du nouveau code.
• Les développeurs sont sous pression pour consacrer 100% de leur temps, même si probablement 20% (ou un nombre similaire) de leur temps est probablement utilisé par des réunions, des distractions, des courriels, etc.
• Les estimations sont approuvées à la valeur nominale et personne ne règle la marge d'erreur ou les imprévus (par exemple, "nous avons décidé que cela prendrait 5 jours, nous nous attendons donc à ce que ce soit fait dans 8.").
• Les estimations sont traitées par tout le monde (développeurs et direction) comme des nombres uniques au lieu d’être des nombres "extrêmes" réalistes - c’est-à-dire
  • Meilleure estimation de cas
  • Estimation réaliste
  • Pire estimation

... La liste pourrait durer beaucoup plus longtemps que cela.

Vous devez effectuer une "enquête factuelle" et comprendre exactement pourquoi les estimations sont systématiquement déconnectées de la réalité. Le logiciel de base existant est-il mauvais? Est-ce qu'il manque de couverture de test unitaire? Vos développeurs évitent-ils la communication avec la direction? La direction évite-t-elle la communication avec les développeurs? Existe-t-il un décalage entre les attentes de la direction et les attentes des développeurs en ce qui concerne "Definition of Done" ?

Mon conseil pour redémarrer l'équipe est de choisir la plus petite histoire possible par équipe, par sprint, et de compléter cette histoire, et cette histoire seulement!

Je suis d'accord avec les autres affiches, soit l'équipe est incompétente, soit ils essaient de faire trop de choses.

Commencez par les plus petites choses, les histoires les plus réduites et complétez un seul sprint. Amenez l'équipe à terminer un sprint et à réussir, et cela l'aidera à voir comment hiérarchiser ses engagements en termes de temps et de travail. Au fil du temps, l’équipe sera en mesure d’assumer de plus en plus de travail jusqu’à ce qu’elle atteigne son pic de productivité.

Vous devriez collecter des données et créer des niveaux de confiance basés sur les performances passées.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

L'exemple le plus simple est celui des sprints à temps constant, comme toutes les deux semaines. Estimez le nombre de points d'histoire que l'équipe terminera dans les deux semaines. Puis, une fois le sprint de deux semaines terminé, voyez combien de points d’histoire ont été réellement complétés. Au fil du temps, vous constaterez peut-être que vous estimez 15 points, mais que vous n'en terminez que 10. Dans ce cas simple, vous pouvez commencer à avancer avec un réglage de la vélocité de manière à ne planifier que 10 points par sprint. Ou que vous envisagez de terminer 66% du travail estimé.

En établissant des niveaux de confiance avec des écarts types, vous pouvez dire aux responsables: selon les objectifs actuels du projet, nous ne prévoyons qu’une confiance de 50%, nous pouvons terminer en 3 semaines, mais de 95% en 5 semaines.

L'idée derrière Agile et Scrum est de créer une boucle de rétroaction étroite afin que vous puissiez évaluer votre processus. Vous devez demander "Où est-ce que cela s'est effondré?", Car il semble s'être complètement effondré.

1. Planifiez ce que vous allez faire et faites-en une liste
   • Cela devrait consister à sélectionner des éléments dans un arriéré d’articles à compléter. Avant que quoi que ce soit ne soit inscrit dans la liste des tâches à effectuer pour le sprint, l’équipe doit convenir qu’elle le comprend parfaitement et estime qu’en gros, il faudra moins d’un sprint pour le mener à bien.
   • Idéalement, l'arriéré est classé par priorité (par rapport à l'entreprise) et vous pouvez passer par ordre de priorité.
   • Si les éléments de l'arriéré sont trop volumineux, décomposez-les en petits morceaux. Ensuite, divisez les morceaux en tâches individuelles qui peuvent être accomplies en une journée ou moins.
   • Ne vous attendez pas à ce que la planification soit facile ou rapide.
2. Exécuter sur des éléments de la liste pendant une période définie (un sprint)
3. Examinez ce que vous avez accompli
   • Quelles histoires ont été finies?
   • Si aucune histoire n'est terminée, alors quelles tâches constituant les histoires sont terminées?
   • Si aucune tâche n'était terminée, alors qu'est-ce que tout le monde a fait exactement lundi dernier? Mardi dernier ?, etc. - l'heure est à l'introspection.

4. Résoudre les problèmes (analyser les commentaires et les adapter)

   • Combien de temps les choses qui ont été finies ont-elles pris?
   • Qu'est-ce qui empêche les tâches de s'achever?
   • Les membres de l'équipe décomposent-ils les histoires (fonctionnalités) en tâches pouvant être accomplies en une journée ou moins? Sinon, faites-le et intégrez-le à la liste des tâches à effectuer.
   • Quelles modifications ont été apportées à la liste de tâches ou aux éléments de la liste de tâches au cours du sprint? Était-ce une raison pour ne pas finir? Si c'est le cas, ne changez pas la liste ni les fonctionnalités. Jetez la fonctionnalité modifiée sur le carnet de commandes jusqu'à ce qu'elle soit stable.
   • Comment pouvez-vous réduire la taille et la portée de quelques éléments à quelque chose qui peut être fini dans un sprint? Choisissez quelque chose de minuscule, comme une amélioration de la journalisation, une simple correction de bogue, une faute de frappe, juste pour terminer certaines choses et permettre à l'équipe de disposer d'une jauge de ce qu'elle peut faire. Si vous ne pouvez pas faire cela, alors arrêtez de sprinter et re-planifiez .

5. Retour à la première étape et répéter jusqu'à la libération ...

Existe-t-il des obstacles à la documentation, des problèmes de couplage créant des dépendances, des problèmes de communication, des informations insuffisantes dans les exigences? ... Quoi? Les développeurs ont-ils passé leur temps à essayer d'apprendre de nouvelles technologies? Ont-ils passé énormément de temps dans la conception? Des éléments tels que l'apprentissage ont-ils été pris en compte dans la liste des tâches de sprint?

Avez-vous pensé que votre équipe pensait avoir isolé ses problèmes à chaque rétrospective? L'équipe a-t-elle agi pour corriger les problèmes? L'équipe n'a-t-elle pas répondu et la direction a simplement dicté les solutions et le plan d'action?

Étant donné la longue période, quelque chose ne va pas systématiquement, pas simplement avec les développeurs. À un certain moment (avant un an était) une personne de l'équipe (y compris le scrum master) ils auraient pu demander, quoi, si petit, pouvons nous accomplissons?

Dans votre cas, les rétrospectives sont trop tardives.
Tenez-vous des réunions de stand-up quotidiennes et obtenez-vous vraiment le statut de ce que les gens ont fait au cours des dernières 24 heures?
Le scrum master utilise-t-il ces réunions pour mesurer les progrès de chaque développeur par rapport à leurs objectifs?
Vous devez utiliser cet élément de la méthodologie Scrum pour suivre les progrès au fur et à mesure. Cela devrait vous donner un bon aperçu de ce que les gens font.
Sont-ils distraits? Vous passez trop de temps à prendre un café, à aider d’autres personnes sur SE / SO, à lire les nouvelles ou à effectuer des inspections non comptabilisées? Ou sont-ils vraiment tête baissée, à toute vapeur et totalement sur-engagés? La vue quotidienne devrait vous donner une bonne idée. Cela aidera également à garder les développeurs concentrés sur la tâche à accomplir, afin qu'ils n'aient pas à admettre qu'ils n'ont rien fait hier.
Et bien sûr, s’ils font état de progrès constants tout au long du sprint et ne livrent toujours pas à la fin, ils mentaient et il serait peut-être temps pour un nouveau développeur.

Il est difficile d'estimer l'effort et le temps requis pour effectuer une tâche complexe, telle que le code de programmation. Comme Joel Spolsky le dit:

Les développeurs de logiciels n'aiment pas vraiment faire des plannings. Habituellement, ils essaient de s'en sortir sans un. "Ce sera fait quand ce sera fait!", Disent-ils, s'attendant à ce qu'un zinger aussi courageux et drôle réduise leur patron à une crise de fou rire, et dans la jovialité qui s'ensuit, l'horaire sera oublié.

Cependant, les entreprises ont besoin de délais pour fonctionner. Comme Joel l'a suggéré, essayez d'utiliser une planification basée sur des preuves qui fournira des estimations de temps avec une probabilité associée, ce que la direction peut associer à n'importe quel type de risque.

Scrum fait quelques choses.

Premièrement, cela encourage la priorisation. Le fournisseur de travail doit d'abord dire ce qu'il veut faire et non pas "tout est d'égale importance".

Deuxièmement, il génère un produit utilisable même si tout n’est pas fini. C’est le point d’avoir un «produit potentiellement expédiable» à la fin de chaque itération.

Troisièmement, cela donne une boucle de rétroaction plus serrée. En insistant pour que les choses soient "terminées" à la fin d'un sprint, vous évitez le problème "90% des fonctionnalités sont terminées, mais seulement à mi-chemin"; Lorsque vous insistez pour respecter les délais, vous pouvez écarter les tâches à accomplir pour donner l'impression que vous avez presque respecté les délais ou que vous pouvez simuler des délais. En définissant ce qui est fait et en insistant pour que les choses soient faites, vous savez si quelque chose est plus difficile qu’il ne le semble plus tôt au lieu de plus tard.

Quatrièmement, il évite les inventaires en déplaçant la planification détaillée près de faire le travail. La planification à distance est une forme d’inventaire: l’argent dépensé en ressources qui ne sont ni disponibles à la vente ni utilisées immédiatement par les clients. Un tel inventaire peut pourrir (les plans changent, les nouvelles informations le rendent obsolète), ne pas correspondre aux besoins (il s'avère que nous n'avons pas besoin d'un réseau distribué whatzit, parce que son utilisation n'en valait pas la peine) et de réduire la valeur des marchandises expédiées. (Si, au cours de la dernière année, la moitié de votre temps avait été consacrée à la planification pour l’année suivante et au-delà, vous auriez reçu deux fois plus d’expédition si vous aviez plutôt travaillé sur des choses à préparer pour le moment). Si vous pouvez rapprocher la planification de l'exécution sans perte (délicate!), Vous pouvez réduire l'inventaire.

Ce n'est pas le seul moyen de résoudre ces problèmes. Vous semblez utiliser scrum lorsqu'il fournit aux développeurs un flux de travail sur lequel travailler, pour chaque période de temps, en ajoutant périodiquement de nouveaux travaux à effectuer et en contrôlant les progrès.

C'est un moyen utile d'utiliser des motifs scrum-esque. Il permet de travailler sans interruption, de planifier proche de la production, de fournir des boucles de rétroaction, etc. Il présente même des avantages en ce sens qu'il ne gêne pas le développement et les tests pour correspondre au système (si les tests sont mieux réalisés, le travail est essentiellement terminé , essayer de terminer et de tester les choses dans le même sprint oblige l’arrière du sprint à ne pas impliquer de nouveau développement!)

L'échec à mettre exactement ce qu'ils vont faire dans un sprint ne prouve pas que vos développeurs ne font pas un excellent travail. Cela signifie qu'ils ne suivent pas SCRUM d'en haut, mais qu'ils utilisent des parties du framework.

S'ils s'étaient divisés en deux (ou divisés en quartiers) combien ils avaient engagés pour chaque sprint, mais que tout le reste était identique, ils auraient fini plus que ce qu'ils avaient engagé pour chaque sprint! Vous auriez la même quantité de code produite. Clairement, les "échecs de sprint" ne sont pas la partie importante, car il ne s'agit que d'un détail de processus interne. Le but de l’entreprise est de se faire chier, et que c’est bon. ne pas suivre un processus spécifique, sauf si votre objectif est un certain type de certification de processus ISO.

Le processus est subordonné à l'objectif de la tâche effectuée.

D'autre part, comme ils ne suivent pas les règles de SCRUM, vous n'obtenez pas le même type de retour. Vous devriez examiner les résultats obtenus pour voir si le type de défauts produits sont ceux que SCRUM a été conçu pour traiter; Y a-t-il des histoires qui vivent pour toujours comme des zombies et ne sont tuées que très tard? Existe-t-il des histoires qui semblent faciles, qui explosent et qui, dans une rétrospective, ne valent pas le travail total? Le produit est-il réellement expédiable au moment où vous avez besoin / souhaitez l'expédier?

"Le logiciel est terminé quand c'est fait, pas plus tôt, pas plus tard" est une recette d'échec si vous n'avez pas défini ce que "fait" ressemble à.

La plupart des ingénieurs essaieront de produire la meilleure solution possible, mais cela peut facilement conduire à une dorure, en particulier avec des ingénieurs moins expérimentés. Les seules responsabilités de la direction sont de définir exactement où se trouve l'objectif et de garder vos ingénieurs dans cette direction. Les ingénieurs tentent souvent de prendre des virages pour améliorer les fonctionnalités, et il appartient à la direction de décider si ce virage accélérera les choses à long terme, ou s'il ne s'agit que d'une amélioration.

Le point essentiel du développement agile est que chaque nouveau travail doive être aussi performant que nécessaire pour répondre à ce sprint ET PAS MIEUX !!!!!! Oui, c'est à peu près tout ce que je peux ajouter dans StackOverflow - et ce n'est toujours pas assez. Si vous trouvez que les gens ajoutent des choses qui n'est pas nécessaire bien cette seconde dont ils ont besoin alors une formation sur la façon de faire correctement le développement agile.

Oh, et oui, nous utilisons des rétrospectives.

Oh bien, alors vous savez pourquoi votre équipe échoue, n'est-ce pas? Vous avez eu 36 occasions de parler de ce qui a fonctionné et de ce qui n'a pas fonctionné, alors les Scrum Master devraient bien comprendre comment résoudre les problèmes, n'est-ce pas?

D'après la description que vous donnez, je pense que votre entreprise est tombée dans la mentalité "SCRUM nous rend productifs". La vérité est que SCRUM ne vous rend pas productif. Au contraire, il est un outil pour vous aider à faire vous - même productif d'une manière qui identifie les réalités du développement qui sont souvent négligés par la direction et les développeurs.

Qu'est-ce que le scrum master a identifié comme des problèmes potentiels avec l'équipe? Assigne-t-il constamment deux fois plus de travail que possible? Si tel est le cas, le maître de mêlée devrait suggérer doucement de faire moins de travail, car il peut examiner la vélocité de l'équipe.

Quand est-il juste de chercher le problème de la qualité des développeurs?

Le moment où vous devez rechercher le problème de la qualité des développeurs est le moment où vous êtes certain que tel est le problème. Ce n'est pas un nouveau problème créé par SCRUM. C'est la réalité des affaires. SCRUM devrait vous fournir beaucoup plus d’informations sur les capacités des membres de votre équipe que les approches traditionnelles. Vous devez savoir si le problème est "les développeurs de logiciels ne sont pas assez bons" par opposition aux "attentes de la direction sont irréalistes" dans une bien meilleure mesure que vous ne le comprendriez avec une approche traditionnelle. Le moment est venu pour la direction de faire ce que la direction fait de mieux: trouver les bonnes personnes pour le poste afin que l’entreprise puisse gagner de l’argent. Si vous ne savez pas où est le problème, alors imaginez à quel point il serait difficile de le dire sans toutes ces rétrospectives!

Si vous pensez que les gens sont assez bons (ce qui implique que leur embauche n'est pas une erreur de la part de la direction), mon conseil serait alors de commencer à penser en dehors des sentiers battus. Si le travail n'est pas terminé, envisagez de modifier la forme du travail pour les développeurs. L’une des manières les plus simples que j’ai trouvée de respecter les délais d’achèvement du sprint consiste à ajuster les critères DONE afin que vous soyez satisfait du résultat, peu importe la façon dont il est réalisé. Ainsi, être complété devient une tautologie.

Cela met la responsabilité sur la gestion, en particulier le maître SCRUM. L'astuce consiste à rédiger des tâches qui, si elles sont terminées, sont très utiles, mais si elles sont incomplètes, elles apportent néanmoins une valeur ajoutée suffisante à la société pour qu'elles valent leur salaire. Après 18 mois, je suppose que vos rétrospectives vous ont appris quelque chose. Si ce n’est pas le cas, vous devriez peut-être écrire les histoires avec l’intention explicite d’histoires échouées de découvrir ce qui ne va pas dans votre entreprise et de le mettre au jour. Cela fournirait à la société d'immenses données précieuses, compte tenu de la frustration que semble avoir la société vis-à-vis de l'équipe de développement. Le problème peut en effet être les développeurs, comme vous le demandez. Ou le problème peut être une pathologie dans la mentalité de la société dont vous n'aviez aucune idée jusqu'à présent!

Si en effet le problème concerne la société, et non les développeurs, les informations que vous collectez à partir de ces histoires incomplètes pourraient bien valoir plus que le produit que vous collectez auprès des entreprises qui ont réussi! C'est peut-être l'information qui sauve toute votre entreprise! Cela me semble être une information vraiment précieuse et vous pouvez utiliser SCRUM comme un outil pour vous aider à la recueillir.

"Quand est-il juste de regarder la qualité des développeurs?"

Tout le temps. Évidemment, certaines personnes sont plus productives que d'autres, vous n'avez pas besoin d'une excuse en tant qu'employeur pour mesurer leur performance.

La difficulté est comment vous le faites. Mon conseil est d’engager des contractants expérimentés pour travailler aux côtés de votre personnel permanent sur le même ensemble de tâches que celles évaluées par vos permanents et de voir s’ils ont une vitesse plus élevée.

Cela vous donnera une bonne comparaison avec le marché actuel sans vous enfermer dans une location à long terme.

Cela pourrait aussi donner un coup de pied aux gars de la permanente.

De plus, s’ils se plaignent que les sous-traitants négligent la qualité, etc., pour gagner en rapidité, cela entraînera une discussion sur la valeur commerciale. Produits de maintenance à long terme ou à court terme expédiés.

Si c'est le cas à long terme, cela vous obligera à le quantifier et à le reporter au sprint comme condition requise!

Il y a déjà plusieurs excellentes réponses. En particulier, une mauvaise estimation, un engagement excessif et / ou des travaux non planifiés sont des causes fréquentes de dérapage.

Mais je suis curieux de savoir pourquoi "vos développeurs choisissent les fonctionnalités qu'ils souhaitent inclure dans chaque sprint". Les développeurs doivent généralement travailler en priorité sur les fonctions avec la priorité la plus élevée. La priorité est une décision commerciale, c’est-à-dire qu’elle doit provenir du propriétaire du produit, qui agit en tant que proxy pour les parties prenantes de l’entreprise.
(Il existe des exceptions. En particulier, les fonctionnalités à haut risque sont généralement exploitées plus tôt. Et dans certains cas, une fonctionnalité orientée utilisateur peut dépendre d'autres fonctionnalités, par exemple "nous avons vraiment besoin d'ajouter une base de données avant de pouvoir implémenter X". )

Par ailleurs, les estimations sont des décisions techniques et ne doivent pas être prises (ou devinées) par des hommes d’affaires. Vous ne dites rien à ce sujet - je soulève la question uniquement parce que, selon mon expérience, lorsque les développeurs choisissent ce sur quoi travailler, il est assez courant pour les gens d'affaires d'essayer de dicter le temps que cela prendra.

On dirait que votre processus est assez dysfonctionnel. Je recommanderais de ne pas faire appel à des consultants en développement, du moins pour le moment, car cela va probablement avoir un effet négatif sur le moral. Mais il semble que votre organisation pourrait avoir besoin d'aide du côté de la gestion de projet. C'est là que je commencerais par faire appel à un coach agile expérimenté - sinon pour un engagement à moyen et à long terme, au moins pour une évaluation ou un "bilan de santé". Un bon entraîneur vous dira si vos développeurs sont peu performants, mais au moins, toute l’équipe (et pas seulement les développeurs) fait l’objet d’un examen minutieux.

Autre observation: d'après mon expérience, il est très difficile de faire de Scrum une méthodologie de gestion de projet si vous ne suivez pas de bons processus de développement. Faites-vous des tests unitaires automatisés? ou mieux encore, des tests d'acceptation automatisés? Est-ce que vos développeurs appairent ou au moins effectuez-vous des révisions de code fréquentes et / ou des procédures pas à pas? Pratiquez-vous une forme d'intégration continue?