En 2010, alors que j’occupais un poste de gestionnaire en TI chez un assureur, on m’a demandé d’améliorer significativement l’efficacité de mes équipes de développement. Ayant accepté le défi, je me suis initiée aux pratiques agiles. Cette organisation effectuait en même temps un virage Lean fortement soutenu par le président de l’entreprise. Revenons en arrière et laissez-moi vous raconter comment les deux approches Lean et Agile peuvent cohabiter et pourquoi, il n’est maintenant plus possible pour moi de les dissocier.

À l’époque j’ai fait appel à Pyxis Technologies pour nous guider dans notre volonté d’améliorer significativement notre processus de développement TI. Nous avons démarré avec une équipe pilote composée presque entièrement de volontaires.

Cette initiative se faisait avec l’appui des gens d’affaire et des TI. Tant le vice-président aux opérations de la ligne d’affaire que le vice-président des TI de l’entreprise étaient impliqués. Il est important que ce genre d’initiative soit soutenue par la haute direction.

L’organisation des équipes

Nous étions alors en mesure de dire à la ligne d’affaires de nous donner le projet de leur choix, nous avions certainement une équipe capable de le mener à bien.

Par contre, avec la capacité d’alors, nous ne ferions pas plus de trois projets en même temps. Une quatrième équipe s’occuperait quant à elle de faire en sorte que les trois autres équipes se concentrent sur leur projet. Cette équipe s’occupait donc de réaliser les améliorations mineures, priorisées mensuellement par un groupe d’utilisateurs représentatif de la ligne d’affaires, et effectuait le soutien de second niveau.

Dans le cadre de la gouvernance qui était en place, tout était géré par deux processus :

  1. Les projets stratégiques
    Il n’y avait pas plus de projets en cours de réalisation que le nombre d’équipes.

  2. Les demandes d’évolution
    Un comité avait été formé, composé de représentants des différents points de vue de l’organisation. Au moyen d’une rencontre d’une heure par mois, ils établissaient l’ordre de priorité des demandes. Cette priorisation était guidée par des critères établis par un consensus basé sur les valeurs de l’organisation. La liste priorisée constituait le backlog d’évolution que l’équipe chargée de l’amélioration réalisait avec une approche Scrumban.

La réalisation des projets était plutôt Agile, mais voyons maintenant ce que l’approche Lean apportait de plus…

Les pratiques agiles (Scrum et Scrumban) sont essentiellement basées sur la valeur d’affaires. Elles consistent à réaliser la plus grande valeur en premier, puis d’ajouter la seconde et ainsi de suite tel que priorisé par le responsable du produit soit le Product Owner.

Le PO essaie quant à lui de prioriser les opportunités d’amélioration des étapes du processus en place. Bien qu’on cherche toujours à remettre en question les besoins, il est probable que les fonctionnalités priorisées concernent des processus et/ou étapes de processus non optimisés ou encore impertinents pour le client au final.

Alors, on aura beau livrer la plus grande valeur d’affaires selon le PO, si on travaille à optimiser une partie de processus qui n’aurait plus lieu d’être si elle était épurée, on travaille un peu dans le beurre. Vous vous dites que c’est évident? Le problème c’est qu’on est rarement conscient que cette portion de processus n’a plus lieu d’être.

Avec l’approche Lean, la valeur d’affaire est prise très au sérieux !

L’approche Lean repose sur 14 principes du modèle Toyota (selon Jeffrey Liker) :

  1. Fondez vos décisions sur une philosophie à long terme, même au détriment des objectifs financiers à court terme.
  2. Organisez les processus en flux pièce à pièce pour mettre au jour les problèmes.
  3. Utilisez des systèmes tirés pour éviter la surproduction.
  4. Lissez la production (heijunka).
  5. Créez une culture de résolution immédiate des problèmes de qualité du premier coup.
  6. La standardisation des tâches est le fondement de l’amélioration continue et de la responsabilisation des employés.
  7. Utilisez le contrôle visuel afin qu’aucun problème ne reste caché.
  8. Utilisez uniquement des technologies fiables, longuement éprouvées, qui servent vos collaborateurs et vos processus.
  9. Formez des responsables qui connaissent parfaitement le travail, vivent la philosophie et l’enseignent aux autres.
  10. Formez des individus et des équipes exceptionnels qui appliquent la philosophie de votre entreprise.
  11. Respectez votre réseau de partenaires et de fournisseurs en les encourageant et en les aidant à progresser.
  12. Allez sur le terrain pour bien comprendre la situation (genchi genbutsu).
  13. Décidez en prenant le temps nécessaire, par consensus, en examinant en détail toutes les options. Appliquez rapidement les décisions.
  14. Devenez une entreprise apprenante grâce à la réflexion systématique (hansei) et à l’amélioration continue (kaizen).

Voici sommairement comment ces principes étaient appliqués concrètement :

D’abord, chaque ligne d’affaires faisait l’analyse de sa chaîne de valeurs (VSM, Value Stream Mapping) en s’assurant d’avoir toutes les parties prenantes autour de la table. Les gens désignés étaient isolés en groupe pour l’exercice qui pouvait durer d’une à deux semaines.

Ensuite, grâce à l’information recueillie durant l’exercice précédent, les gens d’affaires sélectionnaient la partie de processus la plus significative dans la chaîne de valeur et se donnaient un objectif ambitieux pour l’améliorer. Par exemple, qu’une transaction soit traitée en l’espace de trois jours dans 80% des cas (selon le VSM, cela prenait en moyenne plus de 15 jours). On produisait alors un Lean canvas simple et dûment réfléchi qui devenait le premier mandat à réaliser.

Kaizen

Une équipe était formée pour réaliser ce Kaizen d’une durée d’une à deux semaines. Cette fois encore, des gens de tous les points de vue étaient mis à profit et réunis sur un même site. Pour réaliser leur mandat, les membres de l’équipe formée devaient premièrement se donner une compréhension commune du processus en place en le rendant visible sur un mur.

Lors de cet exercice, on prend soin de rendre visibles les étapes qui constituent de la valeur ajoutée pour le client, de même que les différents gaspillages, tels que les délais d’attente, les passages de mains, etc. Ensuite, l’équipe part d’un mur vide et crée un nouveau processus qui, en s’inspirant des 14 principes énumérés plus haut, répondra aux besoins du client pour obtenir les bénéfices recherchés. L’écart entre l’ancien et le nouveau processus se traduit par une liste d’activités et de livrables à produire. Imaginez que cette liste de projets/activités est très différente de la liste des besoins du processus original.

Pour réaliser ces livrables, une équipe d’utilisateurs et de TI était formée afin de réaliser la mission (le projet) découlant du Kaizen. Les backlogs étaient donc alimentés de besoins dûment définis afin de répondre aux nécessités d’un processus nettoyé. Ainsi, on ne faisait que des projets vraiment payants. Et la contribution des utilisateurs finaux au projet était implicite. Il arrivait même que les clients finaux (les payeurs) participent à ces travaux par des présences ciblées dans les démonstrations afin de récolter leur feedback le plus tôt possible dans le processus.

Toutes les équipes de TI travaillaient ensemble avec les clients internes (qu’on appelaient partenaires) le plus tôt possible dans le processus. Ainsi, elles visaient à produire une architecture, une infrastructure et des applications émergentes adaptées au besoin du « juste assez » pour atteindre les objectifs du Kaizen. Une fois ce processus ou cette portion de processus clairement amélioré, l’organisation priorisait le prochain item de sa chaîne de valeur.

Conclusion

Cela semble facile vous pensez, pas du tout ! Et est-ce vraiment possible ? Oui, en se donnant un objectif clair et en mettant l’égo de chacun de côté, au bénéfice de cet objectif inspirant pour tous qui permet de garder le client au centre des préoccupations de tous.

Billet précédent

Pourquoi les leaders ont besoin de devenir plus co-créatifs

Billet suivant

Bracket Show - Episode 5

Nathalie Desautels

Nathalie compte 26 années d'expérience en développement informatique, dont 15 en gestion d'équipes et 4 avec les approches Agiles et Lean. Passionnée par le dépassement de soi, elle s'est jointe à Pyxis pour y vivre intensément l'Agilité, avoir l'occasion d'apprendre, mettre son expérience au service des clients et continuer de développer l'offre de service de Pyxis. Elle est séduite par le mode de fonctionnement de Pyxis, car on y fait vraiment ce qu'on enseigne, et plus...

2 Commentaires

  1. marc.st-cyr@revenuquebec.ca'
    Marc St-Cyr PMI-ACP PMP
    10/06/2017 at 12:49 — Répondre

    Article extrêmement intéressant et qui devrait être source d’inspiration pour une multitude d’organisations qu’elles soient du domaine public, parapublique ou privé!
    Bravo!
    Marc St-Cyr PMI-ACP, PMP

    • Nathalie.desautels@pyxis-tech.com'
      Nathalie Desautels
      12/06/2017 at 09:04 — Répondre

      Merci !
      Souhaitons le :-)

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *