Keynote - Industrialiser l'agilité
•Transferir como PPTX, PDF•
2 gostaram•1,056 visualizações
Les grands groupes sont en pleine transformation. Pour aller vite et impacter, certains choisissent de s’organiser comme les GAFAs et les startups, en petites équipes agiles. La transition est complexe pour ces groupes, dont la taille et l’organisation historique sont souvent des freins. Si l’effort nécessaire pour créer ces nouvelles équipes agiles est important, il est souvent récompensé par de premiers vrais impacts sur le business. Les organisations les plus avancées cherchent aujourd’hui à augmenter l’impact de ces "squads", à passer l’agilité à l’échelle. Comment une équipe produit peut rester agile en passant de 5 à 50 personnes ? Si la littérature est abondante, et de premières bonnes pratiques commencent à se dégager, nous avons décidé de nous pencher sur le sujet. Une keynote présentée en septembre 2018 lors de notre Business&Breakfast.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Keynote - Industrialiser l'agilité
Semelhante a Keynote - Industrialiser l'agilité (20)
Mais de Fabernovel
Mais de Fabernovel (20)
Keynote - Industrialiser l'agilité
- 2. 2Confidentiel © 2018 FABERNOVEL CODE Les grands groupes sont en pleine transformation. Pour aller vite et impacter, certains choisissent de s’organiser comme les GAFAs et les startups, en petites équipes agiles. - des entreprises en Europe ont déjà lancé un nombre significatif de projets en utilisant les méthodes agiles. Etude Neoma et Goetzpartners (2017) 50%
- 3. 3Confidentiel © 2018 FABERNOVEL CODE La transition est complexe pour ces groupes, dont la taille et l’organisation historique sont souvent devenus des freins. - Choc culturel Rapport à l’échec Expression du besoin Cycle de décision ...
- 4. 4Confidentiel © 2018 FABERNOVEL CODE Forts de trois ans de projets en mode 100% agile, nous pouvons partager avec vous quelques bonnes recettes garantissant de premiers vrais impacts sur le business. - 3 facteurs-clés de succès : - Recruter les volontaires les plus motivés de l’organisation, - Isoler cette équipe et la mettre dans une “bulle” (excubée si possible), - Hybrider l’équipe avec des artisans externes pour apporter leur fraîcheur. Retrouvez notre article Forbes sur les Corporate Startupeurs
- 5. 5Confidentiel © 2018 FABERNOVEL CODE Les organisations les plus avancées cherchent aujourd’hui à augmenter l’impact de ces squads, à passer l’agilité à l’échelle. - Pourquoi ? L’équipe doit sortir de sa “bulle”. Jusqu’ici protégée, elle ne peut plus agir isolément, dans son coin. - Le périmètre fonctionnel augmente ; - Souhait d’embarquer des développeurs de la DSI ; - Besoin de mutualiser les ressources tech.
- 6. Alors comment passer une équipe produit de 5 à 50 personnes tout en restant agiles ?
- 7. 7Confidentiel © 2018 FABERNOVEL CODE Notre conviction est que c’est un peu comme creuser un tunnel : deux parties doivent faire leur bout de chemin. - Strategic Agility Top-DownScale up Bottom-up
- 8. 8Confidentiel © 2018 FABERNOVEL CODE Quel est l’équivalent de la méthode agile “Scrum” pour s’organiser à 50 personnes ? Les méthodes abondent. - SAFe Less
- 9. 9Confidentiel © 2018 FABERNOVEL CODE … avec leurs avantages et leurs inconvénients. - SAFe LeSS
- 10. 10Confidentiel © 2018 FABERNOVEL CODE De notre côté, nous nous sommes intéressés au “Scrum@Scale”, édité par l’un des deux fondateurs du cadre “Scrum”. - Scrum@Scale is the framework for organizations to iteratively develop the best way for Scrum to work in their context. So I’ve kept it simple. The Scrum@Scale Guide is just a few pages.” (Jeff Sutherland)
- 11. 11Confidentiel © 2018 FABERNOVEL CODE Plus les équipes sont élargies, plus certaines contraintes vont émerger, liées à l’organisation historique du groupe. - Quand plusieurs squads apparaissent, des décisions doivent être prises au dessus : à qui appartient la customer journey ? Est-ce qu'il y a des business owners ? Etc. Les équipes divergent. Il faut en permanence qu'elles se ré- alignent.
- 12. 12Confidentiel © 2018 FABERNOVEL CODE Certains modèles d’organisation émergent et créent des contextes favorables à l’agilité. C’est ce que nous appelons la Strategic Agility. - L’organisation organique “à la Spotify” Les OKR de John Doerr (Intel, Google)
- 14. ALIGNER v.t [78] (lat.linea) Mettre une action, une attitude en conformité, en rapport avec une autre.
- 15. Agile Index © One index to rule them all!
- 16. 16Confidentiel © 2018 FABERNOVEL CODE Souvenez-vous : L’Agile Index © au niveau projet - TEAM Équipe auto-organisée Équipe co-localisée & outillée Équipe empowerée Culture lean & agile diffusée TECHNICAL Architecture moderne Urbanisme optimisé Stack adaptée Qualité maîtrisée VISION Problème et cibles cernés Proposition de valeur claire Mesure de l’impact définie Business Case validé DELIVERY Roadmap produit claire Production itérative Atterrissage maîtrisé Livraison continue MARKET FIT Data récoltée Feedback quali recueilli Utilisateurs onboardés Produit drivé par le marché
- 17. enjeux d’alignement à relever pour réussir son passage à l’échelle de bas en haut A L’ÉCHELLE
- 19. 19Confidentiel © 2018 FABERNOVEL CODE L'équipe est auto-organisée. Les rôles et responsabilités sont compris ; la pluridisciplinarité garantit l’auto- organisation. PROJECT LEVEL 1. Ré-aligner les individus sur le corporate purpose SCALED LEVEL Message LinkedIn de 3 collaborateurs HSBC certifiés Scrum.org
- 20. 20Confidentiel © 2018 FABERNOVEL CODE L'équipe est co-localisée. Dans un lieu connecté (tooling), favorisant la productivité, la créativité et la spontanéité. PROJECT LEVEL 2.Ré-aligner les espaces de travail à l’échelle de l’organisation SCALED LEVEL La Digital Factory de Thalès s’excube chez WeWork
- 21. 21Confidentiel © 2018 FABERNOVEL CODE L'équipe est empowerée. Dans sa “bulle”, elle a acquis les compétences. Elle est sponsorisée et a remporté l'adhésion de son organisation. PROJECT LEVEL 3.Ré-aligner le contexte startup sur le contexte corporate SCALED LEVEL CapLoc (devenu Youse) rayonne sur Medium
- 22. 22Confidentiel © 2018 FABERNOVEL CODE "If things are not failing, you are not innovating enough." Elon Musk 4. Ré-aligner culture et organisation SCALED LEVEL L'équipe a une culture lean & agile. Elle prône la transparence. Elle s'améliore en continu. Elle est orientée création de valeur pour le client. PROJECT LEVEL “
- 24. 24Confidentiel © 2018 FABERNOVEL CODE Le problème et les clients sont cernés. Le problème existe vraiment ; il est complexe et non résolu. Les clients sont écoutés et compris ; les early adopters sont ciblés pour lancer le MVP. PROJECT LEVEL 5. Ré-aligner les équipes sur une même définition du “client” SCALED LEVEL MAIF met le client au centre et nomme un CXO
- 25. 25Confidentiel © 2018 FABERNOVEL CODE La proposition de valeur est claire. La solution apportée au problème crée de la valeur pour les utilisateurs. PROJECT LEVEL Ré-aligner les équipes sur une proposition de valeur unique 6. SCALED LEVEL
- 26. 26Confidentiel © 2018 FABERNOVEL CODE 7. L'impact de la solution est mesurable. Des KPI sont définis ; ils permettent de prioriser l'effort et de savoir dans quelle direction aller face à l’aléas. PROJECT LEVEL Ré-aligner les KPI des équipes SCALED LEVEL Digital customer onboarding process ↘ Customer support call ↘ Customer support people
- 27. 27Confidentiel © 2018 FABERNOVEL CODE 8. Le business case du produit est validé. Les sponsors identifient un ROI clair et partagé (transaction, données, apprentissage, etc.) PROJECT LEVEL Ré-aligner l’entreprise sur la définition de valeur SCALED LEVEL ✓ ? ?
- 29. 29Confidentiel © 2018 FABERNOVEL CODE Ré-aligner le cadre corporate sur les enjeux data La donnée est collectée et analysée. Une stack analytics / growth marketing est en place sur le produit. Elle permet d’en mesurer la performance en continu à moindre coût. PROJECT LEVEL 9.SCALED LEVEL
- 30. 30Confidentiel © 2018 FABERNOVEL CODE Ré-aligner ceux qui font et ceux qui utilisent Les utilisateurs sont écoutés en continu. Leurs feedbacks sont recueillis ; les personae du produit mis à jour. Via ces retours priorisés, le produit est optimisé en continu. PROJECT LEVEL 10. SCALED LEVEL Des utilisateurs viennent régulièrement tester les nouveautés de leur produit
- 31. 31Confidentiel © 2018 FABERNOVEL CODE Les utilisateurs sont onboardés. L’activation des utilisateurs est maximisée grâce à un onboarding optimisé (features ; doc ; customer success mgmt). PROJECT LEVEL Ré-aligner le marketing sur l’ensemble des étapes du funnel AARRR SCALED LEVEL ACQUISITION ACTIVATION RETENTION REVENUE REFERRAL 11.
- 32. 32Confidentiel © 2018 FABERNOVEL CODE Le produit est drivé par le marché. Équipes (growth marketing) et produit travaillent main dans la main pour atteindre le product-market fit. Rôles, outils et rituels facilitent leur collaboration. PROJECT LEVEL Ré-aligner le marketing et le produit dans un cadre de travail collaboratif SCALED LEVEL 12. ?Marketing Produit
- 34. 34Confidentiel © 2018 FABERNOVEL CODE La roadmap produit est claire. Sa transparence permet à l’équipe de développement de participer à son élaboration. Elle est traduite en un product backlog priorisé, activable (ready) et unique. PROJECT LEVEL Ré-aligner les roadmaps produits13. SCALED LEVEL
- 35. 35Confidentiel © 2018 FABERNOVEL CODE Ré-aligner les rituels d’inspection et d’adaptation SCALED LEVEL La production est itérative. Les rituels garantissent l’itération. Il n’y a pas d’effet-tunnel. Le time-to-market est réduit et la valeur livrée immédiate. Le tout à un rythme soutenable. PROJECT LEVEL 14.
- 36. EMS Executive MetaScrum EAT Executive Action Team Vision sharing from a business perspective Top-down Impediment removal Bottom-up Scrum@Scale Framework
- 37. 37Confidentiel © 2018 FABERNOVEL CODE L’atterrissage est maîtrisé. Le time-to-market n’est pas une variable d’ajustement. L’équipe priorise le périmètre lui permettant de confronter la plus grande valeur possible aux utilisateurs dans les délais. Pour cela, elle ajuste son atterrissage en permanence. PROJECT LEVEL 15. Ré-aligner en permanence les équipes sur leur atterrissage respectif SCALED LEVEL
- 38. 38Confidentiel © 2018 FABERNOVEL CODE Le produit est livré en continu. L'infrastructure d'hébergement garantit le meilleur taux de service. La CI permet de livrer un incrément sur n'importe quel environnement à n’importe quel moment. PROJECT LEVEL 16. Ré-aligner le time-to-release sur le niveau d’exigence clients SCALED LEVEL
- 40. 40Confidentiel © 2018 FABERNOVEL CODE Coding L’architecture respecte les patterns modernes de développement. Le code est revu par toute l'équipe. PROJECT LEVEL 17. SCALED LEVEL Ré-aligner la scalabilité technique sur la croissance business
- 41. 41Confidentiel © 2018 FABERNOVEL CODE 18.Urbanisme L'application est correctement interfacée avec tous les éléments de son écosystème. PROJECT LEVEL Ré-aligner en permanence l’écosystème applicatif sur les meilleurs standards SCALED LEVEL APPLICATIONs
- 42. 42Confidentiel © 2018 FABERNOVEL CODE Stack technologique Les technologies employées sont en adéquation avec le scope fonctionnel visé et sont évolutives. PROJECT LEVEL 19. Ré-aligner en permanence la stack avec les standards marché et les aspirations des talents SCALED LEVEL {...}
- 43. 43Confidentiel © 2018 FABERNOVEL CODE Qualité Le code est documenté. La qualité est mesurée régulièrement. PROJECT LEVEL 20. Ré-aligner l’équipe autour d’une même exigence qualité SCALED LEVEL
- 44. Le passage à l’échelle est très complexe. Et vous, où en êtes- vous ?
- 45. WHAT’S NEXT ? Nous prenons la parole sur le sujet dans les semaines à venir.
- 46. erci PARIS 25, rue Drouot, 75009 Paris +33 1 42 46 36 44 TOULOUSE 17, rue de Metz, 31000 Toulouse
Notas do Editor
- Bench de titres d’événements On cuisine l’agilité Entreprise agile (trop large) Scale Up ! Passage à l’équipe Passer une équipe agile de 5 à 50 personnes Alignement Comment passer de 1 à 5 sprint rooms Comment passer un projet agile de 5 à 50 personnes. Agile Delivery in a large corporation Les 5 enjeux de l’agilité à l’échelle Tout le monde peut être agile Est-ce que l’agilité est scalable ? Et si vous deveniez vraiment agile ? Et si votre organisation devenait agile ? Culture Eats Strategy for Breakfast , You Should Eat Agile (For Lunch) Petit projet agile deviendra grande organisation agile Être agile... le destin de l’entreprise d’aujourd’hui https://www.cairn.info/revue-l-expansion-management-review-2009-1-page-118.htm
- Depuis 1 an, FABERNOVEL CODE accompagne ses clients au passage à l’échelle. Nous nous sommes forgé des convictions fortes et de premières bonnes pratiques.
- Pour parcourir ces enjeux d’alignement, nous avons opté pour une grille de lecture maison : notre Agile Index. Ça fait 3 ans. On a une base de data (fake it until you make it). Ce qu'on s'apprête à vous livrer, c'est notre retour d'expérience sur le 1er quartile de nos clients les plus performants
- PROJECT LEVEL SCALED LEVEL [Inspiration WattsOn] A l’échelle, le sentiment de responsabilité (accountability) diminue. Le cadre s’élargit et devient l’affaire de tous. De tous, et donc de personne. Le what finit par primer sur le why. Au long-cours, difficile de maintenir une équipe de développement motivée (?) => On le verra, c’est accentué par d’autres enjeux qui alimentent cette démotivation. De l’alignement doit renaître l’engagement (OKRs). La Direction Générale doit s’engager à rendre sa vision transparente.
- PROJECT LEVEL Souvent, elle est excubée dans un espace de coworking, ou chez un partenaire en Sprint Room. SCALED LEVEL [Inspiration ALM] A l’échelle, l’excubation ne suffit plus. L’organisation doit repenser ses espaces de manière globale afin d’offrir un nid aux Corporate Startupeurs en devenir. L’accès aux outils doit être repensé globalement comme un véritable Service Store.
- PROJECT LEVEL N/A SCALED LEVEL [Inspiration WattsOn] A l’échelle, rayonner pour remporter l’adhésion ne suffit plus. Jusqu’à alors protégée des impondérables du quotidien, l’équipe doit réintégrer son environnement et prendre en compte sa complexité. Les réorganisations successives ; les menaces concurrentielles ; les nouvelles régulation, etc. L’executive doit s’intéresser au cycle Scrum Mastering, et aider son organisation à éliminer les impediments. Elle doit agir comme une véritable Action Team. Une des solutions à apporter: favoriser le swarming.
- PROJECT LEVEL - Culture du client : les injonctions managériales ne priment pas sur feedback client - Culture de l’erreur : on n’a pas peur de se rendre responsable de KPI au risque d’échouer (HSBC) - Culture de la transparence : pas de codir en cercles restreint rendant opaque l’info. SCALED LEVEL A l’échelle, les contraintes historiques freinent la diffusion d’un état d’esprit Corporate Startup. L’organisation agile se structure en pensant output (périmètres historiques et intérêts politiques) avant outcome ; les grilles RH ralentissent la progression. La Direction Générale doit devenir elle-même une équipe agile ; le DRH doit s’engager à valoriser l’expérience autrement que comme synonyme d’ancienneté (l’impact et apprentissage avant tout !). Commentaires: Inspiration HSBC Inspiration ALM : les périmètres historiques et enjeux politiques prennent le pas sur le sens commun (design vs. front) Inspiration Youse : les aspirations personnelles prennent le pas sur le sens commun (UX vs. UI / product siloté) => Des silots se re-crée
- PROJECT LEVEL N/A SCALED LEVEL [Inspiration ENGIE : WattsOn et Vertuoz] A l’échelle de l’organisation, qu’est-ce qu’un client ? Comment se définit-il (contact, usage, transaction ?) ? Comment réconcilier les différentes définitions de “client” (sur le terrain ; au corporate ?) ? Des Customer Management Offices voient le jour, CXO en tête, afin de répondre à ces questions et ré-aligner les équipes sur une même définition du client. La première étape pour partager une vision, c’est avant tout cerner le problème et les clients qui le rencontrent. À l’échelle du projet, on étudie ces clients, on en a une définition qui est plutôt claire. On définit même des early adopters pour valider rapidement son produit. À l’échelle de l’organisation, on pense qu’il est essentiel de se reposer cette question car on a tendance à l’oublier : qu’est-ce qu’un client ? Quels sont les différents points de contact que nous avons avec lui ? Quels usages il fait de nos produits ? Comment réconcilier les différentes définitions de “client” (sur le terrain ; au corporate ?) ? Pour réaligner les équipes sur une même définition du client et donc répondre à ces questions, on constate que les entreprises se dotent de nouvelles practices dédiées au client. On nomme parfois un Customer XP Officer comme c’est le cas de la MAIF, qu’une équipe FABERNOVEL accompagne dans cette stratégie.
- PROJECT LEVEL N/A SCALED LEVEL [Inspiration HSBC] A l’échelle, les expériences client proposée manquent parfois de cohérence. On voit apparaître des Business Owners. A qui appartient la customer experience ? A l’inverse, plus l’équipe grandit, moins la proposition de valeur est partagée par tous. L’équipe ne peut y contribuer que faiblement dans ses choix de conception. Passage d’une logique produit à une logique clients. Répondre à ses besoins plutôt que proposer des produits. Une fois que l’organisation est alignée sur une même définition du client, il faut l’aligner sur la solution que l’on apporte à son problème, ie à la proposition de valeur unique. C’est un constat que l’on fait souvent quand on passe à l’échelle : le manque de cohérence dans l’expérience client. On voit apparaître des Business Owners qui gèrent leur produit de leur côté. Je prends l’exemple d’une banque qui va avoir un Business Owner sur la plateforme web, un sur l’application mobile, un sur le retail et un sur le centre d’appels. C’est un enjeu essentiel que d’avoir une proposition de valeur unique identique quel que soit le canal pour créer un max de valeur pour son client.
- PROJECT LEVEL Ex de défi : Définition du succès non imposée d’en haut => Deresponsabilisant. Eliminer la peur de se rendre responsable d'un KPI car peur d'échouer. SCALED LEVEL A l’échelle, les KPI de certaines équipes se superposent voire s’opposent. La valeur créée par l’organisation au global est réduite. - Superposent : HSBC Lead gen vs onboarding - Opposent : HSBC digital onboarding vs call center L’entreprise doit réaligner les indicateurs de performance des différentes équipes en partageant une vision claire et priorisée des objectifs à atteindre, tout en veillant à confier la responsabilité de résultats-clés à chacune d’entre elle afin de ne pas les déresponsabiliser. Plus les équipes grandissent, moins l’impact de chaque équipe sur la solution est perceptible. Il est essentiel de pouvoir mesurer l’impact pour non seulement engager les équipes mais surtout les aligner. L’enjeu va être de définir des KPIs qui responsabilisent chaque équipe et surtout qui soient complémentaires, qui ne se contredisent pas. Je prends un exemple que nous avons rencontré : une entreprise investit dans une équipe en charge de l’onboarding en ligne. Son KPI : le nombre d’appels au service client qu’elle doit réduire. Dans le même temps, la responsable du service client obtient du budget supplémentaire pour augmenter son équipe au centre d’appel. Bien aligner les indicateurs des équipes qui doivent aller dans la même direction.
- PROJECT LEVEL SCALED LEVEL A l’échelle, la valeur créée au niveau projet n’est évaluée que sous un angle financier (transactionnel) par les Directions Financières. Les notions de valeur et de risque doivent être repensés. Des approches small bets sont à favoriser. Pour terminer sur cet axe vision, le dernier enjeu majeur lorsqu’on passe à l’échelle c’est de ré-aligner toute l’organisation sur la définition de valeur. Quel est le ROI qu’on tire du produit ? Là, c’est intéressant de se poser la question : est-ce que mon ROI est uniquement business ? Chez FABERNOVEL, on pense qu’il n’est pas uniquement business. On vise un fort impact business, mais on vise également d’autres sources de valeurs : ça peut-être l’enrichissement de la data sur mes clients, ça peut-être l’appropriation d’une nouvelle stack technologique pour mes équipes, etc.
- PROJECT LEVEL SCALED LEVEL A l’échelle, le volume de données collectées explose. Un accès rapide aux données agrégées (dashboarding) devient clef pour maintenir un rythme de décision rapide. L’executive doit accepter de pérenniser une stack Growth Marketing non traditionnelle (saas) pour tester plus rapidement et valider les hypothèses. L’approche expérimentale High Tempo Testing doit être maintenue. Quand on passe à l’échelle, le volume des données que l’on collecte explose. Le problème, c’est qu’on peut rapidement s’y perdre, analyser les mauvais indicateurs, etc. Une des manières de cadrer cette data, c’est un accès rapide à cette data via du dashboarding. Il peut être à plusieurs niveaux suivant le public visé, mais il doit permettre une vue agrégée pour prendre des décisions rapidement. De plus, avec une petite équipe, c’est plus facile d’expérimenter, de tester rapidement des choses. L’expérimentation, avec notamment le High Tempo Testing, a tendance à se compliquer quand on grandit. Pour le faciliter, l’exécutif doit sponsoriser une stack/des outils peut-être non traditionnels mais qui permettent de tester plus rapidement et valider des hypothèses.
- PROJECT LEVEL La priorisation des feedbacks n’est pas optimisée : sentiment d’urgence pour chaque retour. SCALED LEVEL [Inspiration HSBC ; Youse] A l’échelle, les rôles se précisent ; les individus se spécialisent. L’équipe Marketing se considère comme le seul gardien de la connaissance client. Elle refuse de donner accès à ses clients. Une approche d’écoute des utilisateurs doit être industrialisée grâce à un framework d’interviews et testing facilement activable. Le Top Management doit s’engager à mettre le qualitatif au coeur de sa prise de décision (vs. quantitatif). Et ne plus faire passer ses intuitions sans être allé au contact des clients sur le terrain. En plus de récolter de la data/de quanti, vous avez besoin de récolter du quali afin d’améliorer votre produit. Ce qu’on appelle le Feedback Loop, écouter en continu ses utilisateurs. À l’échelle, les rôles se précisent dans l’organisation, les individus se spécialisent. On voit très souvent une équipe Marketing qui se considère comme le seul gardien de la connaissance client. De fait, elle refuse à l’accès à ses clients. Tout l’enjeu est ici d’industrialiser la rencontre avec vos utilisateurs grâce à un framework d’interviews et testing facilement activable. Je pense ici à un projet où nous avons systématiser la collecte de feedback quali via nos Sprint Reviews : on fait venir à chaque fois une quinzaine d’utilisateurs pour leur faire prendre en main le produit et les nouveautés, directement au contact des doers = des développeurs, des designers.
- SCALED LEVEL A l’échelle, les Corporate Startupeurs se heurtent parfois à une approche du marketing encore trop traditionnelle. L’acquisition et la notoriété priment ; les actions marketing n’influent pas sur toutes les étapes du funnel AARRR. L’activation (onboarding) - boostée par l’équipe produit - doit être reconnue comme servant directement le ROI des actions d’acquisition = faciliter les conversions des utilisateurs acquis. Les KPIs des équipes media/marketing - qui servent principalement l’acquisition - sont à réaligner avec ceux des équipes produit. Il faut s’imaginer qu’en moyenne le budget d’acquisition est 5 fois supérieur à celui de la rétention ! De micro-campagnes média doivent permettre aux équipes de procéder à des tests à petite échelle, afin de se rapprocher du Product-Market Fit. Sur un projet que j’ai accompagné, on avait mis le paquet sur l’acquisition. On avait des centaines de nouveaux clients chaque semaine qui pouvaient se logger mais aucun ne l’utilisaient car ils n’avaient jamais été onboardés. Ils ne savaient pas comment utiliser la plateforme. Pour y répondre, CSM = coût marketing. Garantir le succès des utilisateurs sur la plateforme = permettre leur activation et leur rétention.
- PROJECT LEVEL SCALED LEVEL In fine, on voit bien qu’il y a un risque de silotage entre les équipes growth marketing et produits lorsqu’on passe à l’échelle. L’enjeu est ici de ré-aligner leur cadre de travail - des rôles, des outils et des rituels - pour permettre aux équipes produits de maintenir un rythme de décision et d’expérimentation rapide, drivé par le marché. À vous de définir à l’échelle : comment permettre aux équipes produits de rencontrer des utilisateurs ? comment le marketing et les POs collaborent sur les prochaines expérimentations à faire ? A l’échelle, une organisation organique doit permettre à chaque équipe produit de maintenir un rythme de décision et d’expérimentation rapide, drivé par le marché.
- PROJECT LEVEL N/A SCALED LEVEL A l’échelle, les roadmaps se désalignent. Chaque Product Owner travaille sur sa roadmap = son Backlog. Son backlog ne reflète pas forcément la priorité business issue des retours qualis et quantis du produit. A l’échelle, la roadmap produit doit se traduire par un macro Product Backlog priorisé par la valeur. Cela n’est pas contradictoire avec une gestion jointe du RUN et du BUILD WattsOn > réorganisation en ft. Chaque PO est maître de son backlog. Chacun donne les priorités qu’il veut. Pas de vision partagée pour coordonner l’ensemble. L’impact est direct : les équipes sous-performent. La valeur délivrée n’est pas maximisée. Dans le Scrum@Scale, on appelle ce cycle de coordination le Meta Scrum. On s’est aligné sur le what => la valeur que je crée pour mes utilisateurs.
- PROJECT LEVEL N/A SCALED LEVEL Trop de dépendances entre les équipes (partenaires externes ; équipes pas sur le même rythme…) Mauvaise communication et donc synchronisation entre les équipes. => Mettre en place une Action Team, hors des équipes, dont le but est de débarrasser l’équipe des goulots d’étranglement et des blocages. => Lors des SoS et des rétros, un membre de l’Action Team est présent, et constitue le Backlog de l’Action Team. Objectif : se concentrer maintenant sur le how : comment délivrer un maximum de valeur le plus régulièrement possible. Rituels = la durée des sprints, le Scrum of Scrum. Projet où équipe back et équipe front sont désynchronisées. Pas la même durée de Sprint. Scrum of Scrum => les 2 flux qui structurent le S@S.
- L’avancement de l’équipe est suivi de manière quotidienne ou trimestrielle. L’atterrissage visé tient compte d’une vélocité empirique et d’un backlog raffiné en continu pour en garantir la maîtrise. Au niveau d’une équipe, on a un ttm fixe. Et on peut faire varier le périmètre. C’est la variable. On va prioriser. (priorisation). Échelle => plus complexe car dépendances entre les produits => périmètre est moins variable. Rendre transparent son atterrissage sur la base de l’empirisme est d’autant plus clé dans le contexte de dépendance. les aléas qu’ils rencontrent. On en revient aux rituels bien synchronisés. L’agilité c’est pas une recette miracle, rendre visibles plus rapidement les problèmes pour trouver des solutions. Par exemple, avec un TTM et un périmètre fixé, on peut ajuster le capacité de production donc ajuster les ressources pour délivrer un maximum de valeur. Ex : WattsOn.
- PROJECT LEVEL Au niveau d’un projet, livrer en continu est pour certains déjà un défi de taille. Les standards DevOps doivent être adoptés. Il s’agit d’automatiser l’ensemble des tâches manuelles récurrentes sur lesquelles le développeur n’a pas de valeur ajoutée, de la création d’une application à son exploitation. Concrètement, cela concerne par exemple : les déploiements, les merge. Le gain est significatif dans un projet en Agile : la fréquence des déploiements augmente et les livraisons sont continues ⇒ Meilleure atteinte des objectifs économiques de l'entreprise. SCALED LEVEL A l’échelle la situation se complexifie : 1/ Chaque équipe doit conserver son autonomie d’intégration continue. En d’autres mots : elle ne peut pas se permettre d’attendre que toutes les autres équipes soient prêtes à livrer pour elle-même livrer son incrément. Garantir cette indépendance nécessite d’améliorer significativement les standards DevOps. Pour les plus techniciens d’entre vous, cela passe par exemple par des déploiements automatisés au merge de pull request ou un roll back automatique en cas d’erreur 2/ L’infrastructure doit supporter un trafic bien plus dense Cela suppose également d’augmenter les standards d’infrastructures (monitoring serveur, analyse log, etc.) A nouveau, par exemple, pour les plus techniciens d’entre vous : il faut être capable d’augmenter la disponibilité des machines lors d’une grande opérations communication (spot TV).
- PROJECT LEVEL Qu’est qui rythme le quotidien des dev ? L’art de coder. On parle de “craftsmanship”. Chez CODE, on parle d’artisans. Au niveau projet, développer en respectant les patterns modernes de développement est un défi pour certains : Les utilisateurs sont de plus exigeants. Le marché s’accélère (certaines industries sont très menacées). Le nombre de standards s’est démultiplié ; ainsi que le nombre de techno. Le contexte de développement est de plus exigeant. En particulier, les standards de coding (PSR2, ES6, Design Pattern, etc.) doivent être respectés. SCALED LEVEL A l’échelle, cela se complexifie : Moins les standards sont respectés, plus l’application sera difficile à maintenir dans la durée. Faire évoluer à un rythme soutenu l’application - en fonction des retours du marché - exige un code aux meilleurs standards. Enfin, une équipe de développement qui grandit doit optimiser son onboarding : cela passe par une documentation à jour, mais aussi et surtout par le partage de standards de code communs au sein de l’équipe. Code agnostique : on ne doit plus retrouver qui est à l'origine d'un bout de code. Il faut sortir de la phase des 'héros' où un gourou de la tech qui serait le seul à maitriser tout un pan du produit.
- PROJECT LEVEL Au niveau projet, il est parfois difficile pour une équipe d’interfacer correctement son produit au sein de son écosystème applicatif : - En interne : Dans le pire des cas, l’interfaçage avec le SI est compliqué car ce dernier est veillissant, non APIsé. Dans le meilleur des cas, si les API existent, elles ne sont pas toujours fiables (instables), ni documentées. Il m’est arrivé de travailler sur un projet où la connaissance reposait sur 1 ou 2 personnes clés. - En externe : l’équipe est parfois dépendante de service-tiers sur lesquels elle n’a pas la main (ex : billetterie, prestataires de paimeent). Bref, le sujet complexe. SCALED LEVEL En passant à l’échelle, la complexité est d’autant plus forte : Le volume d’interfaçage se démultiplient dans les 2 sens (appli mobile, partenariat) ! Si le produit se situe au sein d’un écosystème dont les standards ne sont pas unifiés, c’est rapidement la catastrophe. La scalabilité et l’évolution du business renforce le caractère changeant du projet : il faut limiter au maximum les couplages forts avec les services externes. Prévoir une interface pour chaque service, pour faciliter le branchement/débranchement (Plug & Play). La gestion au quotidien d’un produit crée et consomme beaucoup d’éléments, plus ou moins “technologiques” ou connecté. Il faut sans cesse veiller à diminuer l’entropie de ces éléments lié au nombre de fonctionnalités et de personne qui vont interagir avec le produit L'objectif d'une démarche d'urbanisation est donc d'aboutir à une structuration du système d'information permettant d'en améliorer ses performances et son évolutivité. Elle permet ainsi de donner les moyens à l'entreprise de faire évoluer son système d'information en connaissance de cause.”
- PROJECT LEVEL Au niveau du projet, il est clef de choisir de stack qui correspondent au coeur de métier. Autrement dit, les choix techniques et technologiques (framework back ou front, infra…) découlent avant tout des enjeux business et de la problématique à résoudre. SCALED LEVEL À l’échelle, l’adéquation techno / métier ne suffit plus : Une fois qu’une équipe commence à scaler, la techno n’est plus à prouver. Elle est là. En revanche, 3 défis doivent être relevés : 1/ Il faut mettre à jour régulièrement la techno pour ne pas dépendre d’une techno qui se meurt à petit feu. Par exemple, Angular est passé de la version 1 à 6 en seulement 9 ans ! Cela exige un haut niveau de réactivité de la part des équipes. La version 1 n’a plus rien à voir avec la version actuelle. L’absence de mise à jour peut représenter d’importantes failles de sécurité. 2/ Il faut prendre en compte les tendances des talents en interne / sur le marché pour que la mise à l’échelle de l’équipe ne soit pas freinée par un manque de ressources. Plus la techno est vieillissante, plus il est difficile de recruter de nouveaux devs, et de trouver de bons prestas (pour de la TMA par exemple). Sans compter le fait de fidéliser les développeurs existant, constamment en soif de nouveaux défis techniques, sur un marché du travail extrêmement tendu… Conserver des artisans enthousiastes ! Ca va de pair avec un code capable de rester à jour pour éviter le sentiment d’enlisement. 3/ Enfin, la DSI, elle aussi a envie de vibrer. Elles sont souvent en demande pour faire évoluer leur propre Stack, qui leur est imposée historiquement (HSBC) => Impliquer la DSI dans l’Action Team pour ouvrir le champ des possibles technologiques
- PROJECT LEVEL Au niveau projet, investir sur la qualité n’est pas toujours une évidence. Pour certains Product Owners, c’est renoncer à passer du temps sur le développement de nouvelles fonctionnalités. La qualité est parfois reléguée au second plan, ou réduite au minimum. SCALED LEVEL À l’échelle, la quantité de code augmente de manière exponentielle, et non linéaire. 1/ Les tests manuels ne sont plus viables à une plus grande échelle. Pour limiter les régressions, des tests automatisés doivent être mis en place Il est nécessaire notamment d’avoir un meilleur taux de couverture (par exemple Youse : 70%) 2/ La devteam a besoin de KPI partagés et mesurés en continu pour s’aligner sur une même vision de la qualité technique. Ainsi, elle peut s’auto-organiser pour la maîtriser. Une approche “artisanale” (sans KPI) n’est plus viable à ce stade. 3/ Quand un produit grossit, la dette technique augment. Il faut s’imposer des standards de qualité pour la maîtriser et se réserver du temps d’amélioration continue du code (dit “Kaizen”).