Photo source
Pour la troisième année maintenant, j'introduis les valeurs et les principes de l'Agile dans la vie des équipes de développement. Derrière les épaules - travail en tant que Scrum master dans deux grandes entreprises, expérience de la mise en œuvre à distance de méthodologies agiles dans des secteurs complètement différents, d'innombrables livres lus et assisté à des rencontres.
Mais tout a commencé petit, et pendant ce temps, j'ai comblé plus d'une bosse. Et avec le temps, j'ai commencé à remarquer que ces bosses étaient assez typiques, et mes collègues novices les rencontrent régulièrement. Ne voulant pas rester à l'écart, et afin de mettre en garde mes collègues contre d'éventuels échecs, j'ai décidé de partager mon expérience dans cet article.
Alors, quelles leçons ai-je apprises et conclusions tirées au cours de la première année de travail en tant que Scrum master (que j'ai brièvement décrites dans les points à la toute fin):
Lunettes roses
Après deux jours de formation Scrum, j'étais prêt à déplacer des montagnes, à changer le monde sur le chemin de l'entreprise pour le mieux. Rien n'inspire plus qu'un coach compétent et une équipe de personnes partageant les mêmes idées! Mais dès que vous commencez, vous vous retrouvez soudain seul avec votre framework Scrum. Il y a des gars chargés de leurs propres tâches, il y a des habitudes et des valeurs qui se sont déjà formées dans le travail de l'équipe, il y a une direction qui voit les processus à sa manière, et cela ne va pas toujours en parallèle avec les valeurs et les idées d'Agile. Dans l'ensemble, bienvenue dans le monde réel .
Par conséquent, au début, il faut gagner la confiance et l'ouverture de l'équipe. Il est important de vous fier à votre expérience antérieure et à votre bon sens.Comprenez ce dont votre équipe a vraiment besoin maintenant, quels sont les problèmes et les sous-estimations et comment vous pouvez les aider à résoudre au moins certaines des questions qui se posent.
La résistance
Bien sûr, les innovations et les changements à venir évidents n'étaient pas très heureux. Dans mon cas, c'était plutôt une résignation au fait que quelqu'un d'autre était venu pour diriger et enseigner: « Eh bien, après tout, tout va bien ». Il n'y a rien à faire - je devais prouver que je suis venu pour aider, et en pratique pour le démontrer.
Un point important: si au tout début vous ne trouvez pas de supporters dans l'équipe de développement, vous risquez d'être rejeté.
La première chose à laquelle un Scrum master nouvellement créé doit faire face en essayant de changer est la résistance. Le processus, bien sûr, est naturel, mais pas indolore. Les gens ne sont prêts à changer que lorsqu'ils y voient une valeur pour eux-mêmes.Par conséquent, la meilleure option est de donner à l'équipe l'opportunité d'en venir à l'idée que Scrum améliorera à la fois leurs processus et leur vie.
Demandez-vous: "Quel est le but de ma présence dans ce rôle et comment puis-je aider mon équipe à améliorer les processus de travail existants?" Si vous pouvez trouver la réponse - super, passons aux changements! Sinon, cela vaut la peine de regarder un peu plus.
En parlant d'amélioration, vous pouvez organiser une série de réunions visant à identifier les douleurs de l'équipe et à créer une ouverture, par exemple. Mais je veux en parler dans les articles suivants.
La hâte est la pire des aides
La précipitation et le désir de se montrer dès les premiers jours de travail est probablement la plus grosse erreur qu'un Scrum master débutant fait. Il est d'une importance vitale de savoir que des changements drastiques sans comprendre pourquoi cela est nécessaire et comment cela affectera le mode de vie actuel de l'équipe peut provoquer encore plus de résistance et de méfiance. Il y a eu des moments où le Scrum Master a nui aux équipes précisément à cause de changements mal conçus et inachevés.
La préparation au changement vient progressivement de l'équipe.Observez l'équipe pendant 1 à 2 semaines sans interférer avec le cours «naturel» des choses. Dans les premières étapes, vous devez comprendre par vous-même la chaîne logique des processus et des valeurs établies, voir les vulnérabilités dans le travail et, en fait, proposer une solution. Étape par étape, essayez d'introduire les événements et les valeurs de la méthodologie dans la conscience et la vie de votre équipe.
Facilitation de réunions, interaction fréquente avec l'équipe, à la fois personnelle et sous forme d'événements, le coaching vous y aidera. Et, bien sûr, la confiance et l'ouverture au dialogue.
Comprendre l'environnement
Quand j'ai commencé à travailler avec l'équipe, j'ai fait une grosse erreur, qui au début n'a pas attiré mon attention et m'a semblé une bagatelle. A savoir, j'ai perdu de vue les nombreuses discussions thématiques des développeurs qui les ont révélées de l'autre côté. Elle a pris ses distances avec la direction et a raté des informations importantes, qui pourraient à leur tour transmettre à l'équipe.
Ne répétez pas mon erreur: peu importe que votre entreprise soit petite ou grande, mais vous devez comprendre la communication entre les services et connaître personnellement quelques collègues clés . On dit que le Scrum Master doit supprimer les obstacles qui empêchent l'équipe de créer un produit informatique. Mais comment pouvez-vous faire cela si vous ne savez pas vers qui vous tourner?
Donc, au tout début, c'est particulièrement important:
- aller à tous les chats et voir comment et avec qui les équipes communiquent, quels problèmes elles ont;
- communiquer avec la direction, suivre les objectifs globaux et secondaires que l'entreprise poursuit au cours d'une période donnée;
- communiquer avec des personnes partageant les mêmes idées si l'entreprise a déjà des Scrum Masters plus expérimentés.
Je suis sûr que tout ce qui précède est le plus susceptible de vous aider à vous immerger rapidement dans l'environnement et à mener une observation plus complète des processus.
Présence stratégique
Nous avons donc discuté avec l'équipe et la direction, posé des questions d'intérêt, reçu des réponses, participé à tous les chats et reçu des invitations à tous les événements. Nous voyons le problème, nous connaissons les objectifs de la gestion - mais par où commencer pour le résoudre n'est pas encore clair. Que faire ensuite?
Afin de prendre une décision, il est important de formuler des objectifs clairs sur ce que nous voulons changer exactement et pourquoi . Et puis - pour élaborer un plan de travail répondant à la question « comment allons-nous faire cela? ".
Le plus souvent, quand je suis venu dans l'équipe, j'ai vu comment les gars tiennent des réunions quotidiennes pendant 1,5 à 2 heures, au cours desquelles ils essaient de résoudre tous les problèmes. Et c'est d'ailleurs un temps colossal qui est déduit des heures de travail et réduit l'efficacité du travail des équipes. Et le Guide Scrum ne propose que 15 minutes pour cet événement et pas une minute de plus.
Comment être: l'approche la plus correcte, à mon avis, est de séparer ces activités et de se concentrer sur les tâches définies dans les objectifs du Sprint.
Sur la base des douleurs et des questions les plus fréquentes, en plus des principaux événements Scrum (planning, quotidien, démo, rétro), par exemple, une réunion de recherche hebdomadaire, une discussion sur l'arriéré d'idées, ou des sessions de brainstorming pour discuter en profondeur des problèmes peuvent se former, comme c'est le cas aujourd'hui dans ICL Services. ... Nous voyons la douleur, nous savons comment corriger la situation et ce qui doit être fait - il ne reste plus qu'à discuter du changement de format de travail avec la direction et l'équipe pour obtenir le meilleur effet.
Le plan doit également être flexible et changer en fonction des conditions et des caractéristiques des membres de l'équipe. Il est important de discuter du chemin prévu avec la direction, car tout ce que vous proposez ne sera pas toujours immédiatement mis en œuvre. Et quelque chose peut tout à fait changer en fonction de la fixation des objectifs et des demandes de la direction elle-même.
Manque de connaissances techniques
Je n'ai pas de formation technique, et par conséquent, comprendre à fond la terminologie extensive de l'équipe de développement était (et reste dans certains endroits) une tâche assez difficile pour moi, étant donné que la technologie ne s'arrête pas.
Mais ici aussi, il y a quelques hacks de vie assez simples:
- n'ayez pas peur de demander de l'aide à l'équipe;
- étudier la littérature pertinente;
- rechercher sur Internet des dictionnaires terminologiques pour les nuls ou obtenir un dictionnaire personnel si nécessaire.
Bref résumé
- Tirez parti de l'expérience précédente. Comprenez ce dont l'équipe a besoin, quels sont les problèmes et les sous-estimés, et comment vous pouvez l'aider.
- Identifiez en quoi le changement peut être bénéfique pour l'équipe et montrez-le-leur. Les gens ne sont pas prêts à changer tant qu'ils n'en voient pas la valeur par eux-mêmes.
- Sprint, , .
- – , , – -.
- « ?», . « ?» , , . . .
- Manque de connaissances techniques. Si vous n'avez pas de formation technique, mais que vous voulez ou devez maîtriser la terminologie, n'ayez pas peur de demander de l'aide. Un dictionnaire de terminologie personnel peut également être une bonne aide.
Je suis sûr que toutes les leçons que j'ai apprises vous aideront à tirer des conclusions et à reconstruire dans la bonne direction, car j'aime vraiment ce que je fais. Et, surtout, n'ayez pas peur des erreurs, mais apprenez d'elles. Bonne chance!