Maximiser l’utilisation comme une relique du passé de la gestion industrielle
Il y a beaucoup de possibilités d’échec avec Scrum. Étant donné que Scrum est un cadre intentionnellement incomplet avec un « manuel » raisonnable mais court, cet effet ne devrait surprendre personne. Par exemple, que se passe-t-il si l’objectif de l’organisation est de maximiser l’utilisation des « travailleurs » des équipes Scrum ? Et si l’organisation était toujours profondément engluée dans la pensée du paradigme industriel, ignorant les avantages du temps mort pour la création de valeur dans le domaine du travail de la connaissance ?
Rejoignez-moi et découvrez les effets de ce principe de gestion dépassé en 60 secondes.
Le guide Scrum sur la maximisation de l’utilisation ou la sélection des éléments de travail
Rafraîchons-nous la mémoire concernant l’organisation du travail pour le Sprint :
L’unité fondamentale de Scrum est une petite équipe de personnes, une équipe Scrum. L’équipe Scrum se compose d’un Scrum Master, d’un Product Owner et de Développeurs. Au sein d’une équipe Scrum, il n’y a pas de sous-équipes ou de hiérarchies. Il s’agit d’une unité cohésive de professionnels concentrés sur un objectif à la fois, l’objectif du produit.
Les équipes Scrum sont interfonctionnelles, ce qui signifie que les membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint. Ils s’autogèrent également, ce qui signifie qu’ils décident en interne qui fait quoi, quand et comment.
L’équipe Scrum est responsable de toutes les activités liées au produit, de la collaboration des parties prenantes, de la vérification, de la maintenance, de l’exploitation, de l’expérimentation, de la recherche et du développement, et de tout ce qui pourrait être nécessaire. Ils sont structurés et habilités par l’organisation à gérer leur propre travail. Travailler dans les sprints à un rythme durable améliore la concentration et la cohérence de l’équipe Scrum.
La source: Le Guide Scrum de l’équipe Scrum
En discutant avec le Product Owner, les Développeurs sélectionnent les éléments du Product Backlog à inclure dans le Sprint actuel.
La sélection de ce qui peut être accompli au cours d’un sprint peut être difficile. Cependant, plus les développeurs en savent sur leurs performances passées, leur capacité à venir et leur définition du fait, plus ils seront confiants dans leurs prévisions de sprint.
Personne d’autre ne dit [the Developers] comment transformer les éléments du Product Backlog en incréments de valeur.
Source : Le Guide Scrum sur la planification de sprint
Sans surprise, le Guide Scrum ne fait pas référence à l’organisation de l’équipe Scrum de son travail quotidien en plus de pointer les événements Scrum de base et la nécessité d’affiner le Product Backlog en continu. Sinon, définir la façon de travailler de l’équipe fait partie de l’obligation d’autogestion de l’équipe Scrum.
Techniquement, si l’équipe Scrum choisit de le faire, se concentrer sur la maximisation de l’utilisation est une option valable dans le cadre de son autonomie. Cependant, cela devient quelque chose de complètement différent une fois que la direction ou l’organisation poursuit cette approche, l’imposant à l’équipe.
Les effets de la maximisation de l’utilisation tout en ignorant le temps mort
Le problème: L’organisation impose une approche de gestion axée sur les résultats à ses équipes Scrum. La direction voit plus de valeur dans la protection de l’organisation contre le « relâchement » des travailleurs que dans le soutien à l’autogestion au niveau de l’équipe Scrum. De plus, le « Slack time » – autorisant une équipe Scrum à allouer une partie de sa capacité totale comme bon lui semble – est interdit.
Les conséquences: À long terme, l’effet de pousser pour une organisation du travail traditionnelle et axée sur les résultats nuit à la cohésion de l’équipe et permet d’atteindre un niveau élevé de performance soutenue sur le long terme :
- Chacun se concentrera sur l’accomplissement de ses tâches. (Maximiser l’utilisation n’est qu’un pas du classement de la pile.)
- Il y aura moins de temps pour soutenir les coéquipiers ou pour faire équipe.
- L’équipe ne traitera plus rapidement les problèmes mineurs ou moins urgents.
- Les membres individuels de l’équipe pourraient devenir des goulots d’étranglement, ce qui pourrait sérieusement entraver le flux au sein de l’équipe.
- Enfin, l’attitude « Je suis occupé » réduira la création d’une compréhension partagée entre tous les membres de l’équipe, contribuant à une détérioration de la productivité à long terme.
La solution: La surutilisation poussera toujours les membres de l’équipe à se concentrer sur leur rendement individuel, réduisant ainsi la cohésion de l’équipe ou la création d’une équipe Scrum en premier lieu. D’un autre côté, permettre à l’équipe Scrum d’utiliser le temps mort permettra à l’équipe Scrum d’agir en collaboration et de se concentrer sur le résultat tout en améliorant continuellement sa façon de travailler, à la fois au niveau de la collaboration et des compétences.
Conclusion
Lorsqu’on pratique Scrum sérieusement, le souci de la direction de « relâcher les travailleurs » et le besoin qui en résulte de protéger l’organisation contre eux n’est pas pertinent. Au contraire, la direction doit habiliter les équipes Scrum à adopter pleinement l’autogestion. En fin de compte, ceux qui sont les plus proches d’un problème savent généralement mieux comment le résoudre.
Votre direction choisit-elle de protéger l’organisation contre le « relâchement des travailleurs ? » Veuillez partager vos apprentissages avec nous dans les commentaires.