Je suis convaincu que les itérations sont comme les blagues : les plus courtes sont souvent les meilleures… J’ai pu le constater au fil du temps. Par conséquent, dans ce billet, je vous propose de parcourir ensemble différents points qui démontrent l’intérêt de s’en tenir à des objectifs réalistes et ayant une grande valeur à court terme afin de produire des incréments livrables plus fréquemment.

Vouloir courir un marathon

« En un mois, déjà nous n’arrivons pas à atteindre nos objectifs… alors en moins de temps, ça relève de l’impossible! » « On n’arrivera jamais à terminer nos activités sur une période de deux semaines! » « Cela fait un an que l’on fonctionne avec des sprints mensuels, pourquoi devrait-on changer maintenant? »

Pour celles et ceux parmi vous qui ont déjà tenté l’expérience de réduire la durée de leurs sprints ou de promouvoir des itérations courtes, les objections émises sont certainement nombreuses.

Oui, la durée des sprints est fonction du marché et de son contexte, de l’attente et de la disponibilité des utilisateurs, de la vision du Product Owner, etc. Toutefois, nombreux sont aussi les facteurs liés à l’équipe de développement, à sa taille, à ses qualités (courage, transparence, engagement, respect) et à son expérience.

Il n’est pas rare, et cela est tout autant intriguant avec un minimum de recul, de voir des équipes s’appropriant Scrum d’opter pour des sprints de quatre semaines en début de projet ou de poursuivre dans ce mode de fonctionnement. Cette décision est souvent prise injustement. Ce choix est fondé sur des dates plutôt que sur un nombre de jours de travail, sur une réticence palpable à changer de manière perturbatrice les habitudes, sur la peur d’engagements inconfortables…

Prenez un instant et remémorez-vous le manifeste Agile. Le danger d’opter pour des sprints de quatre semaines doit alors vous sauter aux yeux.

Avec cette option, nous tendons à vivre dans un certain confort, et ce, aux dépens de l’efficacité, et donc de la livraison de valeur, de la qualité et des améliorations pouvant être apportées à l’équipe. Prenons pour métaphore un sportif occasionnel ou débutant souhaitant courir un marathon ou participer à l’Ironman. Malgré une motivation forte, si ses premières tentatives sont directes, leurs issues sont inéluctables : il ne complétera pas le parcours dans le temps imparti, sera vite démoralisé, rencontrera le mur et renoncera. Pire encore, il pourra se blesser et endommager sa force physique.

Et vous, faites-vous des sprints de quatre semaines? Si oui, pourquoi? Notez les raisons et poursuivons!

Idées reçues, causes et remèdes

Reprenez les différentes raisons qui vous conduisent à avoir de longs sprints. Ne sont-elles pas des contraintes, des goulots d’étranglement insidieux? Sont-elles comparables aux cas suivants?

1. Le client et les utilisateurs ne sont pas souvent disponibles pour les revues et nous communiquent rarement leurs besoins.

Scénario : Le client, les ayants droit sont rarement présents lors de la présentation des incréments. Ils sont géographiquement éloignés ou leurs retours sont rares. Il y a une perte d’intérêt de leur part à l’égard du produit. Bref, l’équipe devient dépendante de la fréquence des échanges avec le client.

Prescription : Il est infondé de considérer cet obstacle comme une erreur de timing! Il s’agit manifestement d’un problème de communication sur lequel le Product Owner et le Scrum Master sont les mieux placés pour intervenir. Revoyez la qualité de vos revues pour que les ayants droit, clients et utilisateurs y participent. Si nécessaire, rapprochez-vous de certains nouveaux interlocuteurs qui utilisent le produit et qui ont une part importante dans son sponsoring, ses demandes d’évolution… Le lieu des revues est-il adapté? Avez-vous envisagé la téléconférence en dernier recours?

Aussi, bien que les revues soient des moments privilégiés pour inspecter ce qui est terminé et déterminer les prochaines étapes, s’il n’y a aucun feedback, c’est le Product Owner qui décidera du chemin à prendre pour livrer de la valeur… indépendamment du temps et selon un carnet de produit entretenu, accessible et dûment ordonné.

2. Le client est intrusif et exige trop souvent des renseignements, des nouveautés. Et nous accédons immédiatement à ces demandes.

Scénario : Contrairement au premier point, les ayants droit s’investissent pleinement dans le projet, tellement que cela devient envahissant et difficilement gérable pour l’équipe. Les changements en plein sprint sont légion.

Prescription : Un sprint ne doit pas s’avérer trop « élastique ». Le changement est bienvenu, mais avec modération. S’il est accepté pour l’itération, alors on procède à un rééquilibrage sensé du travail en toute transparence, y compris avec le client. On ne rajoute pas une heure de travail, puis deux, puis quatre… seulement pour se faire rassurants aujourd’hui et devoir bricoler les chiffres demain (sans compter les nouvelles intégrations, livraisons…). Retenez aussi qu’un sprint est fondé sur un objectif ayant de la valeur aux yeux du client. Il faut donc le préserver. Le client doit en être conscient et l’accepter.

Trop de changements? Et en plus, ils sont urgents? Pourquoi alors attendre jusqu’à la fin des quatre semaines si cela ne peut se faire au cours du sprint courant? En passant à des sprints de deux semaines, vous obtenez ainsi sur une période mensuelle deux objectifs plus modestes et des sprints plus malléables qui ne mettront pas en péril celui en cours! Demandez aussi au Product Owner d’arbitrer et de valider les exigences. Il serait dommage de les voir s’annuler entre elles ou ne rien apporter au cours des prochaines semaines.

3. Pour minimiser les risques liés aux incertitudes sur les besoins du client, techniques et organisationnels, on s’accorde une marge de manœuvre.

Scénario : Nous sommes indécis sur l’utilisation de telle ou telle technologie. Les besoins ont encore besoin d’être raffinés alors que nous les sélectionnons comme objectif du sprint. Les membres de l’équipe de développement ne seront pas forcément là pendant tout le sprint, car ils ont des feux à éteindre, d’autres projets prioritaires à réaliser. Les tâches ciblées sont tellement importantes que l’on rate nos estimations et on les dépasse amplement.

Prescription : S’accorder une marge de manœuvre n’est pas une mauvaise idée en soit, mais elle doit rester raisonnable et contrôlable. Idéalement, elle doit même être un bloc de temps. Retenez aussi le principe des scénarios INVEST et des tâches SMART et n’hésitez pas à utiliser les critères mentionnés pour solidifier vos sprints. Si les items qui y figurent les respectent, vous vous retrouvez alors avec une définition pertinente de « prêt ». Suivant cette règle, vous n’avez pas assez d’items qui sont prêts à développer? Réduisez la durée de vos sprints et diagnostiquez le problème avec votre équipe à la prochaine rétrospective!

Petit point sur la sollicitation des membres de l’équipe. Une équipe efficace consacre 100 % de son temps à son projet. Si les membres sont sollicités ailleurs pour une urgence indiscutable (une vraie de vraie, j’insiste!) ou alors si l’urgence a lieu à la fin du sprint, alors vous pouvez considérer plus aisément de vous séparer d’un développeur temporairement sans mettre en danger l’objectif du sprint courant. Autrement, laissez l’équipe s’auto-organiser en se concentrant sur le projet et demandez au Scrum Master de ramener le problème au management.

4. Il y a souvent trop de bogues à corriger en vue d’un prochain bien livrable.

Scénario : Les bogues sont nombreux à chaque sprint. Le client n’est pas satisfait et réclame des correctifs en urgence. Pour répondre à sa demande, nous accordons du temps spécialement pour ça. Il nous faut donc bien quatre semaines!

Prescription : N’est-ce pas là un problème de clarté de la définition de « terminé » et de discipline envers celle-ci? Revoyez votre définition. Clarifiez-la et assurez-vous que chacun la comprenne. Puis, communiquez-la de manière transparente à chaque acteur du projet. Et rendez-la publique pour recevoir des suggestions. Notez que les critères de « terminé » pour toute activité de l’équipe doivent être mesurables, réduits au minimum et strictement nécessaires. Si ce n’est pas le cas, ça signifie que le critère n’est pas valide.

Avant d’envisager de longs sprints pour terminer un item, assurez-vous au préalable que la définition est claire afin de développer de manière uniforme, moins vite, mais de manière certaine. Et non pas l’inverse!

5. La plupart du temps, on n’atteint pas nos objectifs. Si on pouvait faire des sprints plus longs, nous le ferions.

Scénario : Nous sommes bien trop optimistes lors de la planification, nous prenons trop d’items ou bien l’avis de l’équipe n’est pas pris en considération lors de la définition de l’objectif du sprint et du choix de son contenu. Du coup, pour réaliser ce qui est demandé, il nous faut énormément de temps et nous nous en tenons à des sprints de quatre semaines… parfois plus, mais chut!

Prescription : Selon Scrum, l’objectif est défini lors de la planification du sprint avec la pleine collaboration et l’accord de toute l’équipe, et ce, selon sa capacité. Le Product Owner peut faire des suggestions au préalable, selon son travail sur le carnet de produit. À l’issue de la première moitié de la rencontre de planification, l’équipe s’est entendue sur ce qu’elle va livrer (l’objectif, un premier carnet de sprint à dégrossir). L’autre partie lui permet de décider comment elle va s’organiser et d’établir la liste des tâches à réaliser. Au terme de la planification, elle s’approprie son carnet de sprint qui comporte des tâches SMART et s’engage à respecter l’objectif, éventuellement revu. Elle seule, en tant que réalisatrice, a le dernier mot. En raison de la responsabilité et de l’expertise de l’équipe, les décisions qu’elle prend doivent être entendues et respectées.

Quelques raisons de plus…

Si ces arguments n’ont pas suffi à vous convaincre de faire le pas, en voici d’autres moins triviaux, mais tout aussi frappants.

6. Crise de réunionite aigüe et perte d’énergie

Tout le monde le vit ou l’a déjà vécu… Les réunions sont chronophages et épuisantes. Si les cérémonies de Scrum sont vos bêtes noires, sachez que sur des sprints plus courts, votre endurance sera mise à moindre épreuve. Parlez-en aux gens autour de vous. Préférez-vous avoir une succession de réunions collées sur deux jours pour un sprint mensuel ou deux séries séparées d’une journée chacune, et ce, au maximum? La dernière option est effectivement plus attrayante.

Qui plus est, la réduction de la durée des planifications, revues et rétrospective assure une meilleure concentration lors de ces séances.

C’est aussi un argument valable lorsque les personnes censées participer aux rencontres ne se présentent pas par lassitude. N’hésitez donc pas à jouer cette carte!

7. Expérimentez, il n’y a aucun risque!

En somme, que risquez-vous? Avez-vous encore une objection? Y-a-t-il un risque qui vous vient en tête à la suite de cette question? La première tentative d’un sprint de plus courte durée est souvent balbutiante, certes. Laissez-vous le temps d’en faire deux pour expérimenter et analysez objectivement les résultats. Ce n’est pas non plus un engagement définitif. Toutefois, je suis persuadé qu’après avoir essayé, vous serez surpris du résultat et ne pourrez plus vous en passer!

Moralité

Félicitations si vous avez lu ce billet de bout en bout! Comme vous pouvez le constater, le choix de la durée des itérations ne relève ni du temps, ni du niveau de maturité d’une équipe, ni d’une négociation sur la qualité. Ces facteurs ne devraient aucunement être des excuses pour quelque équipe que ce soit.

Qu’importe la taille de l’équipe, ses compétences ou le budget alloué au projet, la production d’incréments livrables ayant une grande valeur relève du bon sens, des valeurs humaines et de la volonté de celle-ci à satisfaire le client.

Entraînez vos muscles et forgez vos esprits de champions. Alors, arriverez-vous peut-être même à faire en une semaine ce que vous prévoyiez faire en quatre il y a seulement quelques mois de cela?

Billet précédent

(Re)découvrir Scrum par le jeu

Billet suivant

L’ingrédient souvent oublié dans la mise en œuvre d’Agile Lean

pyxis

Pyxis est présente en Amérique du Nord, en Europe et en Asie.

Nos conseillers Agiles vous aident à concrétiser réellement les avantages de l’Agilité : accroître la fréquence des livraisons et la vélocité des équipes; collaborer avec les clients en s’alignant sur leurs besoins; maîtriser les risques et les changements en cours de livraison et encourager la concentration, la rigueur et l’énergie au sein des équipes. Communiquez avec nos coaches, formateurs, Scrum Masters et développeurs pour en apprendre davantage sur nous.

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *