« Lancer un projet agile » est une expression intéressante. Car en matière de « lancer », chacun a déjà une expérience…
En filant la métaphore, lancer votre projet doit se faire comme on lance un javelot, pas comme on lance un boomerang… Et nombreux sont les projets qui, quelques mois après un lancement avec tambours et trompettes, décrivent une trajectoire courbe non anticipée à la manière d’un boomerang, reviennent dangereusement vers les lanceurs avec leurs lots de problèmes humains, d’architectures, de dettes techniques, de scalabilité…
Nous allons passer en revue les éléments clés de la réussite d’un lancement de projet agile. Un projet agile n’est pas un projet flou ni improbable, ni sans engagement. Lorsque vous choisissez le mode agile, c’est que votre projet revêt une forme de complexité où les détails ne peuvent être tous prévus avec pertinence et économie de moyens, mais où il faut tenir le cap et embrasser le changement en livrant un maximum de valeur au métier.
Alors comment éviter de délaisser un mode classique, mais connu, où le lancement dure plusieurs mois (parfois plus de 6 mois), passe par plusieurs phases (opportunité, faisabilité, cadrage, consultation, spécifications…) et coûte une fortune pour in fine, basculer vers un mode agile qui parfois n’apporte pas les bénéfices escomptés et qui aboutit en de gros points d’interrogation : où va-t-on ? que fait-on ? Pour qui ? Avec qui ? Avec quel ROI ? Quelle architecture ? Quelle levée de risques ? Quelle évolutivité ?
Comment éviter de partir dans la mauvaise direction, d’oublier les choix structurants, de créer 3 mois de dettes techniques dès les 3 premiers mois ?
Si cela vous parle, alors, cet article est fait pour vous.
Avant de démarrer, on parle de quoi ?
- Lancement d’une idée (quelques jours) ?
- D’un POC (quelques semaines) ?
- D’un projet (quelques mois) ? D’un produit (quelques années) ?
Ici on va s’intéresser aux projets et aux produits.
Et qu’entend-on par “mode agile” ? … Une culture basée sur une croyance : dans un monde complexe où il faut répondre toujours plus vite de manière personnalisée à des besoins divers, il est difficile de tout prévoir longtemps à l’avance. Alors il faut modifier la manière de penser un produit, de le fabriquer, de le tester, de le déployer, de le faire évoluer…
Les 7 clés pour réussir un lancement de projet agile
-
Créez une équipe de candidats passionnés
L’équipe est importante. Trouvez les personnes qui ont envie de travailler avec vous sur votre idée de produit.
- Candidats : pour avoir des gens engagés
- Passionnés : pour avoir de la créativité, de la résilience, de la persévérance
Questions :
- Comment constituez-vous une équipe ? Nommez-vous les personnes ? Staffez-vous des “compétences” ? Des “ressources” ? Pitchez-vous votre idée et recueillez-vous des candidatures ?
- Comment faites-vous pour détecter s’ils sont passionnés ?
-
Assurez-vous d’avoir la bonne équipe :
- Comprenant une bonne proportion d’expérimentés, polyvalents, avec une bonne maîtrise de l’ingénierie agile. L’agilité n’est réelle que lorsqu’elle est poussée au niveau du code, des pratiques de design, de test et de déploiement. Sinon, on retombe vite dans le mode classique avec des post-its en plus… ;D
- éviter les rôles officiels “architecte / responsable tech / dev …”, les rôles vont émerger naturellement, avec un cadre bienveillant et maîtrisé par le ScrumMaster
- des équipes petites (3 à 5 équipiers techniques) et pas en silos de compétences
Questions :
- Sur votre dernier / prochain projet, avez-vous au moins la moitié d’expérimentés, polyvalents ? Y a-t-il des rôles “nommés” architecte, tech lead ou seulement un leadership qui émerge et que l’on décide de suivre ?
- Combien y a-t-il d’équipiers techniques qui conçoivent, codent, testent, déploient ?
- Mesurez-vous la dette technique ? À combien de jours de dettes êtes-vous après quelques mois ?
- Si vous avez plus de 5 devs fullstack dans une équipe produit, avez-vous essayé de réduire à 5 ? … Vous livrerez autant !
-
Partagez une culture de l’équipe
La culture de l’équipe sera la clé, car le succès ou l’échec dépendra en grande partie de l’humain…
- Une équipe se construit, ce n’est pas une collection d’individus ; cela prend du temps, passe par plusieurs étapes (Tuckman), s’entretient et se développe.
- Associer les premiers équipiers au recrutement des suivants
- Pas du chacun pour soi en silo avec uniquement des stars avec un trop gros ego et la culture agile, la culture du fail fast, learn fast, être certains qu’on est sur la même longueur d’onde, qu’on ne va pas s’identifier à son idée, qu’on va savoir pivoter…
- Croire que rien n’est impossible
- Être prêts à échouer, à apprendre qu’ils se trompent, à l’entendre, l’accepter, pivoter…
- Avoir plein d’idées
- Être à l’aise avec l’imprévu, l’incertain, l’aventure
- Être agnostiques et ouverts (pas prisonniers d’un framework…)
- Être assez expérimentés et formés au design et au build agile (XP)
Questions :
- Qui recrute les équipiers ?
- Y a-t-il des egos forts dans l’équipe (lead, archi…)
- Quand avez-vous pivoté la dernière fois ?
- Quelle amélioration avez-vous faite dans votre manière de travailler avec votre équipe sur les 15 derniers jours ?
- Votre Scrum Master et votre PO sont-ils exemplaires ?
- Quelle est la durée de vos sprints ? Tous les combien de jours faites-vous une amélioration (rétro avec décision) ?
- Combien de jours (fourchette) prend la livraison d’une story ? (En dehors du 1er sprint, êtes-vous entre 0,5 et 1,5 jh ? Pratiquez-vous le carpaccio ? )
-
Vérifiez si le projet/produit est attendu, s’il y a de la traction…
Inutile d’investir plusieurs centaines de jours sur une croyance pour s’apercevoir tard qu’on n’a pas adressé la bonne cible avec la bonne solution pour répondre au problème qui vaut la peine d’être résolu…
- Partagez la vision du projet/produit, pitchez votre idée, posez un Lean Canvas, GOOTB (get out of the building pour confirmer / invalider votre perception),
- Valider la VISION, que le PRODUIT a de la traction, que le PROBLEME vaut la peine d’être résolu (les gens essayent de trouver des solutions, mais aucune ne leur convient, ils sont prêts à payer X pour avoir une résolution de leur problème
- Vos outils : design sprint, POC… Les innovateurs qui pensent que « si Ford avait écouté le marché il aurait fait des chevaux dopés, pas des voitures…» n’ont pas compris comment Ford a fait. Certes il a trouvé l’idée, mais il l’a testée avant d’en vendre des millions…
Questions :
- Avez-vous un groupe d’utilisateurs finaux que vous consultez à chaque itération ? Livrez-vous en production aux utilisateurs avant 10 semaines puis toutes les deux semaines ?
Anti-pattern : développer pendant 3 ans un projet à 30 personnes, le présenter au moment de sa sortie aux commerciaux chargés de le vendre et s’entendre dire “ce n’est pas ce qu’attendaient nos clients, on ne peut pas le vendre”
-
Tracez grossièrement la route (VISION et roadmap)
Une fois rassuré sur la pertinence de votre idée de produit / projet, tracez grossièrement la route, à quelques mois et n’entrez dans les détails que peu de temps avant l’action. Gardez les options de pivot le plus longtemps possible (real options).
Considérez votre backlog comme un iceberg : n’affinez que la partie émergée (prochain sprint) et sans aller dans l’excès de description (restez 3C – card, conversation, confirmation et face à face // fuyez la spec détaillée de 2 pages ou plus et le “t’as qu’à la regarder, je l’ai mise dans Jira”))
Questions :
- Avez-vous une roadmap à 3 mois, 6 mois, 9 mois ? Est-elle très macro ou détaillée ?
- Avez-vous un plan de release (grosses epics des quelques itérations de la release) ?
- Quel est le niveau de finesse de vos demandes ? Centrées sur le bénéfice (afin de ) ? Précises sur la situation (je souhaite) voire sur la solution (avoir un champ,un écran comme ci…) voire la décomposition du travail (créer l’écran)
-
Mettez-vous en ordre de marche :
Échanger entre équipiers en travaillant au quotidien avec toute l’équipe (métier et technique) dans une même «war-room » : la communication ne passe pas à plus de 10 m… une équipe agile doit être solidaire, petite et proche pour avancer vite à plusieurs en même temps sans plan détaillé, mais en concevant le produit en avançant (architecture émergente), en réagissant aux imprévus, la communication est fondamentale.
Soyez prêts à passer en prod le premier jour !! Commencez par mettre en place une usine logiciel devops jusqu’à la production permettant de pousser un micro-incrément comme un « hello world » en production plusieurs fois par jour.
Créez un groupe de futurs utilisateurs et échangez avec eux au moins une fois par semaine pour éviter d’investir des centaines de jours de travail sans savoir si c’est ce qu’attendent les utilisateurs, il faut garder un contact le plus rapproché possible.
Questions :
- Votre équipe SCRUM (P.O. inclus) est-elle rassemblée dans une même war-room ?
- Avez-vous un “bureau des Product Owners” et un “bureau des développeurs” ?
- Commencez-vous par mettre en place un « Hello World » en prod avant de démarrer les développements ?
- Échangez-vous avec des utilisateurs sur une base quotidienne, hebdomadaire, de sprint, mensuelle, trimestrielle, semestrielle, annuelle ? Jamais ?
- Entre P.O. et équipiers de la même war-room, échangez-vous oralement ou par mail / Jira ?
-
Démarrez le cycle agile et visez un TTM (time-to-market) rapide
- Lancez-vous rapidement sur un premier incrément minimal (MVP) et démontrable, qui apporte une première valeur concentrée (pas de dilution, d’options, de fioritures) aux utilisateurs.
- Fabriquez un produit évolutif par assemblage de petits composants simples et interactifs et auto-testés, prêt à évoluer et à se réinventer sans cesse.
Questions :
- Et vous, quel est votre TTM ?
- À quelle fréquence mettez-vous en prod ?
- Votre produit est-il un assemblage de petits composants simples, interactifs et auto-testés ? Votre équipe pratique-t-elle le refactoring sur une base quotidienne ?
Voilà les 7 clés d’un lancement de projet agile. Pour en savoir plus, contactez-nous !
