Dans un monde idéal, une équipe Scrum devrait être dédiée au projet et exposée le moins possible à des dérangements extérieurs. Toutefois, dans la plupart des cas, les équipes doivent se concentrer à la fois sur du nouveau développement et sur le soutien des versions antérieures du logiciel en production. Quand des demandes de soutien arrivent, celles-ci peuvent perturber le déroulement du sprint. Selon leur urgence, ces demandes peuvent même mettre en péril l’engagement de l’équipe. Quand une partie de l’équipe doit passer en mode « pompier » pour éteindre des feux, certaines situations peuvent pousser à réduire la portée de l’engagement, voire à arrêter le sprint. Peut-on faire autrement?

Pour plusieurs équipes, il peut être frustrant de ne jamais pouvoir respecter son engagement de sprint à cause des demandes de soutien. Pourquoi s’engager quand l’équipe est sûre de se faire déranger? L’engagement perd tout son sens et l’équipe s’engage à faire de son mieux plutôt qu’à livrer des résultats. Comment rendre plus prévisible, l’imprévisible?

Voici quelques stratégies qui vous permettront de voir plus clair et de mieux gérer ce genre de situation :

1. En tant que PO, être ferme sur ce qui peut compromettre le sprint ou ce qui peut attendre aux prochains sprints et gérer les attentes des clients.
2. En tant que membre de l’équipe, garder ses bonnes habitudes lors du traitement des demandes de soutien. Ce n’est pas parce qu’il y a un problème urgent en production qu’il faut sauter des étapes contenues dans la définition de « Terminé » en testant à moitié et en corrigeant directement en production. Au contraire, c’est dans des situations d’urgence et de stress que le risque d’erreur est le plus élevé. Le Scrum Master doit s’assurer que l’équipe garde la tête froide et s’en tient à la routine de rigueur et de qualité instaurée au cours des sprints.
3. Prévoir une banque de temps pour les imprévus pendant le sprint (ex. : 20 %). Bien suivre le temps utilisé pour les imprévus au fil des sprints pour voir si la banque allouée est suffisante. Adapter la banque en conséquence. Cependant, si les demandes de soutien continuent d’occuper un pourcentage trop élevé pour vous, d’autres stratégies plus « importantes » devraient être envisagées.
4. Dédier un ou plusieurs membres de l’équipe au soutien. Ces membres protègent le reste de l’équipe des dérangements en prenant en charge les demandes de soutien. De plus, les tâches de soutien ne sont pas comptabilisées dans l’engagement de l’équipe. Si pendant un sprint, le soutien est moins important que prévu, l’implication de ces membres dans l’engagement du sprint ou le développement de nouvelles fonctionnalités est considérée comme un bonus. Il est possible de faire des rotations pour le soutien afin que ce ne soient pas toujours les mêmes qui s’en chargent.
5. Créer une équipe de soutien séparée de l’équipe de développement. Si l’effort le justifie, une équipe dédiée au soutien applicatif pourrait être créée. Comme les demandes ne sont pas prévisibles, une autre approche Agile comme Kanban ou Agile Lean pourrait être employée. Pour l’équipe de développement, l’approche Scrum est toujours appropriée et sera maintenant plus efficace puisque l’équipe sera moins dérangée. De la même façon, des rotations après quelques sprints de l’équipe de développement et de soutien pourraient permettre de diversifier les expériences en limitant l’impact sur la vélocité.

Il n’en demeure pas moins que consacrer autant d’effort à gérer du soutien applicatif est très coûteux et pourrait être évité. Autant prévenir et régler ce problème à la source en mettant dès le début l’accent sur la qualité de la solution, l’excellence technique et la simplicité dans la conception, en maintenant un rythme soutenable et en évitant que la dette technique ne s’accumule.

Bref, la mise en place de certaines de ces stratégies pourrait vous permettre de voir plus clair dans des situations difficiles et de passer d’un mode « réactif » à un mode plus « proactif ».

Bien entendu, les stratégies mentionnées ci-dessus ne s’appliquent pas à tous les contextes ou elles doivent peut-être avoir à être adaptées à votre réalité ainsi qu’à la taille et à l’expertise de vos équipes.

Dans votre contexte, quelles stratégies utilisez-vous?

marc-andré filion-pilon

Diplômé en génie informatique de l’École Polytechnique de Montréal en 1998, Marc-André compte plus de 15 années d’expérience en TI. Au cours de sa carrière, il a occupé plusieurs rôles dans des domaines variés, ce qui lui permet d’avoir une vue d’ensemble du cycle de réalisation d’un projet.

Afin d’ouvrir ses horizons, il a résidé en Belgique de 2002 à 2009. C’est à partir de 2005 qu’il s’intéresse à la gestion de projet et aux méthodes Agiles, en particulier Scrum et Extreme Programming (XP). Depuis, il accompagne, forme et prend en charge des équipes sur des projets complexes.

Billet précédent

Les bureaux de projets à l’ère de l’Agilité

Billet suivant

En Agilité, avons-nous besoin d’un gestionnaire avec des équipes auto-organisées?

1 Commentaire

  1. jflabelle@reptiletech.com'
    31/08/2016 at 10:57 — Répondre

    Très intéressant!

Laissez un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.