Notes de l'éditeur

• 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”).