Le Sprint Objectif, un « Scrum Implementation Point Of Failure » ? Je vous propose de voir cela tout de suite.
Scrum Implementation Point Of Failure
Avez-vous rencontrés des Sprints d’équipe « Scrum » qui ressemblent à ça ?
- Des Sprint sans objectifs ; le sprint est juste une liste de fonctionnalités
- Des Sprint avec un objectif non décidable ; à la fin on ne peut pas dire qu’on l’atteint ou pas
- Engagement de Sprint basé sur le nombre de points
Si oui, je vous invite à prendre quelques minutes avant d’aller plus loin ; réfléchissez à la question suivante :
Quels sont pour vous les impacts ou les conséquences possibles ?
Me concernant, je peux dire que j’ai rencontré cette « mauvaise » implémentation, à plusieurs reprises, qui respectent « la forme, certaines pratiques » sans le « fond, la valeur » ce qui donne comme conséquences la démotivation et le manque de cohésion.
Qui à leur tour, petit à petit, inscrivent l’équipe dans un cercle infernal et vicieux 🙁
Mon but n’est pas de pointer Scrum ou de redéfinir la notion d’objectif de Sprint (cf. fin article), mais de partager mon expérience et éventuellement quelques actionnables et take-away. L’absence ou la multiplicité des objectifs de Sprint, conduit malheureusement à plusieurs « symptômes » plus au moins liés, observables sur quasiment l’ensemble des équipes Scrum que j’ai accompagné en mode « change management »
Symptômes constatés
- Absence de cohésion, l’équipe ressemble plus à un groupe d’individus, partageant une liste de chose à faire qu’une équipe réunie et soudée autour d’une vision et d’un objectif commun.
- Dé-Responsabilisation, l’équipe se voit responsable d’une quantité de travail, qui n’est pas vraiment portée par l’équipe, car en général se sont les managers qui « règlent cela entre eux », entre défense des collaborateurs « IT » et « Plan d’Actions »
- Individus démotivés, certains le vivent, pour ne pas dire tous les membres de l’équipe, comme une incompréhension de leur mission et surtout de leurs raisons d’être. Leur mission c’est de résoudre des problèmes utilisateurs/client, pas de produire de la quantité de travail. Un engagement via la quantité de travail, c’est manquer de sens, manquer d’autonomie et manquer de créativité
- Qualité médiocre, c’est une réaction naturelle à une forte pression et stress, car naturellement, l’absence d’objectif de valeur, conduit à un cercle vicieux lié au stress et au manque de temps (j’entends des phrases comme on a pas terminé nos Sprints) engendré par les mini-forfaits « sprints » mis en place, et bien entendu, et malheureusement, c’est bien la qualité qui est sacrifiée dans ces cas là
- Parfois, Mauvaise ambiance, dans une situation de stress, l’être humain, cherche la survie et parfois cela passe aussi par la recherche du coupable. Qui est responsable de la non tenue des engagements quantitatif ? La chasse à la sorcière est ouverte !
Avez-vous quelques uns de ces symptômes (et il y’en a certainement d’autres) dans la réponse à la première question ? Bien évidement, ces « symptômes » peuvent être également liés à d’autres conditions, seulement, une absence ou une mauvaise implémentation de l’objectif de Sprint, présente déjà un bon « Scrum Implementation Point Of Failure », la définition ?
C’est un point qui peut simplement avoir un impact important sur votre implémentation de Scrum, et du coup sur le moral de l’équipe.
Quelques questions-take-away
Pour finir cet article, quelques questions-take-away :
- Par ici un superbe template d’objectif de Sprint : https://www.romanpichler.com/tools/the-sprint-goal-template/ Un objectif de Sprint, lorsqu’il est atteint, c’est une victoire non négociable, non contestable.
- Pouvez-vous, avec la durée de vos Sprint, avoir un objectif décidable ( Soit atteint soit non atteint à la fin, 0 ou 1, pas entre les deux) avec une valeur apportée claire ? Si oui, très bien, sinon deuxième question !
- Si vous avez plusieurs objectifs habituellement, pouvez-vous ajuster la taille de vos sprints pour en avoir qu’un ? Si oui super, sinon troisième question
- Et s’il n’est pas possible de définir un objectif par Sprint, ni d’ajuster la durée de vos Sprints, avez-vous besoin d’avoir des itérations ? Si oui pourquoi ?
- Si oui, pouvez-vous envisager un IP Sprint ( Sans parler forcement d’agilité à l’échelle, j’ai vu une équipe Scrum l’implémenter justement pour donner du souffle à la team et faire de la qualité )
- Enfin, avez-vous envisagé d’utiliser le Kanban ? C’est peut-être plus adapté à votre contexte.
Un Sprint Goal atteint, est une opportunité pour une belle célébration !
Coach Agile expérimenté, et je continue à apprendre tout les jours donc je ne sais rien #agnostic-agile power !
Disaclaimer et Références
- Il ne s’agit pas de pointer Scrum, j’affectionne particulièrement ce tout petit Framework, et si puissant. Encore faut-il en comprendre les mécanismes profonds ou appliquer ses règles fondamentales et côté de manières holistique (cf Scrum Check-list ).
- Il ne s’agit pas non plus de redéfinir ce que c’est qu’un objectif de Sprint ni comment le construire.
Soyez le premier à commenter