5 faux espoirs de Scrum et comment les corriger

Comme beaucoup de conflits classiques et sans fin, le débat sur la manière dont les équipes de développement devraient s'organiser et s'autogouverner fait rage. Actuellement, il semble presque qu'il y ait plus de critiques que de fans de Scrum. Les trois plaintes les plus courantes sont :

1. Le processus peut prendre le devant de la scène sur le travail.
2. Il peut être facilement confondu avec la microgestion par un autre nom.
3. Le stand-up quotidien peut ressembler à une réunion où l'on doit justifier son existence.

Dans d'autres cas, les rôles de Scrum ne sont pas représentés de manière appropriée. Parfois, le propriétaire du produit veut trop de choses à l'intérieur d'un sprint ou veut changer les priorités en cours de sprint - un Scrum master qui est obsédé par le maintien de la vitesse et l'adoption de chaque nouvelle cérémonie Scrum qu'il apprend. Après un certain temps avec le cadre, une question commune semble se poser : « Est-ce nous ou la méthodologie ? »

Les faux espoirs de Scrum

Bien qu'il existe de nombreux dysfonctionnements comme ceux décrits ci-dessus, une cause fondamentale simple pour la plupart d'entre eux est que Scrum n'a pas été conçu pour résoudre les problèmes sous-jacents au sein d'une organisation en suivant simplement le processus. Ne pas le reconnaître peut mettre les nouvelles équipes en danger presque dès leur démarrage.

Faux espoir #1 : Scrum permet aux équipes de travailler plus vite

Scrum utilise une terminologie qui sonne pour un étranger comme si elle allait accélérer le processus sans ajouter de ressources supplémentaires. Il est facile de s'enliser dans la terminologie en tant que nouvelle équipe Scrum (par exemple, qu'est-ce qu'un Scrum master ? Quelle est la différence entre un propriétaire de produit et un chef de produit ? Que sont les points d'histoire et comment sont-ils attribués ?)

Plus troublant est que beaucoup voient des termes comme vélocité et sprints et pensent « vitesse ». Cependant, le but de toute méthodologie Agile, y compris Scrum, est de livrer un produit fini. Finalement, au fur et à mesure que votre équipe deviendra plus compétente avec Scrum, vous serez en mesure de fournir de nouvelles fonctionnalités plus rapidement. Cependant, la vitesse n'est pas nécessairement l'objectif principal. Cette distinction doit être articulée au sein de votre équipe Scrum et également lorsque vous sensibilisez votre entreprise à soutenir la méthodologie Scrum.

Vous ne vendez pas de vitesse ; vous vendez l'achèvement.

Faux espoir #2 : Une adhésion stricte à Scrum résoudra les problèmes de culture d'entreprise

Tout le monde a des styles de travail différents. Certaines personnes aiment les réunions. D'autres utilisent des phrases comme "travailler dur, jouer dur". Il est essentiel de reconnaître que, quel que soit le style de travail que votre entreprise apprécie, vous en acceptez à la fois les avantages et les inconvénients. Une entreprise qui valorise les réunions est susceptible d'avoir du mal avec le stand-up quotidien. Les équipes agressives et axées sur la vitesse vont avoir des problèmes avec le fluage de la portée à l'intérieur d'un sprint.

Il est parfois facile de perdre de vue la situation dans son ensemble, en particulier pour les équipes récemment formées. Ce qui compte, c'est de livrer un produit fini au lieu de suivre chaque étape du processus. Plutôt que de blâmer la méthodologie, cherchez toujours des moyens d'affiner votre style de travail pour atteindre vos objectifs.

Faux espoir #3 : les contributeurs critiques peuvent envoyer leurs délégués aux réunions

Une fois que vous avez commencé la méthodologie, il est crucial que l'équipe d'origine participe plutôt que des délégués. S'il y a une plainte presque universelle que je vois de la part des développeurs, c'est que les maîtres Scrum et les propriétaires de produits n'étaient pas disponibles en cas de besoin et que leurs délégués n'étaient pas habilités. Personne n'aime venir à une réunion en s'attendant à une décision seulement pour se faire dire que la personne qui peut prendre la décision n'est pas disponible.

La délégation peut être une pratique courante, mais dans Scrum, vous devez également responsabiliser les participants.

Faux espoir #4 : Les stand-ups quotidiens obligeront tout le monde à être plus concentré

Le stand-up meeting quotidien ne doit pas se concentrer uniquement sur ce que chacun a fait au cours des dernières 24 heures. Il est beaucoup plus important de donner la priorité à la découverte d'obstacles ou à de nouvelles approches pour résoudre un problème.

Scrum exige que certains rôles, en particulier le Scrum master, soient affirmés mais pas écrasants. Il est important pour le Scrum master de créer un environnement positif qui mène à des produits finis.

Faux Espoir #5 : Nous réussirons du premier coup

Scrum implique des conjectures, une réflexion déductive et des erreurs. Les gens réussissent rarement du premier coup. Scrum est itératif à tous égards : non seulement dans la manière dont vous atteignez un produit fini, mais également dans la manière dont vous gouvernez et exploitez le processus. Scrum est conçu pour avoir une faible barrière à l'entrée pour les équipes à adopter, mais il nécessite également un engagement à itérer et à améliorer continuellement la participation dans le cadre.

Comment réparer un processus Scrum cassé

Scrum résiste au sophisme des coûts irrécupérables. La nature itérative de Scrum crée des opportunités d'adapter ou d'éliminer les processus inefficaces. Considérez certaines des suggestions suivantes si votre processus Scrum n'est pas aussi efficace que prévu.

Affinez vos attentes

Qu'il s'agisse de réduire les délais de mise sur le marché, de créer des produits attrayants ou d'aider les équipes à collaborer, le succès demande de l'engagement et du temps. Pour les nouvelles équipes, une étape raisonnable à atteindre est de savoir si, après chaque sprint, vous pouvez introduire du code fonctionnel et testable dans votre environnement de production.

Les équipes avancées peuvent mesurer le succès par leur capacité à créer, tester et déployer à la demande. Êtes-vous capable d'instrumenter et de quantifier les réactions des utilisateurs aux nouvelles fonctionnalités ? L'organisation dans son ensemble est-elle prête à soutenir les changements que l'équipe apporte au produit ?

Responsabilisez vos participants

Il est important d'encadrer les membres de l'équipe hors ligne sur la manière dont ils peuvent augmenter leur valeur pour l'équipe. Si on leur demande de prendre des décisions, renforcez leur confiance en les guidant sur le moment et la manière d'inclure d'autres membres de l'équipe. Les managers doivent être prêts à éliminer les obstacles et à soutenir l'équipe en cas de besoin.

Résoudre les problèmes de manière proactive

Scrum n'est pas conçu pour relooker votre entreprise. Si vous avez laissé des problèmes sans réponse, il est plus que probable que ces problèmes apparaissent dans votre processus de développement de produits. Les Scrum Masters peuvent introduire des cadres conçus pour créer une manière positive pour les membres de l'équipe de structurer leurs commentaires afin de réduire le sentiment de conflit.

Un tel exemple est le cadre « Je souhaite, je me demande, et si ». Lors de discussions d'équipe ou de rétrospectives, un membre de l'équipe peut donner son avis en ouvrant sa déclaration par l'une de ces trois phrases. Par exemple, ils pourraient dire : "J'aimerais que les réunions debout mettent davantage l'accent sur les obstacles dont je devrais être conscient ce jour-là". Vous pouvez également utiliser votre propre ouvreur tel que "J'aime…".

Une autre solution de rétroaction structurée qui peut être utile lors des réunions est la méthode Triage de Holocracy, créée par Brian Robertson et utilisée par des entreprises comme Zappos. Par exemple, les participants élaborent un programme de « tensions » à discuter. Chaque participant décrit son problème en disant « J'ai une tension », puis énumère les personnes et les ressources dont il a besoin pour le résoudre. En encourageant les participants à aborder directement les problèmes comme des « tensions », l'holocratie permet aux participants de communiquer librement sans créer une atmosphère de conflit.

Utiliser les rétrospectives pour résoudre les problèmes et itérer sur le processus

Dans de nombreuses entreprises, la rétrospective ne reçoit pas l'attention qu'elle mérite. Cela est principalement dû à la crainte que beaucoup ont que la rétrospective soit un lieu pour de vieux arguments, conflits et griefs. Il est vital pour l'équipe de développer des règles de base qui reflètent les valeurs de l'équipe et la culture de l'entreprise.

Il est tout aussi important d'éviter d'investir dans des processus statiques. Ce qui a fonctionné une fois peut ne pas fonctionner éternellement. De nombreuses équipes sont aux prises avec le roulement des participants. Cela est courant dans de nombreuses entreprises, car les participants sont réaffectés à d'autres équipes, sont promus ou quittent complètement l'entreprise. Au fur et à mesure que la composition de l'équipe évolue, il est important de ne pas rester convaincu que tout est itératif dans Scrum. Des erreurs se produiront, mais j'espère qu'elles seront de courte durée au fur et à mesure de votre itération.

Scrum fonctionne mieux lorsque les directeurs sont présents

En équipe, il faut s'engager à être présent et disponible. Le développement de produits est probablement le processus le plus crucial que votre entreprise puisse entreprendre pour améliorer sa croissance à long terme. Par conséquent, il est important que le processus Scrum, en tant que voie principale vers le développement de nouveaux produits, reçoive l'attention qu'il mérite. Dans de nombreux environnements, l'équipe de développeurs travaille souvent indépendamment des décisions et des discussions qui orientent les objectifs de l'entreprise. Scrum est différent. Scrum est l'endroit où les décisions, la direction et le développement se rejoignent en un seul processus. Il est trop important d'un processus d'envoyer des délégués ou d'exclure les membres de l'équipe des réunions qui ont lieu dans le cadre de la méthodologie Scrum.

Résumé : Vous pouvez réparer un processus Scrum cassé

En raison de sa nature itérative, Scrum aide à empêcher l'entreprise d'aller trop loin sur la route et de s'engager dans ce qui pourrait finir par être une mauvaise idée ou un processus mal mis en œuvre. Adhérer à ce principe peut aider à se défaire des erreurs passées et à améliorer de manière itérative le processus Scrum.

Il est important de se concentrer sur les individus et l'équipe que vous avez. Les membres de l'équipe changent. Tous les projets sont différents. Le strict respect d'un processus ne produit pas toujours les meilleurs résultats. Ce que vous investissez dans les membres de votre équipe en dehors du processus est tout aussi important que la façon dont vous vous comportez au sein du processus.

Scrum peut être flexible. Si quelque chose ne fonctionne pas, envisagez d'incorporer des éléments d'autres frameworks à la fois dans Agile et à l'extérieur. Identifiez et adoptez des styles de communication structurés qui favorisent les discussions conflictuelles.

Scrum est bénéfique pour le retour sur investissement à long terme en permettant aux équipes de créer des produits complets en réponse aux besoins changeants des clients. Scrum est probablement la meilleure méthodologie pour vous empêcher de trop vous engager dans de mauvaises idées tout en donnant aux bonnes idées un peu d'espace pour se développer davantage.