Articles

Une journée pour lancer la mise en place de Kanban

Kanban s’impose toujours plus pour la gestion des flux de travail ! C’est pourquoi nous voyons toujours de nombreuses entreprises mettre en place cette méthode. Par expérience, je partage avec vous un exemple d’animation possible pour introduire et initialiser la transition en Kanban dans une équipe… en une journée d’ateliers !

Si vous ne connaissez pas encore Kanban, je vous conseille de regarder la conférence « Kanban pour l’IT » de Laurent Morisseau[1].

 

Icebreaker

Tout d’abord, j’aime bien démarrer ce genre de journée par un icebreaker / energizer.

Celui que j’apprécie particulièrement pour les équipes qui découvrent Kanban est le jeu du prénom. En plus de mettre les personnes en mouvement et en action, il commence à introduire les problématiques du multitasking et les bénéfices de la limite de l’en-cours.

Si vous souhaitez expérimenter ce jeu, les explications d’Henrik Kniberg sont très claires et très complètes pour se lancer.

 

Présentation du Lean, de l’origine de Kanban et de ses objectifs

Ensuite je présente rapidement l’histoire de Kanban, ses origines, les principes du Lean, avant d’en venir aux objectifs principaux de Kanban, énumérés dans le visuel ci-dessous.

Kanban1

 

A ce moment-là, nous prenons un moment avec l’équipe pour qu’ils définissent les objectifs qu’ils cherchent à atteindre en mettant Kanban en place. Nous veillons à ce que ces objectifs soient SMART (spécifiques, mesurables, atteignables, réalistes (ou pertinents), inscrits dans le temps). Ces objectifs donnent du sens à la mise en place de Kanban et nous permettront dans quelques mois d’en évaluer les bienfaits et définir des améliorations à effectuer.

 

Découverte des principes et des pratiques Kanban au travers d’une simulation

Plutôt que de présenter les principes et pratiques Kanban de manière théorique, je préfère l’aborder au travers d’un jeu de simulation. Celui que je fais jouer souvent pour ces journées de présentation et de mise en place est le Kanban Pizza Game.

En effet, il permet en deux heures de découvrir et d’expérimenter plusieurs des pratiques Kanban, telles que la visualisation du flux de travail, les limites de l’encours, l’amélioration continue, l’utilisation des boucles de feedback…

Vous pouvez trouver les explications du jeu en français ou anglais.

 

Revue des principes Kanban

Kanban2

C’est l’étape où je revois avec l’équipe que j’accompagne les principes de Kanban. C’est l’opportunité pour moi d’expliquer que nous n’allons pas révolutionner leur manière de fonctionner d’aujourd’hui : les rôles, les responsabilités et les processus actuels seront conservés. Mais qu’en revanche il est de leur responsabilité de s’approprier le Kanban qui sera mis en place afin de l’améliorer.

 

Revue des différentes pratiques de Kanban et proposition de mise en place pour l’équipe

Une fois que les pratiques ont été découvertes au travers du jeu, nous les parcourons une à une afin de voir comment elles peuvent se transposer dans leur domaine. Pour chacune d’entre elles, une fois que la présentation est faite, j’accompagne l’équipe à réfléchir à la mise de la pratique qu’ils pourraient en faire dans leur contexte.

 

Kanban3

A. Visualiser le flux

Je commence par demander à l’équipe pour qui ils travaillent (quels sont leurs clients ou utilisateurs) et quel est le service qu’ils leur apportent. Il est important de connaitre les clients qui sont à l’origine des demandes. Ainsi l’équipe identifie comment les demandes entrent dans le système. L’idéal est d’impliquer ces personnes dans cette mise en place de Kanban.

Ensuite, je leur demande de m’expliquer leur flux pour les différents types de demandes qu’ils ont à traiter. En Kanban, nous essayons autant que possible d’avoir une vision globale du flux de valeur. Pas à pas, nous construisons le flux au tableau, jusqu’à la livraison de valeur. Une fois que cela est fait, nous regardons les colonnes qui pourraient avoir du sens dans leur tableau Kanban.

Ici le but n’est pas de définir un flux qui va correspondre à 100% des demandes de l’équipes, mais à la majorité des demandes.

 

B. Rendre les règles de gestions explicite.

Une fois les colonnes du tableau Kanban définies, je demande à l’équipe de m’expliquer qui travaille sur chaque colonne, et quelles sont les conditions de passage à la colonne suivante. Je continue de prendre des notes sur le tableau.

 

C. Limiter le travail en cours

Je propose ensuite à l’équipe de définir quelques limites dans leur tableau, sans la pousser à définir des limites trop contraignantes. Il s’agit ici d’un démarrage de Kanban. Ils affineront leurs limites avec l’expérimentation. Je profite de ce moment-là pour reparler de la notion de flux tiré et de flux poussé. Je leur propose alors d’avoir deux sous-colonne « En cours » et « Fini » dans chacune de leurs colonnes. Enfin, nous abordons le sujet des urgences, et ils définissent comment les adresser dans un premier temps.

Si l’intérêt des limites a du mal à être compris par l’équipe, même après le Kanban Pizza Game, certains jeux permettent de mieux appréhender leur intérêt, tels que l’Aeroplane Game.

 

D. Gérer le flux

Pour la gestion du flux, nous abordons la possibilité de mettre en place une réunion quotidienne. Je leur présente les bonnes pratiques pour ce daily Kanban et leur demande s’ils souhaitent le mettre en place dans leur contexte, et si oui, ils définissent ensemble l’horaire de ce point de synchronisation.

 

E. Implémenter des boucles de feedback

A ce moment-là, nous voyons ensemble sur quoi ils souhaitent mettre en place des boucles de feedback :

  • Sur leur produit : souhaitent-ils organiser des démonstrations des fonctionnalités mises en place ? Si oui, à qui ? A quelle fréquence ?
  • Sur la planification de leur travail : à quelle fréquence et comment souhaitent-ils gérer l’approvisionnement et la priorisation des demandes ? Il est possible de définir des cadences fixes (exemple : on réapprovisionne toutes les deux semaines) ou à l’évènement (exemple : on réapprovisionne quand il nous reste moins de X demandes dans notre backlog). Les techniques d’approvisionnement et de priorisation seront abordées plus en détail ultérieurement avec le ou les personnes en charge de cela.
  • Sur leur performance : je leur présente ici les différentes métriques fréquemment utilisées en Kanban et leur utilité. Généralement dans un premier temps, s’ils utilisent un tableau physique et non digital, je leur propose de noter les dates d’entrée et de sortie du système Kanban, ainsi que de compter quotidiennement le nombre de tickets dans chaque colonne. Je leur explique qu’il va falloir du temps et du volume de données pour pouvoir exploiter ces données. Je leur demande donc juste de noter ces informations et leur propose de planifier un point ensemble quelques semaines plus tard pour voir comment ils pourront les exploiter.

 

F. S’améliorer de manière collaborative et évoluer de manière expérimentale

Je leur parle ici des rétrospectives. Autant sur les autres parties de la mise en place de Kanban j’essaie d’accompagner sans pousser à la prise de décision, autant sur cette partie je me permets d’insister pour la planification d’une première rétrospective. Je leur conseille également de définir une récurrence pour les premières rétrospectives. En effet, pour des équipes débutant en Kanban ou en Agile, le réflexe ou le besoin de faire des rétrospectives n’est pas naturel. Je me permets donc d’impulser la dynamique !

Nous pouvons également aborder les autres pratiques qui sont fréquemment utilisées en Kanban :

  • Les classes de services : nous reprenons ici les différents types de demandes qu’ils traitent pour voir s’ils veulent en faire des classes de services
  • Les couloirs : je leur présente ensuite l’utilisation qu’il est possible de faire des couloirs et ils définissent ensemble si cela fait sens pour eux

 

En fin de journée, ils ont donc une idée de ce qu’est Kanban, de ce que cela peut leur apporter, et ils ont initié leur premier Kanban. Généralement, à la fin de la journée, toute l’équipe s’active pour créer le Kanban board sur la base de ce qui a été décidé dans la journée ! Il faut bien insister sur le fait qu’il s’agit d’un point de départ, que c’est leur Kanban et qu’il leur appartient de se l’approprier et de le faire évoluer afin d’en retirer un maximum de bénéfice.

Bien entendu, l’accompagnement par le coach ne s’arrête pas là : nous demandons aux équipes ce qu’elles attendent du coach. De plus, nous leurs proposons de faire des points réguliers ensemble, du support pour les premiers daily meetings, les premières rétrospectives pour la priorisation et la planification du travail et des livraisons, pour exploiter leurs métriques…

 

Deux points de vigilance à garder à l’esprit pour cette journée :

  • Le coach doit veiller à laisser l’équipe concevoir son propre Kanban. Si l’équipe ne le l’approprie pas, il y a de fortes chances qu’elle ne porte pas l’amélioration continue. Le coach sera donc là pour faciliter, accompagner, éventuellement conseiller et lever des points de vigilance s’il en identifie.
  • Si l’équipe n’est pas familière avec l’agilité ou l’amélioration continue, il me semble important que le coach les accompagne quelques temps pour insuffler cet état d’esprit. Il en est de même pour questionner les pratiques et les améliorations possibles. Sans accompagnement, il y a de fortes chances que le Kanban de l’équipe n’évolue pas, et qu’elle se retrouve quelques mois plus tard avec exactement les mêmes problématiques qu’avant le passage en Kanban !

 

 

Les images de cet article sont issues de fiches Kanban que nous avons créées et que nous distribuons à l’issue de nos formations et sensibilisations Kanban.

Vous pouvez télécharger la version française ou la version anglaise.

 

Pour aller plus loin avec Kanban, retrouvez notre article « Kanban, l’art japonais de l’efficacité pour une TMA agile ».

 

 

 

[1] https://www.infoq.com/fr/presentations/kanban-pour-it/

 

Agile à l’échelle ? Jamais sans les métiers !

Le double impératif d’accélérer la livraison de la valeur à sa clientèle et de le faire avec des moyens constants, voire revus à la baisse, a poussé de nombreuses entreprises à lancer des programmes de transformation digitale. Les conséquences de la crise sanitaire actuelle n’ont fait qu’amplifier l’importance d’une optimisation concurrente du time-to-market et des coûts de réalisation. L’agilité et plus particulièrement sa déclinaison agile@scale sont souvent choisies, à juste titre, comme un vecteur de cette transformation devenue indispensable. La totalité des bienfaits promis par l’agilité à l’échelle ne pourra pourtant pas être constatée sans un embarquement efficace des métiers dans le dispositif dès le début, dans une logique partenariale, afin que tous avancent dans le même sens.

 

On ne peut faire l’économie d’une implication forte des métiers

L’embarquement des métiers dans un programme d’agilité à l’échelle est nécessaire pour sa bonne conduite. Ils sont une ressource précieuse pour structurer le besoin et ajuster les livrables pour atteindre la valeur recherchée tout en évitant les latences coûteuses. Pourtant, ce n’est pas chose simple. Dans beaucoup de cas, ils restent des donneurs d’ordre lointains.

Bien souvent, l’agilité à l’échelle est d’abord ciblée par les directions informatiques comme moyen de répondre à leurs enjeux de transformation. Pour peu qu’il s’agisse d’une entreprise où les directions métier ont pour habitude de considérer l’informatique comme un prestaire interne plutôt que comme un partenaire de création de valeur, il peut s’avérer compliqué de leur demander d’adopter cette approche qui nécessite non seulement un changement de leurs habitudes de travail, mais aussi une implication tout au long du processus.

Si les directions métier ne sont pas convaincues des avantages que ce changement leur apportera, elles maintiendront naturellement le statu quo et ne laisseront aux équipes informatiques d’autre pis- aller que de nommer en leur sein des délégués pour représenter les enjeux métier. Ces représentants ne sont pas pour autant pourvus d’un vrai pouvoir décisionnel ou du recul nécessaire pour prioriser efficacement. Ceci nécessitera forcément des allers-retours supplémentaires avec le métier et introduira ainsi des rigidités et des latences qui vont à l’encontre de l’efficience structurelle d’une approche agile à l’échelle qui, fortement inspirée par la pensée Lean, a été conçue pour supprimer ces gaspillages et optimiser la création de valeur. Ainsi, l’entreprise perdra-t-elle d’avance une partie des avantages recherchés par cette approche.

Tel a été le cas lors de la transformation d’un programme au sein d’une grande maison de luxe : la direction du programme n’estimait pas pouvoir embarquer directement les métiers dans les instances agile à l’échelle (planification, revue de la solution, etc). Les enjeux métier ont dû être portés par l’équipe produit (principalement des product owners) dont les membres, dépourvus de mandat décisionnel, devaient faire des allers-retours supplémentaires et planifier des instances parallèles, réduisant ainsi leur rapidité d’action, l’immédiateté des retours et l’efficacité de l’ensemble.

 

Identifiez des ambassadeurs

Afin de convaincre les métiers d’embarquer, et ce dans leur globalité, créez une logique d’ambassadeurs. Identifiez parmi les directions métier les plus curieux et prêts à s’investir dans cette logique.

Faites ensuite participer ces early adopters à un cadrage agile. Ce type d’atelier de travail collaboratif de plusieurs jours, mélangeant représentants métier et équipes de développement, permettra de leur faire expérimenter l’efficacité interactive de l’agilité tout en structurant leurs besoins d’une façon parfaitement adaptée pour enchaîner sur une réalisation au sein du programme agile à l’échelle. Encouragés par cette première expérience positive, ils seront enclins à rester engagés par la suite et seront à même d’en vanter les bienfaits et les retombées positives à l’ensemble des collaborateurs. La tradition orale est encore puissante, et cette logique de storytelling vous permettra de convaincre progressivement le reste des équipes métiers.

Dans une grande banque française dont la transformation était tirée par la direction informatique, cette approche a permis d’embarquer la direction métier du risque de crédit qui, après avoir participé à un atelier de cadrage agile aux côtés des acteurs informatiques, a été séduit par l’efficacité de la démarche, a demandé à l’appliquer à d’autres initiatives, et en a fait la promotion auprès de ses confrères.

 

Une implication nécessaire de la Direction

Cette logique centrale d’ambassadeurs permettant de favoriser l’embarquement initial des métiers, il faudra en parallèle favoriser la pérennité de cette implication en se dotant d’une sponsorisation au niveau des directions.

Ces dernières, métier comme informatique, doivent généralement rendre des comptes sur leur capacité à répondre aux enjeux stratégiques de l’entreprise tout en faisant preuve d’une grande efficacité financière. Pour les embarquer, il faudra donc pouvoir leur tenir un discours mariant KPI business (coût de réalisation d’une initiative, adéquation de la solution avec le besoin, qualité et maintenabilité de la solution) et conduite de changement (nombre de personnes accompagnées, niveau de maturité agile), et leur exposer ainsi clairement la différence de retombées entre une approche classique et une approche agile. Ici encore, le cadrage agile peut s’avérer un premier élément fédérateur : une analyse quantitative comparative entre un cadrage classique et un cadrage agile fera clairement ressortir les avantages de ce dernier, que ce soit en termes de coût, de délai ou de satisfaction. Par la suite, le même type d’analyse, étendu à l’échelle du programme agile à l’échelle, achèvera de convaincre.

Une fois cet objectif de conviction atteint, chaque direction métier prendra plus facilement les mesures nécessaires pour garantir une disponibilité continue de ses équipes opérationnelles pour participer pleinement au programme agile à l’échelle, et deviendra, à l’instar des ambassadeurs issus de ses équipes, votre porte-parole et sponsor auprès de ses homologues au sein d’autres métiers afin que tout le monde avance dans le même sens en même temps.

Un Agile Health Check pour accompagner l’amélioration continue

En tant que coachs, mes collègues et moi-même voulions proposer aux équipes que nous accompagnons un outil afin qu’elles puissent se challenger sur leurs pratiques agiles, mais aussi trouver par elles-mêmes des axes d’amélioration. Après quelques réflexions et un travail collaboratif, nous en sommes arrivés à construire un set de cartes « Agile Health Check ». On vous explique tout !

 

Pourquoi cet Agile Health Check ?

De nombreuses équipes que nous accompagnons appliquent des frameworks agiles (avec rituels, artefacts et rôles) sans pour autant avoir compris ou encore acquis le « mindset » agile. Nous voulions donc leur proposer un moyen de prendre de la hauteur par rapport à ces frameworks et de s’interroger sur plusieurs principes agiles, ainsi que sur les bénéfices qu’ils peuvent en retirer.

En créant ces cartes, nous voulions :

  • Revenir aux valeurs de base de l’agilité et aux bénéfices que l’on cherche à en tirer
  • Amener les équipes à prendre du recul sur leurs pratiques agiles
  • Permettre aux équipes de se questionner et de trouver par elles-mêmes des axes d’amélioration

Ce que nous ne voulions pas :

  • Que ces cartes deviennent un moyen d’évaluer les équipes, voire de les comparer. Nous avons volontairement choisi de ne pas avoir de système de notation et avons préféré une échelle de satisfaction de l’équipe sur la base de smileys. Nous sommes cependant conscients que l’usage de ces cartes dépendra de la volonté des personnes qui les utiliseront…

Agile health check

  • Interroger les équipes uniquement sur les frameworks agiles. Ces derniers peuvent être utilisés à tort comme des boites à outils pour faire la même chose qu’avant sous une forme différente (nouveaux rôles, nouveaux rituels mais sans pour autant adopter l’auto-organisation, la collaboration, l’acceptation du changement, …). Nous voulions donc nous affranchir des frameworks pour adresser l’état d’esprit.

Comment sont structurées les cartes ?

Inspirées de Heart Of Agile qui revient aux bases de l’agilité, nos 12 cartes sont structurées en 4 thématiques :

  • Collaboration
  • Livraison
  • Inspection et amélioration
  • Moral de l’équipe

Sur chaque carte, le recto présente une question générale sur un principe de l’agilité, et le verso propose des questions pour aller plus loin sur cette thématique. Nous proposons 4 niveaux d’évaluation de la satisfaction de l’équipe (pas de note). L’équipe peut ainsi s’évaluer sur chaque sujet présent sur les cartes puis discuter de l’évaluation et surtout chercher des axes d’amélioration.

Voici un exemple de carte :

Agile health check 1

Vous pouvez télécharger les cartes en français et en anglais.

Bien sûr, ces cartes évolueront sûrement dans le temps, au gré des retours et des expériences que nous aurons eus.

 

 

[SUCCESS STORY] GRAVOTECH : UN SITE POUR UNIFIER SES MARQUES

Gravotech est un leader international en solutions de gravure et de marquage permanent, du graveur laser pour l’identification de pièces aéronautiques aux machines à graver mécaniques pour la personnalisation de bijoux.

SQLI a assuré la refonte des 74 sites de Gravotech en une vitrine digitale unique de ses offres.

Le site représente la principale source de développement business de l’entreprise.85% du chiffre d’affaires est réalisé à l’export, il est nécessaire pour Gravotech d’entretenir une proximité locale, en couvrant les 22 langues parlées par leurs clients au travers des 77 pays d’implantation.

Téléchargez notre success story Gravotech

Where to play - Innover en 3 étapes pour saisir des opportunités en contexte d’incertitude

Dans le contexte d’incertitude que nous vivons, il est primordial pour tout entrepreneur, chef d’entreprise ou responsable innovation, d’identifier toutes les possibilités d’évolution du marché et d’évaluer les opportunités qui en découlent, pour pouvoir se projeter sereinement et construire une stratégie de développement qui saura s’adapter au changement.

 Être sûr de courir dans la bonne direction et rester agile, sans vous disperser ! 

Voilà l’ambition de cette méthodologie imaginée et outillée par Marc Gruber (Chercheur et vice-président pour l’Innovation à l’École Polytechnique Fédérale de Lausanne EFPL) et Sharon Tal (Conférencière et ancienne administratrice du Centre pour l’entreprenariat Technion à l’institut de technologie d’Israël) qui se sont nourris de 15 ans de recherche et d’accompagnement à la création d’entreprise (plus d’une centaine de cas d’entreprise étudiés et analysés)[1].

Cette méthodologie est recommandée par Alex Osterwalder et Yves Pigneur (les auteurs du Business Model Canvas) qui en font un complément parfait à l’approche Lean startup et aux outils de Business Model Canvas pour définir votre terrain de jeu.

Elle repose sur 3 étapes pour vous accompagner pas-à-pas dans la réflexion en associant à chacune d’entre elles des outils d’aide à la décision pour :

  1. Explorer les opportunités afin de bien connaître son terrain de jeu
  2. Évaluer les options en les comparant pour identifier les plus attractives
  3. Définir une stratégie agile en se concentrant sur une option mais en conservant des alternatives pour rebondir

 

Ces 3 étapes vous permettront de prendre une décision éclairée, d’établir un langage commun et de vous accompagner dans le temps. 

 

1. Identifier de nouvelles opportunités

L’objectif de cette 1ère étape est de faire le point sur les capacités ou les technologies essentielles propres à votre organisation afin d’identifier des opportunités de marché. Pour vous aider, la méthodologie propose d’utiliser le modèle « Generate your market opportunity set ».

  • La première étape consiste à identifier votre savoir-faire métiers et technologiques, au travers des ressources et compétences dont vous disposez actuellement ou en cours de développement. Envisagez-les en tant que telles, décolérés de leur contexte d’usage (produit, besoin client…) pour les décrire de manière générique en termes de propriétés et de fonctionnalités dans la partie « Abilities».
  • La liste de vos capacités et éléments technologiques étant établis, vous pouvez passer à l’étape de découverte en recherchant des applications potentielles. L’idée ici est de rechercher au-delà de son marché de prédilection, pour générer une grande diversité d’applications et libérer votre créativité. N’hésitez pas à combiner votre technologie avec d’autres types de technologies pour enrichir votre panel d’applications. Exploitez toutes vos connaissances et vos expériences, appuyez-vous sur des sources externes, plateformes en lignes, bases de brevets…
  • En parallèle de cette phase de découverte, pour chaque application, il faut identifier les profils de clients potentiels. Segmentez-les pour identifier des sous-segments qui vous permettront d’être plus pertinent dans votre analyse.
  • Pour finir, combinez application et profil client pour obtenir vos opportunités de marché que vous estimez prometteuses pour remplir votre panier d’opportunités afin de passer à l’étape suivante d’évaluation.

Cette phase de découverte peut s’avérer être assez longue, ce qui est normal, même préférable, car cela témoignera d’un travail sérieux et se traduira par un nombre important d’opportunités qu’il faudra trier pour mettre de côté celles qui ne sont pas assez prometteuses : pas de besoin client existant, manque de compétences, contraintes techniques trop fortes, ne correspond pas à vos valeurs

 

2. Évaluer vos opportunités

Une fois votre panier bien garni avec les opportunités les plus prometteuses, faut-il encore savoir lesquelles privilégier ! Toutes ne se valent pas, il faut pouvoir les comparer pour se concentrer sur les plus attractives et qui ont le plus de chance d’aboutir.

La méthodologie repose sur 2 dimensions : le potentiel qu’elle représente et le défi de mise en œuvre. Cela vous donne une matrice qui permet des comparer les opportunités entre elles.

Avant d’arriver à la matrice, il faudra évaluer chaque opportunité en se posant les bonnes questions, en cherchant à valider les hypothèses pour les transformer en connaissances et ainsi les analyser pour en déduire des enseignements précieux pour prendre une décision. C’est le moment clé pour mieux connaître vos clients, votre environnement, la chaîne de valeur du marché ainsi que vos capacités internes.

C’est aussi le moment mettre en place des ateliers de travail regroupant votre équipe, pour évaluer ensemble chacune des opportunités à travers le prisme de 2 dimensions constituées de 3 paramètres :

  • Le potentiel
    • Une raison convaincante d’acheter : quelqu’un voudra-t-il de notre produit/service et sera-t-il prêt à payer ? Existe-il un réel besoin insatisfait ? Pouvons-nous y répondre, et si oui mieux que les autres ?
    • Le volume de marché: quelle est la taille du marché aujourd’hui, combien de clients potentiels, quelle consommation cela représente sur une année ? Quelles sont les perspectives de croissance, quelle est sa maturité ? Le marché s’est-il développé au cours des 2 dernières années ?
    • La viabilité économique : la rapport investissement-revenu est-il intéressant d’un point de vue économique ? Les clients ciblés ont-ils les moyens ? Seront-ils fidèles ?

Lorsque vous aurez répondu à toutes ces questions, vous pourrez alors donner une note d’appréciation d’abord à chaque paramètre allant de faible, moyen à élevé et très élevé. Pour ensuite donner une note globale qui peut tenir compte de pondération lorsqu’un paramètre doit être plus fort qu’un autre (à vous de décider suivant le contexte). Une note volontairement non-numérique pour prendre en compte toutes les subtilités de l’évaluation.

  • Le défi
    • Obstacles au déploiement: quelles difficultés vous rencontrez pour développer votre produit/service (technologiques, UX/UI, réglementaires…), pour accéder au marché (canal de distribution existant ou à construire) ou pour trouver des financements (capital d’amorçage) ?
    • Délai de retour sur investissement: Combien de temps de développement avant de mettre en production ? Le marché est prêt ? Quelle est la durée du cycle commercial, quelle est le processus d’achat (B2B) ?
    • Risques externes : quel est le poids de la concurrence, quelles menaces fait-elle peser sur vous ? Êtes-vous dépendant de tiers ou de réglementations ? Votre produit/service est compatible avec les pratiques existantes ?

De la même manière que pour la dimension potentiel, on notera chaque paramètre avant de donner une note globale.

Après avoir noté chacune des opportunités, il est important de revoir l’ensemble pour ajuster si besoin les notes afin d’être homogène dans l’évaluation et de passer à l’étape suivante : la matrice d’attractivité.

 

Pour compléter cette matrice, il suffit de prendre chaque opportunité et de la placer en fonction des notes qu’elle a obtenues. Vous aurez ainsi une vue d’ensemble permettant des comparer les opportunités entre elles, et d’identifier l’opportunité de marché principale et les alternatives.

  • Gold mine (mine d’or) : ces opportunités traduisent généralement un besoin important mais encore non satisfait, ce qui est relativement rare aujourd’hui. Si c’est le cas, vous possédez certainement une capacité unique pour répondre à une problématique très répandue. Ce qui correspond sans aucun doute à votre opportunité de marché principale.
  • Moon shot (pari colossal) : les offres hautement technologiques et innovantes qui demandent une prise de risque élevée, mais qui en cas de succès sont les plus intéressantes. Si vous êtes solides d’un point de vue technologique, c’est une opportunité de marché principale pour vous. Sinon elle peut être considérée comme une option à long terme.
  • Quick win (victoire rapide) : ces opportunités offrent peu de résultats mais nécessitent peu d’investissement. Vous pouvez les intégrer comme premiers jalons à court terme dans une démarche plus globale à long terme.
  • Questionable (discutable) : les opportunités les moins intéressantes, rapportant peu de valeur à terme et difficile à mettre en œuvre. A mettre de côté.

 

 

3. Construire sa Stratégie Focus Agile

Les phases de découverte et d’évaluation vous aurons permis de définir un ensemble d’opportunités de marché riche d’enseignements. Maintenant, il est temps de prendre une décision pour concentrer vos efforts sur les opportunités les plus prometteuses tout en restant agile pour appréhender l’incertitude. Et c’est dans cette décision que réside une des clés de réussite de tout entrepreneur : savoir envisager d’autres options pour s’en sortir, si les choses ne tournent pas comme vous l’auriez prévu… et les choses ne tourneront pas à coup sûr comme vous l’aviez prévu !

Plutôt que de se concentrer à fond sur une seule opportunité, Sharon Tal et Marc Gruber proposent une stratégie qui permet de gérer l’équilibre subtil entre focus et agilité. Une stratégie issue de leurs travaux (500+ projets technologiques passés à la loupe) qui ont démontré les avantages à sélectionner une opportunité principale pour concentrer vos premiers efforts et à garder des options ouvertes pour rebondir et faire face aux changements.

En vous appuyant sur la matrice précédente, vous serez capable de choisir l’opportunité la plus attractive, mais il s’agira également de construire un portefeuille intelligent d’options qui viendra renforcer votre agilité. C’est tout l’enjeu de cette stratégie focus agile.

Deux catégories d’options :

  • De repli : une opportunité attractive qui ne comporte pas les mêmes risques que la principale qui vous permettra de rebondir si vous ne réussissez pas.
  • De croissance: une opportunité attractive qui permet de créer de la valeur dans le temps et de savoir quoi faire après si vous réussissez.

Dans l’idéal, toutes les opportunités que vous choisirez, doivent être liées entre elles pour pouvoir réutiliser les capacités et ressources que vous aurez mises en œuvre pour l’une ou pour l’autre.

 

Comment construire sa stratégie focus agile ? En équipe. Les discussions d’équipe feront vivre les différents points de vue et vous permettront d’aller au fond des choses, et ainsi de prendre une décision éclairée et partagée. La réussite commence par la création d’une équipe !

1- Choisir votre opportunité de marché principale

Un choix pas si évident : le cas où une opportunité se détache arrive rarement ; on fait plus souvent face à des options soit très proches, soit diamétralement opposées en termes de risque versus ROI (victoire rapide vs. pari colossal). Le seul conseil que donnent les deux chercheurs est de considérer vos préférences personnelles (valeurs, passion, ambition, propension au risque…) et l’intérêt de vos parties prenantes d’une part, et d’autre part d’éviter de choisir une option dans le quadrant « discutable ».

 

2- Étudier les options de repli et de croissance

Listez toutes les opportunités attractives qu’il vous reste comme candidates potentielles. Évaluez ensuite celles qui sont peu, relativement ou très proches de l’opportunité principale, en termes de produits ou de marchés.

  • Dans quelle mesure les produits partagent-ils les ressources (humaines, matérielles…), les capacités technologiques (socle, fonctionnalités…) et les réseaux (commercial, distribution, partenaire…) ?
  • Dans quelle mesure les clients connaissent-ils votre marque (valeur, réputation, promotion…) et utilisent-ils les canaux de distribution existants ?

Définir le type de chaque option :

  • Option de repli (plan B) : elle ne comporte pas les mêmes risques et ne s’appuie pas sur les mêmes hypothèses, mais partage des ressources ou des capacités technologiques avec l’option principale permettant de réutiliser les ressources et capacités déjà engagés.
  • Option de croissance (plan long terme) : elle permettra d’utiliser l’opportunité principale comme tremplin pour augmenter votre potentiel de création de valeur. Elle doit s’inscrire dans une feuille de route sur le long terme.

 

3- Définir une stratégie pour chaque option

Un dernier choix s’impose : vous devez sélectionner une option de repli et une de croissance pour accompagner votre opportunité principale dans votre stratégie focus agile. Pour ce faire, posez-vous les questions suivantes :

  • Exploiter maintenant: Pouvons-nous exploiter cette option maintenant ? Sommes-nous en capacité de supporter son investissement humain et financier ? Cette option nous permet-elle de réduire les risques et/ou d’augmenter le potentiel de création de valeur de l’opportunité principale ?
  • Garder ouverte: Devons-nous garder cette option ouverte ? Et se tenir informé du marché ciblé et développer un produit ou service flexible ? Ce qui nécessite en parallèle de l’option principale, d’allouer un peu de temps et de budget pour rester en veille sur ce marché (nouvelles tendances, études, concurrence, réseau…) et prendre en compte très tôt la modularité de votre offre pour atteindre plusieurs cibles.
  • Entreposer: Qu’en est-il des opportunités restantes ? Sauvegardez-les dans une liste, elles vous serviront peut-être un jour.

 

Vous êtes désormais fin prêts pour décrire votre cible focus agile. Utilisez le diagramme ci-dessous en positionnant votre option principale et les options de repli et de croissance. N’oubliez pas d’accompagner vos options choisies par un argumentaire pour défendre leur position et faire passer les bons messages. La réussite passe par une très bonne communication !

Bien que la méthodologie et les outils associés soient conçus pour définir votre stratégie, le processus d’apprentissage tout au long du cheminement est tout aussi important. Il vous aidera à mieux cerner les forces de votre organisation, votre paysage concurrentiel, vos clients et les difficultés que vous rencontrerez. Les connaissances et enseignements que vous allez réunir sont tout aussi précieuses.

 

 

[1] Where to Play: 3 steps for discovering your most valuable market opportunities, Marc Gruber and Sharon Tal, FT Publishing International

Comment (ré)concilier Agilité et e-commerce ?

Si la plupart des projets e-commerce étaient encore réalisés en cycle en V il y a peu, force est de constater que l’Agilité a su se faire une place de choix. Les principes agiles ont convaincu les équipes métiers comme techniques de l’efficacité de la méthode pour des projets en développement continu. La transparence qu’elle crée entre les parties prenantes limite la friction et la frustration, tout en permettant une résolution plus en amont des problématiques, tandis que l’autonomie apportée à l’équipe technique la rend plus responsable et plus apte, sur le long terme, à s’engager sur les produits livrés.

Mais alors, quel est le problème ?

De nombreux projets e-commerce sont freinés par des contraintes, comme un budget fixe, une deadline imposée ou encore un cahier des charges figé. Alors comment l’équipe technique peut-elle estimer ses user stories au fil des sprints, si tout est déjà gravé dans le marbre ? Cela nuit à la notion même de souplesse métier et risque de conduire indirectement la gestion du projet vers un cycle en V et ainsi de provoquer la frustration des équipes.

Une autre erreur fréquemment commise par des équipes novices est de penser que réaliser un projet de « manière Agile », implique que ce dernier se déroulera sans embûche. Or, il ne suffit pas de dire que l’on pratique l’Agilité pour faire un projet agile. Il dépend de certaines conditions préalables telles que l’engagement et la maturité de toutes les parties prenantes, aussi bien celles de l’équipe projet que celles inscrites dans votre écosystème (supérieurs hiérarchiques, chefs d’équipe, autres équipes etc.)

Faut-il pour autant renoncer à l’Agilité dans les projets e-commerce ?

Rassurez-vous, il est tout à fait possible de pratiquer l’Agilité au sein des projets e-commerce ! Le premier réflexe à adopter est d’analyser au plus tôt, dès le kick-off du projet si possible, les frictions encourues et trouver une solution à chacune d’entre elles. Cela peut passer par une formation à l’Agilité d’une ou plusieurs personnes, l’établissement par écrit des grands principes qui accompagneront l’équipe de production (autonomie, transparence, engagement, …), ou encore la désignation d’un Scrum Master (dans le cas de SCRUM) présent et expérimenté pour le début du projet, si l’équipe en ressent le besoin.

OK, mais j’ai un cahier des charges à respecter…

S’il est vrai qu’une équipe technique a besoin de visibilité sur le projet pour mieux adapter les développements, gardons malgré tout à l’esprit qu’un besoin exprimé en début du projet a de fortes chances d’évoluer au fil des développements. Un besoin peut se préciser, ou au contraire être dépriorisé, voire même… abandonné.

Pourquoi ne pas simplement donner les grandes lignes du besoin pour que chacun ait une vision globale du produit fini, et attendre que le besoin se précise et que le projet avance suffisamment pour établir des spécifications concrètes ? Ce parti pris évite à l’équipe de défaire pour refaire, ce qui induit également des dépassements de budget et de délai. En travaillant en Agilité, il n’est pas nécessaire de cadrer la totalité des fonctionnalités dès le début du projet, de manière précise et définitive, afin de pouvoir suivre l’évolution du besoin.

A noter également qu’un développeur qui passe du temps sur une fonctionnalité et voit celle-ci abandonnée quelques semaines plus tard par l’équipe métier, peut subir une frustration qui entame sa motivation pour les sprints à venir. Garantir la motivation et la mobilisation des effectifs est nécessaire pour assurer le déroulement du projet dans les meilleures conditions.

J’ai aussi une deadline et un budget…

Une chose est sûre, l’équipe technique sera toujours la mieux placée pour estimer les différentes fonctionnalités à développer. Plus elle communiquera avec le Product Owner, plus elle gagnera en autonomie, affinera ses estimations, et maîtrisera sa vélocité (capacité à produire).

Pour le métier, l’important est de prioriser au maximum les différentes fonctionnalités. Il doit remettre sincèrement en question la nécessité de la présence de chacune d’entre elles dans la première version du produit fini. Il est préférable de déprioriser les idées les moins matures et de prévoir une V2 dès le début du projet pour étaler certains besoins moins capitaux après la première mise en production d’un MVP fonctionnel, voire même de revoir et adapter certaines spécifications en fonction des retours de la première version. C’est un pari gagnant-gagnant : il apporte un gain de temps à l’équipe technique en lui permettant de peaufiner ensuite sa conception technique, la documentation, les tests unitaires, les performances, etc. et garantit aussi un meilleur time-to-market au client.

Ma DevTeam / Mon Product Owner ne me comprend pas

Il est important qu’à chaque sprint, chacun connaisse son rôle, ses responsabilités, ainsi que les responsabilités des autres membres de l’équipe. L’équipe de développement doit faire preuve d’engagement, de transparence et accompagner le Product Owner lorsque le besoin s’en fait sentir (rédactions de specs, soutien technique, tests).

Pour un Product Owner, faire le lien entre l’équipe métier et l’équipe technique n’est pas une position facile à tenir sur toute la durée d’un projet. Il doit se rappeler que c’est l’équipe de développement qui dispose de la meilleure connaissance du projet, il doit donc faire preuve d’écoute, respecter les décisions prises et mises en garde soulevées par l’équipe. Et cela passe aussi par savoir dire non aux équipes métier si cela s’avère nécessaire.

Enfin, il est toujours bon de rappeler que l’équipe de développement et le Product Owner sont membres de la même équipe projet, et font avancer la barque ensemble. Sans l’un, l’autre ne peut rien faire.

 

Si un budget fixe, un cahier des charges figé ou encore une deadline imposée peuvent apparaître comme des freins à l’application des principes Agile, il ressort en pratique que ces trois contraintes s’allègent souvent le long du projet grâce à la maturation de la réflexion métier et à l’engagement des équipes. Les connaître et les anticiper permettent donc d’aborder plus sereinement le projet et de mettre le cap vers le succès, en toute Agilité !

[Success Story] PIERRE FABRE : Nouveau parcours de recrutement aux tests cliniques

Pierre Fabre repense le recrutement et la gestion du panel du centre de recherche sur la peau. Dans le but d’assurer la bonne conduite de cette activité de Pierre Fabre, SQLI a imaginé et développé un nouvel outil de recrutement et de gestion de ce panel.

Mise en ligne fin 2019, la plateforme facilite le parcours des volontaires et l’équipe du Centre de Recherche sur la Peau accompagne avec plus de fluidité chacune de ces personnes.

Téléchargez la success story Pierre fabre

[SUCCESS STORY] RADIANCE MUTUELLE - Un site web pour booster sa visibilité

Afin de donner un vrai coup d’accélérateur à sa visibilité et gagner en notoriété, Radiance Mutuelle s’est dotée de son propre site vitrine.

« SQLI a très vite compris nos besoins et a su ajouter de la valeur pour aller au-delà de notre vision. La collaboration à distance s’est révélée efficace grâce à la grande maîtrise de SQLI de la méthode Agile et à la gouvernance qu’elle a mise en place. »

Ludovic Scapin, directeur général adjoint, Radiance Mutuelle

 

Téléchargez notre success story Radiance Mutuelle

Vis ma vie de Scrum Master : les enseignements à tirer d’une expérience sur le terrain

En 2019, j’ai eu la chance d’être SCRUM Master et coach agile pour repenser le parcours web de recrutement de volontaires pour des études cliniques menées par un acteur de la cosmétique. J’aimerais partager avec vous les clés de la réussite de ce projet mais également certains enseignements que j’ai tirés de cette expérience. 

 

La phase de cadrage du projet : un incontournable 

Avant le commencement du projet, la phase de cadrage a permis aux 7 participantsdont le client qui était néophyte, de mieux comprendre l’agilité et surtout de cadrer le budget et les délais. 

En amont des sprints prévusont été menés : 

  • Une formation de 2 jours à l’agilité pour l’ensemble des intervenants. Elle a permis au Product Owneraux membres de la DSI et aux utilisateurs clés de comprendre l’état d’esprit agile et le mode de collaboration que nous allions mettre en place avec le rôle de chacun. 
  • Plusieurs jours d’ateliers de vision, personas et story mapping afin d’aligner tout le monde sur les objectifs du produit et de commencer à construire le Backlog Produit. A ces ateliers étaient présents la Product Owner, la Proxy Product Owner, les utilisateurs clés, l’interlocutrice DSI, un UX designer et un développeur. La présence de ces deux derniers leur a permis de capter beaucoup d’informations, de construire une UX Map (ou carte d’expérienceet d’échanger sur des questions ou problématiques techniques qui pouvaient déjà se présenter. 

 

Le Sprint 0 ou la préparation du projet : l’étape primordiale 

L’agilité nécessite de faire une bonne préparation, ou sprint 0, en amont des sprints. Au-delà de la liste des actions à mener, ce sprint a révélé certains points positifs qui ont par la suite permis de mener à bien ce projet. 

 

Réalisation de plusieurs POC

Le projet comprenaiplusieurs points techniques à risque : 

  • Serveur HDS (Hébergement de données de santé) : les données de santé étant des données sensibles, nous avons dû travailler avec des serveurs ayant des contraintes particulières (accès limités, encryptage des données, séparation des données, etc.) 
  • Connexion de notre application à l’agenda Outlook de notre société avec un besoin fort d’écriture dans les agendas demandés par les métiers 
  • Refaire tout le site vitrine de notre client 

Pour essayer de limiter les risques, et surtout ne pas s’engager sans savoir vraiment de quoi il retournaitnous avons réalisé des POC pour les deux premiers points. Ces POC nous ont permis : 

  • De faire en amont le code source de base pour le projet 
  • De vérifier le fonctionnement avec la DSI 
  • De monter en compétence pour l’équipe de développement 

Pour le site vitrine, il se trouve que le site corporate du client venait d’être entièrement refait par SQLI. Nous avons donc étudié le fait de réutiliser son socle technique et de l’adapter à nos besoins : cette opération permis de gagner du temps et du budget pour la partie « application » du projet. 

 

Mise en place des environnement

La gestion des environnements techniques est toujours très consommatrice de temps et d’argent, aussi bien à la mise en place qu’à la maintenance sur le long cours. Nous avons donc décidé de monter en premier un environnement de développement et d’intégration entièrement opérationnel et disponible dès le premier sprint, ce qui nous a offert une visibilité sur le déploiement des suivants. 

 

Réalisation d’une première user story

L’importance de la première US (user story) à faire pendant le sprint 0 s’est confirmée pour ce projet. A partir d’une US très simplenous nous sommes rendu compte de certains problèmes de déploiement que nous avions sur nos environnements (droits d’accès aux serveurs et packaging du produit notamment). Sans cette première US, nous n’aurions jamais pu livrer une seule US en sprint 1 ; n’hésitez pas à la faire ! 

 

Une organisation d’équipe dans l’esprit de SCRUM

L’équipe a su trouver une organisation dans l’esprit de SCRUM. Elle était composée comme suit (avec le temps alloué au projet pour chacun car cela a joué un rôle crucial dans la réussite du projet) : 

  • Un Product Owner (PO) côté client avec 25% de son temps alloué au projet 
  • Un Proxy Product Owner (PPO) avec 100% de son temps alloué au projet 
  • Un UX Designer avec un nombre de jours fixes alloués au projet 
  • Trois développeurs dont deux à temps plein et un à 80% 
  • Un SCRUM Master/Coach agile à mi-temps 

 

Une DSI facilitatrice du projet

Nous avons eu la chance d’avoir une DSI qui a compris l’importance du travail « sans intermédiaire » dans les projets agiles, ce qui nous a permis de travailler directement avec les acteurs des métiers. En effet, nous voyons souvent notre interlocuteur (PO) « métier » être une personne de l’informatique qui fait le « passe plat » entre l’équipe et les acteurs des métiers. La DSI nous a donc fourni un soutien sur les sujets techniques lorsque nous en avions besoin, et le PO du projet était une personne directement du métier. 

 

Le rôle du PO : impliqué et à temps plein ! 

Pour moi, le rôle du PO est souvent sous-estimé en Agile. C’est pourtant lui qui porte le produit et qui définit ce à quoi il va ressembler. Nous avons eu l’occasion d’avoir ce que j’appelle un « vrai » PO ; une personne côté métier qui va utiliser l’application développée, qui connait les métiers et sait où chercher les informations sur les métiers. Notre PO a fait un travail colossal en amont pour définir avec les utilisateurs leur besoin, cadrer vis-à-vis à de la vision (et parfois dire non) et avoir 90% des informations de la user story lorsque nous l’abordions en séance d’affinage. Nous avons gagné beaucoup de temps en allers-retours inutiles et en discussions stériles 

 

L’UX designer: comment l’intégrer?

Vous avez sûrement dû vous poser la question « Comment intégrer les profils « spécifiques » dans un projet agile comme les architectes, les experts ou encore les UX Designer ? »
Le facteur primordial pour le rôle d’UX Designer est de l’impliquer le plus en amont possible dans le projet et tout le long. Dans notre cas, il a été présent dès le cadrage du projet (avant le sprint 0) ce qui a permis: 

  • À notre client de se projeter plus facilement dans le projet grâce à des maquettes en fils de fer. Le client a également pu plus facilement exprimer son besoin grâce à ce travail. 
  • À notre UX Designer de connaitre les besoins et contraintes du client pour proposer le meilleur design et parcours client.   

Pendant le sprint 0, il a travaillé avec nous sur l’affinage des premières US pour qu’il puisse fournir les maquettes dès le sprint 1. Il a aussi défini la charte graphique et les éléments principaux de navigation. Son activité n’est pas constante tout au long du projet : au début, il doit fournir tout le socle de l’UX dans lequel les développeurs n’ont qu’à piocher pour le design des nouvelles fonctionnalités, sauf si un nouveau comportement est attendu. Dans ce cas, une intervention sur ce sujet sera nécessaire. En revanche, je trouve important qu’il soit présent jusqu’à la fin pour garantir la cohérence jusqu’à la livraison du produit final et éviter toute dérive.  

 

Accepter le changement 

Les trois développeurs de l’équipe étaient expérimentés sur les technologies utilisées. Un point qu’il a fallu gérer a été l’acceptation des changements, à la suite des retours utilisateurs ou suite aux découpages des US. Le fait d’itérer sur un écran et/ou une fonctionnalité, de faire une solution simple avant la solution définitive n’était pas bien compris. Il fut crucial de leur expliquer que le but était que les utilisateurs puissent se projeter sur la fonctionnalité futureCette partie de mon job m’a demandé beaucoup d’écoute active, de compréhension des peurs sous-jacentes à ces réactions pour les aider à trouver la meilleure solution. J’ai essayé de ne jamais leur souffler une solution mais de faire en sorte qu’ils trouvent la solution adaptée à leur projet. Ils ont rapidement vu l’intérêt de montrer les fonctionnalités et d’avoir des retours. 

 

La phase projet : au cœur du sujet 

 

Périmètre / Coût / Délais 

La première chose à souligner est que nous avons respecté le budget et le délai ! Le périmètre s’est quant à lui ajusté au fil du projet. Au début, le client a choisi uniquement les besoins « MUST » que nous avons alors affinés sur notre story mapping. A la clôture du projet, en partant du story mapping initial, nous avons réalisé 99% des « MUST », 79% des « SHOULD », 65% des « COULD » et 50% des « WOULD » (méthode MoSCoW) avec le même budget. Comment est-ce possible me direz-vous ? 

Voici les facteurs de réussite : 

  • Une équipe stable et à temps plein pendant tout le projet 
  • L’expérience des développeurs pour proposer toujours la solution la plus adaptée au besoin (et souvent la plus simple) 
  • La réutilisation du socle technique d’un autre site du client qui nous a permis d’utiliser les ressources de ce socle pour des besoins métiers 
  • Le PO à temps plein, impliqué, avec du pouvoir de décision et qui sait dire « Non » 
  • Le travail en amont du PO avec les utilisateurs 
  • Une vision claire et partagée avec tous, y compris avec les sponsors 
  • L’utilisation de Drupal qui a permis une gestion facilitée des droits d’accès aux différents profils 

Si nous regardons le périmètre décrit initialement et le périmètre implémenté, nous nous rendons compte que certaines fonctionnalités n’ont pas été réalisées car elles sont devenues inutiles à la suite des retours utilisateurs. A l’inverse, et pour l’exemple, une démonstration nous a mis en lumière que le collaborateur à l’accueil du centre avait besoin tous les jours du planning des RDV pour faciliter l’accueil des volontaires, besoin qui n’avait jamais été évoqué. Nous avons pu ajouter ce retour dans notre backlog et le faire dans le sprint suivant car indispensable pour le bon fonctionnement de l’application. 

 

Le plus important d’abord 

Avec un projet agile, la priorisation doit être axée sur le plus important d’abord et non le plus compliqué ou risqué. Nous en avons fait l’expérience : un besoin primordial exprimé par les utilisateurs était la possibilité pour l’application de se connecter à leur agenda Outlook pour pouvoir lire leurs RDV et inscrire les nouveaux pris par les volontaires pour participer aux tests cliniques. Nous avions donc mis les US sur ce sujet dès le deuxième sprint. Malheureusement, suite à un problème sur l’accès sécurisé à Outlook, nous n’avons pas pu réaliser ces besoins qui se sont vus repoussés en sprint 6 (sur 8). La conséquence a été double : 

  1. Nous avons dû avancer en imaginant la solution pendant 4 sprints, ce qui a été un changement de priorisation énorme pour le PO. Nous avons dû également développer des solutions alternatives en attendant d’avoir la solution Outlook pour pouvoir tester et avoir un logiciel opérationnel ; solutions qui ont bien sûr été défaites par la suite. 
  1. Lorsque la solution Outlook a pu être implémentée, nous avons découvert plein de petites subtilités ou de problèmes sur les fonctionnalités liées, ce qui nous a demandé un important travail de tests, d’ajout d’US pour aménager les besoins pourtant validés par les utilisateurs aux nouvelles contraintes.  

 

Attention aux tests 

Une autre leçon que je retire de ce projet est l’importance des tests. Souvent en agile, nous négligeons un peu les tests car nous faisons les fonctionnalités au fur et à mesure. C’est là où des tests automatisés pourraient être fort utilesDans notre cas, les critères d’acceptation étaient bien notés dans les US, mais il manquait des tests plus globaux (ou TNR – Test de Non Régression) pour vérifier que l’ajout de ce besoin à la fonctionnalité globale ne l’avait pas altérée 

Nous avions également prévu des tests métiers mais ceux-ci ont été réalisés avec un décalage d’au moins un sprintdu fait du manque de temps de la part de certains intervenantsLa conséquence a été de voir des anomalies ou nouveau besoin tardivement et de devoir les gérer dans l’urgence lors des derniers sprints, mais tous les retours pertinents étaient pris en compte. Bref, une attention toute particulière sur les tests en général est à avoir en agile (et même en cycle en V) en gardant en tête le dicton « Just in time and just enough » (« Juste à temps et juste ce qu’il faut ») 

 

Si c’était à refaire, je préconiserais les points suivants : 

  • Ajout de tests automatisés sur les fonctionnalités clés 
  • Systématisation des TNR 
  • Implication et dégagement du temps des métiers pour faire les tests « Just in time » 

 

Implication des métiers  

Les utilisateurs finaux ont été identifiés très tôt et nous avons tenu à ce qu’ils soient présents aux différentes cérémonies et aux tests. Nous avons ajouté des ateliers spécifiques avec eux en milieu de projet pour : 

  • Leur rappeler l’importance de leur rôle 
  • Leur demander si notre façon de communiquer avec eux était satisfaisante ou non et comment l’améliorer 
  • Leur demander quels sont les nouveaux besoins qu’ils ont identifiés aux vues des précédentes démonstrations. 

Une implication forte de la part des intervenants métiers est primordiale pour la réussite d’un produit car sans eux nous ne pouvons que faire « un produit » et pas faire « LE bon produit ». 

 

Rédaction des spécifications

Attention, je vous vois venir en me disant que nous avions des spécifications donc nous n’étions pas tout à fait en agile ! Et bien si, car nous avons rédigé des spécifications non pas en amont des US pour dire à l’équipe de développement ce qu’il fallait faire, mais en aval de la discussion que nous avions eu lors de l’affinage de l’US. Ces spécifications servent uniquement pour la maintenance et les futures évolutions du produit. 

Il y a eu deux types de spécifications rédigées pendant ce projet : 

  • Les spécifications techniques que la dev team a produites tout au long du projet soit dans l’US elle-même soit lors du sprint N+1 sur les US terminées du sprint précédent. 
  • Les spécifications fonctionnelles qui ont été rédigées par moi-même sur les deux derniers sprints et sur les 2 premières semaines de garantie.  

Aussi bien l’une comme l’autre, le niveau de détails a posé quelques soucis par la suite (découverte de bugs et de contraintes techniques tardivement) et je pense que nous aurions dû les faire plus au fur et à mesure avec des validations intermédiaires.  

 

Transition avec l’équipe TMA (Tierce Maintenance Applicative) 

Lorsque nous avons démarré le projet, nous savions que l’application allait devoir être maintenue. Nous avons malheureusement traité ce sujet tardivement, ce qui n’a pas permis de fluidifier la passation. L’aprèsprojet doit être géré au plus tôt, ainsi que le transfert de connaissances. La solution idéale pour moi est d’avoir une maintenance gérée directement par l’équipe initiale et qui continue à faire les évolutions.  

 

La contractualisation

Pour finir sur les points positifs, nous avons géré ce projet avec une contractualisation au forfait qui n’a pas été du tout contraignante pour plusieurs raisons : 

  • Aucun suivi à la lettre du contrat quant aux périmètres engagés. Comme expliqué plus haut, nous avons suivi le besoin des utilisateurs tout en gardant en tête notre engagement.  
  • Un suivi financier allégé niveau SQLI puisque nous avions le bon nombre de jours par personne et par sprint pour l’ensemble du projet. 
  • Les indicateurs suivis étaient ceux de l’agilité (nombre d’US dans le backlog/réalisé, nombre de points dans le backlog/réalisé, velocity chart, burndown chart) et aucun engagement n’était fait dessus. 

En conclusion, ce projet est une réussite (utilisateurs satisfaits, client content, projet délivré dans les temps avec le budget respecté et l’équipe Scrum contente de son expérience) malgré quelques écueils grâce auxquels nous avons tous grandi pendant ce projet et tiré des enseignements pour les futurs projets. 

 

Kanban, l’art japonais de l’efficacité pour une TMA agile

Dans un monde digital où la méthodologie Scrum est omniprésente, les équipes TMA (tierce maintenance applicative) sont confrontées à des problématiques bien particulières. Difficile d’appliquer Scrum lorsque l’on gère en parallèle des dizaines de clients ayant tous des demandes de support, d’anomalies et d’évolutions toutes plus urgentes les unes que les autres. Comment construire des sprints avec des tickets qui arrivent au fil de l’eau ? Quand et comment prioriser ? Comment s’adapter rapidement et efficacement ?

 

Nouveau call-to-action

 

Pour moi, la réponse tient en un mot : Kanban.
Cette méthodologie issue de l’industrie automobile au Japon (Toyota) se base sur l’approche Lean. Elle vise l’amélioration continue des processus de production grâce à une méthode de gestion des flux qui permet d’éviter les blocages et de réaliser une livraison rapide et continue.

Kanban n’est pas une solution clé en main mais repose sur 4 principes et 6 bonnes pratiques.

 

Les 4 principes de Kanban

  1. Commencer par ce que vous faites actuellement
  2. Accepter d’appliquer des changements progressifs
  3. Respecter le processus actuel, les rôles, les responsabilités et les titres
  4. Encourager les actes de leadership à tous les niveaux

 

Les 6 bonnes pratiques de Kanban

  1. Visualiser le travail en cours et le processus
  2. Limiter le travail en cours
  3. Gérer et mesurer le flux de travail
  4. Rendre les règles explicites
  5. Implémenter des boucles de feedback
  6. S’améliorer de manière collaborative et expérimentale

Comment bien démarrer ?

  • Il est souvent difficile de convaincre les équipes de changer leurs méthodes de travail. Alors, n’essayez pas d’imposer la méthode Kanban, mais entrainez votre équipe dans ce processus de changement dès les premières étapes.
  • Partez d’un tableau le plus simple possible (avec les 3 colonnes To Do / Doing / Done). Ce tableau évoluera par la suite pour décrire le workflow idéal dans votre contexte.
  • Mettez en place des rétrospectives mensuelles, idéalement avec l’aide d’un coach Agile, pour vous permettre de prendre le recul nécessaire.
  • Rédigez en équipes des règles visibles de tous. N’ayez pas peur des conflits qui résulteront de l’application de ces règles car ce sont eux qui seront à l’origine de l’amélioration.

Vous constaterez rapidement des résultats positifs au niveau des équipes, de la qualité, des délais, du management et des clients.

  • Vous obtiendrez ainsi en un coup d’œil une visualisation globale de l’activité TMA sur votre tableau. Utile pour l’équipe mais aussi pour votre manager.
  • Vous identifierez rapidement les points de blocages et créerez une solidarité au sein de votre équipe pour les débloquer.
  • Vous arriverez à une meilleure prédictibilité de la capacité de production grâce à une meilleure gestion du flux.
  • Des règles connues et appliquées par tous participeront à l’amélioration de la qualité.
  • L’arrêt du multi-tâches permettra une meilleure productivité des développeurs.
  • En définitive une équipe efficace et solidaire pour des clients satisfaits par la qualité et les délais.

 

Pour vous donner une idée, voici un aperçu du workflow mis en place au sein de mon équipe :

Kanban

 

Et après ?

Une fois votre système bien en place, il peut être utile de le digitaliser via un outil tel que JIRA. Non seulement vous rendrez le travail d’équipes à distance possible (difficile de déplacer un post-it par Skype !) mais aurez également une totale visibilité sur les statiques avancées pour valider les améliorations constatées au quotidien.

Nouveau call-to-action

 

Vous souhaitez aller plus loin dans l’apprentissage du Kanban ?

Je vous recommande vivement les lectures suivantes :

Introduction visuelle à Kanban : Tableaux Kanban pas à pas

Une synthèse de la méthode Kanban : Kanban for Software Development

Maitriser la méthode Kanban : Kanban pour l’IT de Laurent Morisseau chez Dunod