Voir, Comprendre, Agir

Délivrer de la valeur au client, dans les délais et en respectant la qualité requise est l’enjeu premier d’une équipe IT, et de toute équipe quel que soit son domaine d’activité.

Dans cet article, je vais vous parler d’une équipe IT (PO et développeurs) que j’ai accompagnée et qui avait justement des difficultés : elle avait très peu délivré sur ses derniers sprints et connaissait des problèmes de qualité.

Le « Voir »

J’ai commencé par effectuer des Gembas et assister aux différentes instances dont le daily meeting.  Le daily était en fait seulement un tour de table où chacun parlait de ce qu’il était en train de faire, puis une fois le tour de table terminé, chacun repartait vers ses occupations.  

Quand je pose les questions suivantes à l’équipe : « Qu’est-ce que le client attend ? Que devez-vous réussir à la fin du sprint ? Qu’est-ce qui a été fait et qu’est-ce qui reste à faire ?  D’ailleurs je ne vois pas votre sprint, comment savez-vous si vous êtes proche ou loin de l’objectif ? »

On me répond :

« En effet, je ne sais pas ce que les dev font ».

« Tout est sur Jira, y’a qu’aller voir les tickets de chacun ».

« En tant que développeur, a-t-on vraiment besoin de savoir ce que les autres font ? »

« Moi, je traite les tickets qu’on m’affecte ».

« Je ne sais pas ce que le client attend, ni l’objectif du sprint, je ne suis pas PO ».

« On n’arrête pas de rajouter des tickets pendant le sprint, cela désorganise tout, je n’arrive plus à suivre ».

A la fin de mon premier sprint d’observation, il était évident que l’ensemble des parties prenantes n’étaient pas d’accord sur le contenu du sprint. Sur les 45 tickets « supposés » du sprint, près d’une quinzaine ont été intégrés en « catimini » :  pourquoi ces tickets avaient-ils été ajoutés ? sur quels critères ? étaient-ils vraiment prioritaires ? la réponse était « non ». A la fin de ce sprint, personne n’était capable de dire ce qui avait été fait, ce qui restait à faire et quel était l’état d’avancement exactement. Pourtant, chacun avait l’impression d’avoir tout donné.

C’est justement toute l’importance et l’utilité du management visuel : le VOIR.  Voir la même chose que les autres, la voir en temps réel, la voir en toute transparence, voir ce qui a de la valeur, qui permet de piloter le delivery et de prendre les bonnes décisions.

En construisant et mettant en place le management visuel du sprint avec l’équipe développeurs et product owners, et en l’organisant en flux tiré (flux tiré que je vous expliquerai dans un prochain article), la communication est devenue claire, transparente et factuelle. Toute l’équipe était tournée vers l’objectif à atteindre, chacun responsabilisé. Les tensions se sont d’un coup apaisées.

Le management visuel comprenait donc :

• L’objectif du sprint : attendu client + dates de livraison prévues (préprod et prod)
• L’ensemble des tickets planifiés pour le sprint
• Le bac rouge comprenant tous les tickets qui régressent ou restent bloqués au lieu d’avancer dans le process.
• Les tickets urgents non planifiés qui rentrent en cours du sprint sont tagués afin de mieux les quantifier à la fin du sprint.

Le « Comprendre »

Une fois que l’on voit un sprint organisé en flux tiré, que l’on voit ce que l’on doit délivrer à la fin du sprint, nous allons, grâce au management visuel, voir évoluer le sprint, et comprendre son déroulement :

D’abord il y a des hotfix qui apparaissent pendant le sprint et qu’il faut traiter en urgence : « C’est suite à la dernière mise en production, ça a créé des problèmes côté facturation.» « Oui mais il y a eu des tests avant la MEP ? » « Euh j’en suis pas sûr… ».

Il y a aussi des tickets qui restent bloqués en phase de développement parce qu’il manque des données nécessaires au développeur : « J’attends le retour du PO »

Il y a également des tickets qui, arrivant en phase de recette ou préprod, reviennent à la case développement parce qu’ils ne répondaient pas au besoin fonctionnel attendu : « Oui mais le besoin fonctionnel n’était pas clairement défini dans le ticket ».

Il y a Kevin qui est parti en vacances, sans laisser de consigne sur ses tickets en cours « Je ne sais pas s’il a terminé son dev ».

On a David qui traite à lui seul plus d’un tiers des tickets du sprint : « C’est l’expert de cette application, le seul d’ailleurs et de fait, il est tout le temps surchargé. C’est vrai qu’on a problème de formation et de montée en compétence ».

On a eu aussi un goulet d’étranglement au niveau des tests : « On n’a pas assez de testeurs en recette, et les métiers sont indisponibles pour valider les tests en pré-prod, qu’est-ce qu’on fait ? ».

Autant de « problèmes » qui impactent le sprint, et l’atteinte de son objectif.

Pendant ce temps, le client attend toujours le delivery à la fin du sprint…

A l’issue de mon second sprint avec l’équipe, grâce au management visuel, l’équipe a pu identifier et quantifier chacun de ces « problèmes », voir concrètement son impact sur le sprint. C’est la première étape de la résolution de problème : voir et comprendre le problème.

L’« Agir »

Évidemment nous ne pouvons pas tout révolutionner en un sprint.

L’équipe et les managers ont pris conscience que les difficultés rencontrées durant le sprint sont les conséquences des problèmes que l’entreprise vit de façon plus large : des problèmes d’anticipation, des problèmes de compréhension et de traduction du besoin client, des problèmes d’organisation, des problèmes de formation et de compétence, des problèmes de process et de clarification du qui fait quoi, des problèmes de tests,..

Notre objectif avec l’équipe et avec l’appui des managers, était de définir des petits pas d’amélioration (kaizen). Certes, petits mais des pas qui apportent de la valeur ajoutée.

Nous avons alors procédé de manière itérative : à chaque sprint nous déployons une amélioration tout en consolidant les améliorations précédentes déjà mises en œuvre. A la fin de chaque sprint, on évalue l’efficacité de l’action déployée.

Nous avons ainsi travaillé, product owners et développeurs, main dans la main, sur plusieurs thématiques et notamment à :

• Fiabiliser les flux entrants par la mise en place de standards tels que « l’expression du besoin clients », « la matrice des interdépendances » et « le ready to dev ».

• Réduire le flux des incidents entrants par l’analyse systématique de tous les incidents entrants et du bac rouge. Analyse animée lors des Kaizen (il s’agit d’un créneau hebdomadaire dédié à l’amélioration continue regroupant l’équipe), avec actions visant à réduire l’occurrence et la gravité des incidents.

• Améliorer la qualité avant la vitesse par la définition d’un process de delivery avec une stratégie de tests claire et toujours un message clé : la qualité d’abord et avant tout, la qualité avant la vitesse, la qualité est la responsabilité de tous.

• Et améliorer la qualité avant la productivité : l’amélioration de la qualité ne se fait pas au détriment de la productivité mais au contraire elle la nourrit, ce qui peut sembler contre-intuitif.

En l’espace de 4 sprints, l’équipe a réduit de 30 % son flux entrant d’incidents et a multiplié par 3 le volume des tickets livrés. L’équipe POs et développeurs était fière de ce qu’elle a accompli. Ils ont encore beaucoup d’idées et de propositions d’amélioration. Ils se sont réapproprié leurs missions et travaillent collectivement dans le but de satisfaire leurs clients en livrant le besoin client dans les délais, avec la meilleure qualité et dans le respect des coûts.

Le travail d’amélioration et de consolidation se poursuit, parce que les possibilités d’amélioration sont infinies, mais aussi parce qu’il faut toujours de la rigueur et de la pratique au quotidien. La résolution de problème et l’amélioration continue sont un apprentissage, un apprentissage au quotidien, et à tous les niveaux (direction, manager, équipes) qui au fur et à mesure sont devenus, pour cette équipe, un état d’esprit individuel et collectif, une culture d’entreprise.

Si vous aussi vous souhaitez aider vos équipes à réussir leurs sprints et livrer une qualité irréprochable, contactez-nous : contact at operaepartners point com