Ok donc commençons rudement - une grande partie du problème est avec vous - Vous entendez, mais vous n'écoutez pas. Votre équipe vous dit clairement quels sont les problèmes. Vous devez vous adresser à eux au lieu de blâmer votre équipe.
Planification
Pour eux, la planification n’est qu’une perte de temps, car nous ne faisons que déborder du nouveau Sprint et ne terminons pas le travail de toute façon, alors pourquoi s’embêter.
Exactement. Si vous omettez systématiquement d'allouer le temps correct aux tâches et que celles-ci sont constamment sous-estimées, cela a des effets très négatifs:
- Les développeurs se sentent constamment sous pression.
- "Je ne peux rien faire à temps".
- Comme le processus ne fonctionne pas, ils le voient à juste titre comme une perte de temps.
Solution : corrigez vos estimations en utilisant une combinaison de:
En guise de base, vous devez absolument suivre le temps qu'il a effectivement fallu pour terminer les tâches précédentes. Cela inclut les tests, la rédaction de la documentation, la rédaction des tests, la formation des utilisateurs finaux, les efforts d'intégration, le déploiement. etc.
Une fois que vous avez le temps total pour une tâche donnée, vous pouvez baser le temps attendu sur ces tâches précédentes.
Demandez à chaque membre si la tâche qui leur est confiée vous semble plus compliquée ou plus facile que la sélection des tâches précédentes, ajustez le nombre de tâches attribuées en fonction de cela.
Si vous n'avez pas utilisé SP auparavant, mon conseil est de commencer par 1h de vrai travail honnête avec dieu = 5SP à titre indicatif. Gardez à l'esprit que dans l'environnement de développement habituel, vous en obtiendrez peut-être 6 par jour, donc 30 PS / jour maximum . Ne permettez jamais à une tâche de prendre plus de 2 jours pour être inscrite au tableau. Idéalement, d'après mon expérience, vous devriez avoir 2 tâches par jour.
Si vous ne planifiez pas correctement, le reste de vos activités Scrum ressemblera à une perte de temps (y compris la planification).
Rétrospective
Pendant la rétrospective, je peux simplement sentir qu'ils veulent dire "Arrête de faire Scrum". Une personne le fait, mais les autres se taisent et je dois régler ce problème à chaque fois.
Cela me rappelle Daily beatings will continue until morale improves!
deux emplois passés. Si vous ne supprimez pas les obstacles, ils ont alors raison de dire que c'est une perte de temps.
Encore une fois, écoutez ce que les gens disent réellement. Si les plaintes soulevées lors de la rétrospective ne sont pas traitées, pourquoi se donner la peine de les traiter?
Alors:
- Considérez les techniques Six Thinking Hats pour améliorer la communication.
- Réduisez le temps passé sur Rétrospective, maximum 30 minutes.
- Assurez-vous que les plaintes formulées lors de la rétrospective sont traitées avant la prochaine.
SCRUM quotidiens
Daily Scrum est encore une perte de temps pour eux, car aucun d’eux ne veut parler et planifier sa journée. Ils disent simplement: "J'ai travaillé sur la tâche X hier et y travaillerai encore aujourd'hui". Et la plupart du temps, ils plaisantent jusqu'à ce que je devienne plus sévère.
On dirait que vous avez deux problèmes ici: les réunions SCRUM sont trop longues et votre planification et la création de tâches sont nulles.
Les deux peuvent donner l'impression qu'une réunion de mêlée est une perte de temps.
Pour la longueur SCRUM:
- Essayez 15 minutes maximum.
- Essayez tout le monde debout.
- Formule fixe:
- Qu'as-tu fait hier?
- Que comptez-vous aujourd'hui?
- Ce que les membres de votre équipe (pas vous!) Devraient savoir sur la tâche, comment cela va les affecter.
- Ne vous embêtez pas avec des obstacles si vous n'allez pas les aborder.
C'est une deuxième preuve que votre planification nuit à votre situation - si vous n'avez rien de précis à signaler, cela signifie généralement que la tâche est trop lourde et que tout ce que vous pouvez dire, c'est: je travaillais là-dessus.
- Décomposer les tâches en points critiques.
- Assurez-vous que les tâches sont suffisamment petites pour prendre moins d'une journée. Dans l’idéal, la tâche de l’OMI devrait durer environ 3 heures et équivaloir à 13 SP environ, de sorte que vous puissiez en faire 2 par jour dans la plupart des conditions.
Traiter avec l'équipe
Aujourd'hui, la personne qui est toujours contre moi m'a dit de cesser de dire: "Ils ont dit que c'était ce qu'ils s'engageaient pour ce Sprint" parce que, selon ses mots, "Nous ne terminons jamais un Sprint. Nous ne faisons que déplacer des tâches et en intégrer de nouvelles dans le prochain sprint pour remplir un quota. Nous faisons KanBan en réalité. Alors arrêtez de dire ça. "
Il a raison. Vous avez tort. Vous faites un SCRUM bâtard et / ou une variation sur le Kanban. Pas de leur faute du tout.
Je comprends pourquoi il dit cela, mais il ne semble pas se rendre compte que c’est comme cela parce que lui et tous les autres membres de l’équipe ne s’inquiètent pas.
Je ne pense pas que vous comprenez du tout. Ils se soucient peut-être moins qu'avant, cependant, les blâmer ne permettra pas d'améliorer rien, cela pourrait simplement aggraver la situation. Si c'était le fond, ils pourraient commencer à creuser.
Ils travaillent simplement au lieu de gérer les obstacles.
Et là, je pensais que faire leur travail était leur travail. Je me demande qui était supposé avoir affaire à des empêchements ... oh oui. Un Scrum Master. C'est ton travail. Ils vous disent ce qui ne va pas. Vous le réparer. Pas l'inverse.
C'est probablement pourquoi vous avez tant de problèmes dans la rétrospective.
Comment puis-je leur faire voir que les plaisanteries et les cercles saccadés lors de ces réunions coûtent beaucoup d'argent à l'entreprise?
Arrêtez les réunions inutiles et ils vont plutôt plaisanter autour du refroidisseur d'eau. Voir également le paragraphe sur les passages à tabac qui améliorent le moral. S'ils utilisent l'humour comme mécanisme de défense, vous avez de sérieux problèmes, monsieur!
Plongez dans une blague - comme dans le travail avec votre équipe, pas contre. (Qui le fuuuuuuck se soucie de l'argent de la société? Êtes-vous actionnaire maintenant?)
Résumer
Votre mauvaise planification fait échouer d’autres parties de SCRUM, et tous ceux qui participent participent malheureux. Ils voient que rien ne change, que rien n’est adressé et que leurs plaintes ne sont pas entendues.
Améliorez votre planification et vous améliorerez le flux et le moral.
En éliminant les obstacles, votre équipe progressera plus rapidement. Demandez-leur ce qu'ils pensent que vous devriez faire pour les aider.
Le plus important: écoutez votre peuple. Ils vous ont déjà dit (et moi) quel est le problème.
Bonne chance!