MeetUp Lean IT Agilité : Theodo et Operae Partners
J’ai assisté à un MeetUp Theodo / Operae Partners très intéressant sur le Lean IT / Agilité le 4 avril dernier : voici la description du mode de fonctionnement qu’ils ont mis en place.
[Rappel] Une entreprise a deux objectifs : satisfaire les employés (et notamment en étant capable de leur proposer un parcours de progression), et satisfaire le marché. Ce sont les fondements de l’ensemble des éléments ci-dessous.
Lancement du projet agile
3 étapes importantes se distinguent pour le lancement d’un projet agile :
1) Former une équipe qui va résoudre un problème métier. L’équipe (Scrum Team) est mixte : un architecte, dix développeurs, des parties prenantes (Ops, Marketing, etc.), un product owner (qui écrit les users stories, challengé par les devs), un sponsor (1 fois / semaine, et un sponsorship élevé c’est mieux), et éventuellement un Directeur de Projet. La Scrum Team se colocalise sur un Plateau Projet avec un objectif : mettre en production auprès de l’utilisateur au plus vite et apprendre des uns et des autres en permanence.
2) Il faut définir correctement un problème business (exemple : on fait -2% de chiffre d’affaires par an) et définir l’objectif business en face, en miroir : augmentation du chiffre d’affaires de X, réduction des charges de Y, ainsi qu’un succès business (par exemple, monétiser) pour être capable de savoir à tout instant où on en est par rapport à la satisfaction client.
3) Il faut identifier des jalons (exemple : il est important de faire s’inscrire les patients sur l’espace patients). Un objectif business doit être SMART (par exemple, faire revenir le patient sur l’espace patient – engagement, ou encore monétiser à partir de telle date, etc.). Pour info, il s’agissait ici d’un projet d’un an et demi.
Déroulement du projet agile
Chaque fin de sprint est l’occasion de récupérer les feedbacks du client. L’équipe projet pose 4 à 5 questions au client :
1) Comment notez-vous de 1 à 5 la qualité de la prestation Theodo ?
2) Comment notez-vous de 1 à 5 la qualité de l’accompagnement Theodo ?
Si la note totale est inférieure à 8/10 : l’équipe projet doit réagir. Ils doivent demander au client quels changements et/ou améliorations prioritaires s’imposent et doivent obtenir une réponse – dans tous les cas -.
3) Avec une baguette magique, que souhaitez-vous changer chez Theodo ?
4) Seriez-vous prêts à continuer à travailler avec Theodo ? Oui bien sûr, Oui, Non.
En ce qui concerne le pilotage et la transparence, des burndown charts s’affichent (avec une moyenne sur les 3 derniers sprints pour la projection). Une demi-journée est consacrée au planning et à la rétrospective.
Le Sprint zéro a servi à :
- présenter la méthode,
- former les PO,
- découper les users stories (une fonctionnalité doit être inférieure à 1 person-day de développement),
- expliquer comment piloter l’équipe et driver le projet.
Une plateforme de validation est déployée tous les jours.
Si un problème survient, on dédie 15 minutes pour respecter le principe de transparence avec le client et pour proposer un plan d’action. L’action proposée doit être validée par l’équipe. On tient un tableau des problèmes avec la date d’identification du problème, sa description, l’impact quantifié en points par le client, l’analyse des causes (Go & See, 5 pourquoi, PDCA, etc.), l’action correctrice la plus simple, les dates des actions prises, les résultats attendus et la date de fin de problème. L’objectif ici est de protéger le client le plus vite possible.
Les 10 facteurs clefs de succès d’un projet agile chez Theodo
Chez Theodo, 10 standards sont en place. Si un seul de ces 10 standards n’est pas respecté, l’équipe considère que le projet a un risque d’échec non négligeable :
- J’ai un plan visible du sponsor pour atteindre le succès.
- J’ai 3 sprints détaillés d’avance.
- Mon payeur / sponsor erst venu à la précédente démo.
- J’ai fait tester mon user en production.
- Mon sprint est une réussite (points brûlés supérieurs ou égaux aux points prévus).
- Je n’ai aucun blocage dû à une dépendance extérieure.
- J’ai fait une mise en production automatisée (ssi numéro de sprint supérieur ou égal 2).
- Aucun défaut (régression, bug, user story mal écrite, mauvaise estimation, ticket bloqué, performance) pendant mon sprint.
- L’équipe technique est fière (pour toujours inciter à la transparence).
- Mon PO valide sur une plateforme à iso production : mêmes versions que la production. Les jeux de données représentatives de la production, inputs = cas de tests + users stories de qualité.
Merci à Théodo pour ce partage, à bientôt pour d’autres partages sur ce blog. Bonne journée, AG.
