Je suis nouveau dans le monde scrum.
L’équipe dans le lequel je travaille traite des sujets d’infra à 70% et dev 30% environ.
Je vous expose une problématique que nous avons.
L’équipe travaille dans un environnement où il y a de très (trop) nombreux problèmes techniques indépendants de l’équipe. De nombreux outils Paas/Saas/Iaas, microservices tiers nécessaires à la réalisation des tâches de l’équipe sont en effet souvent dysfonctionnel
Lorsque cela arrive, nous devons ouvrir des tickets d’incidents chez ces équipes qui peuvent mettre quelques jours à quelques semaines pour les traiter… bloquants donc le traitement des US en attendant. Les US « suspendues » se cumulent…
Comment fonctionner en scrum dans ce type d’environnement car nos estimations sont complètement faussés selon l’arrivée d’incident… sans compter la perte d’efficacité(et motivation…) des équipiers dans le traitement de ces US qui font du STOP and GO sans arrêt à cause de ces incidents récurrents… ?
Est-ce que dans ce type de contexte un fonctionnement en Kanban, Scrumban ne serait pas plus approprié ? En effet, a-t-il un intérêt de parler de sprint et de point de complexité quand on sait d’avance que la probabilité de finir une US dans le sprint relève de l’ésotérisme ?
Merci
PS :
Bien sûr nous avons remonté ces problèmes récurrents depuis des mois aux différentes équipes/manager concernées mais rien ne bouge…
à chaud, je pense à Mock et TDD. Découpler.
Décrire une interface pour se rendre indépendant de ces tiers.
Le but est de livrer pour permettre d’apprendre des utilisateurs du produit.
On peut apprendre sur base de données factices.
De l’intégration continue qui permettra ensuite recoler les morceaux.
Bref se rendre assez indépendant pour récuper la maitrise des conditions de développement.
Vraiment posez vous la question « comment se passer d’eux pour travailler »,
Quand on aura validé ce que nous on a livré, alors on se réintègrera à eux.
Je ne pense pas que la question doit se poser en fonction de cette situation de dépendance aux tiers.
La question Scrum VS Kanban, elle tourne autour du
Y a-t-il un sens d’avoir un cycle de livraison basé sur un objectif de sprint bien clair, et d’envisager des PBI liés à cet objectif ?
Est-on sur un flux d’éléments « à réaliser » indépendants les un des autres ? on va juste essayer de les finir avant d’en commencer d’autres.
Y a-t-il un sens d’avoir une approche lean (avancer par petit pas ) tester, apprendre, choisir ? Où est-on tellement certain de ce qu’il faut livrer que le waterfall est finalement plus rentable …
Je ne prétends pas que mes questions et choix sous-jacents soit parfait, mais par contre, je suis convaincu que ce n’est pas un choix qui se fait en fonction de la dépendance aux tiers.
Autre point d’attention.
Faire la différence entre
J’ai besoin que le tiers ait FINI son travail avant de commencer le mien => dans ce cas, vous êtes en fait une colonne d’un kanban d’un flux plus global
J’ai besoin que le tiers soit fiable => on est dans une question d’architecture, et vous pouvez développer un produit résiliant. Qui fait de la non-fiabilité du tiers une contrainte
J’ai une vision plus globale : l’optimisation locale c’est l’équivalent du mythe de Sisiphe. Vous aurez beau pousser, le rocher retombera.
Découpler le maximum de travail est une évidence, comme le dit Moosh. Mais de ce que je comprends : vous êtes totalement dépendants de ces outils.
Donc soit vous en créez d’autres pour vous (du vécu : une équipe avait une CI/CD qui était pourrie, ils ont créé la leur), soit vous abandonnez l’idée de la vitesse et vous freinez. Comme dans une randonnée, le plus lent, on l’attend tous et on va à son rythme !
Perso, fonctionner en Scrum ou autre dans ce genre d’environnement n’a pas de sens. Scrum fonctionne quand l’entreprise essaie de limiter les dépendances, pas quand elle les maximise (c’est le cas ici…). Kanban, à la limite, pourrait aider à montrer le stock et créer un sentiment d’urgence que ça se passe mal, mais faut que le management accepte à minima de voir ce stock…
J’irais un peu plus loin. Scrum est intéressant quand l’équipe a besoin de pivoter. Toutes ces dépendances externes empêche de pivoter. Et on se retrouve à vouloir évoluer en essayant de se faire pousser des pattes de lièvre alors que l’on porte sur son dos la carapace écrasante de l’organisation. Soit comme le propose @BenjaminF, vous virez votre carapace et vous assumez votre statut de lièvre, soit on se met dans la tête qu’on est une tortue, et que des pattes de lièvre, c’est pas l’idéal.
?