Est-ce professionnel de finir le Sprint à 21h ?
RESSOURCES
Temps de lecture estimé : 10 minutes
Résumé
Parfois, certaines actions semblent bonnes à court terme, mais masquent en réalité des dysfonctionnements lourds. Faire des heures supplémentaires en situation de stress n’est pas un remède viable à long terme et ne doit pas être vu comme une solution professionnelle, mais un signal d’alarme à entendre courageusement.
Contexte
Nous sommes jeudi soir, la veille de la fin du Sprint. Il est prévu par le Product Owner que l’incrément qui va être inspecté demain soit mis en production à l’issue de la Sprint Review. La dernière mise en production a été réalisée plusieurs Sprints plus tôt. Le Scrum Master constate que “L’équipe reste jusqu’à 21 h la veille de la mise en production, elle est très engagée et professionnelle !” En êtes-vous certain ? Est-ce un comportement que vous souhaitez valoriser et voir reproduit régulièrement ? Ce comportement est-il vraiment aligné avec le rythme soutenable prôné par le Manifeste Agile et les valeurs de Scrum ?
Symptômes
Jeudi matin, la mise en production espérée le lendemain est très incertaine, d’autant plus que de nombreux travaux sont encore en cours.
Pourtant, aucune alerte ni action corrective n’a été levée au sein de l’équipe de développement ou avec le Product Owner pendant le Sprint.
Tous ces travaux représentent un risque important vis-à-vis de l’atteinte du Sprint Goal et de la réussite du Sprint.
En outre, les procédures de mise en production sont complexes et demandent l’intervention d’autres équipes opérationnelles qui ont les compétences, outils ou habilitations requises pour réaliser les installations sur les serveurs de production.
Enfin, l’entreprise attend beaucoup de cette nouvelle mise en production. La dernière a eu lieu il y a plusieurs Sprints, et l’équipe ressent une forte pression liée à l’importance de cette nouvelle mise en production.
Le risque et les enjeux sont ressentis par tous comme étant tellement élevés que l’échec n’est plus une option acceptable pour l’organisation.
Le niveau de stress est très élevé, l’équipe de développement sait déjà qu’une journée infernale s’annonce.
L’équipe marche sur une corde raide, elle ne travaille plus en confiance, dans le respect d’un rythme de travail soutenable, elle s’épuise physiquement et psychiquement, les risques d’erreurs croissent, la motivation baisse.
Causes
Une grande force de Scrum est d’être un formidable outil de gestion de risques.
Dans un environnement complexe, une approche empirique telle que Scrum est un outil parfaitement approprié : la part d’incertitude est si importante que nous avons plus de chance de réussir par l’exploration, l’analyse et la réaction que par la conception et le suivi d’un plan rigide.
Pour parvenir à cela, nous avons besoin des 3 piliers de l’empirisme que sont :
- La Transparence,
- L’Inspection
- L’Adaptation.
Mais l’empirisme fonctionne à condition de travailler dans un contexte où l’adaptation est possible, c’est-à-dire qu’il est possible que les résultats ne soient pas ceux escomptés et que des décisions soient prises pour mettre en place des adaptations pertinentes.
En clair : vous avez le droit à l’erreur, car le risque lié à une erreur probable est acceptable.
Il est malheureusement fréquent que Scrum soit mis en place dans des organisations qui n’ont pas pleinement intégré ce que signifient les notions fondamentales d’empirisme et de complexité.
Scrum est mis en place sans changement d’état d’esprit ni changement de comportements :
on travaille “comme d’habitude”, on essaye au mieux de respecter le plan de livraison initialement prévu (respect des délais et des périmètres initialement prévus), mais en utilisant un nouveau jargon.
Ainsi, le Product Owner continue de prévoir des grosses livraisons peu fréquentes, ce qui affecte la transparence et restreint les opportunités d’inspection. L’horizon de risque acceptable pour fonctionner de manière empirique est alors largement dépassé. On ne “gère” plus les risques, on espère, on croise les doigts, on brûle des cierges et on fait tout pour que le plan soit respecté comme prévu.
Le travail est poussé vers l’équipe sans que l’organisation ne respecte la capacité et la responsabilité de l’équipe ou sans que l’équipe n’ait le courage de refuser de se laisser imposer plus de travail que de raison.
Il est également fréquent que les membres de l’équipe de développement travaillent en parallèle sur de trop nombreux Product Backlog items. L’équipe n’est pas focalisée sur l’atteinte du Sprint Goal, mais sur l’occupation des “ressources”.
De ce fait l’implémentation des Product Backlog items débute tôt dans le Sprint, mais ils sont déclarés “finis” très tardivement, et l’intégration de l’ensemble des travaux se termine dans la douleur jusqu’au jeudi soir 21 h !
L’équipe n’arrive pas à réduire les risques à cause de ce manque de focalisation pour terminer régulièrement et fréquemment les Product Backlog items, un par un au fil du Sprint. Parmi les causes possibles, on peut retrouver une insuffisance de collaboration entre les membres de l’équipe.
Cette insuffisance peut être accentuée par un manque de polyvalence (profils en “I” plus que profils en “T” car chacun a son domaine d’expertise et ne peut ou ne veut pas contribuer sur un autre domaine) ; un manque de compétence ou d’outils pour atteindre une Définition de Terminé permettant une mise en production simple ; des dépendances avec d’autres équipes qui empêchent notre équipe d’être suffisamment autonome pour implémenter et déployer des incréments seule et rapidement.
Tout cela laisse planer les risques comme une épée de Damoclès au dessus de la tête de l’équipe jusqu’à la toute fin du Sprint.
Remèdes possibles
Gunther Verheyen nous aide à comprendre ce qui signifie la notion d’engagement dans le contexte de Scrum :
“L’engagement concerne le dévouement et s’applique aux actions et à l’intensité de l’effort. Il ne s’agit pas du résultat final, car cela en soi est souvent incertain et imprévisible pour des défis complexes dans des circonstances complexes.”
Une équipe Scrum qui se déclare à la fois professionnelle et engagée doit donc limiter l’accumulation des risques en faisant les efforts pour se focaliser et collaborer à faire le travail différemment.
L’équipe doit exploiter l’empirisme pour travailler dans un périmètre de risque tolérable, ce qui signifie qu’au quotidien, en particulier grâce au Daily Scrum, l’équipe de développement doit inspecter le travail restant à accomplir pour atteindre le Sprint Goal et agir dès qu’elle considère, de manière professionnelle, que les risques s’accroissent au lieu de diminuer.
Par exemple, si l’équipe se rend compte que l’implémentation d’un Product Backlog item est plus difficile que prévu, le Sprint Backlog est impacté. Cela peut conduire l’équipe de développement à considérer maintenant que l’implémentation d’un autre Product Backlog item est fortement compromise, sauf à sacrifier la qualité, ce qui n’est pas une option acceptable de la part d’une équipe Scrum professionnelle.
L’équipe Scrum pourra alors agir avec ouverture, courage et professionnalisme et décider d’adapter le Sprint Backlog tout en préservant le Sprint Goal.
Cette adaptation peut se faire en décidant de revoir le découpage des Product Backlog items en isolant les fonctionnalités qui assurent l’atteinte du Sprint Goal et en laissant de côté pour des Sprints ultérieurs des fonctionnalités moins importantes. Mais l’adaptation peut se faire également en organisant le travail de l’équipe de développement différemment, en mettant en place du binômage, du mob programming, de la formation ou du mentoring pour faciliter la polyvalence, l’autonomie et la focalisation de l’équipe.
Ainsi, la gestion des risques est un sujet de préoccupation quotidien et n’est plus un sujet qui se rappelle douloureusement à l’équipe Scrum uniquement la veille de la fin du Sprint ou d’une mise en production.
De son côté, le Product Owner devrait rechercher à limiter autant que possible la taille des livraisons idéalement dès qu’un incrément est prêt, plusieurs fois par Sprint. Et bien sûr, le Scrum Master est là pour rendre tous ces problèmes transparents pour que l’équipe mette en place les adaptations pertinentes.
Conclusion
Une utilisation professionnelle de Scrum doit se traduire par le respect et la mise en oeuvre de l’ensemble des valeurs et principes de l’agilité.
En particulier, des produits à forte valeur ajoutée doivent être livrés rapidement et régulièrement, sans jamais abaisser les critères de qualité, dans le respect d’un rythme de travail soutenable pour tous.
Charge à chacun d’agir en professionnel responsable et d’avoir le courage de transformer ses manières de travailler afin d’obtenir tous les bénéfices de l’Agilité. Cela peut nous inviter à remettre en cause nos modèles mentaux si l’on veut obtenir des changements pérennes.
Et vous, qu’allez-vous avoir le courage de faire différemment maintenant ?
