AgilePM Success story chez Smals
Karine est Project Leader & Team Leader chez Smals.
Elle est spécialiste des outils collaboratifs et est responsable du centre de compétences SharePoint de Smals.
Quelle est votre fonction actuelle, quelles sont vos missions ?
Je suis responsable du centre de compétences SharePoint chez Smals, l’organisation ICT commune des institutions publiques belges de sécurité sociale. Je suis chef de projets en charge de mener à bien les projets SharePoint qui nous sont confiés par nos membres.
Comment avez-vous connu Agile PM, quel était votre besoin initial ?
La formation Agile PM fait partie de notre catalogue de formation.
Je cherchais une méthode agile et je savais que l’approche SCRUM, aussi utilisée chez Smals, vise essentiellement à répondre au besoin d’organisation des équipes de développement.
Nous avions essayé de mettre en place cette approche sur les projets SharePoint mais cela n’avait pas été convaincant. Je cherchais une approche plus globale, intégrant aussi la gestion de projet, qui permettrait de mieux impliquer les représentants du métier sur nos projets, d’être certains de travailler sur des choses qui ont de l’importance.
Peu de temps après la formation vous avez géré avec succès un projet d’une certaine envergure. Pouvez-vous nous expliquer le contexte du double projet ?
Smals soutient et seconde les organismes du secteur social et du secteur des soins de santé – ainsi que d’autres services publics à leur demande – dans leur gestion de l’information afin qu’ils puissent offrir une prestation de services efficace et effective à leurs utilisateurs.
Smals met ses compétences à disposition pour être réutilisées dans le but de générer des effets d’échelle mutuels et une plus grande valeur ajoutée.
Le premier projet sur lequel nous avons appliqué l’approche Agile PM concerne une institution de la sécurité sociale belge qui cherchait à renouveler deux applications, qui existaient auparavant en Lotus Notes, en applications SharePoint.
Il s’agissait de deux gros projets pilotes (une application de gestion de demandes et un portail de communication interne), qui devaient en outre leur permettre de développer leurs compétences Sharepoint et leurs compétences en gestion de projet avec Sharepoint.
Nous avons mis en place l’approche de projet agile AgilePM avec ce membre et tout s’est très bien passé, nous avons été très satisfaits pour de nombreuses raisons. Suite à ma formation, j’ai formé un de mes collègues qui jouait le rôle d’architecte/ développeur/coach technique vis-à-vis du membre.
Le but était que cette personne développe et paramétrise un certain nombre d’éléments tout en travaillant avec l’équipe à former pour que les collaborateurs de cette équipe participent également au développement du projet. Nous avons briefé nos interlocuteurs business (business ambassador) et techniques (les développeurs) lors d’un même kick off pour les deux projets.
J’ai expliqué la méthode, quels sont les rôles et responsabilités de chacun, comment cela allait fonctionner et à la fin du kick off nous avons donné pour mission au business de faire une première version du backlog en décrivant leurs exigences et en les priorisant selon la technique MOSCOW.
Le challenge était de désigner 60% de l’effort total du projet comme étant des musts, ce qui est souvent difficile (souvent on obtient 70 voire 80% d’exigences en must au premier round).
Quelles étaient vos contraintes, vos challenges ?
Le premier challenge était celui du coaching, puisqu’une partie de l’équipe n’était pas mon équipe habituelle.
Ensuite mon deuxième challenge était de m’assurer que l’ensemble de l’équipe de projet suit bien, comprend les règles, la vision, les enjeux.
Un des développeurs, qui était par ailleurs très bon techniquement, n’était par exemple pas convaincu par la méthode AgilePM, il était un peu sceptique au départ, mais il a finalement joué le jeu et a pu constater que cette approche ne marchait pas si mal et que les relations avec le business se sont très bien passées.
Les clients ont d’ailleurs apprécié travailler en mode agile grâce à la méthode Agile PM, qui permet d’inclure beaucoup plus le business dans le projet et des décisions au jour le jour. Parfois, le business pense que quelque chose est simple mais le fait d’être impliqué lui permet de se rendre compte des difficultés réelles ; à l’inverse les développeurs comprennent mieux les besoins sous-jacents.
La méthode AgilePM permet d’avoir un dialogue en toute transparence et de faire les bons choix, sans que les équipes de développement ne s’acharnent sur des choses qui ne sont pas si importantes que cela pour le business.
Les clients attendaient que le projet aille vite et souhaitaient obtenir des résultats rapidement sans pour autant avoir fixé une deadline (ce qui peut être un piège puisqu’il est possible de mettre beaucoup plus longtemps que nécessaire).
Nous avons toutefois réussi à livrer rapidement et en 3 mois nous étions prêts à partir en production. Il y a eu des problèmes de performance réseau qui ont empêché d’être live comme prévu mais nous étions prêts. Nous avons simplement préféré attendre et résoudre le problème de réseau plutôt que de livrer un outil qui aurait été perçu comme peu performant, même si la cause était externe à l’outil.
Comment avez- vous implémenté la méthode ?
Après avoir réalisé le coaching et le kick off, nous avons mis en place des réunions de sprint review/sprint planning toutes les deux semaines pour chacun des projets, ce qui revenait à traiter un projet une semaine et l’autre la semaine suivante et ainsi de suite.
Il y a avait un des deux business ambassador qui participait d’office aux réunions de l’autre pour assurer une certaine consistance dans les décisions, vu qu’on travaillait sur la même plateforme technique. Tous les jours, il y avait également une réunion de standup de 15 minutes impliquant l’équipe de projet (interlocuteurs business et techniques).
Nous organisions un project board tous les mois d’une heure et cela suffisait pour suivre l’avancement du projet.
Il est important de ne pas trop rentrer dans les détails fonctionnels ou techniques durant les project board, mais de rester concentré sur le suivi du projet.
Une fois cette structure de suivi mise en place, le projet s’est déroulé tout seul ou presque !
A la fin du projet, nous avons réalisé un lessons learned à distance et le feedback du client qui est ressorti est qu’au départ ils n’avaient pas forcément bien compris ce qui avait été expliqué lors du kick off, ni pourquoi nous demandions certaines choses, mais au fur et à mesure tout s’est éclairci, ils ont compris pourquoi et la raison de l’intensité des efforts. Pour un prochain projet il faudrait être plus attentif à cette dimension là.
Le client n’était pas non plus conscient au départ de l’effort que cela allait lui demander de son côté. Être business ambassador est un travail à quasi temps plein et il faut pouvoir dégager du temps aux personnes qui reçoivent cette mission, pour qu’elles puissent mener à bien leur engagement.
Il y a un rythme de réunion à suivre, mais il faut aussi répondre aux questions de l’équipe de développement au jour le jour, participer aux tests, etc.
Comment la méthode AgilePM vous a-t-elle aidée ?
Quelle partie vous a été la plus utile ?
Le plus utile selon moi reste la technique de priorisation MOSCOW. Il y a une grosse différence entre classer les exigences selon un ordre (1-2-3-4-5) et accepter qu’une exigence qu’on estime tout de même importante ne soit finalement qu’un “should” qui peut-être ne sera jamais implémentée… parce que d’autres exigences passent avant.
La priorisation continue, c’est sans doute LE point le plus utile.
Naturellement il n’y a pas que cela, la méthode dans son entièreté est utile.
Avez-vous des conseils pour les professionnels du secteur ?
Il faut se former.
Je recommande de suivre une vraie formation avec un expert et non pas simplement de regarder, lire le livre et picorer des éléments en fonction de ce qui nous parle. J’ai suivi une formation en petit groupe de 4 ou 5 et cela m’a permis de bien comprendre la méthode, d’avoir des templates et de poser mes questions.
Personnellement sans la formation je n’aurais jamais lu tout le manuel en entier et je serais passée à côté des bienfaits de la méthode.
Un petit mot pour conclure ?
Récemment j’ai aussi suivi une formation DevOps et je vois que les deux s’articulent bien ensemble puisque la philosophie et la culture sont similaires.
Karine Picart
Karine est Project Leader & Team Leader chez Smals. Elle est spécialiste des outils collaboratifs et est responsable du centre de compétences SharePoint de Smals.
Suivez Karine sur Linkedin