Développement axé sur la mission

Au fur et à mesure que les entreprises se développent, la mise à l'échelle du développement de produits Agile devient plus difficile. Selon 52% des répondants du 13e rapport sur l'état de l'Agile, les différences entre la culture organisationnelle et les valeurs Agiles sont le principal inconvénient de leur travail.

Les dirigeants organisationnels peuvent tirer parti de la culture Agile pour améliorer le développement de produits. Une solide culture Agile implique l'autonomie de l'équipe dans l'approche de problèmes complexes, un travail en étroite collaboration avec les clients, ainsi qu'une vision et une stratégie à long terme.

Ces valeurs abstraites sont difficiles à évaluer et à engager. Dans une organisation, mettre en œuvre une stratégie efficace pour les exploiter devient un travail non trivial. L'approche Mission Driven Development (MDD) est passée des startups à mi-parcours comme une alternative pour développer une telle culture.

Défis de mise à l'échelle

Plusieurs modèles de ralentissement peuvent apparaître lors de la mise à l'échelle. La motivation des équipes peut diminuer avec des projets dont la fin n'est pas claire. Les chefs de produit peuvent se sentir perdus dans les réunions opérationnelles et ainsi perdre du temps à concevoir des parcours produits stratégiques. Le déploiement de nouvelles fonctionnalités et de nouveaux produits peut ralentir à mesure que les systèmes deviennent de plus en plus complexes.

Ces obstacles doivent être abordés d'un point de vue culturel et pratique. Les surmonter implique de renoncer au contrôle, d'accroître l'autonomie de l'équipe, de mettre en œuvre une transparence radicale et de mettre en place un cadre de développement de produits efficace pour générer des résultats.

Défis de la mise à l'échelle des cadres Agile traditionnels

Lors de la mise à l'échelle d'Agile, les niveaux de gestion et d'équipe doivent être synchronisés. Le niveau de gestion est responsable du développement de la stratégie de l'entreprise, de la création et de la communication de la vision du produit, de l'exécution des décisions de dotation en personnel et de la promotion du développement de l'équipe. Le niveau de l'équipe effectue les tâches nécessaires pour traduire efficacement cette vision et cette stratégie en produits et fonctionnalités de valeur.

Les cadres Agile traditionnels (XP, Scrum et Kanban) sont optimisés pour fonctionner au niveau de l'équipe, laissant les relations de gestion principalement sans réponse. Une nouvelle vague de cadres Agiles à l'échelle a évolué pour combler cette lacune, c'est-à-dire SAFe, LeSS, Scrum of Scrums, Nexus, DAD, etc. Cependant, ces approches nécessitent beaucoup de planification à mettre en œuvre et d'efforts à gérer et à entretenir.

Une approche légère, le cadre de développement piloté par la mission donne suffisamment de lignes directrices pour mettre en œuvre une structure robuste autour du développement à grande échelle et de l'exploitation des valeurs Agile.

Éléments de base du développement axé sur la mission

Missions

Le point de départ est Mission Découverte. Une mission commerciale prend du temps et des efforts et doit identifier un problème latent, un espace de solution et le résultat commercial souhaité. Lorsqu'elle est définie avec précision, une mission stimule la motivation, favorise la collaboration et favorise la recherche sur des espaces de conception plus larges.

Equipes

Les acteurs responsables de la réussite de chaque mission sont les escouades. En collaboration avec les chefs de produit, de petites équipes de 2 à 4 personnes mènent les activités nécessaires pour fournir des solutions qui correspondent à l'objectif de la mission et aux contraintes de temps.

Cycle de 6 semaines

Le délai de 6 semaines permet à toutes les équipes de suivre le même calendrier pour la planification de base tout en donnant suffisamment de temps pour fournir un résultat significatif.

Période tampon

Le cadre MDD comprend généralement une période tampon d'une ou deux semaines pour les intégrations et les déploiements finaux, la formation et le développement des compétences, les activités d'innovation et la planification du cycle suivant, entre autres.

L'importance du cycle de 6 semaines

Bien que la période de six semaines puisse sembler beaucoup pour certains praticiens Agile, elle contient plusieurs avantages importants.

Les équipes travaillant en cycles courts ont tendance à perdre leur engagement vis-à-vis de la vision du produit, car elles ont l'impression de cocher une «liste de blanchisserie» de correctifs, de bogues et de petites fonctionnalités. Cela menace l'autonomie des équipes pour explorer et choisir la meilleure façon de fournir des solutions.

Au fur et à mesure que les cycles s'allongent, la précision de l'estimation des produits diminue. Par conséquent, cela nécessite de lourds efforts de planification de la part des équipes de produits.

Six semaines ont été appelées la boucle d'or des délais de production, offrant suffisamment de temps pour fournir un produit minimum viable grâce à une réflexion innovante, un prototypage rapide et une livraison continue.

Le cycle de 6 semaines améliore encore l'engagement vis-à-vis de l'équipe en tirant parti de l'autonomie. La microgestion n'est pas nécessaire tant que les missions sont clairement énoncées et que les cycles sont suffisamment courts pour que les équipes se concentrent uniquement sur les résultats souhaités.

Enfin, les chefs de produit peuvent s'engager dans des activités de planification toutes les six semaines, en maintenant suffisamment de prévisibilité pour que les équipes restent sur la bonne voie vers la mission. Par conséquent, plus de temps peut être consacré aux dimensions stratégiques et exploratoires du développement de produits.

Mise en œuvre du développement axé sur la mission

Prenons, par exemple, une start-up à mi-parcours qui propose un produit B2B offrant une optimisation des prix du réseau qui augmente les revenus des clients grâce à l'utilisation d'applications d'intelligence artificielle. L'entreprise a récemment signé un nouveau cycle de financement, dans le but de se consolider en tant qu'acteur pertinent de l'industrie et d'augmenter sa part de marché de 300 %.

Dans ce scénario, il existe plusieurs défis de développement de produit :

• Comment obtenir les commentaires des clients actuels et potentiels pour valider l'hypothèse de valeur en attente ?
• Quelles fonctionnalités doivent être intégrées ou supprimées de la plate-forme pour une expérience utilisateur convaincante ?
• Comment la structure de gestion peut-elle être mise en place pour gérer la mise à l'échelle et tirer parti des valeurs culturelles pour accélérer la croissance ?

Au final, pour éviter les frameworks complexes, l'entreprise décide d'appliquer le framework Mission Driven Development. Dans Mission Driven Development, les détails du « dernier kilomètre » sont définis par chaque organisation. Les principaux éléments à définir sont :

• Mission découverte
• Structure de la mission
• Assemblage d'escouade
• Contrôle et adaptation
• Itération de tampon
• Planification des capacités

Mission Découverte

Le point de départ est Mission Découverte. Tim Herbig décrit la découverte comme le processus itératif de réduction de l'incertitude autour d'un problème ou d'une idée pour s'assurer que le bon produit est conçu pour le bon public. Avant qu'une mission ne soit engagée dans un cycle d'itération, elle doit être aussi complètement validée que possible.

Le processus de découverte de mission est mené par des équipes spécifiquement affectées. L'équipe de découverte est dirigée par le chef de produit et se compose de chercheurs de produits, d'analystes commerciaux et de concepteurs. Lorsqu'il existe plusieurs chefs de produit, ils rendent compte au Chief Product Officer (CPO), qui assure une vision commune à travers les produits, l'adéquation des produits et la stratégie globale de l'entreprise, ainsi que la livraison dans les délais.

Le point de départ recommandé pour la découverte de la mission est les défis, les problèmes ou les opportunités. Commencer par un défi, par exemple, aide l'équipe à explorer davantage d'espaces de conception, élargissant finalement les possibilités de solutions.

La validation de la mission implique plusieurs activités qui aident l'entreprise à mieux comprendre les besoins des clients :

1. Réalisation d'études de marché et d'analyses concurrentielles
2. Comprendre l'espace problématique dans lequel la mission est définie
3. Concevoir des croquis et des prototypes basse fidélité
4. Définir un périmètre clair pour la mission
5. Recueillir les commentaires et la validation des clients

Ces activités aident la mission à être une ligne directrice solide pour l'équipe de développement et garantissent que la valeur sera créée pour les utilisateurs.

En conséquence, certaines missions sont validées pour entrer dans le Mission Backlog, qui évolue en permanence avec les activités de découverte et la collecte de retours d'expérience.

Dans l'exemple, reprenons ce défi : quelles fonctionnalités doivent être construites à partir de la plate-forme pour produire une expérience utilisateur convaincante ? Une seule équipe de découverte, dirigée par le chef de produit, serait suffisante pour relever ce défi.

Supposons qu'actuellement, la plate-forme de l'entreprise exemple prend les données brutes du client et renvoie un réseau de tarification optimisé sur les fichiers de données traités. Cependant, la plate-forme UX n'a ​​pas été optimisée pour une expérience captivante. L'objectif à ce stade est de déterminer si la valeur client viendra de l'amélioration de l'UX, du développement de nouvelles fonctionnalités ou de l'amélioration des services de la plateforme.

Après une première étude de marché, la décision est de développer de nouvelles fonctionnalités. Les fonctionnalités candidates pour la plateforme sont :

• Retarification ultra-rapide
• Interface rapide et réactive
• Règles de retarification intelligentes et avancées
• Retarification et historique des ventes

À des fins de découverte, l'entreprise décide d'adopter une approche de sprint de conception : un processus de cinq jours pour répondre aux questions commerciales critiques par le biais de la conception, du prototypage et du test d'idées avec les utilisateurs. Le processus de découverte est exécuté pour chaque fonctionnalité candidate afin de voir laquelle créera plus de valeur pour les clients actuels et potentiels. La principale fonctionnalité sélectionnée pour le développement est les règles de retarification intelligentes et avancées.

Structure de la mission

Parvenir à une définition de mission solide n'est pas une tâche triviale. Il doit décrire un défi commercial clair et fixer des limites pour son résultat, tout en laissant suffisamment d'espace aux équipes pour arriver à une solution innovante et efficace. Une mission claire et précise :

• Indique clairement un défi commercial, après avoir identifié et délimité l'espace du problème.
• Synthétise toutes les informations et idées découvertes lors des phases précédentes.
• Liens vers un résultat commercial souhaité.
• Est axé sur les résultats, indiquant clairement l'image du succès de la mission.
• Est réaliste et réalisable dans le cadre du cycle de 6 semaines.
• Est suffisamment étroit pour garantir la mise au point et suffisamment large pour éviter les détails.

Dans l'exemple, après une semaine de découverte, les informations et les retours des utilisateurs ont été collectés et synthétisés.

Utilisateur cible : analystes de tarification client.

Espace problématique : les utilisateurs souhaitent pouvoir définir et gérer des règles de tarification intelligentes et avancées afin de pouvoir ajuster automatiquement les prix en fonction de certaines conditions.

Les conditions les plus précieuses pour les règles sont le prix du concurrent, l'urgence de l'expédition, le total de la commande, l'inventaire disponible et la remise pour les clients premium.

Insights : les règles doivent être appliquées dans les priorités personnalisées et être modifiables, si nécessaire.

Les analystes aimeraient voir facilement quelles règles s'appliquent à certains moments pour un produit donné.

Résultat commercial souhaité : augmenter l'engagement des utilisateurs sur la plateforme de 25 %, mesuré par le temps passé sur la plateforme.

Assemblée d'escouade

Le processus de formation de l'équipe est fait ad hoc pour chaque cycle de développement. Les principes d'autonomie et d'auto-organisation des équipes restent centraux. L'assemblage de l'équipe est guidé par un mélange de facteurs, allant de la complexité de la mission, des compétences des développeurs et des concepteurs, des intérêts et de la chimie de l'équipe.

Le processus de formation de l'équipe est facilité par des coachs Agiles. Avant toute décision, il est demandé à chacun quel type de travail il aimerait faire au cours des six prochaines semaines. Ensuite, sur la base de l'expérience, des connaissances et des compétences, des escouades sont constituées en s'assurant qu'elles possèdent les connaissances et les compétences nécessaires pour mener à bien la mission.

Les coachs agiles travaillent avec plusieurs équipes tout au long du cycle de développement, les aidant à lever les obstacles et les dépendances. Lorsqu'il existe plusieurs coachs Agile, ils rendent compte au responsable Agile, qui est responsable de l'assemblage de l'équipe, de l'amélioration continue et de la livraison des produits Agile.

La taille d'équipe recommandée est de 2 à 4 personnes : généralement, un concepteur et un ou deux développeurs, selon la complexité de la mission. Un ingénieur QA est considéré comme aidant une ou plusieurs escouades à atteindre les normes de qualité souhaitées.

Les équipes sont souvent mélangées après chaque cycle, afin que chacun puisse coopérer avec différentes personnes, diffuser ses connaissances et travailler sur différentes dimensions de produits, bien qu'une équipe très performante puisse travailler ensemble pendant quelques cycles.

L'équipe particulière de l'exemple doit prendre en compte les personnes ayant des capacités de conception d'interface utilisateur, de traitement de données et de visualisation de données.

Inspection et adaptation dans le cycle

La transparence, l'inspection et l'adaptation doivent être encouragées en permanence par les coachs Agile par le biais de pratiques Agile standard.

De courtes réunions hebdomadaires sont organisées pour organiser le travail et faciliter la levée des empêchements et des dépendances. Un toilettage est effectué, si nécessaire, pour s'assurer que les escouades comprennent parfaitement la mission et les user stories. De courtes rétrospectives sont menées à la fin de chaque semaine pour identifier et mettre en œuvre les changements et les améliorations.

Les pratiques de livraison continue doivent être maintenues tout au long du cycle. L'objectif de la mission pourrait être atteint plus tôt, car le cycle de 6 semaines est une approche basée sur la cadence pour établir des règles de base tout en aidant à atteindre la prévisibilité de l'équipe.

Une bonne pratique pour améliorer la transparence est une démonstration à la fin de la quatrième semaine, basée sur un jalon convenu entre les équipes et les chefs de produit. Le but de ces démos est de s'adapter, de réduire ou d'augmenter la portée selon les besoins.

Pour l'exemple de mission, un plan de release a été convenu entre l'équipe et le chef de produit dans quatre releases différentes :

1. Version 1 :
   • Nouvelle interface utilisateur de fonctionnalité de règle
   • Règles tarifaires des concurrents
2. Version 2 :
   • Règle d'urgence d'expédition
   • Règle du total de la commande
   • Priorités des règles
3. Version 3 :
   • Règle d'inventaire disponible
   • Règle d'application de visualisation
4. Version 4 :
   • Remise pour les clients premium

La version 3 est convenue comme démo pour la quatrième semaine. Comme les versions ont été réalisées tout au long du cycle de développement, le résultat commercial souhaité (dans ce cas, l'engagement des utilisateurs) doit être suivi dès le début du cycle de développement. Graphiquement, les progrès seraient attendus comme suit :

Période tampon

Prendre une ou deux semaines comme période tampon est une pratique reproduite par les implémentations de développement piloté par la mission, ainsi que par d'autres approches de mise à l'échelle telles que SAFe.

Dans SAFe, une itération d'innovation et de planification est effectuée à chaque cycle de développement. Il sert de sélecteur de contexte, permettant des processus et des activités d'exploration et d'innovation généralement laissés de côté par d'autres cadres axés sur la livraison. Exemples d'activités mises en œuvre dans cette semaine tampon :

• Intégration finale de la solution . Lors du déploiement vers la fin du cycle de 6 semaines, il est probable que l'intégration, la vérification, la documentation et la validation restent en attente. Le temps dédié permet d'assurer une intégration efficace et fluide des nouvelles solutions dans les produits existants.
• Planification et priorisation des missions . Les missions sont affinées, classées en petits ou grands lots et priorisées pour le prochain cycle de développement. Lors de la hiérarchisation des missions, certaines entreprises mettent en place des journées de pitch au cours desquelles les meilleures missions sont présentées à l'entreprise puis, de manière collaborative, engagées pour le prochain cycle de développement.
• Hackathons . Les hackathons ont gagné en popularité parmi les startups et les entreprises grâce à leur capacité à favoriser l'innovation, à créer une communauté et à développer de nouvelles connaissances et compétences de manière ludique. Les résultats sont présentés aux autres et deviennent des candidats pour le Mission Backlog.
• Développement de prototypes expérimentaux ou projets annexes . Il est courant de donner aux ingénieurs et aux concepteurs le temps de travailler sur ce qu'ils décident, tant qu'ils montrent le travail effectué à la fin du temps tampon.
• Travaux d'ingénierie . Des travaux d'ingénierie pure tels que le développement d'infrastructures, l'automatisation des tests, la réduction de la dette technique et les migrations de systèmes sont généralement effectués.
• Développement de nouvelles compétences et connaissances . Le rythme rapide de l'évolution des connaissances oblige les développeurs à se tenir au courant des tendances mondiales. Le temps tampon est adapté pour organiser des formations sur site, des communautés de pratique et des ateliers technologiques, entre autres.

Les périodes tampons doivent reposer sur les lacunes identifiées dans les connaissances, les objectifs d'innovation et les besoins pour le prochain cycle. Par exemple, une période tampon d'une semaine pourrait ressembler à ceci :

Planification des capacités

Au moment de décider de l'engagement de la mission pour le prochain cycle de développement, une pratique courante, selon le cofondateur de Basecamp, Jason Fried, consiste à identifier d'abord les petits ou les grands lots. Les gros lots font référence à de grandes caractéristiques ou fonctionnalités du produit, tandis que les petits lots font référence à des itérations ou des tâches plus petites. Dans l'exemple donné, la mission sélectionnée pour une nouvelle fonctionnalité pourrait être considérée comme un gros lot.

La recommandation ici est simple : ayez toujours un mélange de petits et de gros lots. Les petits lots sont des missions dont la durée est estimée à 3-4 semaines, et les gros lots peuvent prendre six semaines ou plus.

Si une équipe en petit groupe a accompli sa mission à la semaine 3 ou 4, la démo convenue est l'occasion d'évaluer si l'équipe doit continuer à travailler sur l'amélioration de la solution mise en œuvre, aider une autre équipe, prendre une nouvelle mission en petit groupe ou commencer travaux non planifiés.

Un bon mélange de gros et de petits lots empêche les gens de travailler à 100 % de leur capacité, leur permettant ainsi de manœuvrer et de s'adapter en cas de travail imprévu. Les équipes de gros lots obtiennent autant d'attention que possible pendant le cycle, tandis que les équipes de petits lots peuvent gérer des tâches ad hoc qui découlent d'un travail inattendu.

La combinaison de petits et de grands lots réduit également les risques. Le fait de n'avoir que de gros lots peut augmenter la probabilité d'un impact négatif sur l'expérience utilisateur. Si plusieurs nouveautés sortent à proximité les unes des autres, elles doivent être accompagnées d'une bonne gestion du changement. De plus, en cas de travaux non planifiés, il y aura moins de capacité disponible. Enfin, si plusieurs grosses équipes échouent, l'itération pourrait être ressentie comme improductive et ainsi démoraliser les escouades.

Risques du développement axé sur la mission

La mise en œuvre du développement piloté par la mission présente de nombreux avantages, mais comme tout cadre normatif, il comporte plusieurs risques inhérents qui doivent être pris en compte.

Portée de la mission

Les missions doivent être réalistes, viser une bonne adéquation entre la complexité du défi et les compétences de l'équipe ; sinon, l'impact sur les résultats de développement peut être significatif.

Une mission trop ambitieuse pourrait susciter de la frustration et de l'anxiété, ce qui aurait un impact négatif sur les performances de l'équipe. D'un autre côté, une mission sans enthousiasme pourrait entraîner la démotivation et l'ennui de l'équipe. Ainsi, une mentalité de produit minimum viable devrait rester constante dans le cadre.

Le pourquoi d'une mission

Les missions commerciales robustes doivent avoir une définition complète de l'espace du problème et de sa relation avec la vision de l'entreprise. Si cette relation n'est pas claire, des informations précieuses peuvent être perdues en raison d'un manque de compréhension de l'impact de la résolution des problèmes sur les objectifs de l'entreprise.

Piège cascade

Tomber dans un modèle en cascade pendant les six semaines est une tendance naturelle pour les équipes. Il y a deux facteurs principaux à cela. Premièrement, la pression pour le déploiement est plus forte vers la fin du cycle. Deuxièmement, les escouades veulent réduire autant que possible la portée d'une mission, ce qui entraîne une urgence à se déployer à la fin du cycle de développement. Par conséquent, les pratiques de livraison continue doivent être encouragées pour réaliser des versions Agiles tout au long du cycle et éviter les risques liés aux cascades.

Fonctionnement du produit

Les tâches d'exploitation du produit telles que la gestion de l'infrastructure, des services ou la surveillance des composants doivent rester en dehors du champ d'application des escouades, car elles pourraient avoir un impact sur la vitesse. S'appuyer sur des normes et des pratiques de développement telles que la conception atomique réduit les efforts de développement et accélère par conséquent la mise à l'échelle. Une autre pratique courante dans ce cadre est une équipe d'exploitation centrale qui gère l'infrastructure, en plus de gérer les opérations et la surveillance des produits.

Cycle de 6 semaines comme cadre myope

Certains scénarios ne seront pas adaptés au framework. Cela devient particulièrement vrai lorsqu'il s'agit de systèmes volumineux et complexes qui peuvent avoir un impact énorme sur l'expérience client, tels que les projets de R&D ou la migration de systèmes critiques.

Une option légère pour une mise à l'échelle agile

Faire évoluer Agile pour suivre le rythme du développement de produits et de la croissance de l'entreprise est un défi latent pour les praticiens Agile. En tant qu'approche Agile récemment développée, le cadre de développement piloté par la mission a gagné en popularité parmi les entreprises pour sa facilité d'utilisation et de mise en œuvre. Le cadre MDD met en mouvement un processus d'innovation produit transversal de bout en bout, de la découverte à la livraison, qui comble les lacunes présentes dans les structures Agiles traditionnelles. Mission Driven Development a le potentiel d'être le nouveau Scrum pour les entreprises en croissance.