4 processus malsains qui peuvent ruiner votre sprint

Dans mon article précédent, j’ai lancé la discussion autour d’habitudes mal développées au sein d’une équipe Scrum qui finiront par conduire (tôt ou tard) à un échec de livraison. Dans cet article, je voudrais développer ce sujet une fois de plus et me concentrer maintenant sur les processus fonctionnels au sein de l’équipe.

Celles-ci sont tout aussi importantes que l’excellence technique de l’équipe. Même si les personnes à l’intérieur sont super qualifiées pour le travail qu’elles sont sur le point d’accomplir, il y a encore des domaines qui peuvent ruiner leurs efforts pour atteindre la perfection. Et ce ne sera pas tant leur faute car ce sera la responsabilité directe des décisions de gestion de projet et leur capacité à servir l’équipe avec des processus adaptés pour soutenir l’équipe avec une intention claire et des activités prévisibles.

Équipe hautement séparée avec des compétences distinctes

Imaginez que l’équipe compte des développeurs compétents, parfaitement indépendants et capables de tenir leurs promesses et de livrer le contenu du sprint convenu juste à temps avant la fin du sprint. Même dans un scénario aussi parfait (ce qui est très peu probable de toute façon), l’équipe aura des problèmes à suivre les fonctionnalités de backlog (en constante augmentation) si les compétences sont strictement séparées entre les membres de l’équipe.

Quelques exemples

• L’équipe compte 1 ou 2 ingénieurs DevOps capables d’apporter des modifications aux pipelines automatisés ou de s’occuper des services à l’intérieur de la plate-forme, mais le reste de l’équipe n’a aucune idée de ces choses. Ensuite, discuter de ces histoires lors de cérémonies scrum comme des améliorations entraînera une perte de temps pour la majorité de l’équipe en s’accrochant à la réunion sans aucune participation et vice versa – le développeur DevOps n’aura aucun intérêt pour le reste des histoires axées sur les fonctionnalités, et le temps de la réunion sera également en grande partie perdu.
• Il y a un seul expert en base de données pour toute l’équipe. En fonction de la complexité et de l’utilisation des solutions de données dans le système que l’équipe développe, cette personne peut être constamment surchargée d’histoires qu’elle n’a aucune chance de terminer assez tôt, en particulier en tenant compte de ses priorités. Pire encore, d’autres histoires devront également attendre, car elles dépendent de la source de données fournie par les histoires de la base de données.
• Lorsqu’un produit particulier est principalement orienté vers le développement backend, le seul développeur frontend est là juste au cas où (car de temps en temps, quelques petits changements sont nécessaires même dans l’application d’interface utilisateur de toute façon). Dans ce cas, encore une fois, la plupart des cérémonies Scrum sont une perte de temps pour ce membre de l’équipe, car ses connaissances se limitent uniquement au front-end, et rien d’autre n’a d’importance.

Où ça se termine

Dans tous les cas ci-dessus, le résultat est que les gens perdent leur temps ou, alternativement, ils sont incapables de rattraper la demande en attente. Ils empêchent le reste de l’équipe de commencer à travailler sur les histoires suivantes, ou ils diminuent effectivement l’efficacité globale de l’équipe Scrum car il y a trop de temps qui n’est pas utilisé dans le sprint.

L’équipe compte cependant toujours ce nombre de développeurs. De l’extérieur, il n’est pas visible (même sans vouloir être exposé) que les personnes à l’intérieur de l’équipe ne sont pas en mesure d’assumer certaines histoires simplement parce qu’elles sont trop orientées vers un ensemble de compétences spécifiques. Ils ne peuvent donc pas aider les autres membres de l’équipe avec les histoires, même si leur capacité le permettrait, et les priorités pour les histoires le favoriseraient également.

Il est même difficile pour le propriétaire du produit de composer un contenu de sprint significatif pour l’équipe, car le propriétaire du produit doit toujours garder à l’esprit combien de personnes peuvent travailler sur chaque histoire et si d’autres histoires similaires sont apportées au sprint en même temps. , en fin de compte, la capacité de l’équipe est dépassée, même s’il y a en fait des gens qui pourraient éventuellement travailler sur ces histoires, mais ils n’ont pas les compétences nécessaires pour commencer avec celles-ci.

Résoudre le dilemme

C’est un dilemme à résoudre, et les chefs de projet doivent être conscients de la voie à suivre. Concrètement, un choix entre :

• Avoir de nombreux développeurs full-stack capables de travailler sur un contenu plus large, mais pas vraiment des experts dans de nombreux sujets. Ainsi, ils peuvent aller large mais pas en profondeur. Ensuite, la livraison peut progresser rapidement, mais la qualité peut en souffrir.
• Avoir des experts dédiés pour chaque technologie, mais ensuite accepter la limitation et travailler plus dur sur un contenu imprimé mieux adapté. Ensuite, les gens peuvent approfondir et créer de belles histoires, mais les histoires devront être abordées de manière séquentielle, ce qui prendra plus de temps à livrer.

Product Owner faible

Celui-ci n’est pas nécessairement un «problème de processus» par définition, mais je le traite comme ça simplement parce que la création d’histoires solides peut être comprise comme un processus que l’équipe devrait vouloir avoir solide et compatible avec l’équipe de développement.

Ce que j’entends par faible n’a pas besoin de faire référence à la propriété de connaissances d’une personne, mais plutôt à la capacité du propriétaire du produit à servir les histoires de l’équipe que les développeurs peuvent comprendre et qui ont un sens clair du point de vue de la feuille de route du produit. Ces deux éléments sont très importants pour une équipe Scrum réussie.

Si les histoires manquent de détails pour que les développeurs puissent comprendre clairement l’objectif, la valeur fonctionnelle ou les attentes techniques, alors deux scénarios peuvent se produire :

• Les développeurs construiront quelque chose de différent de ce que le propriétaire du produit voulait réellement. C’est même difficile à saisir pendant le sprint lui-même, car la plupart du temps, le propriétaire du produit n’a pas eu la possibilité de suivre la progression des histoires à un niveau aussi détaillé, et la plupart du temps, le PO s’attendra à ce que la chose se produise (par magie).
• Les développeurs passeront beaucoup trop de temps à clarifier les histoires et à en discuter encore et encore plutôt que de commencer à les construire. Cela implique de nombreux appels supplémentaires, des accords répétés et le report du travail à la phase de sprint tardif. Il atteint un point où les estimations originales des histoires ne peuvent plus être considérées comme exactes, et les histoires ne peuvent pas être clôturées dans le sprint et se déroulent dans les sprints suivants. Dans le pire des cas, la situation se répète ensuite dans les sprints suivants.

Temps d’auto-réflexion

C’est généralement difficile à admettre, mais le propriétaire du produit doit trouver le temps de réfléchir, d’examiner les histoires de backlog créées et éventuellement de le comparer avec la vision de la feuille de route du produit s’il existe encore un lien sensé entre les deux – s’il existe une feuille de route du tout. Sinon, c’est la première chose à résoudre. Parfois, la solution est d’admettre que le Product Owner est trop loin de l’équipe et trop loin de sa propre cible.

Dans un tel cas, la partie Product Owner de l’équipe est à résoudre. Si rien d’autre, faire entrer dans l’équipe un solide analyste d’affaires orienté davantage vers le contenu de l’équipe plutôt que vers le contenu commercial (pour cela, nous avons déjà un propriétaire de produit dans ce cas) pourrait être une option valable, même pour le prix de augmentation des coûts totaux de l’équipe.

Processus de test sans calendrier fixe

Que se passe-t-il si les activités de test ne sont pas limitées à un calendrier concret dans un sprint Scrum ?

À première vue, cela pourrait ressembler à quelque chose de bien que nous souhaitons pour une équipe agile / scrum. La flexibilité est toujours la bienvenue et sonne bien lorsqu’elle est présentée à l’extérieur.

Mon expérience montre que le résultat de cette liberté est plus le chaos que la flexibilité. Cela ne signifie pas que la solution à cela devrait être de créer des «cascades à l’intérieur du sprint» avec des phases de test dédiées suivies juste après la fin du développement. Ce n’est en aucun cas la bonne approche dans ce cas. Vous pouvez en savoir plus à ce sujet dans mes articles sur la stratégie de test Scrum et le cycle de vie des tests agiles.

Nous pouvons toujours autoriser une certaine flexibilité et choisir le calendrier des tests car il semble le plus approprié pour l’équipe de développement actuelle et les propriétés de produit données que l’équipe fournit. Il y a, cependant, deux objectifs principaux qui devraient être atteints par ce choix :

1. Minimiser la perturbation de la progression du développement pendant les activités de test.
2. Faites en sorte qu’il y ait une activité solide (du point de vue du contenu), fiable (du point de vue de l’occurrence) et répétée (du point de vue de la prévisibilité) au sein de l’équipe.

Si ces conditions sont remplies, l’équipe s’adaptera naturellement au processus d’adaptation et le calendrier de livraison ne sera pas affecté par des activités de test prolongées imprévues.

En fin de compte, ce qui compte le plus, c’est une publication de sprint fiable et prévisible, ce qui m’amène au dernier point de ce blog.

Processus de lancement non défini

Maintenant, c’est une chose tellement évidente pour chaque équipe Scrum. Pourtant, assez curieusement, c’est aussi généralement l’un des processus les plus sous-estimés.

Très souvent, une équipe Scrum dira simplement que la publication aura lieu après chaque sprint, mais cela n’est pas soutenu par un processus solide. Ce qui se passe alors, en réalité, c’est que beaucoup d’activités chaotiques et imprévisibles se produiront pendant le temps de sortie. Tout à coup, tout le monde est occupé par des « tâches de publication » et personne n’est en mesure de se concentrer sur la poursuite du développement de nouvelles histoires de sprint. Les métriques de sprint sont désactivées et la publication ressemble à une activité aléatoire et imprévisible du point de vue de la 3ème personne (généralement le client).

Les gens sont tellement concentrés sur le backlog, le contenu du sprint, le développement, les tests et enfin la présentation des résultats qu’ils oublient qu’une fois qu’ils ont terminé avec tout cela, le prochain sprint est déjà en cours et qu’ils perdent déjà du temps.

À la recherche d’un bon moment pour sortir

Alors, quand exactement l’équipe doit-elle effectuer la mise en production proprement dite ? La seule chose importante qui compte à la fin.

La réponse à cette question se trouve dans le processus, en supposant que vous en ayez un. Selon:

• la complexité du contenu que l’équipe produit dans les sprints,
• durée d’un sprint,
• nombre de composants affectés dans le système
• le nombre de personnes utilisant et demandant les modifications,

un processus de libération répétée doit être établi et suivi à l’avenir. Les règles exactes du processus peuvent être à nouveau flexibles dans la définition. Mais comme c’est le cas pour les activités de test, en faire une habitude solide comme le roc, prévisible et programmée pour des jours concrets à l’avenir, en fait quelque chose sur lequel s’appuyer et se référer.

Choix à choisir

Les formes possibles d’un tel processus pourraient être l’une des suivantes ou d’autres :

• Terminez le test des fonctionnalités du sprint en cours lors du sprint suivant et publiez le contenu à la fin de ce sprint (une fois le test terminé). Cela signifie que chaque version n’aura aucun contenu du tout dernier sprint, mais elle contiendra des histoires des 2 sprints précédents.
  • Le dernier sprint avant la publication est toujours dédié au test du contenu des deux sprints précédents.
  • Cela ne signifie pas que le développement pendant le « sprint de test » sera arrêté ; il indique seulement que le contenu développé lors de ce sprint de test ne sera pas encore inclus dans la prochaine version.
• S’il y a déjà suffisamment d’activités de test automatisées en place, efforcez-vous de faire la publication après la fin de chaque sprint. Ensuite, cela doit être un processus très strict avec des personnes dévouées se concentrant sur ces quelques jours à 100 %. Cela ne devrait toujours pas affecter le reste de l’équipe de développement.
• Vous pouvez également choisir de publier une fois par mois ou une fois tous les N mois, principalement si cela convient du point de vue des utilisateurs finaux. Cela augmentera l’effort du côté des tests pour chaque sprint (car le contenu sera plus grand pour chaque version). Mais d’un autre côté, cela signifiera moins d’activités répétées dans le temps, ce qui, dans ce cas, peut avoir des avantages pour l’équipe. En conséquence, cela peut permettre à l’équipe de créer plus de nouvelles fonctionnalités entre les versions, malgré le fait que les fonctionnalités arriveront en production avec une cadence plus lente.

Mais comme déjà indiqué à quelques reprises auparavant, il n’est pas si important de savoir lequel de ces processus sera choisi. Il est beaucoup plus important de savoir à quel point l’équipe s’en tiendra à ce processus et en fera une habitude durable.

Vous pouvez également lire ce guide sur le processus et les pratiques de gestion des versions.