L'équipe échoue constamment à atteindre les 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 livré les fonctionnalités auxquelles elle s'était engagée pour un sprint.
J'ai lu beaucoup de messages/réponses indiquant quelque chose comme "le logiciel est fait quand c'est fait, pas plus tôt, pas plus tard ... ça n'aide pas de mettre la pression sur l'équipe, de mettre plus de gens dessus, ... "J'ai reçu des commentaires similaires de l'un des développeurs sur ma question sur la manière d'améliorer le taux de réussite des sprints. Oh, et oui, nous utilisons rétrospectives .
Ma question est essentiellement:
Quand est-il juste de rechercher le problème dans la qualité des développeurs?
Je commence à penser que si vous choisissez 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 superviser la complexité.
Suis-je en train de manquer quelque chose?
Vous devriez d'abord demander, "qui s'en soucie"?
Terminer les sprints se sent bien et dans certaines entreprises, les cookies du parent Scrum sont générés. Mais le test ultime est de savoir si l'entreprise atteint ses objectifs.
Ce qui précède est facétieux. Si l'entreprise réussit sans jamais terminer le contenu prévu d'un sprint, vous pourriez aussi bien utiliser Kanban à la place: vous triez le backlog, vous travaillez sur ce qui est le plus important et vous ne vous inquiétez pas tant des itérations définies.
L'une des valeurs des itérations définies est de conduire à l'amélioration des processus (ou de chasser les sous-performants dans certaines mentalités). Vous ne comprenez pas cela maintenant. Ainsi, vous pouvez soit adopter le reste du processus qui améliore le processus (et éventuellement terminer les sprints), ou vous pouvez décider que vous aimez ce que vous avez.
Suis-je en train de manquer quelque chose?
OUI!
Vous êtes allé 18 mois - ou quelque part dans le voisinage de 36 sprints avec des rétrospectives, mais d'une manière ou d'une autre, vous ne pouvez pas y remédier? La direction n'a pas tenu l'équipe responsable, puis sa gestion ne l'a pas tenue responsable de ne pas tenir l'équipe responsable?
Il vous manque que votre entreprise soit omniprésente .
Alors, comment y remédier. Vous (le dev) arrêtez de vous engager à tant de travail. Si les histoires sont si grandes que vous ne pouvez pas le faire, vous devez les diviser en morceaux plus petits. Et puis, vous devez tenir les gens responsables de ce qu'ils disent qu'ils feront. S'il s'avère qu'ils ne peuvent obtenir qu'une minuscule fonctionnalité à chaque sprint, essayez de comprendre pourquoi et de l'améliorer (ce qui peut impliquer de remplacer le développeur). S'il s'avère qu'ils ne peuvent pas comprendre comment s'engager dans des quantités raisonnables de travail, vous les renvoyez.
Mais avant cela, j'examinerais la gestion qui a laissé les choses aller aussi longtemps, et comprendre pourquoi ils ne font pas leur travail.
Je vous suggère de faire un petit changement et d'essayer Kanban pendant quelques semaines au lieu de Scrum . Cela pourrait mieux fonctionner pour votre équipe.
Alors que Scrum stimule la productivité en limitant le temps de travail disponible dans un sprint, Kanban stimule la productivité et la vitesse 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 Kanban?
Kanban est également un outil utilisé pour organiser le travail dans un souci d'efficacité. Comme Scrum, Kanban encourage le travail à être décomposé en morceaux gérables et utilise un tableau Kanban (très similaire au tableau Scrum) pour visualiser ce travail à mesure qu'il progresse dans le flux de travail. Là où Scrum limite la quantité de temps autorisée pour accomplir une quantité particulière de travail (au moyen de sprints), Kanban limite la quantité de travail autorisée dans n'importe quelle condition (seulement tant de tâches peuvent être en cours, seulement tant peuvent être en cours d'exécution) -faire une liste.)
En quoi SCRUM et Kanban sont-ils identiques?
Scrum et Kanban permettent de décomposer et d'exécuter efficacement des tâches volumineuses et complexes. Tous deux accordent une grande valeur à l'amélioration continue, à l'optimisation du travail et du processus. Et les deux partagent la même focalisation sur un flux de travail très visible qui garde tous les membres de l'équipe au courant des travaux en cours et de ce qui s'en vient.
Voir le reste des détails de cette lien
Ma question est essentiellement: quand est-il juste de chercher le problème dans la qualité des développeurs
Il n'y a pas suffisamment 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 qu'il n'est raisonnable.
Si je suis un développeur incroyablement doué, dans une équipe de développeurs incroyablement doués, et que nous ne parvenons pas à terminer X histoires en deux sprints (ou 36!), Sommes-nous incompétents? Ou, est-ce qu'on aspire à l'estimation? Cela dépend si les histoires étaient "créer un écran de connexion" ou "envoyer un homme en toute sécurité sur mars".
Le problème commence par de mauvaises histoires et/ou de mauvaises estimations
L'estimation est difficile. Vraiment dur. Les humains sont nulles, c'est pourquoi Scrum nous oblige à diviser le travail en blocs qui ne devraient pas prendre plus d'un jour ou deux, et à assembler de petits groupes de ces blocs que nous sommes sûrs de pouvoir terminer en peu de temps. . Plus les blocs sont gros et plus la période de temps est longue, moins nos estimations sont précises.
À quoi ressemblent vos magasins? Sont-ils bien écrits, avec de bons critères d'acceptation? Sont-ils chacun assez petits pour faire en quelques jours? Sans histoires bien écrites (ce qui est la faute de toute l'équipe de développement, y compris le propriétaire du produit), on ne peut pas s'attendre à ce que l'équipe fasse une bonne estimation.
Le problème est aggravé par de mauvaises rétrospectives
Ce que vous faites mal, apparemment, c'est que vous ne profitez pas des rétrospectives. Vous avez passé 18 mois sans résoudre ce problème, alors soit l'équipe ne le remarque pas, soit ne parvient pas à le résoudre dans ses rétrospectives.
Est-ce que chaque rétrospective se termine avec au moins un élément d'action à prendre par l'équipe, afin de faire mieux au prochain sprint. Est-ce que chaque rétrospective inclut de parler des actions du sprint précédent pour voir si elles ont été faites et si elles ont été efficaces?
La solution n'est pas de blâmer, c'est d'apprendre
La première étape devrait être d'arrêter de chercher des reproches et de commencer à travailler pour améliorer l'équipe. Votre équipe n'est probablement pas incompétente, tout simplement mauvaise en estimation et en planification. Forcer l'équipe à terminer un sprint, même si cela signifie qu'elle choisit une seule histoire et termine une semaine plus tôt. S'ils ne peuvent pas le faire, alors soit ils sont incompétents, soit les histoires sont tout simplement trop complexes. La réponse à cette question devrait être évidente.
Une fois qu'ils sont en mesure de terminer une histoire, ils sauront avec une certitude raisonnable qu'ils peuvent faire X quantité de points d'histoire dans un sprint. Des calculs 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 les objectifs de sprint, vous avez trouvé la limite de leurs capacités d'estimation. Revenez au nombre de points d'histoire de l'histoire précédente et respectez-le pendant un certain temps.
À tout moment, prenez les rétrospectives au sérieux. S'ils n'ont pas terminé un sprint, découvrez pourquoi et agissez en conséquence. Avaient-ils trop d'inconnues? Ont-ils le mauvais mélange de compétences? Quelle était la qualité de leurs estimations? S'ils estimaient une histoire à X points, cela nécessitait-il une quantité de travail relativement égale à celle des 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? Puisque vous avez passé 18 mois sans aborder une fois 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 quoi que ce soit d'autre sur Scrum tout ce que vous voulez (d'un commun accord de l'équipe lors d'une rétrospective, bien sûr), mais engagez-vous à prendre régulièrement le temps de parler du fonctionnement du processus pour tout le monde, de partager ce qui a fonctionné et ce qui n'a pas fonctionné. 't travailler, et proposer des idées pour améliorer. Continuez à améliorer votre processus petit à petit à chaque sprint, et tôt ou tard, vous pouvez avoir quelque chose qui fonctionne plutôt 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 rétrospectivement sur la raison pour laquelle c'est le cas. De toute évidence, l'équipe a pris trop de travail pour le sprint. Mais pourquoi ont-ils fait ça?
- Ont-ils sous-estimé la complexité du travail?
- La direction les a-t-elle poussés à accepter plus de travail que l'équipe ne le pensait?
- Y a-t-il eu trop d'interruptions/urgences qui ont privé les ressources de l'achèvement des travaux prévus?
- Ont-ils rencontré des goulots d'étranglement qui ont retardé l'achèvement des travaux (par exemple, en attendant les actifs d'une équipe de conception externe)?
- Et même: un ou plusieurs membres de l'équipe étaient-ils incapables de faire le travail?
Voilà le genre de questions que l'équipe aurait dû se poser à chaque sprint des 18 derniers mois. Puis, armés des réponses, ils peuvent proposer des améliorations de processus suggérées à l'essai pour le prochain sprint. Ceux-ci pourraient inclure:
- Faites moins de travail au prochain sprint (duh!)
- Soyez plus prudent dans les estimations
- Dites à quiconque nous presse de faire plus de travail pour nous en débarrasser, car nous en faisons déjà plus que ce que nous pouvons accomplir en ce moment
- Gérez mieux les interruptions et ajustez la quantité de travail lors du prochain sprint pour répondre aux urgences inévitables
- Corrigez les goulots d'étranglement ou planifiez ceux que vous ne pouvez pas éviter
- Ne pas attribuer d'histoires aux membres de l'équipe qui ne peuvent pas les réaliser (et séparément, déterminer la réponse de la direction pour résoudre une situation avec un membre de l'équipe peu performant, de la formation et du mentorat au licenciement)
C'est le genre de conversation qui aurait dû avoir lieu à chaque sprint au cours des 18 derniers mois. Il ne s'agit pas de mettre la pression sur l'équipe ou d'ajouter plus de ressources, mais d'utiliser vos rétrospectives pour améliorer votre processus sur une base continue. Cela ne se produit clairement pas ici.
On pourrait penser qu'au 15e sprint avec des buts manqués, l'équipe aurait discuté de cela dans sa rétrospective tant de fois, au point où elle a décidé de se contenter des objectifs de sprint les plus minimes possibles juste pour le plaisir 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 peut pas gérer cela dans un sprint, les problèmes sont encore pires que vous ne le laissez croire.
Pour être clair, comme plusieurs l'ont déjà souligné ici, les objectifs de sprint sont des prévisions, pas des engagements de fer, et les objectifs manquants ne sont pas en eux-mêmes indicatifs d'autre chose que de faire des prévisions inexactes. Une grande équipe peut manquer des tonnes d'objectifs parce qu'ils sont de mauvais prévisionnistes, tandis qu'une équipe horrible peut répondre à tous et ne fournir aucune 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 fixer le processus afin que vos prévisions soient raisonnablement proches de la réalité réelle de ce que l'équipe peut offrir à chaque sprint.
"le logiciel est fait quand c'est fait, pas plus tôt, plus tard."
C'est vrai, mais pour chaque tâche sur laquelle vos développeurs commencent à travailler, tout le monde dans votre organisation comprend le Définition de Terminé pour chaque tâche?
Il semble que l'un de vos plus gros problèmes soit Estimation , mais les développeurs ne peuvent fournir une estimation réaliste que lorsqu'ils ont une définition sans équivoque et clairement spécifiée de done '. (Qui inclut les problèmes de processus de l'entreprise - par exemple la documentation utilisateur, les packages de travail sur une version officielle, etc.)
Il n'est pas surprenant que la surestimation cause un problème, étant donné que la plupart des développeurs voient que l'estimation du temps requis pour terminer une tâche est la plus difficile qui leur soit posée.
Cependant, la plupart des développeurs ont tendance à avoir une gestion raisonnable (quoique optimiste) de la quantité d'effort qu'ils sont capables de mis, pour une période de temps donnée.
Le problème est souvent que les développeurs ont du mal à créer une relation entre une tâche et le total effort requis lorsqu'ils traitent des informations incomplètes - en particulier si ils sont poussés à trouver toutes les réponses dès le départ à une tâche vraiment énorme.
Cela conduit naturellement à ce que les estimations de temps soient déconnectées de la réalité, et elles perdent de vue des choses comme 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 aggravé par une personne non technique établissant une liste d'exigences sans avoir la moindre idée de la quantité d'effort nécessaire.
Parfois, les membres de la haute direction spécifient des tâches et ignorent complètement les problèmes de processus d'entreprise; il n'est pas rare que la haute direction pense que des choses comme la définition de tests, ou la création d'une version officielle, ou la mise à jour d'un document utilisateur se produisent comme par magie sans temps ni effort. obligatoire.
Parfois, les projets échouent avant qu'un développeur n'ait même écrit une ligne de code parce que 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 ou la capture des critères d'acceptation, cela constitue un échec de la gestion - car cela signifie qu'une personne qui n'a pas une compréhension suffisante du code et des problèmes techniques a engagé l'entreprise dans un ensemble incomplet d'exigences, et a laissé le projet ouvert à une mauvaise interprétation, au fluage de la portée, au placage à l'or, etc.
Si l'équipe de développement est impliquée dans la capture et l'acceptation des exigences, cela pourrait être un échec de l'équipe, qui est responsable de clarifier les détails (et les critères d'acceptation - c'est-à-dire "à quoi ressemble le livrable? Quand est-il fait? "). L'équipe de développement est également responsable de dire [~ # ~] non [~ # ~] quand il y en a d'autres bloquer les problèmes sur le chemin, ou si une exigence est tout simplement irréaliste.
Donc, si les développeurs sont impliqués dans la capture des exigences:
- L'équipe a-t-elle la possibilité de s'asseoir avec le chef de produit pour clarifier les exigences/définition du fait?
- L'équipe pose-t-elle suffisamment de questions pour clarifier les exigences implicites/supposées? À quelle fréquence ces questions reçoivent-elles une réponse satisfaisante?
- L'équipe demande-t-elle Critères d'acceptation (définition du fait) avant de fournir un devis?
- Dans quelle mesure les critères d'acceptation sont-ils généralement saisis pour chaque tâche? Est-ce un document vague avec des détails clairsemés ou décrit-il une fonctionnalité tangible et une formulation qu'un développeur pourrait sans ambiguïté traduire en test?
Les chances sont que la productivité de votre équipe ne soit pas un problème; votre équipe probablement fait tout son possible pour le développement. Vos vrais problèmes pourraient être l'un ou plusieurs des suivants:
- Exigences incomplètes et vagues.
- Exigences/tâches qui sont tout simplement trop grandes en premier lieu.
- Mauvaise communication entre l'équipe de développement et la haute direction.
- Absence de critères d'acceptation clairement définis avant la remise des tâches à l'équipe.
- Spécification incomplète ou vague/ambiguë des tests d'acceptation. (c.-à-d. définition de Terminé)
- Temps insuffisant alloué à la définition/acceptation 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 comme Problèmes de blocage avant de fournir des estimations sur les 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 un nouveau code.
- Les développeurs sont sous pression pour représenter 100% de leur temps, même si probablement 20% (ou un nombre similaire) de leur temps est probablement occupé par des réunions, des distractions, des e-mails, etc.
- Les estimations sont convenues à leur valeur nominale et personne n'ajuste la marge d'erreur ou de contingence (par exemple, "nous avons décidé que cela devrait prendre 5 jours, nous nous attendons donc à ce que ce soit fait en 8.").
- Les estimations sont traitées par tout le monde (développeurs et gestionnaires) comme des nombres uniques au lieu de nombres "d'échelle" réalistes, c'est-à-dire
- Meilleure estimation de cas
- Estimation réaliste
- Estimation du pire des cas
... la liste pourrait être beaucoup plus longue que cela.
Vous devez faire une "recherche de faits" et comprendre exactement pourquoi les estimations sont systématiquement déconnectées de la réalité. Le logiciel de base existant est-il mauvais? Manque-t-il une 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 terminer cette histoire, et cette seule histoire!
Je suis d'accord avec les autres affiches, soit l'équipe est incompétente, soit elle essaie de faire trop de choses.
Commencez avec les plus petites choses, les histoires les plus épurées et terminez un seul sprint. Demandez à l'équipe de terminer un sprint et de réussir, et cela les aidera à voir comment hiérarchiser leur temps et leurs engagements professionnels. Au fil du temps, l'équipe pourra assumer de plus en plus de travail jusqu'à ce qu'elle atteigne sa productivité maximale.
Vous devez collecter des données et renforcer les niveaux de confiance en fonction des performances passées.
http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/
L'exemple le plus simple est avec des sprints à temps constant, comme toutes les deux semaines. Estimez le nombre de points d'histoire que l'équipe terminera dans les deux semaines. Ensuite, après le sprint de deux semaines, voyez combien de points d'histoire ont été réellement terminés. Au fil du temps, vous pourriez voir que vous estimez 15 points, mais seulement terminer 10. Dans ce cas simple, vous pouvez commencer à avancer avec un réglage de la vitesse de sorte que vous ne prévoyez que 10 points par sprint. Ou que vous prévoyez de terminer 66% du travail estimé.
En établissant des niveaux de confiance avec des écarts-types, vous pouvez dire à la direction: selon les objectifs actuels du projet, nous nous attendons à seulement 50% de confiance que nous pouvons terminer en 3 semaines, mais 95% de confiance que nous pouvons terminer en 5 semaines.
L'idée derrière Agile et Scrum est de créer une boucle de rétroaction serrée afin que vous puissiez évaluer votre processus. Vous devez vous demander "Où est-ce que cela est tombé en panne?", Car il semble avoir complètement disparu.
- Planifiez ce que vous allez faire et faites-en une liste
- Cela devrait consister à sélectionner des éléments dans un carnet d'articles qui doivent être complétés. Avant que quoi que ce soit ne soit inscrit dans la liste des choses à faire pour le sprint, l'équipe doit convenir qu'elle le comprend parfaitement et qu'elle estime approximativement qu'il faudra moins d'un sprint pour terminer.
- Idéalement, le carnet de commandes est ordonné par priorité (pour l'entreprise) et vous pouvez tirer par ordre de priorité.
- Si les éléments du backlog sont trop gros, décomposez-les en plus petits morceaux. Décomposez ensuite les morceaux en tâches individuelles qui peuvent être accomplies en une journée ou moins.
- Ne vous attendez pas à ce que cette planification soit facile ou rapide.
- Exécuter sur des éléments de la liste pendant une période définie (un sprint)
- Revoyez ce que vous avez accompli
- Quelles histoires ont été terminées?
- Si aucune histoire n'a été terminée, alors quelles tâches constituant les histoires ont été terminées?
- Si aucune tâche n'était terminée, que faisait exactement tout le monde lundi dernier? Mardi dernier?, Etc. - à ce stade, il est temps pour une introspection sévère ...
Résoudre les problèmes (analyser les commentaires et s'adapter)
- Combien de temps les choses terminées ont-elles pris?
- Qu'est-ce qui a empêché l'exécution des tâches?
- Les membres de l'équipe décomposent-ils les histoires (fonctionnalités) en tâches qui peuvent être terminées en 1 jour ou moins? Sinon, faites-le et faites-le partie de la liste des tâches.
- Quelles modifications ont été apportées à la liste des tâches ou aux éléments de la liste des tâches pendant le sprint? Était-ce une raison pour ne pas terminer? Si c'est le cas, ne changez pas la liste ou les fonctionnalités. Jetez la fonctionnalité modifiée sur le backlog 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 terminé 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 afin de permettre à l'équipe de mesurer ce qu'elle peut faire. Si vous ne pouvez pas faire cela, alors arrêtez le sprint et replanifiez.
Retour à la première étape et répétez jusqu'à la libération ...
Y a-t-il des obstacles de documentation, des problèmes de couplage créant des dépendances, des problèmes de communication, pas assez d'informations 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 à concevoir? Des choses comme l'apprentissage étaient-elles prises en compte dans la liste des tâches de sprint?
Pensiez-vous que votre équipe pensait avoir isolé leurs 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 la marche à suivre?
Étant donné la longue période de temps, quelque chose ne va pas systémiquement, pas simplement avec les développeurs. À un moment donné (avant la fin d'un an), quelqu'un de l'équipe (y compris le Scrum Master) aurait dû demander ce que, si petit soit-il, peut que nous accomplissions?
Scrum fait quelques choses.
Premièrement, il encourage la priorisation. Le fournisseur de travail doit d'abord dire ce qu'il veut faire et non pas "tout est tout aussi important".
Deuxièmement, il génère un produit quelque peu utilisable même si tout n'est pas fini. C'est l'intérêt d'avoir un "produit potentiellement livrable" à la fin de chaque itération.
Troisièmement, cela donne une boucle de rétroaction plus étroite. En insistant pour que les choses soient "terminées" à la fin d'un sprint, vous évitez le problème "Fonctionnalité à 90% terminée, mais à moitié terminée"; lorsque vous repoussez des délais, vous pouvez mettre de côté les choses qui doivent être faites pour qu'il semble que vous ayez presque atteint le délai, ou vous pouvez le truquer. En ayant une définition de fait et en insistant sur ce qui se fait, vous savez si quelque chose est plus difficile qu'il n'y paraît plus tôt que tard.
Quatrièmement, il évite l'inventaire en rapprochant la planification détaillée du travail. Planifier des choses lointaines est une forme d'inventaire: le capital dépensé pour des ressources qui ne sont pas disponibles à la vente ou à l'utilisation immédiate par les clients. Un tel inventaire peut pourrir (les plans changent sous les pieds, de nouvelles informations le rendent obsolète), ne correspondent pas aux besoins (il s'avère que nous n'avons pas besoin d'un réseau distribué, car la chose qui en valait la peine), et réduire la valeur des marchandises expédiées (Si au cours de la dernière année, la moitié de votre temps a été consacré à la planification de l'année prochaine et au-delà, vous auriez pu recevoir deux fois plus de colis si vous aviez plutôt travaillé sur des trucs pour être prêt pour l'instant). Si vous pouvez rapprocher la planification de l'exécution sans perte (délicat!), Vous pouvez diminuer l'inventaire.
Ce n'est pas le seul moyen de résoudre ces problèmes. Vous semblez utiliser scrum où il fournit un flux de travail aux développeurs sur lequel travailler pour chaque période de temps, avec l'ajout périodique de nouveaux travaux à effectuer et la vérification des progrès.
C'est un moyen utile d'utiliser des modèles scrum-esque. Il continue de travailler, il continue de planifier près de la production, il fournit des boucles de rétroaction, etc. Il a même des avantages en ce qu'il ne déforme pas le développement et les tests pour correspondre au système (si les tests sont mieux effectués avec le travail est fondamentalement terminé) , essayer de terminer les choses et de les tester dans le même sprint force le back-end du sprint à ne pas impliquer de nouveau développement!)
L'échec de 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, utilisant plutôt des parties du framework.
S'ils avaient réduit de moitié (ou divisé en quatre) combien ils s'étaient engagés pour chaque sprint, mais avaient gardé tout le reste identique, alors ils auraient fini plus qu'ils ne s'étaient engagés pour chaque sprint! Vous auriez la même quantité de code produite. De toute évidence, les "échecs de sprint" ne sont pas la partie importante, car ce n'est qu'un détail du processus interne. Le but de l'entreprise est de faire de la merde, et que cette merde soit bonne; ne pas suivre un processus spécifique, sauf si votre objectif est un certain type de certification de processus ISO.
Le processus existe subordonné à l'objectif du travail accompli.
En revanche, comme ils ne suivent pas les règles de SCRUM, vous n'obtenez pas les mêmes kind de feedback. Vous devriez examiner la substance résultante pour voir si le type de défauts produits sont les défauts que SCRUM a été conçu pour traiter; y a-t-il des histoires qui vivent comme des zombies pour toujours et qui ne sont tuées que très tard? Y a-t-il des histoires qui semblent faciles, elles explosent, et dans une rétrospective où cela ne vaut pas tout le travail? Le produit peut-il être expédié au moment où vous en avez besoin/souhaitez l'expédier?
Dans votre situation, les rétrospectives sont trop tardives.
Tenez-vous des réunions quotidiennes et obtenez-vous vraiment le statut des gens sur ce qu'ils 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 à ses 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 font les gens.
Sont-ils distraits? Passer trop de temps sur le café, ou aider d'autres personnes sur SE/SO, ou lire les nouvelles, ou faire des inspections qui ne sont pas comptabilisées? Ou sont-ils vraiment tête baissée, à toute vapeur et complètement 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 signalent des progrès constants tout au long du sprint et ne livrent toujours pas à la fin, alors ils mentaient et il était 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 la programmation d'un code. Comme le dit Joel Spolsky :
Les développeurs de logiciels n'aiment pas vraiment faire des plannings. Habituellement, ils essaient de s'en tirer 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 à un fou rire, et dans la jovialité qui s'ensuivra, l'horaire sera oublié.
Cependant, les entreprises ont besoin de délais pour fonctionner. Comme l'a suggéré Joel, essayez d'utiliser Evidence Based Scheduling qui produira des estimations de temps avec une probabilité associée, que la direction peut considérer comme n'importe quel type de risque.
Oh, et oui, nous utilisons des rétrospectives.
Oh bien, alors vous savez pourquoi votre équipe échoue, non? Vous avez eu 36 occasions de parler de ce qui a fonctionné et de ce qui n'a pas fonctionné, alors les maîtres de mêlée devraient comprendre parfaitement comment résoudre les problèmes, non?
J'ai une intuition, par la description que vous donnez, que votre entreprise est tombée dans la mentalité "SCRUM nous rend productifs". La vérité est que SCRUM ne rend pas votre productivité. C'est plutôt un outil pour vous aider à vous rendre vous-même productif d'une manière qui identifie les réalités de 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 problèmes potentiels avec l'équipe? Attribuent-ils constamment deux fois plus de travail qu'ils peuvent en gérer? Si c'est le cas, le Scrum Master devrait doucement suggérer qu'ils prennent moins de travail, car le Scrum Master peut regarder la vitesse de l'équipe.
Quand est-il juste de rechercher le problème dans la qualité des développeurs?
Le moment où l'on devrait rechercher le problème dans la qualité des développeurs est le moment où vous êtes certain que c'est le problème. Ce n'est pas un nouveau problème créé par SCRUM. Telle est la réalité des affaires. SCRUM devrait vous donner énormément 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 rapport à "les attentes de la direction sont irréalistes" à un bien meilleur degré que vous ne le comprendriez avec une approche traditionnelle. C'est le moment la direction pour faire ce qu'elle fait le mieux: trouver les bonnes personnes pour le travail, afin que l'entreprise puisse gagner de l'argent. Si vous ne savez pas où est le problème, alors imaginez combien il serait difficile de dire sans toutes ces rétrospectives!
Si vous pensez que les gens pourraient être assez bons (ce qui implique que leur embauche n'était pas une erreur de la part de la direction), alors mon conseil serait de commencer à sortir des sentiers battus. Si le travail ne se fait pas, envisagez de changer la forme du travail pour les développeurs. L'un des moyens les plus simples que j'ai trouvés pour respecter les délais d'achèvement du sprint est d'ajuster les critères TERMINÉS afin que vous soyez satisfait du résultat, peu importe la façon dont il est fait. Ainsi, l'achèvement devient une tautologie.
Cela met la responsabilité sur la gestion, en particulier le maître SCRUM. L'astuce consiste à écrire des tâches qui, si elles sont terminées, sont très précieuses, mais si elles sont incomplètes, elles fournissent toujours suffisamment de valeur ajoutée à l'entreprise pour avoir valu leur chèque de paie. Après 18 mois, je m'attendrais à ce que votre rétrospectives pour vous avoir appris quelque chose. Si ce n'est pas le cas, vous devriez peut-être écrire les histoires avec l'intention explicite de raconter des échecs en découvrant quelque chose qui ne va pas dans votre entreprise et en le révélant. Cela fournirait à l'entreprise d'immenses données précieuses, compte tenu de la frustration qu'elle semble ressentir envers 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 l'état d'esprit de l'entreprise dont vous n'aviez aucune idée jusqu'à présent!
Si en effet le problème est avec l'entreprise, pas les développeurs, les informations que vous glanez de ces histoires incomplètes peuvent en effet valoir plus que le produit que vous collectez des réussites! Ce peut être les informations qui sauvent votre entreprise entière ! Cela me semble être une information vraiment précieuse, et vous pouvez utiliser SCRUM comme un outil pour vous aider à les collecter.
"Le logiciel est terminé quand c'est fait, pas plus tôt, plus tard" est une recette d'échec si vous n'avez pas défini à quoi ressemble "fait".
La plupart des ingénieurs tenteront de produire la meilleure solution possible, mais cela peut facilement conduire à un placage à l'or, en particulier avec des ingénieurs moins expérimentés. Les seules responsabilités de la direction sont de définir exactement où est l'objectif et de garder vos ingénieurs dans cette direction. Les ingénieurs tenteront fréquemment de prendre des virages latéraux pour améliorer les fonctionnalités, et c'est à la direction de décider si ce virage latéral accélérera les choses à long terme, ou s'il s'améliore simplement pour l'amélioration.
Le point de développement agile est que chaque nouveau travail devrait être aussi bon que nécessaire pour répondre à ce sprint ET PAS MIEUX !!!!!! Oui, c'est à peu près le plus d'accent que je puisse ajouter dans StackOverflow - et ce n'est toujours pas assez d'accent. Si vous trouvez que les gens ajoutent des choses qui ne sont pas nécessaires dès cette seconde alors ils ont besoin de formation sur la façon de faire correctement le développement agile .
Il existe déjà plusieurs excellentes réponses. En particulier, une mauvaise estimation, un surengagement et/ou un travail imprévu 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 sur les fonctionnalités avec la priorité la plus élevée en premier - et la priorité est une décision commerciale, c'est-à-dire qu'elle doit provenir du propriétaire du produit agissant en tant que proxy pour les parties prenantes de l'entreprise.
. peut implémenter X ".)
D'un autre côté, les estimations sont des décisions techniques, et devraient pas être faites (ou devinées) par des hommes d'affaires. Vous ne dites rien à ce sujet - je soulève le point uniquement parce que, selon mon expérience, lorsque les développeurs choisissent sur quoi travailler, il est assez courant pour les hommes d'affaires d'essayer de dicter combien de temps cela devrait prendre.
Il semble que vous ayez un processus assez dysfonctionnel. Je déconseille de faire appel à des consultants en développement, du moins pour le moment, car cela aura probablement un effet négatif sur le moral. Mais il semble que votre organisation pourrait avoir besoin d'aide pour la gestion de projet. C'est là que je commencerais, en faisant appel à un coach agile expérimenté - sinon pour un engagement à moyen ou long terme, du moins pour une évaluation ou un "bilan de santé". Un bon coach vous dira si vous avez des développeurs sous-performants, mais au moins de cette façon, c'est toute l'équipe (pas seulement les développeurs) qui est sous contrôle.
Une autre observation: d'après mon expérience, il est très difficile de faire réussir Scrum en tant que méthodologie de gestion de projet si vous ne suivez pas également de bons processus de développement. Faites-vous des tests unitaires automatisés? ou encore mieux, des tests d'acceptation automatisés? Vos développeurs sont-ils appariés, ou effectuez-vous au moins des révisions de code et/ou des procédures pas à pas fréquentes? Pratiquez-vous une forme d'intégration continue?
"Quand est-il juste de regarder la qualité des développeurs?"
Tout le temps. De toute évidence, certaines personnes sont plus productives que d'autres, vous n'avez pas besoin d'une excuse en tant qu'employeur pour mesurer leur performance.
Le plus difficile est de savoir comment vous le faites. Mon conseil est d'embaucher des contractants expérimentés pour travailler aux côtés de votre personnel permanent sur le même ensemble de tâches estimé par vos gars permanents et 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 également donner un coup de pied aux gars.
De plus, s'ils se plaignent que les entrepreneurs sautent sur la qualité, etc. pour gagner en vitesse, cela entraînera une conversation sur la valeur de l'entreprise. Maintenabilité à long terme ou produits à court terme expédiés.
S'il s'agit de choses à long terme, cela vous obligera à le quantifier et à le déposer dans le sprint selon les exigences!