Archives des Transformation Agile des Organisations - Page 9 sur 9

12 avril 2018

– 4 min de lecture

Organisation Apprenante & Leadership Agile

Ombeline de Lavenère-Lussan

Coach Professionnelle, Team Leader Transformation Agile des Organisations

Cela fonctionne par ce que les membres de l’équipe s’entendent, participent et communiquent entre eux.

Interview Timothée L.

Sérénité, collaboration, fluidité, l’équipe de Timothée L (Manager dans une Grande Banque Française), est beaucoup plus enthousiaste depuis qu’elle a adopté la méthode Agile Scrumban. Comment ont-ils réussi cette transformation Agile ? Quelles ont été les étapes de mise en œuvre et quels en sont les premiers résultats ? Timothée, revient sur la transformation Agile de son équipe, composée de 3 Business Analystes, 4 Développeurs et 1 support.

Comment as-tu connu les méthodes agiles ?

Lors de ma précédente expérience dans une autre banque, j’ai travaillé dans une équipe en mode Scrum.

Qu’est-ce que le lean management t’a apporté ?

Le Lean Management pose un cadre ce qui nous a permis de mettre en place une démarche d’amélioration continue.

La gestion de la capacité nous a permis de mieux gérer les priorités et de nous rendre compte du temps passé sur d’autres tâches que la réalisation de nouvelles fonctionnalités.

Egalement, la mise en place de la matrice de compétence a permis de mieux se rendre compte des compétences présentes dans l’équipe et de celles à développer.

Pourquoi avoir décidé d’évoluer vers l’agile ?

L’amélioration de notre efficacité est une de nos préoccupations principales.

La gestion de la capacité introduite par le Lean Management nous a fait prendre conscience des freins qui nuisaient à notre efficacité.

Nous avions besoin d’un mode de fonctionnement nous permettant de mieux estimer les tâches, de livrer plus fréquemment pour éviter le rush de fin de cycle et de mieux gérer les goulets d’étranglement entre nos différentes étapes de réalisation.

Comment as-tu géré la transformation vers l’agile ?

Après plusieurs ateliers de PSS (Problem Solving Sessions), nous avons choisi la méthode Scrumban (une combinaison des méthodes Scrum et Kanban) qui permet d’avoir le côté visualisation et gestion du flux, mais aussi la limitation du travail en cours de Kanban et le côté itératif de Scrum.

Quel est ton nouveau mode de fonctionnement ?

Notre white board est le cœur de l’information de l’équipe. D’un coup d’œil il est possible de visualiser où nous en sommes.

Ce support de management visuel est composé de 2 parties :

une partie concerne les projets en cours. Ceux-ci sont estimés en taille de T-shirt
(S : réalisable en une semaine, M : réalisable en 1 ou 2 sprints, L et plus : ne rentre pas dans une release, doit être découpé).
L’autre partie permet le suivi du sprint, avec visualisation des tâches et des User Stories par étape.

Quels sont les rôles dans l’équipe ?

La priorisation est faite par le Product Owner (PO)

Pendant les phases de cadrage et d’analyse, le PO découpe les projets en User Stories. Et lors des Kick Off de Sprint, nous estimons les User Stories par priorité et nous les rentrons dans le Sprint.

Le PO, si besoin avec les Business Analyste (BA) ont donc en charge des étapes de cadrage, d’analyse et également des tests fonctionnels.

Les développeurs découpent les User Stories en tâches techniques et les réalisent.

Quels bénéfices en tires-tu ?

Grâce à l’estimation collective de la charge de travail en Story points (évaluation en fonction de l’effort, de la complexité et des incertitudes), les tâches sont mieux estimées. Toutes les personnes de l’équipe réfléchissent à la façon de réaliser les choses, aux éventuelles difficultés et incertitudes

En ajoutant la limitation du travail en cours (WIP) à chaque étape, nous avons également beaucoup fluidifié le flux de nos réalisations. Nous arrivons dorénavant à terminer plus de tâches qu’auparavant. Nous appliquons le mode « Stop starting, Start finishing ».

D’ailleurs, les résultats sont là : notre productivité a augmenté entre 25% et 30%, ce qui nous permet de traiter d’autant plus de sujets par release.

Avec une couverture de tests unitaires de 90% nous sommes beaucoup plus sereins dans nos réalisations, refactorings et changements.

Nous allouons également dans chaque sprint 10% du temps à l’amélioration technique ou à la réduction de la dette technique.

Il s’agit un cercle vertueux : la pression est bien moindre et surtout diluée entre les sprints. Nous sommes sortis du « mode panique ». Cela fonctionne aussi parce que les membres de l’équipe s’entendent, participent et communiquent entre eux.

Quelles sont les prochaines étapes ?

Nous continuons à nous améliorer chaque jour et nous souhaitons aller vers du Continuous Delivery pour améliorer notre rapidité de livraison (Time to Market).

Il est donc nécessaire d’automatiser plus encore les tests fonctionnels, et de mettre en place l’outillage et les environnements qui nous permettront de livrer en production automatiquement à chaque release dans un premier temps, et ensuite après chaque sprint.

Que conseilles-tu aux équipes qui souhaitent commencer à travailler en agile ?

Suivre une formation d’acculturation Agile en amont est important, car cela permet de bien comprendre ce que l’Agile peut apporter, et échanger sur des retours d’expérience.

En outre, il est essentiel de se faire accompagner par un coach quand l’équipe démarre sans réelle expérience en Agile.

Aussi, il faut avoir conscience que passer en Agile ne résout pas tous les problèmes, d’autant plus si le métier ne souhaite pas s’impliquer. En conséquence, il sera difficile de s’assurer de la valeur de ce qu’on produit.

Grâce à son fonctionnement, l’Agile permet de mettre en lumière et de traiter plus rapidement les points épineux.

Enfin, il est nécessaire pour la cohésion, d’impliquer toute l’équipe pour que ça marche, notamment sur le choix de la méthode (scrum, kanban, scrumban, xp…).