I. Introduction▲
I-A. Qui suis-je ?▲
L'agilité, avant, je voyais cela plutôt de loin. Je développais, donc le fonctionnement de l'équipe ne faisait pas vraiment partie de mon périmètre. Seulement, comment faire lorsqu'on vit pendant un an les dysfonctionnements et la perte de motivation de toute une équipe ?
C'est avec la volonté de sortir de certains malaises que j'ai commencé à m'intéresser à l'agilité. C'est ainsi que je me suis vue prendre progressivement le rôle de Scrum Master au sein de l'équipe que j'ai accompagnée, durant un an et demi, dans une démarche d'amélioration continue.
I-B. Pourquoi ce retour d'expérience ?▲
Cette démarche que l'équipe a entreprise a permis d'encourager la hiérarchie à intégrer des pratiques agiles dans le cadre de la réorganisation du service informatique, incluant ainsi l'ensemble des projets informatiques dans un processus agile.
L'agilité vous intéresse, mais vous êtes dans le cadre d'un projet où il est compliqué d'appliquer une méthodologie agile « by the book » ? Je vous propose de partager mon retour d'expérience. Vous y découvrirez une approche agile par la pratique !
- Partie #1 : La frustration est de l'orLa frustration est de l'or
- Partie #2 : La rétrospective est la clé de voûteLa rétrospective est la clé de voûte
- Partie #3 : Installer collectivement une cultureInstaller collectivement une culture
- Partie #4 : Petites boucles de rétroactionPetites boucles de rétroaction
- Partie #5 : Grandes boucles de rétroactionGrandes boucles de rétroaction
- Partie #6 : L'effet papillonL'effet papillon
II. La frustration est de l'or▲
II-A. Contexte▲
Dans cette première partie, nous allons nous intéresser au contexte dans lequel l'équipe se trouvait et les blocages qui l'empêchaient d'agir.
II-A-1. Un projet à grande envergure▲
Il s'agit d'un extranet, en production depuis dix ans, qui a été victime de son succès. Les fonctionnalités ont été développées par couches avec très peu de ressources au fil des années. Le projet est utilisé à l'échelle internationale par les employés et les clients de l'organisation. L'activité métier est découpée en trois grandes composantes, l'application permet le suivi de l'ensemble du processus métier.
II-A-2. L'organisation▲
Pour des raisons historiques, le projet se trouvait au sein d'un service métier qui représente un tiers des activités métiers gérées par l'application. L'ensemble du service se positionnait plutôt comme utilisateur de l'application, donc la méthodologie de gestion de projet informatique ne faisait pas partie des préoccupations de la hiérarchie.
II-A-3. L'équipe▲
L'équipe est composée de huit personnes avec des niveaux d'expériences et des spécialités hétérogènes. Les rôles n'étaient pas clairement définis, voire historiques ; donc plutôt que de vous faire un long discours, voici un schéma qui vous permettra de mieux comprendre :
II-A-4. Gestion de projet en cascade▲
Toutes les étapes du cycle de développement étaient totalement prises en charge par l'ensemble de l'équipe de développement, en allant du recueil du besoin utilisateur à la livraison de l'application, en passant par la conception et la recette.
II-A-5. Dette technique▲
Le projet continuait de fonctionner de cette manière, mais ce système était de moins en moins efficace. L'équipe déployait une grande énergie en analyse et en maintenance des fonctionnalités, au détriment de la qualité technique et fonctionnelle de l'application.
II-B. Une énergie bloquée▲
II-B-1. Soutien hiérarchique▲
Lorsqu'un projet de cette envergure n'est pas régulièrement refondu, on arrive à un stade où la moindre fonctionnalité prend un temps extrêmement important en développement. Cette situation générait une frustration, tant au niveau de l'équipe, qu'auprès du management. La situation ne faisait que se dégrader. Averti de cette dégradation, le management a tenté d'améliorer la situation.
II-B-2. Du temps pour mieux faire▲
Le management a donc convoqué les membres de l'équipe individuellement pour avoir un retour sur la situation. Afin de répondre à la problématique de dette technique, ils ont accordé un pourcentage de 30 % du temps dédié à la technique.
II-B-3. Blocages▲
Cependant, l'équipe n'arrivait pas à sortir de son quotidien, il était impossible de déclencher le changement. En réalité, la hiérarchie avait accordé du temps pour résoudre la conséquence et non pas la cause du problème. Le sentiment d'insatisfaction au sein de l'équipe s'est accentué, une insatisfaction tellement forte que tous les membres de l'équipe envisageaient de quitter le projet.
II-C. La frustration est de l'or▲
J'ai donc cherché à comprendre pourquoi l'équipe n'agissait plus en initiant des discussions avec les différents membres de l'équipe. J'ai pu en conclure que l'inactivité de l'équipe ne relevait pas d'une absence de motivation, mais d'une frustration.
La frustration est de l'énergie bloquée. Il faut exploiter cette énergie pour provoquer un changement (« Frustration is gold » Culture Hacking de Robert Richman).
J'ai fini par comprendre que l'équipe souffrait terriblement d'un manque de visibilité et de communication. Le point bloquant était que les membres de l'équipe estimaient que ce n'était pas leur rôle de s'impliquer sur la méthodologie de gestion de projet.
II-D. Délivrer l'équipe de la peur d'agir▲
J'ai donc pris l'initiative de proposer une rétrospective dans le but de rétablir la communication au sein de l'équipe. Dans la partie suivante, nous reviendrons sur le déroulement de notre première rétrospective et sur le plan d'action qui a permis à l'équipe de se libérer de la peur d'agir.
III. La rétrospective est la clé de voûte▲
Comment initier le dialogue sur des bases saines ? Quelles sont les actions à mettre en place pour assurer une démarche d'amélioration continue ? Dans ce deuxième billet, je vous propose de revenir sur le déroulement de notre première rétrospective qui a été la clé de voûte dans la transformation de l'équipe.
III-A. Poser le cadre▲
J'ai commencé par lire d'une manière solennelle la phrase suivante, dans le but de poser des bases saines au dialogue :
indépendamment de ce que nous allons découvrir aujourd'hui, nous comprenons et nous croyons vraiment que chacun a fait de son mieux en fonction de ses connaissances, de ses compétences, de ses capacités, des ressources disponibles et de la situation courante. (La rétrospective de sprint de Claude Aubry)
J'ai par la suite cassé le côté solennel en invitant l'équipe à échanger autour de cette phrase. Cette approche a initié le dialogue sur un sujet neutre qui n'impliquait personne en particulier, pour poser les bases d'une communication constructive.
III-B. Récolter les informations▲
Par la suite, j'ai proposé aux membres de soumettre les sujets qu'ils souhaitaient aborder sur des post-it, sans limitation aucune. Un grand nombre de sujets ont été soumis, mais tous ne pouvaient évidemment pas être abordés. Cependant, je tenais à ce que tous les sujets soient entendus au moins une fois. J'ai donc lu à voix haute tous les sujets un à un. Nous avons ensuite regroupé et classé les sujets par thèmes.
Les thèmes suivants ont émergé :
- Réflexion et communication ;
- Scrum (itérations) ;
- Recette croisée ;
- Spécifications fonctionnelles.
III-C. Générer les idées et définir un plan d'action▲
III-C-1. Réflexion et communication▲
Il s'agit du thème le plus important comptabilisant le plus grand nombre de sujets soumis. Cependant, l'équipe a eu beaucoup de mal à initier le dialogue. On sentait bien qu'il y avait des sujets tabous. Au bout de quelques phrases échangées sur le sujet, l'équipe a décidé de clore la conversation en concluant que ce thème était transverse et que les solutions émergeront plus facilement à travers des sujets plus concrets. Ne sachant pas comment alimenter le débat, j'ai donc respecté la décision de l'équipe.
Nous avons donc convenu de nous demander comment on pouvait améliorer la réflexion et la communication dans le cadre des thèmes qui ont suivi. Cela a permis de mettre en place quelques pratiques décisives pour initier une démarche de changement saine, en accordant à l'équipe du temps pour réfléchir et communiquer.
III-C-2. Scrum (itérations)▲
Pour introduire ce thème, j'ai pris le temps de rappeler les valeurs agiles avant d'introduire les principes, les rôles, les pratiques et les artefacts Scrum pour que tout le monde ait le minimum pour aborder le débat autour de la méthodologie.
L'équipe avait besoin de gagner en visibilité en se dirigeant vers du Scrum, mais la méthodologie leur semblait trop rigide. L'équipe souhaitait amorcer une démarche de changement plus douce et adaptée à leur contexte. Nous avons donc convenu dans un premier temps de partager les valeurs Agiles et les principes Scrum.
Notre plan d'action pour y parvenir a été de mettre en place une réunion hebdomadaire d'une heure, animée par une personne de l'équipe pour faire le point sur l'avancement du projet.
III-C-3. Recette croisée▲
Contrairement à des organisations classiques, nous ne disposons pas d'équipe dédiée à la recette. Nous avions donc intégré une phase de recette à notre cycle de développement, en reprenant le principe de revue de code et en y intégrant la recette fonctionnelle.
L'équipe trouvait cette pratique très enrichissante et souhaitait la garder telle quelle. Cependant, certains développements sensibles méritaient plus de réflexion en amont afin d'éviter de tout défaire au moment de la recette croisée.
Pour éviter ce type de situation, nous avons décidé d'identifier collectivement lors de la réunion hebdomadaire les développements sensibles. L'équipe décide collectivement de soumettre ces développements, soit à une programmation en binôme, soit de précéder le développement par une phase d'analyse permettant à l'équipe de choisir la meilleure solution à mettre en place.
III-C-4. Spécification fonctionnelle▲
L'équipe a souligné le manque d'implication des parties prenantes au niveau métier, qui générait des difficultés au niveau de la compréhension du besoin utilisateur.
L'équipe avait besoin qu'un effort plus important soit mis en amont au niveau de l'étude du besoin utilisateur afin de combler le manque de disponibilité du métier.
Nous avons donc identifié au sein de l'équipe deux personnes possédant la connaissance fonctionnelle requise pour jouer le rôle de Product Owner. Leur but est de valider la cohérence et la pertinence des besoins exprimés par le métier ainsi que de formaliser, d'une manière minimale, les exigences fonctionnelles attendues.
III-D. L'apport de la première rétrospective▲
La réunion a duré quatre heures. Tous les sujets n'ont pas pu être traités : l'automatisation des tests et le refactoring de code (qui semblaient au premier abord être le frein principal à l'épanouissement de l'équipe) n'ont pas été abordés.
Cette réunion a permis à chacun de sortir de ses propres préoccupations en s'intéressant à celles de l'équipe.
Dans la prochaine partie, nous découvrirons comment cultiver collectivement une culture agile avec une réunion hebdomadaire.
IV. Installer collectivement une culture▲
Qu'est-ce que cela veut dire être agile ? Quels sont les valeurs et les principes indispensables ? Dans ce troisième billet, nous allons nous intéresser aux principes qui ont permis à l'équipe de cultiver une culture à la fois agile et lean.
IV-A. Intervalles réguliers▲
Pour assurer une amélioration continue du projet, nous avons convenu de nous réunir toutes les semaines. Cette réunion hebdomadaire a significativement amélioré la communication au sein de notre équipe. J'irai même plus loin : la réunion hebdomadaire a donné le tempo d'avancement à l'équipe.
Dans le manifeste agile, on parle d'« intervalles réguliers ». On s'est aperçu dans notre cas que la régularité est vraiment stratégique. Quand nous faisions le point à des intervalles de temps irréguliers, la comparaison des données à inspecter était plus compliquée. La régularité a permis de donner une unité de mesure fixe dans le temps.
IV-B. Leadership à tous les niveaux▲
Le principe de « Leadership à tous les niveaux » de l'approche Kanban est très important. Il permet d'impliquer l'ensemble de l'équipe dans le processus de changement. Il encourage les individus à devenir force de proposition tout en cultivant l'esprit d'équipe.
Nous avons toujours besoin d'être entendus, mais pas forcément d'avoir toujours raison. La réunion hebdomadaire permettait ainsi à chacun des membres de l'équipe d'émettre des idées d'amélioration. Seules les idées ayant obtenu une majorité des voix donnaient lieu à une étude de faisabilité, un développement ou encore une nouvelle pratique pour améliorer notre manière de travailler.
IV-C. Management visuel▲
On voit souvent les équipes agiles travailler avec un tableau blanc et des « post-it ». Cette approche pose problème lorsqu'il s'agit d'un projet qui s'étend sur plusieurs années en termes de suivi et de traçabilité. Dans notre contexte, se passer d'un outil de gestion de projet n'était pas envisageable. Tout en étant convaincus par le management visuel, adopter les « post-it » nous semblait redondant et une perte du temps.
C'est au cours des réunions hebdomadaires que l'équipe a émis le souhait de changer l'outil de gestion de projet en faveur d'un outil plus adapté à la conduite de projet agile. Jira Agile a été identifié collectivement comme étant la meilleure solution compte tenu du contexte. Deux personnes de l'équipe ont donc pris le lead sur le sujet pour configurer l'outil en binôme afin de se l'approprier et de l'adapter aux besoins de l'équipe.
IV-D. Évoluer expérimentalement▲
Lorsqu'on adopte une démarche d'amélioration continue, on se retrouve souvent face à des problématiques pas toujours évidentes à résoudre. Le seul moyen de maintenir l'amélioration est d'expérimenter de nouvelles idées ou pratiques. L'équipe a donc le droit à l'erreur, mais le devoir de s'améliorer.
Il est cependant très important que l'équipe s'accorde à encadrer la phase d'expérimentation ou d'analyse dans le temps. Elle doit aussi placer les indicateurs pertinents avant d'expérimenter une idée ou une pratique. Enfin, elle doit toujours finir par faire le bilan collectivement afin de pouvoir s'adapter.
IV-E. Les petites boucles de rétroaction▲
La configuration de l'outil nous a permis de formaliser notre méthodologie comme étant du « Scrum like » avec des sprints d'une semaine correspondant au rythme de nos réunions hebdomadaires.
Au fur et à mesure des semaines, nous avons continué nos expérimentations. Je vous propose de découvrir dans la partie suivante, la méthodologie de travail que nous avons mise en place et quels ont été les indicateurs qui nous ont permis d'y parvenir.
V. Petites boucles de rétroaction▲
Comment orchestrer le sprint ? Peut-on autoriser le changement de scope ? Comment garantir la qualité sans une équipe de recette ? Comment gérer les livraisons ? Ce quatrième billet exposera notre façon de travailler ainsi que les indicateurs que nous avons mis en place pour nous aider dans notre démarche d'amélioration continue.
V-A. Réunion hebdomadaire▲
V-A-1. Préparation▲
La personne en charge de l'animation est aussi responsable du report du temps passé hors « tâches spécifiques » pour l'ensemble de l'équipe. Elle collecte et reporte dans Jira les temps prévus pour les réunions et les absences.
Ce temps est réparti dans l'outil en quatre, à savoir :
- le temps prévu découpé en deux catégories pour les réunions et les absences ;
- le temps imprévu découpé aussi en deux catégories pour les absences et autres (réunion commerciale, problème matériel, etc.).
Cette pratique nous permet de ne pas perdre du temps pendant la réunion pour calculer la capacité de l'équipe. Si ces informations sont détaillées en plusieurs « activités », c'est parce qu'on les utilise à une autre fin dont je vous parlerai plus tard.
V-A-2. Déroulement▲
V-A-2-a. Rétrospective▲
L'équipe passe en revue les graphiques Scrum classiques en prenant en compte les éventuels changements de périmètre du Sprint. Au changement de périmètre près, c'est du classique Scrum.
Nous allons plutôt nous intéresser à une pratique moins classique. L'équipe a mis en place un « dashboard » sous JIRA qui permet d'avoir une vision sur l'avancement des différentes tâches. Il expose la liste des tâches du Sprint avec les indicateurs suivants : le ratio temps passé par rapport au temps estimé et la cause éventuelle de dépassement.
L'équipe revoit donc toutes les tâches du Sprint et discute autour de ces indicateurs afin de comparer ce que nous avions prévu par rapport aux résultats obtenus et adapte donc sa conduite en fonction. Par exemple : le « refactoring » de certaines parties du code qui ont causé des dépassements.
V-A-2-b. Lancement du Sprint▲
Après avoir fait le bilan, l'équipe planifie le Sprint suivant et la date éventuelle de livraison en fonction de l'avancement des tâches.
De leur côté, les proxy PO présentent les différentes tâches à inclure dans le prochain Sprint. De son côté, l'équipe pose des questions et chiffre les tâches en jour-personne idéal.
Pour encourager l'implication de l'ensemble de l'équipe, les tâches ne sont pas attribuées lors de la planification. Comme en kanban, l'équipe doit traiter les tâches par ordre de priorité et donc n'importe qui peut être amené à développer n'importe quelle tâche.
V-B. Petite itération▲
V-B-1. Déroulement▲
L'équipe travaille sur des sprints d'une semaine. La durée du sprint est courte afin de pouvoir intégrer rapidement les changements de priorité.
Durant le sprint, comme en kanban, on applique aussi une limitation sur le travail en cours : chaque personne travaille sur une tâche à la fois.
Le processus de validation des demandes est intégré dans le sprint. Le but de l'équipe est de fluidifier le cycle de vie des demandes et éviter ainsi les goulots d'étranglement qui pourraient être dus à la recette.
Au cours d'un sprint, l'équipe peut être amenée à travailler sur plusieurs versions du produit :
- une version majeure en cours de développement ;
- une ou plusieurs versions mineures contenant des correctifs et des évolutions mineures.
Nous travaillons ainsi, car la livraison d'une version majeure implique une phase de recette générale de l'application, alors qu'une version mineure peut être livrée plus facilement, car elle contient des développements non impactant.
Les fréquences de livraisons sont variables en fonction de l'avancement des tâches et de l'urgence du besoin.
V-C. Les grandes boucles de rétroaction▲
Le fonctionnement en petites itérations est parfait pour l'équipe afin d'avancer tout en faisant des points régulièrement et en mettant en place des actions en fonction de ce qu'elle a appris durant la semaine.
Cependant, certains sujets méritent une période d'expérimentation plus longue. Je vous propose de traiter ce sujet dans la prochaine partie afin de vous expliquer dans les détails le fonctionnement de nos grandes boucles.
VI. Grandes boucles de rétroaction▲
Comment éviter que l'agilité s'essouffle ? Comment nourrir l'équipe afin qu'elle ne perde pas de vue le but sur le long terme ? Comment soigner la maladie des fausses impressions ? Dans ce cinquième billet, vous découvrirez le fonctionnement de nos grandes boucles qui ont permis de répondre à des problématiques qui méritent une période d'expérimentation plus longue.
VI-A. Des indicateurs factuels▲
La réunion de rétrospective a lieu tous les dix sprints. Elle permet de prendre du recul à moyen et long terme. Le Scrum Master fournit à l'équipe de la matière pour alimenter la réflexion via un document sous confluence qui contient les métriques suivantes :
VI-A-1. Indicateurs quantitatifs▲
Les graphiques en nombre de fiches par composante métier et technique, type, résolution et causes de dépassement. Ces métriques permettent à l'équipe d'avoir une vision quantitative du travail qui a été fourni durant les dix derniers sprints.
VI-A-2. Indicateurs qualitatifs▲
La répartition des nombres de bogues par composantes métiers et techniques. Cela permet de surveiller les bogues et d'identifier les domaines qui posent problème à l'équipe.
VI-A-3. Indicateurs collaboratifs▲
La répartition des composantes fonctionnelles et techniques par développeur et par « Technical reviewer ». Cela permet de vérifier que l'équipe reste bien polyvalente et qu'aucun ne se retrouve trop longtemps seul sur un sujet, qu'il soit technique ou fonctionnel. On vérifie aussi que le système de recette croisée reste bien réparti sur l'ensemble de l'équipe.
VI-A-4. Indicateurs temporels▲
Les temps passés par composante fonctionnelle et technique. Cela permet à l'équipe de prendre du recul et d'avoir une vision macro du projet et de vérifier les points suivants :
- le ratio fonctionnel et technique accordé par la hiérarchie ;
- corrélation entre le temps passé et les sujets développés ;
- qu'il n'y a pas de blocages générant des dépassements sur une composante particulière du projet.
VI-A-5. Indicateurs de vélocité▲
Les graphiques des vélocités de l'équipe sont particuliers, car ils se basent sur une unité de mesure temporelle. Cela a permis à l'équipe d'y intégrer le temps planifié en prenant en compte les imprévus.
VI-B. Une préparation individuelle▲
Les membres de l'équipe préparent individuellement les thèmes qu'ils souhaitent voir abordés en s'appuyant sur les métriques des dix derniers sprints ainsi que le document de la rétrospective précédente. Une limitation de cinq thèmes par personne a été mise en place afin d'éviter que l'équipe se disperse durant la réunion.
VI-C. Déroulement collectif▲
VI-C-1. Générer une vision globale▲
Au cours de la réunion, le Scrum Master génère une vision globale à partir des thèmes soumis. Il demande à l'équipe de placer chaque thème suivant leur ressenti afin de savoir si l'équipe pense qu'elle se positionne positivement ou négativement par rapport à cet événement.
VI-C-2. Générer les idées et définir un plan d'action▲
Ensuite, le Scrum Master aide l'équipe à échanger autour des différents thèmes abordés afin de trouver un plan d'action.
VI-C-3. Feedback sur la rétrospective▲
En fin de réunion, l'équipe donne son retour par rapport à la pertinence des indicateurs et au déroulement de la rétrospective.
VI-C-4. Le compte-rendu▲
Le compte-rendu de la rétrospective est inclus à la suite du document contenant tous les indicateurs.
VI-D. D'où vient cette idée ?▲
La plupart des rétrospectives agiles se concentrent sur le ressenti des personnes. On cherche toujours à toucher l'humain pour transcender le travail quotidien.
Cependant, sur les projets de longue durée, l'humain s'essouffle et devient moins fiable. Il a besoin d'indicateurs factuels pour le conforter dans son besoin d'avancer et de s'améliorer.
En mettant en place ce fonctionnement, l'équipe a cherché à trouver un équilibre entre la perception humaine et les indicateurs factuels.
VII. L'effet papillon▲
Quelles ont été nos difficultés ? Comment nous en sommes-nous affranchis ? Quel a été l'apport de l'agilité au niveau du projet, de l'équipe et de l'organisation ? Au bout d'un an et demi d'agilité, qu'avons-nous appris ? Dans ce dernier billet, je vous propose de découvrir l'effet papillon que nos petites pratiques ont pu avoir à petite et grande échelle.
VII-A. L'effet au niveau des individus▲
Je tiens à préciser qu'il ne faut pas voir l'agilité comme une solution absolue, mais plutôt comme un moyen de faire émerger les solutions possibles. Les valeurs et les pratiques agiles permettent de favoriser l'humain. Elles permettent de lever les tabous autour des problèmes en donnant à l'équipe les moyens d'initier la communication afin de s'améliorer. Cependant, c'est à l'équipe de s'entendre pour maintenir cette communication saine afin d'assurer cette amélioration.
Dans notre cas, l'agilité a exacerbé certains conflits humains. Souvent, les conflits ne s'arrêtaient pas aux personnes impliquées, mais s'étendaient à tout le groupe, chacun prenant parti pour l'un ou l'autre. Avec le temps, plutôt que de chercher une solution satisfaisante pour les deux parties, chacun voyait le différend comme une guerre de clans, opposant d'un côté des « mutins » et de l'autre des « privilégiés ». Le problème de base relevait d'un manque de confiance qui a amené à du temps perdu en travail de cadrage/surveillance. La présence d'un management bienveillant et plus impliqué aurait certainement pu nous aider à soigner certains malaises.
Ces conflits faisaient surface occasionnellement, donnant lieu à des périodes de crise épisodiques. Cependant, les individus s'évertuaient d'une manière générale à mettre de côté les conflits humains en faveur de l'équipe et du projet grâce aux valeurs agiles.
VII-B. L'effet au sein de l'équipe▲
L'effet de l'agilité a permis de grandement améliorer la collaboration au sein de l'équipe. Plusieurs pratiques ont permis d'alimenter cette collaboration.
Intégration des nouveaux : les nouveaux profitent de trois présentations à leur arrivée : fonctionnelle, technique et méthodologique. Ces présentations sont données par des personnes différentes de l'équipe afin de permettre aux nouveaux d'avoir des interlocuteurs privilégiés par domaine.
Veille technique : les membres de l'équipe ont la possibilité d'animer une réunion afin de partager ce qu'ils ont appris lors d'une participation à un événement ou une conférence technique, cela dans le but de voir ce qui pourra être profitable au projet.
Refonte technique : les chantiers de refonte technique sont soumis de façon systématique à une programmation en binôme. Ils donnent lieu à des réunions pendant lesquelles le binôme présente à l'équipe l'avancement, cela pour permettre à l'équipe de donner son « feedback » quant aux choix pris par le binôme, et afin de décider collectivement des éventuels ajustements à mettre en place.
Transfert de compétences : la recette croisée a aussi été un très bon moyen de collaboration. Pour assurer un transfert de compétences de qualité, nous veillons à garder une hétérogénéité entre les niveaux des intervenants sur un même développement, que ce soit sur le plan fonctionnel ou technique.
VII-C. L'effet au niveau du produit▲
La mise en place de l'agilité a permis d'améliorer significativement le produit sur le plan technique et du point de vue des utilisateurs. L'équipe a été capable de livrer plus fréquemment grâce à du refactoring de code que les indicateurs des causes de dépassements que nous avions mis en place nous ont permis de cibler.
L'équipe était capable de livrer en moyenne une fois par mois dont trois versions majeures par an. Certains utilisateurs, surpris, nous ont même demandé si on avait plus de développeurs au sein de l'équipe. En réalité, l'équipe avait deux développeurs en moins suite à des fins de missions dans le courant de l'année et nous investissions du temps dans la formation des nouvelles recrues.
VII-D. L'effet au niveau de l'organisation▲
Le top management a lancé un audit hautement stratégique visant à réorganiser l'ensemble des services de l'organisation. Dans ce cadre, l'ensemble des projets informatiques de l'organisation risquait de se faire absorber par un autre groupe de l'organisation.
Suite aux résultats de l'audit, le top management a décidé de créer un service informatique au sein du même groupe, regroupant ainsi l'ensemble des projets informatiques. Notre projet était non seulement parmi les plus positivement notés, mais il a encouragé le top management à intégrer les pratiques agiles, incluant ainsi l'ensemble des projets informatiques dans cette démarche.
Actuellement, un coach agile accompagne l'ensemble du service afin de mettre en place une méthodologie agile adaptée à ce nouveau contexte !
VIII. Remerciements▲
Cet article a été publié avec l'aimable autorisation de Alexis SEIGNEURIN. L'article original peut être vu sur le blog de la société Ippon.
Nous remercions également Francis Walter pour la mise au gabarit, Malick SECK pour la relecture orthographique de cet article.
Vous pouvez réagir par rapport à cet article. 1 commentaire 