Comment arrêter / éviter au fil du temps sur une équipe Scrum?

En fait, j'aide une petite boutique de logiciels sur leur implémentation Scrum. Récemment, le Scrum Master m'a signalé qu'il avait un problème parce que l'équipe travaille au fil du temps pour atteindre la portée (carnet de commandes engagé). Ils ont donc une vitesse irréelle .

Ma ou mes questions formelles sont:

1. En plus de parler de la réunion rétrospective; Pensez-vous que c'est une bonne idée d'implémenter des blocs durs pour éviter au fil du temps?

2. Si oui, quelles techniques / outils proposez-vous?

   • Système de contrôle des révisions (SVN, GIT, HG, etc ...), blocs par heures (8 à 5)
   • Blocs de poste de travail par heures (8 à 5) ou heures cumulées (jusqu'à 8 heures / jour)?
   • Autres)...

3. Ou, peut-être, ne bloquez pas ce genre de choses; mais mettre en place un "système de pénalité" pour les heures supplémentaires injustifiées ?

@Baqueta (et d'autres avec des questions similaires): Non, ils ne sont pas payés pour les heures supplémentaires. Mon premier conseil a été de revoir leurs estimations car peut - être qu'ils sous-estimaient. C'était mon conseil préféré:

S'ils ont intérêt à faire des heures supplémentaires, supprimez-le. Le développement n'est pas quelque chose que vous pouvez faire pendant 60 heures par semaine et rester productif, et il existe de nombreuses études qui le prouvent. Si la rémunération des heures supplémentaires est le problème, éliminez-la et améliorez leur salaire de base afin qu'ils obtiennent ce qu'ils valent.

En outre, je pense que le problème racine (pour cette équipe) est une combinaison des éléments suivants:

1. Les développeurs sont informés de ce qu'ils doivent réaliser dans un sprint / ne sont pas consultés sur ce qui est réalisable / sont ignorés lorsqu'ils disent qu'il y a trop de travail.
2. Les développeurs sous-estiment constamment le temps nécessaire aux tâches / le nombre d'unités de travail impliquées dans chaque tâche.

Résumé: Je vais parler à l'équipe pour revoir ses estimations, et avec le bon de commande parce que j'estime qu'ils ne sont pas consultés sur la portée, comme vous l'avez mentionné.

Franchement, ces «blocs durs» que vous mentionnez dans # 2 sont la pire idée que j'aie entendue depuis longtemps. Que se passe-t-il si un bug prioritaire est détecté à 16h45 et que le gars qui a la capacité de remplacer vos blocs est malade? Quant au numéro 3 - vous proposez de punir les gens pour avoir fait leur travail .

Si l'équipe travaille régulièrement des heures supplémentaires pour effectuer des sprints, alors soit elle a intérêt à travailler des heures supplémentaires - par exemple, la rémunération des heures supplémentaires ou la récupération des heures supplémentaires comme jours fériés - soit elle s'engage à faire trop de travail dans les sprints.

S'ils ont intérêt à faire des heures supplémentaires, supprimez-le . Le développement n'est pas quelque chose que vous pouvez faire pendant 60 heures par semaine et rester productif, et il existe de nombreuses études qui le prouvent. Si la rémunération des heures supplémentaires est le problème, éliminez-la et améliorez leur salaire de base afin qu'ils obtiennent ce qu'ils valent.

S'il y a trop de travail dans les sprints, c'est généralement pour l'une des trois raisons:

1. Les développeurs sont informés de ce qu'ils doivent réaliser dans un sprint / ne sont pas consultés sur ce qui est réalisable / sont ignorés lorsqu'ils disent qu'il y a trop de travail.
2. Les développeurs sous-estiment constamment le temps nécessaire aux tâches / le nombre d'unités de travail impliquées dans chaque tâche.
3. Les développeurs continuent d'être entraînés sur des tâches qui ne font pas partie de la mêlée.

Si c'est # 1, vous vous trompez . Il n'y a pas deux façons de faire!

Si c'est le numéro 2, la cause habituelle est l'inexpérience - soit en faisant des estimations de temps, soit avec le système en cours de développement. Un bon moyen de contourner ce problème consiste à arrêter de faire des estimations de temps et à commencer à estimer les «unités de travail». Utilisez une unité abstraite, assurez-vous simplement qu'il ne s'agit pas d'heures en temps réel (en fin de compte, vous représentez toujours un intervalle de temps, mais l'abstraction est importante!). Vous pouvez ensuite commencer à calculer le nombre d'unités de travail réellement effectuées en une semaine, puis configurer des sprints en utilisant ces données.

Si c'est # 3, vous devez commencer à prendre en compte ces autres tâches d'une manière ou d'une autre. S'il est cohérent, il devrait être facile d'en tenir compte (voir n ° 2 ci-dessus). Si c'est fréquent mais imprévisible, c'est beaucoup plus difficile à gérer. Vous voudrez voir pourquoi cela se produit (par exemple, de graves bogues dans le code 'live' => vos tests sont-ils suffisamment approfondis?) Mais si cela ne peut pas être corrigé, finalement Scrum pourrait ne pas être la bonne approche pour vous. Mon équipe est récemment passée à Kanban pour cette raison même ...

Edit: clarifié ma critique des idées présentées dans la question.

Tout d'abord, il semble qu'ils aient trop travaillé sur un sprint s'ils doivent faire des heures supplémentaires pour le faire. Toutes les heures sont-elles enregistrées? Si c'est le cas, vous pouvez compter combien de travail réel est un point d'histoire et utiliser ce nombre pour calculer le travail pour le prochain sprint.

Il est également important de s'assurer que l'équipe comprend qu'elle ne se fait du mal qu'en prenant trop de travail. Même le manifeste agile parle de rythme durable: "Les processus agiles favorisent le développement durable. Les sponsors, les développeurs et les utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment." Faire des heures supplémentaires tout le temps n'est pas viable.

Dans l'ensemble, je suggère la communication plutôt que la force et les sanctions. J'imagine que cela ne ferait que conduire à la démoralisation de l'équipe.

Les développeurs qui font des heures supplémentaires répondent probablement à une incitation, réelle ou perçue. Il s'agit soit de supprimer l'incitation si elle est réelle, soit de communiquer qu'une incitation perçue n'est pas opérationnelle.

Chaque limite fixe suggérée présente des solutions de contournement ou d'autres problèmes. Les blocs de contrôle de source conduiraient simplement les développeurs à conserver leurs validations jusqu'à ce que la fenêtre s'ouvre à nouveau. Les blocs de poste de travail devraient disparaître dès qu'il y avait un problème de support ou que l'un des devs devait changer ses heures pour une raison quelconque. Les systèmes de sanctions entraîneront simplement le masquage ou l'enterrement des heures supplémentaires.

Je pense que le problème est plus fondamental - l'équipe est incitée (ou croit avoir une incitation) à faire des heures supplémentaires.

C'est ce qui doit être abordé. Leurs évaluations de performances sont-elles liées à leurs chiffres de vitesse? La direction fait-elle des heures supplémentaires? Des promotions et récompenses sont-elles accordées à ceux qui travaillent de longues heures? S'agit-il de sous-traitants rémunérés pour les heures supplémentaires?

Dites simplement à l'équipe de ne pas faire d'heures supplémentaires. Période.

Cela peut les empêcher de terminer certains travaux. Ce n'est pas un problème, c'est un point de données. Ils peuvent ensuite utiliser ce point de données pour planifier le prochain sprint. Encore une fois, ne les laissez pas faire des heures supplémentaires. Qu'ils terminent ou non, ils ont un autre point de données. Faire mousser, rincer, répéter.

Aucune quantité de tours ou de limites n'est nécessaire. Ne faites pas d'heures supplémentaires. Découvrez combien de travail vous pouvez accomplir et ajustez votre planification de sprint en conséquence.

Peut-être y a-t-il un problème de non pas «combien» ils travaillent mais quand. Cela peut être un problème lorsqu'il y a une journée de travail prévue, mais une grande partie des heures normales sont constituées de réunions et d'autres distractions sociales et personnelles. Travaillent-ils pendant des périodes prolongées parce qu'ils se sentent simplement plus productifs.

Réduisez la quantité de travail dans le sprint et commencez à travailler sur le temps flexible. Permettez-leur de rentrer plus tard. Le responsable doit simplement dire aux gens de rentrer chez eux; C'est bon. Il existe certaines cultures d'entreprise qui créent un environnement où le fait de partir tôt peut provoquer des froncements de sourcils.

J'ai eu du mal avec cela quand je suis passé à la mêlée. Il est naturel de vouloir faire des efforts supplémentaires près d'une échéance, mais la mêlée a des échéances toutes les deux semaines, c'est donc un ajustement. En plus de la suggestion que d'autres ont faite de réduire les points d'histoire engagés à chaque itération, je suggérerais également de veiller à ce que les histoires soient suffisamment détaillées, afin que chaque développeur puisse terminer au moins deux ou trois dans une itération.

Cela garantit non seulement que chaque développeur a l'impression d'avoir accompli quelque chose à chaque itération, mais vous donne également un peu de marge dans votre portée. Lorsque votre burndown montre que vous ne pourrez pas terminer une histoire, vous pouvez la retirer et réaffecter des personnes aux histoires qui peuvent être terminées. Lorsque les gens voient que la portée peut être ajustée, ils seront moins susceptibles de souligner les délais irréalistes. Si vous commencez une itération avec chaque histoire en cours, vous n'avez pas de place pour l'ajustement.

Un organigramme cumulatif idéal devrait ressembler à ceci si tout le monde termine deux histoires par itération:

Cela ne ressemble jamais à ça parce qu'en réalité, il est très difficile de chronométrer toutes les histoires pour terminer le dernier jour tout en gardant tout le monde occupé, mais c'est une bonne règle de base. Si vous êtes trop engagé, la zone rouge sera plus grande et vous pourrez supprimer les histoires. Si vous êtes sous-engagé, la zone bleue sera plus grande et vous pourrez ajouter des histoires. Si vos histoires sont trop grandes, la zone verte sera plus grande et vous devez diviser les histoires.

Pour éviter les heures supplémentaires, vous devez réduire la portée du projet.

Le graphique suivant montre où réside l'incertitude dans un projet:

Si vous remarquez, lors des phases de définition du produit et des exigences, vous avez une énorme variance dans l'estimation de l'effort. Vous ne pouvez pas être sûr qu'il faudra un mois ou un jour pour mettre en œuvre la fonctionnalité.

Je parie qu'aucune des tâches n'est effectuée parce qu'elles sont simplement trop grandes et non spécifiées et qu'elles sont trop nombreuses.

Si votre équipe peut gérer 10 tickets en 5 jours, et qu'ils lui sont attribués 20, réduisez ce nombre, donnez-le au propriétaire du produit / chef de projet / manager / client et dites-lui de prioriser.

À ce stade, c'est le seul moyen de sauver l'équipe des heures supplémentaires. Vous ne pouvez pas tout livrer, mais quoi que vous fassiez, il y aura moins de bogues.

Je conseillerais également de chercher un nouvel emploi et d'aider vos coéquipiers à faire de même et à corriger leurs CV et portefeuilles professionnels. Une entreprise qui s'attend à des heures supplémentaires est une personne pour qui personne ne devrait travailler et le logiciel produit sera bogué comme un enfer.

Je déconseille fortement les "blocs durs". Ces contrôles pourraient être perçus comme de la micro-gestion et pourraient ne pas résoudre le problème sous-jacent.

Je vous suggère de découvrir pourquoi les programmeurs font des heures supplémentaires. La réponse pourrait te surprendre. Il semble que vous soyez un "étranger" (pas un employé de l'entreprise), et les programmeurs peuvent être disposés à être francs avec vous si vous les rencontrez en privé (en tête-à-tête).

La raison de faire des heures supplémentaires est-elle vraiment la charge de travail, ou est-ce davantage la raison de la culture ou des attentes?

Les raisons de la charge de travail pourraient être

• L'arriéré engagé est trop important
• Soit les programmeurs soit le propriétaire du produit "plaquent l'or" (rendant les fonctionnalités plus complexes que nécessaire)

Les attentes pourraient être

• Une sorte de récompense financière ou de reconnaissance pour les heures supplémentaires
• Peur de l'échec. Les programmeurs ont peur de mal paraître ou d'être punis s'ils ne respectent pas le délai
• Les programmeurs sous-estiment les effets néfastes à long terme des heures supplémentaires.