Commencer dans le brouillard

Lorsque nous débutons une nouvelle aventure, nous avons en général trop peu d’informations pour élaborer une stratégie. Nous allons naturellement nous lancer, dans une direction aléatoire, puis ajuster au fil de l’eau, en fonction de ce que nous apprendrons en avançant. Nous développons notre stratégie au fur et à mesure. 

Dans le développement logiciel nous allons précisément élaborer une stratégie pour traverser l’incertitude inhérente à un environnement complexe. Si un plan trop vague est inefficace, un plan trop détaillé se perd dans des subtilités qui ne résistent pas à des frictions inévitables au moment de son exécution : il est fragile.

Les frictions sont tous les éléments imprévisibles susceptibles de contrecarrer le plan initial. Ils peuvent venir de l’environnement (météo, marchés, stratégie de l’entreprise, supports/canaux de communication, etc.) ou des personnes (intérêts, état de santé, biais, etc.).

Les frictions accroissent l’écart entre 

• les connaissances attendues, que nous pensons acquises, et celles assimilés ;
• les actions attendues, supposées, et réalisées ; et
• le résultat attendu, supposé et obtenu.

Dans ces conditions, chercher à accumuler plus de connaissance, de planifier plus d’actions et/ou de façon plus détaillée, ou fournir plus de détails sur les résultats attendus créent encore plus de confusion, car le problème survient au moment de l’exécution : la divergence est inévitable, elle sera juste accrue par l’accumulation d’informations.

L’inconnu (nous ne savons pas exactement quoi faire, comment faire) entraine la spéculation (nous bâtissons un modèle complet sur nos hypothèses), qui entraîne à son tour la confusion (nous constatons une divergence avec le résultat attendu, nous ne sommes pas en mesure de respecter les délais, etc.).

Modèle Cynefin : dépend de l’environnement et de l’expertise. 

• Clair : pas de surprise pour qui que ce soit => raisonner, catégoriser, répondre, et créer un plan détaillé et une voie dégagée.
• Compliqué : peu de surprise avec assez d’expertise => raisonner, analyser, répondre, puis progresser par itérations, en se basant sur l’expertise pour réduire l’inconnu.
• Complexe : fréquentes surprises, peu importe l’expertise => examiner/expérimenter, raisonner, répondre : nous expérimentons avant de planifier, puis nous affinons notre planification au fil des leçons apprises.
• Chaotique : état constant de surprise => agir sur la base d’hypothèses, raisonner / mettre à jour les hypothèses / analyser, puis répondre.
• Confusion : on ne sait pas dans quel domaine nous nous trouvons => prendre du recul, analyser, expérimenter pour identifier le domaine.

L’environnement pour un produit est d’autant moins hétérogène qu’il nécessite plus de domaines d’expertise, et donc d’interactions avec des personnes à l’expérience variable (voir même : des domaines pour lesquels personne dans l’équipe n’a d’expérience).

La mauvaise approche : la voie paraît claire et limpide => nous planifions les moindre détails => nous rencontrons un obstacle => persuadé d’avoir mal anticipé, nous approfondissons encore plus nos plans en pensant maîtriser la solution => nous nous enfonçons dans nos certitudes, réduisant encore plus notre souplesse face aux imprévus qui ne manquerons pas de survenir à nouveau.

Le danger survient quand nous pensons être dans un domaine compliqué, alors qu’il s’avère complexe : nous aurons tendance à planifier sur la base de nos spéculations, qui vont au final s’avérer fausses et nous amener dans une mauvaise direction … Et plus on planifie à l’avance, plus loin nous irons, avant de nous rendre compte que la direction est mauvaise.

Une approche humble consiste à commencer par admettre ce qu’on ne maîtrise pas, pour expérimenter et progressivement clarifier la voie à suivre. C’est un plan qui paraît plus faible, mais qui s’avère à terme plus robuste, car nous l’enrichissons et complétons au fur et à mesure. À ce niveau, Scrum est parfaitement adapté, car il est conçu pour apprendre et approfondir son plan au fil des itérations.

Guider par l’intention

L’entreprise doit fournir un cadre où les intentions sont claires, avec suffisamment de marge de manœuvre, où la prise de risque et la prise d’initiatives sont récompensés. Sanctionner les erreurs réduit drastiquement la prise de décision et d’initiative.

Remarque : ça ne veut pas dire que l’auteur n’a pas à assumer les conséquences de son erreur, mais inutile de l’enfoncer, et au contraire l’aider à comprendre l’erreur, pour l’aider à progresser.

Les équipes et membres de l’équipe ne devraient jamais avoir à attendre l’intégralité de l’information pour commencer à agir.

Pour permettre à l’équipe de commencer à agir, à prendre des initiatives sans punir l’erreur, mais sans laisser passer la médiocrité, le responsable doit soumettre son intention, c’est-à-dire un objectif de valeur à atteindre, et pourquoi cet objectif est pertinent. L’objectif de valeur à atteindre peut se traduire par l’état attendu en sortie. Concrètement, c’est le parcours utilisateurs (« quoi »), avec le résultat final (« pourquoi »), quelles sont les actions que l’utilisateur veut réaliser, et pourquoi.

Remarques :

• L’objectif de valeur consiste donc au comportement attendu du point de vue de l’utilisateur, sans imposer la façon d’y arriver à l’équipe qui va être en charge de la solution.
• En fixant un délai de réalisation, cela donne le cadre complet pour aider l’équipe à déterminer la meilleure solution susceptible de se rapprocher le plus de l’objectif dans le délai imparti (typiquement, le délai sera le sprint).

L’écart de connaissance : il se réduit si les experts disposent de nos intentions et peuvent se concentrer sur leur domaine d’expertise, expérimenter des solutions, et cibler la bonne. 

L’écart d’alignement : il se réduit avec des objectifs exprimant clairement l’intention, les experts savent dans quelle direction faire évoluer les choix techniques (l’objectif devient le phare et pas un chemin imposé).

L’écart sur les actions : il disparaît dans la mesure où les experts en sont directement responsables, et peuvent librement choisir les actions susceptibles de mener au mieux à destination.

Idée :

• « En tant que [profil], sachant que [prérequis], je souhaite [liste_détaillée_des_actions], afin de [résultat] ».
• Décrire de la sorte chacun des parcours alternatifs de l’initiative (avec priorisation des actions à traiter, voir plusieurs niveaux d’aboutissement sur les actions/parcours).
• Travailler le découpage et les dépendances avec les devs.
• Planifier les actions prioritaires / dépendantes à traiter dans le premier sprint. S’il y a trop d’inconnues, identifier les sujets techniques les plus critiques (à la fois les plus complexes techniquement et sur le chemin des actions les plus importantes à traiter) et commencer par des tâches d’exploration. 
• Faire la conception technique et l’implémentation des actions / tâches d’exploration prévues au premier sprint.
• Faire le point à la fin du sprint pour voir si on a assez avancé pour livrer de la valeur à l’utilisateur et/ou si la suite à traiter a une priorité plus haute que les autres initiatives à traiter.
• Remarque : à voir avec les idées en annexe à « User Story Mapping » de J. Patton.

Les objectifs

Les objectifs permettent d’aligner les personnes et les équipes entre elles. Les objectifs doivent également être partagés avec les clients, pour s’assurer que tout le monde travaille dans le même sens.

Des objectifs partagés sont particulièrement importants lorsque les équipes sont organisées selon des domaines distincts. Sans ça, chaque équipe tendra naturellement à prioriser ses propres objectifs, au détriment des urgences des autres, amenant les différentes équipes à développer des solutions de contournement… Pour faciliter la collaboration, les différentes équipes doivent partager une feuille de route commune, avec des objectifs communs, pour garantir l’alignement global.

Au sein d’une équipe, l’objectif permet de valider que les membres de cette équipe sont bien en train de travailler sur le même produit : une somme d’individus, chacun sur son sujet, n’aura pas d’objectif commun. Et sans objectif commun, Scrum n’apportera rien à l’équipe.

Pour Scrum, il s’agit de l’objectif de sprint, tandis que les équipes doivent être alignées sur leur objectif produit.

Scrum et les objectifs

Remarque : Scrum fonctionne en itération dont l’objectif est de livrer un incrément fonctionnel du produit. Ce n’est pas une fatalité en soi s’il n’est pas fonctionnel, vu qu’on parle d’expérimentation. Par contre, il faut garder à l’esprit que seule la valeur livrée au client, satisfaisant les besoins des utilisateurs, répond aux objectifs de l’entreprise pour avoir de quoi investir (et payer les salaires).

OODA :

• Observer : collecte de retours et d’informations issues de l’environnement. Alimente la phase d’orientation.
• Orienter sur la base de la donnée et des habitudes (culture, intuitions, expériences passées, nouvelles informations, analyses). Guide et contrôle l’observation (l’approche et l’analyse des fruits de l’observation). Alimente la phase de décision.
• Décider, ce qui implique d’émettre et soumettre ses hypothèses, pour l’action.
• Agir, et tester les hypothèses. Les résultats vont alimenter les observations.

Leitmotiv : lead + motive, guider et motiver. L’objectif de sprint est le leitmotiv de Scrum : il revient à chaque événement, et connecte les sprints entre eux, et sert de base pour vérifier le gain de valeur que va apporter l’incrément du produit.

Scrum définit la structure d’une équipe autour d’un produit, et plus particulièrement de l’engagement de cette équipe à la réalisation de cet objectif, par l’ajout de valeur à l’adresse de l’utilisateur. La notion de valeur ici insiste sur l’adéquation de la réponse au besoin, ensuite à sa qualité, plutôt que la quantité.

Scrum encourage la transparence, de sorte à faciliter au maximum l’alignement des parties prenantes.

L’objectif de sprint concrétise l’engagement que prend l’équipe pour un sprint donné. Il peut correspondre à un objectif produit, si celui-ci est assez petit (Remarque : cf. OST et Story Mapping), mais en général, l’objectif produit donne une vision à plus long terme et sert de guide pour définir le prochain objectif de sprint. Sur la base de l’objectif produit, on va définir des épopées, qui pourront être re-découpées en récits utilisateurs en phase avec l’objectif du sprint, et pouvant être réalisé sur le sprint.

La façon dont sont réalisés les objectifs de sprint fournit également des retours sur l’objectif produit, et éventuellement le retravailler. Les retours quotidiens aident à garantir l’alignement de l’équipe sur la compréhension, les actions et la réalisation de l’objectif, tandis que la retrospective permet de travailler sur la façon dont sont organisées les retours quotidiens et l’organisation du sprint en général.

Les objectifs du produit et du sprint permettent d’exprimer et détailler l’intention du responsable pour son produit : pour qui et pourquoi il est important, qu’est-ce qu’on espère apporter.

Lorsque l’objectif du sprint est clair, ne pas traiter l’intégralité des tâches prévues n’est plus une fatalité, car nous avons pu nous assurer que celles apportant le plus de valeur (par rapport à l’objectif) ont été traitées en priorité. Si l’équipe sait exactement pourquoi il doit réaliser cet objectif, elle a alors toutes les cartes en main pour proposer le meilleur plan menant à la meilleure solution pour réaliser l’objectif, et sera capable de s’adapter aux frictions sur le parcours (i.e. gérer l’inconnu).

Scrum définit une base rigide (rôles, rituels et artefacts) afin de favoriser l’expérimentation sur le reste. La logique voudra donc que, après avoir fixé l’objectif, nous planifions le minimum de tâches. Celles-ci doivent être spécifiques et prioritaires pour cet objectif (humble dans la planification), afin de laisser la marge nécessaire à l’imprévu (complexité inattendue, problèmes en production, aider d’autres équipe, problème de dépendance, etc.).

Remarque : dans la pratique, nous devons adapter la charge de chaque sprint en fonction du degré de confiance sur les tâches à traiter, et le travail de conception ne doit pas avoir pour but d’éliminer les doutes, mais de cerner les zones d’incertitude pour être en mesure de déterminer un niveau de confiance (sur chaque tâche).

L’objectif de sprint permet de créer de la valeur

L’objectif donne le quoi (quelle valeur apporter), le pourquoi (en quoi cela à de la valeur) et pour qui (quel client). Le sprint oblige à se fixer un moment où nous devons livrer quelque chose qui apporte de la valeur; ce qui apporte de la valeur, c’est quelque chose qui arrive entre les mains de l’utilisateur, et les retours qu’il nous donnera alimenteront la prochaine itération. Bien que l’équipe doive être pluridisciplinaire, nous ne sommes pas obligés de solliciter tous les métiers sur un sprint donné.

SMART et FOCUSED

Smart :

• Smart : clair et parfaitement maîtrisé par l’équipe.
• Mesurable : des indicateurs permettent de mesurer la progression.
• Achievable : réaliste, c’est quelque chose de faisable dans le produit et dans le délai imposé.
• Relevant : pertinent pour le client, l’utilisateur, cohérent avec le reste du produit.
• Time-oriented : respect du délai fixé pour la réalisation.

Focused :

• Fun : mémorable, la cerise sur le gâteau grâce à laquelle l’équipe prendra du plaisir à réaliser l’objectif.
• Outcome oriented : la valeur plutôt que le plan.
• Collaborative : impliquer toute l’équipe dans l’élaboration de l’objectif, partager la compréhension et l’attrait contribue au bon résultat.
• Ultimate : pousser la compréhension du besoin (le pourquoi) au maximum donne le maximum de liberté à l’équipe pour atteindre le meilleur résultat possible, y compris si une meilleure solution est trouvée en cours de route.
• Singular : un seul objectif pour toute l’équipe.

FOCUSED à ceci de plus par rapport à SMART qu’il insiste sur l’engagement et l’implication de l’équipe dans la réalisation de l’objectif.

À chaque daily stand-up, l’équipe mesure sa progression par rapport à l’objectif du sprint et remonte les difficultés rencontrées. Il est alors possible de créer de nouvelles tâches dans le sprint, spécifiquement pour traiter ces problèmes. 

Remarque : un sprint commençera avec un objectif de sprint, les récits utilisateurs correspondant à cet objectif (par ordre de priorité), leurs tâches techniques déjà identifiées, éventuellement quelques tâches d’amélioration continues et/ou bugs à corriger (en fonction de la charge du sprint). En cours de sprint, nous pouvons ajouter de nouvelles tâches techniques aux récits utilisateurs, ou des bugs critiques identifiés en production.

Fin de sprint, début du suivant

1-2-4-all : en fin de sprint, réunir toute l’équipe pour réfléchir au prochain sprint. Cela nécessite de la confiance au sein de l’équipe, et une bonne maîtrise de l’objectif de sprint précédent et de l’objectif du produit (pas seulement des enjeux techniques).

1. 1 minute pour réfléchir chacun à une idée,
2. 2 minutes, 2 par 2, pour faire émerger une idée pour 2,
3. 4 minutes pour faire émerger une idée pour 4, et
4. 5 minutes où tout le monde discute des idées qui ressortent.

Revue de sprint :

1. évaluer la valeur apportée par le sprint,
2. inspecter la qualité de l’incrément,
3. adapter si nécessaire, et
4. réfléchir à la prochaine étape.

La revue de sprint rassemble les différentes parties prenantes, potentiellement avec des attentes différentes, et plusieurs objectifs importants en tête. L’équipe aura toujours à minima un objectif produit, et devrait avoir au moins une base de réflexion sur l’objectif du prochain sprint. Les parties prenantes doivent être conscientes que l’objectif sera retravaillé par l’équipe pour garantir la livraison de valeur en fin de sprint.

Planification de sprint

En planification de sprint, l’équipe va affiner le brouillon de sprint élaboré avec les parties prenantes, en prenant en compte les contraintes techniques. La question sera donc de déterminer ce qu’il est possible d’implémenter durant le sprint pour pouvoir livrer le maximum de valeur possible, par rapport aux attentes des parties prenantes (l’objectif discuté en revue de sprint). Il sera possible de réajuster l’objectif de sprint afin qu’il reflète mieux ce qui sera implémenté durant le sprint.

Remarque : en travaillant sur des releases « candidates » à chaque sprint permet de valoriser les retours de revue de sprint, et de les exploiter dès le prochain sprint. La « golden » release (l’incrément) arrive alors tout les « n » sprints (maximum : on doit s’imposer des livraisons régulières pour être capable d’apporter un minimum de valeur régulière, tout en s’autorisant une livraison plus rapide, si le contenu apporte beaucoup de valeur), avec le contenu validé en revue de sprint.

Rétro de sprint

La rétrospective est l’occasion de se demander si notre façon de travailler nous a permis de créer de la valeur avec les fonctionnalités que nous avons livré, de chercher qu’est-ce qui nous a entravé dans les processus et dans l’organisation, et de réfléchir à des solutions à expérimenter pour faire évoluer notre organisation. La rétrospective est également l’occasion de revoir l’objectif produit, et éventuellement le réajuster, voire le changer, pour accroître l’apport de valeur.

Il ne faut pas craindre d’échouer à livrer de la valeur à chaque itération. L’essentiel est d’avoir pu expérimenter, et surtout appris à chaque itération. Ces apprentissages vont alors alimenter les décisions techniques et fonctionnelles sur le produit, et ainsi progressivement réduire l’incertitude, ce qui réduit les frictions, et favorise le développement du bon produit, répondant au bon besoin.

Chaque fonctionnalité livrée constitue une expérimentation. Nous ne pouvons pas garantir qu’elle apporte de la valeur tant que cela n’a pas été prouvé. Ce n’est qu’une fois exposée aux utilisateurs, que nous aurons obtenu et analysé les retours sur son utilisation, que nous obtiendrons des évidences de la valeur qu’apporte (ou non) cette fonctionnalité.

Trois domaines d’incertitudes dans la définition de l’objectif de son produit :

• La valeur, c’est-à-dire « Pourquoi » faire le produit.
• Quel produit va répondre au besoin.
• Comment construire le produit, quels moyens mettre en œuvre.

Sur la valeur : la notion de valeur contient une part de subjectif. Elle n’est pas prédéterminée, mais nécessite d’être à l’écoute des clients et utilisateurs et d’expérimenter. Les deux combinés permettent de voir concrètement qu’est-ce qui marche et d’itérer.

• La valeur est une notion relative à la perspective de l’acheteur.
• Marketing -> créer des preuves sociales du bénéfice.
• Démarrer avec une idée, identifier qu’elle partie fonctionne bien, et être prêt à pivoter (changement radical de stratégie) pour atteindre le public.

Imaginez que vous deviez choisir entre deux chansons : la chanson A, écrite en 10 minutes, et la chanson B, écrite en un mois. Laquelle choisiriez-vous ? L’une des chansons les plus célèbres du musicien John Denver, “Annie’s Song”, a été écrite en 10 minutes environ alors qu’il était assis dans un télésiège à Aspen. La relation entre effort et valeur est pour le moins trouble. » Même pour le coup de la « valeur travail » les dés sont pipés. Certes l’expérience joue, mais c’est définitivement la réception du produit/service qui déterminera sa valeur.

Mesurer la satisfaction des utilisateurs permet de mesurer la valeur que leur apporte le produit. Mesurer l’engagement des clients permet de mesurer le bénéfice qu’il apporte à l’entreprise.

Remarque : attention à la courbe d’apprentissage (trop difficile à prendre en main induit perte d’utilisateurs)

Le canvas de l’étoile polaire

L’étoile polaire est une métrique unique reflétant à la fois les bénéfices des clients, des utilisateurs et de l’entreprise. Elle sera alors alimentée par un ensemble de métriques choisis spécifiquement parce que nous pouvons agir dessus (via l’organisation de l’équipe, ou les choix techniques et fonctionnels du produit). Ces métriques seront ensuite la base d’initiatives, des objectifs pour le produit, et des épopées et récits utilisateur qui seront traités par l’équipe.

Si besoin, il est possible de construire une arborescence de métriques entre les épopées/récits et l’étoile polaire, puis d’expérimenter sur ces métriques pour voir quand et comment elles agissent positivement sur notre étoile polaire. Les métriques intermédiaires ont l’avantage qu’elles seront directement impactées par les évolutions du produit, tandis que l’étoile polaire aura une évolution plus lente. D’autre part, suivre en parallèle l’impact des métriques sur l’étoile polaire, et celle des épopées et récits sur ces métriques permet de se construire progressivement une base robuste et une source de confiance dans les décisions prises avec les parties prenantes.

En gardant une liste de tâches, portant sur des problèmes à étudier, la plus courte possible, la priorisation devient à la fois pertinente et simple à mettre en place. La priorisation doit se reposer au maximum sur la valeur apportée, en gardant à l’esprit que cela reste de la spéculation, tant qu’aucun retour n’a été obtenu, d’où l’importance des retours rapides.

Vision et stratégie produit

La vision

La vision décrit ce que le produit doit apporter aux clients dans le futur, de sorte à donner un point sur lequel concentrer les efforts de l’équipe.

• Une vision suffisamment précise permet d’orienter chaque décision portant sur le produit dans la bonne direction.
• Une vision suffisamment claire permet à chaque partie prenante de collaborer avec les autres grâce à une compréhension partagée de la destination.
• La vision ne concerne pas le produit, mais le bénéfice (qualité de service, confort, etc.) futur apporté aux clients, et in fine à l’entreprise.
• La vision permet de traduire une idée, une initiative, le fruit de la recherche, en un produit susceptible d’apporter des bénéfices aux futurs clients et utilisateurs, et améliorer l’expérience des futurs utilisateurs.
• La vision permet de garder le cap, même en cas d’échec, et d’améliorer sa stratégie pour tirer tout les enseignements des échecs.

La stratégie

Une bonne stratégie doit prendre en compte le marché. Il est nécessaire d’accepter les faiblesses de son produit vis-à-vis de la concurrence, pour pouvoir ensuite employer ses forces à combler les lacunes, comme Apple admettant que les smartphones allaient lui prendre le marché des mp3, et ainsi créer l’iPhone en exploitant les points forts de l’entreprise. 

Les trois parties de la stratégie selon Rumelt (cf. Good Strategy / Bad Strategy)

1. Diagnostic du principal défi à venir et les éléments critiques.
2. L’approche globale pour aborder du défi.
3. Les actions à mettre en place pour mettre en œuvre cette approche.

Le premier jalon du plan issu de la stratégie doit partir de l’état actuel du marché et des atouts du produit / de l’entreprise pour facilement atteindre les utilisateurs potentiels (un segment donné du marché).

Élaborer sa stratégie Produit repose sur l’analyse du marché, des clients, des utilisateurs, la stratégie de l’entreprise, et sur la collaboration avec l’ensemble des parties prenantes. Cette collaboration pourra s’appuyer sur des outils comme les “liberating structures”, dont le “1-2-4-all” fait partie.

Pour améliorer la relation avec les parties prenantes, il faut les impliquer au plus tôt dans le travail sur le produit, leur partager la vision, la stratégie et la feuille de route du produit, de sorte qu’ils sachent à l’avance si leur idée est pertinente ou non, intégrable dès maintenant ou non, etc. D’une façon générale, cela facilitera la communication avec les parties prenantes.

Remarque : il manque les liens entre objectifs, métriques, vision et stratégie. On peut placer au sommet la vision, qui peut être publique. Elle sert de base, mais aussi alimente la stratégie (boucle d’interaction). La stratégie aboutit sur un plan, et la progression sur ce plan se mesure au travers des métriques. Le choix des objectifs se repose sur les métriques « qu’est-ce que je peux faire pour améliorer telle ou telle métrique ».  Le canevas de l’étoile polaire permet de traduire une métrique haut niveau et abstraite en un ensemble de métriques sur lesquels nous pouvons directement agir au niveau du produit. Et les récits et épopées sont les actions concrètes qu’on peut mener pour faire évoluer le produit dans le bon sens.

La base pour qu’une équipe produit soit efficace, c’est d’avoir une vision, une stratégie et des objectifs clairs. Ceci lui permettra d’exploiter à fond son organisation (e.g.b Scrum) pour apporter le maximum de valeur. Pour le reste, elle doit être pluridisciplinaire, autonome, et capable de s’adapter. 

Surmonter les principaux obstacles aux objectifs de sprint

Dans un contexte de travail complexe, il faut trouver le bon équilibre entre friction, initiatives, actions et analyse des retours.

Mauvais usage de Scrum

Les risques induits par une mauvaise application de Scrum sont (liste non exhaustive) :

• Passer son temps à expérimenter : les expérimentations servent à réduire l’incertitude en balisant les portions mal maîtrisées. Trop d’expérimentation revient à chercher à tout maîtriser, et pénalise le produit en réduisant la capacité à livrer de l’équipe.
• Backlog sans fin, avec tout ce qu’on veut dans le produit. La liste doit rester relativement courte, avec des sujets haut niveau, que nous affineront seulement au moment de les intégrer au prochain sprint.
• Repasser systématiquement pour toujours affiner les mêmes initiatives. Le but n’est pas de maîtriser le moindre détail de l’initiative, mais d’être capable de circonscrire le travail à réaliser au prochain sprint.
• Planification sans fin, à prévoir les moindres détails du sprint. Cela revient à tenter de transformer l’Agile en gestion de projet, et nous ramène au problème initial : un plan trop rigide va échouer au premier problème rencontré.
• Interruptions dans le plan : il y aura toujours des tâches sans rapport avec le sprint qui viendront s’y ajouter (nouvel arrivant, bug en prod, etc.), cela ne sert à rien d’essayer de planifier les interruptions. Il vaut mieux jouer sur le fait qu’un sprint ne devrait pas être planifié à sa limite de charge, et ensuite chercher à comprendre d’où viennent les interruptions.
• Tickets bloqués à cause d’actions bloquées (et nécessaires à la DoD). Problème souvent dû à une DoR trop rigide : elle agit comme un contrat qui impose un format identique quelque soit le sujet. Parfois, la tâche ne nécessite pas tant de préparation, et parfois, l’inconnu est tel qu’on ne peut tout simplement pas répondre aux contraintes de la DoR (Rq: la DoR devrait plutôt imposer que telle et telle métier soit passé pour dire s’il y a quelque chose à dire, et les devs de dire si le sujet est clair).
• Bloqué sur les graphiques parfaits (burndown chart & co). Le graphique parfait est synonyme d’environnement parfaitement maîtrisé avant même de commencer (plan respecté à la lettre, aucun ajout/retrait en cours de route, etc.) et donc l’antonyme d’un sprint efficace.
• …

Problèmes revenant le plus : l’équipe a besoin d’un environnement de confiance pour pouvoir expérimenter. 

• L’équipe n’en sait pas autant qu’elle le souhaite, ou au contraire 
• elle est persuadée de mieux maîtriser le sujet qu’en réalité ;
• elle part d’un plan trop rigide ;
• elle s’impose trop de contrôle. 

Tout ce qui empêche l’équipe d’expérimenter et d’apprendre nuit à son efficacité.

L’objectif comme cadre

L’objectif de sprint ne veut pas dire qu’il n’y a rien d’autre que les sujets en rapport avec l’objectif, mais que ceux-ci seront toujours prioritaires sur les autres. De plus, l’objectif de sprint ne devrait jamais représenter 100% de la charge du sprint, de sorte qu’un développeur puisse facilement se libérer lorsqu’il faut aider un autre développeur de l’équipe, pour relire le code, tester, etc.

La DoR devrait servir à s’assurer que tout le monde est aligné niveau compréhension, plutôt qu’imposer un format. À la limite s’obliger à se poser un minimum de questions si c’est vraiment imposé.

Dans tous les cas, le Product Owner reste maître de son objectif de sprint. Il doit trouver un compromis entre les attentes des parties prenantes et les possibilités de l’équipe de développement, et définir un objectif qui permette d’aller dans l’intérêt des parties prenantes, tout en respectant une charge de sprint raisonnable. Dans ce sens, il vaut mieux re-décomposer l’objectif des parties prenantes en des objectifs plus raisonnables et adaptés pour un sprint, de sorte à garantir la livraison de valeur avant la fin du sprint.

Scrum présente une situation idéale où le Product Owner travaille avec un seul objectif, pour une seule équipe, sauf qu’en réalité …

• Il y a toujours plusieurs produits à prendre en compte.
• Le Product Owner est rarement seul sur son produit.
• Les parties prenantes ont toutes des attentes divergentes, vis-à-vis du produit, entraînant d’autant plus d’objectifs (et si on se concentre sur un objectif, les autres parties prenantes vont forcément se plaindre).

Gérer les dépendances

L’équipe Scrum est théoriquement autonome, mais au final, elle dépend bien souvent d’autres équipes, pour des compétences ou des technologies hors de son périmètre. Pour faire évoluer l’organisation, il faut savoir mettre en évidence les coûts engendrés par l’organisation actuelle, aux yeux des responsables, commencer progressivement, avec des personnes partageant déjà notre opinion, puis tenter d’impliquer progressivement plus d’équipes. Le changement ne va jamais se faire d’un coup, et il est très rare de réussir à obtenir l’implication de tous. D’autres parts, il faut des faits (les chiffres) et des preuves (les premiers résultats) pour réussir à convaincre. Penser également que certains responsables sont impliqués dans certaines parties de l’organisation (financièrement, moralement, etc.).

Lorsque plusieurs équipes sont amenées à collaborer, elles doivent partager un même objectif de sprint, de sorte à garantir qu’elles avancent dans le même sens, avec la même destination dans le viseur. Cela va également contribuer à la collaboration elle-même, là où des objectifs divergents tendent à favoriser la compétition. D’une façon générale, les objectifs des équipes doivent être priorisés les uns par rapport aux autres, et chaque objectif doit avoir une priorité différente des autres. De cette façon, si une équipe doit faire un choix, elle n’aura pas à hésiter sur l’importance.

Les méthodologies Agile, autant que les solutions d’agilité à l’échelle, devraient être vu comme des boîtes à outils. Ils ne donnent pas la solution au problème de l’entreprise; ils auront même tendance à créer de nouveaux problèmes. Par contre, prendre un ingrédient, l’expérimenter, et voir si ça nous aide à avancer dans la bonne direction permettra de résoudre progressivement les problèmes sans en créer de nouveaux. Par exemple, LeSS propose la notion d’équipes produits, pour organiser les équipes selon les produits. Ce peut être un bon point de départ, pour résoudre des problèmes de croissance d’entreprise, avant d’introduire d’autres éléments (ou même en piocher dans d’autres modèles).

Loi de Gall : « Un système complexe qui fonctionne est invariablement le résultat d’une évolution d’un système simple qui fonctionnait. Un système complexe conçu à partir de zéro ne fonctionne jamais et ne peut pas être réparé pour fonctionner. Il faut repartir de zéro avec un système simple qui fonctionne. »

Autant que pour la stratégie produit, la stratégie d’organisation doit reposer sur l’expérimentation, les retours et les itérations courtes. Si l’équipe doit être pluridisciplinaire, autogérée, suffisamment souple pour s’adapter aux changements, elle doit également être capable de compléter Scrum avec les bons outils pour créer de la valeur, et c’est l’expertise Produit qui les apporte.

L’évaluation de l’approche doit reposer sur des faits et/ou des chiffres. Des chiffres montrant l’acquisition des utilisateurs sur chaque fonctionnalité, sur la base des objectifs et développement en cours, quel sera le comportement et les limitations du produit, etc.

« Le pessimiste se plaint du vent. L’optimiste s’attend à ce qu’il change. Le réaliste ajuste ses voiles. » – William Arthur Ward.

Annexes

OKR

• Qu’est-ce qu’on veut réaliser 
• Quel est notre objectif
• Quels sont les jalons à atteindre pour tendre vers notre objectif 
• Que signifie notre réussite, pour l’utilisateur, et comment mesurer cette réussite 
• Les OKR doivent être alignés entre les différentes équipes et/ou personnes et entre les différents niveaux de l’organisation où elles s’appliquent. 

Idées sur la notion d’initiative

Vu qu’il est très difficile de n’avoir qu’une seule initiative à la fois, s’arranger pour que celles-ci soient priorisées. Comme ça, sur un sprint donné, l’initiative la plus importante sera traitée en priorité, tandis que la seconde avancera si la première est terminée (ou du moins les sujets les plus importants). Du coup, si initiative==opportunité, affiner au maximum l’OST permet d’avoir de petites opportunités faciles à traiter en un sprint (voir moins), et permet d’avancer sur d’autres opportunités importantes de l’arborescence. 

Une fois qu’on a des initiatives claires, rassembler autour de la table un représentant des parties prenantes et le lead dev, plus redécouper l’initiative sur la base de ce qui à la fois apporte le plus de valeur, tout en étant réalisable en un sprint. Si le lead dev voit trop d’incertitude, pousser pour un sprint d’expérimentation et/ou tâches techniques (l’objectif sera de tacler la contrainte technique, par exemple un bout d’architecture à retravailler, une nouvelle techno à tester, …), avant de traiter les premiers éléments apportant de la valeur.

Remarque : plutôt que de traquer la vélocité de l’équipe, traquer le temps accordé à l’objectif du sprint, et en rétro, prendre le temps d’analyser l’origine de chaque interruption.