L’enjeu pour notre client est d’optimiser ses process de développement sur son logiciel de formation. En effet depuis plusieurs mois avec l’augmentation du nombre de demandeurs, son équipe n’arrive plus à délivrer dans les temps les développements initialement prévus. La maintenance corrective et l’afflux des demandes d’évolutions faites par les clients prennent le dessus sur les développements internes. Les équipes passent ainsi de plus en plus de temps à gérer ces tâches et n’avancent plus sur les projets de fonds qui sont pourtant plus structurants.
Il faut trouver une nouvelle organisation au niveau des équipes afin de mieux allouer les ressources et de récupérer la satisfaction des clients ET des salariés qui comment à fatiguer de ne plus rien délivrer.
Fiche d’identité entreprise
- Secteur : Formation continue des professionnels de la téléphonie mobile. Plate-forme d’e-learning.
- CA : 2 M€
- Collaborateurs : 12 en France
- Problématique : La charge de travail de l’équipe de développement (6 personnes) devient trop importante avec l’augmentation du nombre de clients et des demandes d’évolutions qui vont avec.
- Notre rôle : Nous sommes sollicités avec notre pôle digital pour analyser le fonctionnement existant et proposer des pistes concrètes pour résoudre la problématique d’organisation. Comment continuer à assurer les évolutions structurantes tout en répondant aux exigences accrues des clients ?
- Durée de l’intervention : 2 mois avec une présence régulière les deux premières semaines et des interventions qui s’espacent une fois l’organisation en place.
- Mesure de l’efficacité :
- Rendu d’un document d’audit + support des réunions d’équipe
- Grille de satisfaction des équipes comparant l’avant et l’après de la nouvelle organisation
- Quantification des projets livrés avant et après la nouvelle organisation
- Résultat :
- Adhésion de l’équipe à la nouvelle organisation
- Mesure à distance du nombre de projets livrés en augmentation par rapport à la phase d’analyse
Comment continuer à assurer les évolutions structurantes tout en répondant aux exigences accrues des clients ?
Phase d’analyse, comment accompagner le changement ?
La phase d’analyse a été assez simple, une période d’observation d’une semaine, d’interviews des équipes et des différents intervenants nous a permis de constater l’impossibilité de délivrer dans les temps conformément au constat fait par la direction.
Historiquement le process était bien organisé. La direction en discutant avec les développeurs et le CP (Chef de projet) prévoyait des évolutions sur la plate-forme d’e-learning (environnement open source LAMP). S’en suivaient des phases de développement classique de type cycle en V (avec quelques étapes de tests en moins).
Nous sommes dans une situation efficace de développement tant qu’il n’y a pas trop d’imprévus à gérer.
Actuellement, les demandes des clients affluent, le CP se retrouve donc à arbitrer en permanence entre cette pression clients, l’insatisfaction des développeurs à ne pas pouvoir terminer correctement leurs projets car ils sont réorientés systématiquement sur les urgences et la direction qui privilégie les demandes clients par peur de les perdre.
Au final peu de projets sont terminés et le mécontentement grandit chez tout le monde, il faut mettre fin à ce cercle vicieux.
Une réunion de restitution de l’audit avec la direction permet très vite d’isoler une voie de sortie en passant du cycle en V vers des processus agiles. Cela permettrait d’avoir des cycles plus courts intégrant développement et livraison, de satisfaire les équipes et de pouvoir communiquer auprès des clients sur une roadmap plus fiable.
Mais pour réussir cette transition, il faut absolument intégrer les équipes à la réflexion en les poussant à choisir eux-même la solution, l’imposer serait risquer l’échec.
La phase de conseil et les propositions
Nous choisissons de réaliser plusieurs réunions avec les objectifs suivants :
Réunion n°1
Objectifs : exposer les problèmes relevés lors de l’audit auprès de l’équipe projet et recueillir des propositions d’optimisation
- Recueillir leurs avis sur les difficultés exposées et leurs causes
- Demander des idées pour résoudre ces difficultés
- Terminer la réunion en prévoyant la suivante axée sur les solutions
Quelques problématiques remontées par l’équipe :
- Peu de visibilité moyen (2 mois) et long terme (6 mois) au niveau production
- Volubilité des demandes qui « fatiguent » les équipes
- Opérationnel / projet / opérationnel /projet / …
- Sentiment de « ne pas avancer » car projets longs et mise en production irrégulière
- Communication globale sur le rôle des équipes de productions
Réunion n°2
Objectifs : synthétiser les problèmes, les pistes évoquées et suggérant le passage à l’agilité
- Reprise des idées de solutions proposées par l’équipe
- Exposé de « l’agile manifesto » et lien avec les solutions de l’équipe
- Go / NoGo sur le choix du passage à plus d’agilité
- Si Go présentation de premiers concepts pour cadrer les solutions présentant le plus l’adhésion
Une partie des objectifs retenus par l’équipe pour la mise en œuvre :
- Rester simple + +, ne pas complexifier, ne pas trop processiser
- Trouver un mix d’organisation entre l’adhésion sans condition à une méthodologie agile et un fonctionnement non structuré
- Etre responsable de sa production avec les pairs en support
- Etre impliqué dans les décisions par rapport à son expertise
D’un point de vue managérial, il est intéressant de remarquer que les souhaits de l’équipe sont très clairement d’être impliqué et responsabilisé. Ils ont également fait le choix de ne pas suivre une méthode en particulier mais d’insuffler un peu d’agilité dans leur processus actuel. Il ressort qu’une organisation mêlant SCRUM, KANBAN et leur process actuel serait appréciée et répondrait aux objectifs.
Réunion n°3
Objectifs : présenter la proposition de nouvelle organisation
- Go / NoGo sur les modalités choisies
- Adhésion sur l’organisation pour chaque rôle dans l’équipe
- Choix des KPI permettant de mesurer l’efficacité du processus mis en œuvre
Cet enchainement de réunions a permis de remplir pleinement l’objectif. L’équipe a été écoutée, a pu s’exprimer et adhère parfaitement à la proposition qu’ils ont contribué à construire.
Mise en œuvre (avec le client)
Organisation des sprints
Pour mettre en œuvre nous avons décidé de séparer un système de sprints classique (où chaque développeur est absorbé par ses tâches et JAMAIS dérangé pour assurer la livraison) avec un système ou un des sprints est dévolu à une activité plus opérationnelle (extract de données pour un client, debug urgent etc…).
Pour organiser le sprint mixte, nous avons au préalable quantifié la durée moyenne de temps passé à traiter des demandes hors cadre projets par typologie de fonction :
Cette évaluation permet sur le sprint mixte d’allouer une plage de temps aux demandes externes et le reste à des items qui seront intégrés en amont au sprint.
Les sprints s’organisent selon le schéma suivant :
Les éléments clés :
- 2 sprints en parallèle (un sprint projet et un sprint plus light avec du temps pour l’activité opérationnelle)
- Durée de sprint de deux semaines
- Le chef de projet prépare les sprints projets un mois à l’avance durant 2 semaines
- Le webdesigner / intégrateur prépare le design et l’intégration 2 semaines à l’avance
- Chaque sprint commence par une réunion de chiffrage, l’exposé du projet par le CP et la fourniture des éléments de design et d’intégration
- La livraison s’effectue en fin de sprint, il faut comptabiliser le temps de livraison dans la durée globale de sprint
Outils utilisés pour gérer les sprints
Il a été décidé d’avoir trois backlogs dans lesquels sont enregistrés les différentes demandes.
Un backlog stratégique géré par la direction et servant à alimenter les projets de fond de l’entreprise. Ne sont notés dans ce backlog que les projets très « gros grain » comme par exemple le passage du LMS à un LCMS (gestion de contenu intégrée à la plate forme d’e-learning).
Ce backlog géré sur excel permet de faire un chiffrage approchant de chaque projet et ainsi de planifier dans un gantt annuel les projets structurants de l’entreprise.
Un backlog projets dans lequel sont notés tous les projets détaillés. Il est géré sur excel et permet d’affiner le chiffrage ainsi que de déterminer les responsabilités décisionnelles item par item.
Un backlog de sprint qui reprend les items du backlog projets qui seront réalisés dans le sprint qui démarre. Il sert à réaliser la burndown chart de suivi.
Des fiches de fonctionnalités réalisées sous Libre Office Writer
Le suivi des tâches est ensuite réalisé avec un outil classique de gestion nommé Trac
Conclusion
Nous sommes revenus à distance chez le client (6 mois) pour évaluer la mise en place. Les équipes sont clairement satisfaites, la productivité a réellement augmenté et le champagne ainsi qu’un bon repas nous ont été offerts !
Vous souhaitez auditer vos équipes projets et co-construire une organisation performante ?
