L’adoption de scrum en entreprise⌗

Depuis 2018, tous mes clients emploient la méthodologie scrum pour mener à bien leur projet, ou construire leurs produits. Sa popularité est indéniable. À la fois simple à implémenter, léger, associé à une bonne réputation, tout y est pour favoriser son adoption en entreprise.

Scrum est défini comme un framework, idéale pour qu’une équipe de développeur, testeur, analystes(, etc) puissent travailler en autonomie.

Recherchons dans le scrum guide en quoi utilise l’agilité au profit d’une entreprise. Recherchons le mot agile dans le scrum guide :

0 occurrence trouvée. C’est étonnant, car scrum est souvent associé à l’agilité. Pourquoi scrum n’est pas agile ? Est-ce que le scrum est une implémentation de l’agilité ?

Relation entre scrum et agilité⌗

Quand je discute avec les clients, la notion est facile à comprendre. Pour beaucoup, scrum est un moyen d’atteindre l’agilité. Une fois le scrum appliqué, l’agilité est implicitement appliqué à l’entreprise. Cet article vous démontre du contraire.

flowchart LR
    Scrum --Implemente--> Agilité

Le raccourci est à la fois facile, et pas complètement erroné. Bien sûr que le daily scrum implique une interaction entre individus. Évidemment que présenter le résultat de sprint provoque une collaboration entre stakeholders et équipe scrum. La livraison d’un sprint permet une livraison continue à un rythme régulier et durable.

Mais est-ce que le scrum existe dans l’objectif d’appliquer l’agilité ? Non. Pour preuve, le scrum est apparue aux alentours des années 1995, les principes et valeurs de l’agilité datent de 2002.

flowchart LR
    Agilité --Est inspiré de--> Scrum
    Scrum --Est inspiré de--> Agilité

Ce qui implique que l’agilité contient des éléments de scrums, mais ne s’y limite pas. Appliquer scrum en entreprise ne signifie pas appliquer l’agilité.

L’agilité, entre autre, propose de remettre en question les pratiques employés par tous les acteurs d’une entreprise. Afin de s’assurer que l’équipe soit en mesure d’accepter les changements tardifs et d’être en capacité de livrer en continu de la valeur à un produit. Adapter ses process peut y aider, Scrum inclus. J’entends souvent que les entreprises appliquent une ‘scrum-yonnaise’ présentant que l’adoption de scrum s’est faites à la sauce de l’entreprise. Alors que ce mot porte une connotation négative, la ‘scrum-yonnaise’ n’est pas nécessairement un repoussement de l’agilité.

Le framework volontairement incomplet (voir https://scrumguides.org/scrum-guide.html#scrum-definition et https://www.scrum.org/resources/blog/scrum-tools-and-practices-enhance-incomplete-framework-part-1). Il est nécessaire d’apporter des adaptations propices afin d’atteindre le véritable objectif : profiter des principes agiles pour améliorer la qualité des livraisons.

Cet article vous propose de parcourir quelques idées pour adapter le scrum à votre organisation. L’objectif est d’implémenter des méthodologies agiles, pour base de référence le scrum. Voici quelques pistes de réflexions pour étendre l’agilité. Nous nous limiterons aux solutions organisationnelles et de communication. Les sujets techniques seront évoquées peut-être dans un article futur, et apporter un impact positif continu au business.

Questionner l’efficacité du daily scrum⌗

L’équipe se regroupe chaque matin, entre 10 et 20 minutes pour informer de la progression de leur travail individuel (voir en pair). Après cette session, est-ce qu’il y a une décision prise ?

Si la réponse est oui, alors félicitation, le daily scrum est bénéfique. Vous avez peut-être identifié un collègue qui part dans la mauvaise direction. L’un d’eux a peut-être besoin d’une assistance. Peut-être qu’une annonce à influencer un changement de priorité pour atteindre le sprint goal. Tous ces scénarios, je les vois toutes les semaines

Si la réponse est non, alors il n’y a pas eu de plus-value. Au mieux, il y avait des post-its à déplacer dans les bonnes colonnes.

Selon la fréquence d’action prise durant le daily scrum, sûrement que faire le daily scrum 3 fois par semaines serait plus bénéfique ?

De nombreuse fois, la bonne chose à faire était de garder le daily scrum. Mais n’ayez pas peur de vous demander réellement si la fréquence peut être adaptée.

À l’inverse, dans le cas où un hotfix urgent est requis, pourquoi ne pas avoir des réunions de synchronisation de 5 minutes 2x par jours pour s’assurer que le travail urgent soit sur une bonne voie ?

L’estimation de complexité comme aide à la décision⌗

Le scrum guide propose de raffiner et d’évaluer la complexité des Product Backlog Items(PBI) durant le sprint planning. L’objectif des estimations étant de donner de la confiance si le contenu du sprint planning peut-être accomplie raisonnablement.

Toutefois, de nombreuses équipes font l’exercice de refiner et d’estimer durant le sprint précédent. Après tout, faire entre 4 et 8h d’affilé de sprint planning peut-être à la fois démotivant et épuisant. Étendre ces sessions sur plusieurs jours sont à mon opinion bienvenue.

Toujours dans l’objectif de délivrer de manière continue de la valeur au produit, l’estimation de complexité est pour le Product Owner une mesure précieuse pour organiser la priorité du backlog. Si 2 PBIs ont une valeur business équivalente, mais l’un a une complexité minime, et l’autre énorme, il est normal de donner des priorités différentes à chacune d’entre elles. Sûrement que même qu’après un seuil de complexité dépassé, la valeur ajouté au produit étant trop petite, le bon choix est d’abandonner complétement le PBI.

Notez bien que je présente l’estimation comme un outil d’aide à la décision et de priorisation. Il n’est pas question de se demander si ça fit dans un sprint.

Aussi, le principe “Simplicity–the art of maximizing the amount of work not done–is essential.”, confusionnant à la première lecture, et malheureusement ouvert à interprétation, il est toutefois convenu dans la communauté agile que cela signifie de supprimer le travail inutile.

Adapter la longueur de sprint⌗

Dans beaucoup d’entreprise, la tentation d’utiliser des sprints de longue durée se fait sentir. Lorsque l’inventaire des réunions de début et de fin de sprint est faite, il est facile d’interpréter erronément que les rétrospectives, reviews et planning sont du temps perdu. Malheureusement pour tous, la solution choisie pour palier à ce sentiment de temps perdu est d’adopter des longues périodes de sprints. Se voir imposé (hum hum) des périodes de sprints longs implique un sprint planning plus difficile.

L’implication est qu’il est quasiment impossible de travailler sur un (ou 2, voir 3) sprint goals. Un sprint plus long implique une abondance de sprint goal, le planning est rempli d’éléments de fonctionnalités variées. Sans objectif de sprint formulé sur un scope restreint, l’équipe n’a plus d’occasion de collaborer vers un objectif commun. Les développeurs se retrouvent à travailler chacun de leur côté, avec des PBIs à piocher dans un backlog. Il n’y a plus de sprint, il y a un kanban sur 4 semaines.

Afin de définir un (ou 2 ou 3) sprint goal(s), selon l’environnement de travail, raccourcissez la durée de sprint. De cette manière les priorités définit par l’équipe reprend son sens.

Il m’est déjà arrivé ou le rôle de l’équipe étant différentes de ce que l’on a l’habitude de voir, il était identifié à raison que multiplier les sujets à traiter était la bonne solution. Dans ce cas, je vous invite à lire le paragraphe suivant …

Supprimez le sprint⌗

Ceci est bénéfique uniquement si vous ne définissez pas d’objectif unique de sprint. L’équipe à assumer qu’il y aura du travail sur plusieurs sujets et il n’est pas possible de travailler communément sur une seule livraison. La solution est d’adapter la longueur de sprint. Ne partagez pas ce paragraphe sans le contexte présenté ci-dessus.

Sans sprint goal, le travail quotidien peut se remplir de travail dont le PO a déterminé une priorité grâce à la plus-value et la complexité. Comme annoncé plus haut, le sprint est en réalité un kanban dont le flux s’arrête à la fin de sprint. Dans ces conditions

De nombreuse fois, afin de donner effectivement une valeur ajoutée en production à un produit, le travail à faire était étalé sur plusieurs sprints. Dans la volonté de “caler” un maximum de PBI dans un sprint, l’équipe finit par augmenter le temps de livraison d’une fonctionnalité. Prenons en considération le planning ci-dessous.

gantt
    title Développement par sprint
    dateFormat  DD-MM-YYYY
    section Feature 1
        Task 1      :a1, 2024-01-01, 10d
        Task 2      :2024-02-01  , 5d
    section Feature 2
        Task 1      :a1, 2024-01-11, 10d
        Task 2      :2024-02-06  , 5d
    section Feature 3
        Task 1      :a1, 2024-01-21, 11d
        Task 2      :2024-02-11, 5d

Dans le cas présenté ci-dessus, le sprint planning a permis de travailler sur 3 fonctionnalités différentes. Les 3 fonctionnalités finissent par être livrés à la fin du sprint 2. Cette organisation est proposée sous la contrainte que chaque tâche doit être terminée en 1 sprint, et que les tâches ne peuvent pas être dépendantes les unes des autres durant un sprint. La crainte de ne pas compléter l’engagement de sprint implique des délais de livraison dispersés. Livrer 3 fonctionnalités simultanément demande plus de travail d’acceptation, le déploiement contient 3 fonctionnalités à monitorer.

Pas si mal que ça, mais on peut faire mieux.

Notez toutefois que l’exemple ci-dessus sont des cas optimistes qui ne requièrent pas d’adaptation. Une fois livré, la fonctionnalité ne requiert plus de changement. Ceci ne prend pas en compte les étapes qui peuvent suivre le développement.

gantt
    title Développement au fil de l'eau
    dateFormat  DD-MM-YYYY
    section Feature 1
        Task 1      :a1, 2024-01-01, 10d
        Task 2      :a2, after a1, 5d
    section Feature 2
        Task 1      :a3, after a2,  10d
        Task 2      :a4, after a3, 5d
    section Feature 3
        Task 1      :a5, after a4, 11d
        Task 2      :a6, after a5, 5d

Sans contrainte de sprint, le nombre de fonctionnalités développées en parallèle diminue, les fonctionnalités sont délivrées au fil du temps. L’équipe peut se concentrer ensemble sur un nombre plus restreint de développement et améliore leurs concentrations.

Cependant, dédier du temps à un “development review”(=demo) et à la rétrospective est toujours nécessaire. La formule devra y être adapté. Ceci permet de satisfaire le second principe de l’agilité “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Améliorer la relation entre développeurs, stakeholders et utilisateurs⌗

Le scrum oblige des rencontres avec les acteurs extérieurs à l’équipe. Néanmoins, un développement continu requiert de s’adresser couramment aux bonnes personnes. Parfois, une présentation intermédiaire du développement en cours permet de récolter les feedbacks à des moments plus opportuns. Après tout, l’agilité stipule que “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” ainsi que “Business people and developers must work together daily throughout the project.”

Écrivez les PBI sous forme de user story⌗

Les users stories est un format de PBI offrant ces caractéristiques

1. Il indique qui est l’utilisateur cible, profil inclus.
2. Il décrit la fonctionnalité espérée.
3. Il informe de la plus-value apportée à l’utilisateur.

Si nous travaillions à Netflix, un exemple serait “En tant qu’abonné et père de famille, je veux connaitre le temps de visionnage de mes enfants, afin de m’assurer que l’engagement fait avec mes enfants sur le temps de visionnage soit respecté”. Cet énonce répondre aux 3 attentes.

L’utilisateur du système dont la fonctionnalité doit être défini, pointe précisément le segment de marché. L’équipe en charge de développement peut comprendre qui est le public cible. On s’attend à un profil sans connaissance de statistiques ou de mathématique. L’écran doit être simple à comprendre, sans doute au détriment de données précises.

Un père de famille a la responsabilité d’éduquer ses enfants. C’est dans cet objectif personnel que l’inspection lui est utile. Ainsi, facilement et rapidement, il est capable de s’assurer que l’engagement de ses enfants est respecté. Par exemple, de limiter le temps de visionnage à 2h par semaine soit respecté. Une fois la plus-value identifiée, il est plus simple de proposer une fonctionnalité et des écrans adaptés au besoin exprimé initialement.

Enfin, il donne de la marge à la discussion. Est-ce que l’information doit indiquer de la consommation par semaine ? Par jour ? Est-ce que le temps exact de session doit être donné ? Est-ce que les heures de journée de sessions doivent être indiquées ? Dans un objectif de contrôler le temps de visionnage, est-ce que le type d’émission doit être représenté ? Autant de question à poser aux analystes et au business afin d’implémenter la solution adéquate.

La user story est un outil pour combler la première moitié du premier principe de l’agilité “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

De plus, accepter la discussion au sein de l’équipe assure l’avant-dernier principe agile : “The best architectures, requirements, and designs emerge from self-organizing teams.”. S’il n’y a pas de discussion possible, alors l’équipe n’est pas auto-organisée.

Si le sujet vous intéresse, je vous recommande User Stories Applied de Mike Cohn (2004). Évidemment qu’une user story ne peut pas être résumé sur 7 lignes d’un blog.

Autres idées en vrac⌗

Les possibilités d’améliorer les procédures sont nombreuses. Afin de ne pas faire un article interminable, voici encore quelques pistes de réflexion :

• Rencontrez vos utilisateurs pendant qu’ils emploient votre application. Vous y découvrez des cas d’usage que vous n’imaginez pas, comprendriez que la succession d’écran ou que l’usage de fenêtre modal ne correspond pas à leur travail quotidien.
• Impliquez les testeurs avant la livraison de fin de sprint. Le processus d’acceptance ne doit pas trouver de bug, et plus un bug est identifié tôt, et moins il coûte à réparer. Après tout “Working software is the primary measure of progress.”
• Adaptez le contenu du sprint afin de définir 1 ou 2 sprint goals clair. Avoir un goal restreint incite l’équipe à collaborer sur le développement au lieu de se disperser. Ceci conduira naturellement vers l’usage des principes XP.

L’article cité en introduction contient aussi des pistes de réflexion que je soutiens, et qui mérite votre temps de lecture : https://www.scrum.org/resources/blog/scrum-tools-and-practices-enhance-incomplete-framework-part-1

Conclusion⌗

Adopter scrum n’implique pas nécessairement d’utiliser l’agilité. C’est un excellent début, il est facile à implémenter, et est propice à la discussion entre les membres d’une organisation en forçant des process simples. Toutefois, l’agilité est un état d’esprit, une manière de penser, une manière de travailler. Pour atteindre cet objectif, il est nécessaire de remettre en question les pratiques employées, et de s’assurer que le travail effectué est en accord avec les valeurs et principes de l’agilité. Il s’agit de démarrer par le framework as-is, et de questionner quelques fois comment améliorer le framework.