Chapitre 3 : La naissance d’une Scrum Team

Cette volonté des deux unités distinctes de se rapprocher pour améliorer globalement la performance de la création du produit numérique fut quelque chose acceptée par la direction. Non sans un effort tout de même conséquent, notamment de Paul, pour arriver à convaincre que cette expérience valait le coup d’être tentée. Cette nouvelle unité rassemblée était bien évidemment attendue sur les résultats escomptés de cette expérience, notamment autour du fait que ce rassemblement devait améliorer; le Time to Market (T2M). 

Ce T2M était clairement le temps de cycle, mais l’équipe utilisa cette appellation mieux comprise de la direction pour vendre l’expérience qu’elle souhaitait réaliser.

Paul relate que cette évolution d'organisation amena deux choses :

"Le chef de projet "métier" intégra plus ou moins l'équipe dans une redevabilité de Product Owner. Je dis plus ou moins, car on était au tout début de Scrum chez nous. Si aujourd'hui a encore pas mal d'endroits, Scrum n'est pas correctement mis en place, notamment autour de ce rôle de PO, je vous laisse imaginer ce qu'à l'époque (et on parle des années ~2010) ce rôle de PO avait de différents avec celui d'un chef de projet (spoiler alert : rien ou presque). 

Nous (BA) formions avec les développeurs internes, l'équipe de développement Scrum (oui c'est comme ça que ça s'appelait à l'époque, donc j'ai le droit de le dire !)

Nous nous dotions d'un super outil de ticketing. Super est ironique, car il est certainement responsable de pas mal de travers que nous avons pris lorsque nous définîmes notre workflow d'équipe unifiée :

Nous avions enfin une vue plus globale, unifiée de ce que nous faisions pour créer de la valeur.”

Vous avez peut-être remarqué que cette colonne "en attente" était toujours présente avec cette unification des workflows par la fusion des deux entités. 

Paul explique pourquoi : “Eh bien pour nous en tout cas, c'était très clairement parce que nous n'étions pas encore une équipe, mais seulement un groupe de personnes avec quasi toutes les compétences nécessaires, mais toujours à parler de MOA, MOE et à se repasser la patate chaude. Donc oui, on avait toujours cette colonne en attente signifiant principalement qu'on attendait des personnes de la MOE de corriger un problème détecté.”

Une bien mauvaise pratique, en tout cas pour espérer atteindre un flux performant ! (Mais tellement courante dans une organisation avec des silos).

En effet, chaque silo peut être considéré comme une dépendance, par laquelle chaque élément de  valeur potentielle va devoir passer pour pouvoir atterrir enfin dans les mains de l’utilisateur final.

Chaque dépendance est un point où le flux se rompt avec potentiellement (et fréquemment) des éléments qui s’empilent.

En conséquence, ces silos entraînent un accroissement du nombre d'éléments en cours, car par exemple la “MOA” démarre des travaux supplémentaires en attendant soit des développements, soit des corrections. Les changements de contexte sont nombreux ce qui entraîne également une perte d’efficience, liée aux coûts non négligeables en termes de temps à se replonger dans des éléments. Une étude sérieuse sur le sujet des changements de contexte a montré qu’en changeant de contexte entre 2 sujets, il y avait une perte d’environ 20 % du temps, 40 % de temps perdu en poursuivant 3 sujets en même temps. (voir : https://www.scrum.org/resources/blog/financial-cost-task-switching)

Malgré tout, ce rapprochement après quelques semaines d’expérimentation commença à montrer des signes positifs. A la fois sur le T2M, des mesures que tenait le Product Owner en devenir, une tendance baissière était visible. Mais également sur la qualité de ce qui était produit. En effet, ce rapprochement avait entraîné parfois (malheureusement pas encore régulièrement) des ateliers de travail collaboratifs entre les différentes compétences pour comprendre l’attente, la problématique à résoudre et trouver ensemble la meilleure solution. Les compétences techniques pouvaient donc mieux saisir ce qui était attendu, ce qui leur permettaient de faire des propositions (et non plus coder sans chercher à comprendre le pourquoi), ce qui collectivement permettait de mettre en œuvre des incréments plus qualitatifs.

Cependant, il y avait un point d'inefficience notable encore dans cette organisation, il se situait autour de cette unité de développement externe provenant d’un centre de service.

Paul le souligne d’ailleurs très bien :
“En fait dans ce workflow, si un zoom était fait dans "Développement" on voyait que des choses n'étaient plus au sein de notre équipe unifiée, mais du côté de ce centre de services. Les travaux qu'ils faisaient, devaient être intégrés. Nous avions ajouté une étape d'intégration avant l'étape de recette pour rendre cela transparent. Les données collectées montraient clairement un point d'inefficience, cela nous aida à appuyer auprès de la direction le besoin de traiter la problématique. ”

Au détour de l'opportunité d'un changement de centre de service, Paul et ses collègues réussirent à convaincre la direction de faire quelques modifications au contrat et au processus interne. Non sans mal, ils réussirent à faire en sorte que cette force de coding supplémentaire rejoigne leur équipe Scrum et puisse intervenir au même titre que n’importe qui sur le produit.
Une dépendance en moins, un alignement aussi de ces personnes sur un objectif commun, des nouvelles cellules grises pour réfléchir ensemble aux meilleures solutions possibles. In fine, un prestataire et des intervenants plus engagés, car face à des problèmes à résoudre qui avaient du sens pour des utilisateurs finaux (au lieu de “pisser” du code sans en comprendre la raison).

Un changement qui fut clairement payant, vous le découvrirez dans le chapitre suivant.

Consultez mes classes certifiantes à mon catalogue sur la stratégie Kanban,  je peux aussi enseigner les classes ASPK et APV du catalogue de ProKanban. Contactez-moi pour arranger une classe privée inter-entreprise, ou si vous voulez suivre une classe publique mais n'avez pas les moyens de vous l'offrir.