Les entreprises, dans le contexte du sujet, s'intéressent souvent au fait que même si ce n'est pas dans un court laps de temps, dans quel délai pouvez-vous transformer la transformation en équipe, car on sait que c'est le «travail d'équipe» qui vous permet d'obtenir les résultats les plus efficaces. Ici, ils s'appuient sur des leaders - chefs de projet, Scrum Masters, chefs d'équipe. Quelqu'un parlera de l'importance «d'aller ensemble au bar» à l'étape initiale, quelqu'un parlera de choisir un nom ou un logo comme moyen de définir et de mettre en valeur l'identité de l'équipe.
Ce que j'aime le plus, c'est la vision de l'équipe en tant que groupe de personnes qui ont eu leur première expérience commune réussie. En coaching sur un sujet similaire, je suis tombé sur la métaphore du «franchissement de la barrière». Dans ce document, la clôture est notre capacité à développer des solutions aux problèmes communs, et pour "surmonter cela", vous avez besoin de chaleur, d'un sens de l'humour et d'un désir de travailler ensemble.
Cet été, j'ai commencé à travailler sur un projet qui est actuellement l'une des plus hautes priorités de l'entreprise. Son objectif principal est de remplacer les anciens backends par une architecture de micro-service moderne et de rendre ainsi le monde des télécommunications meilleur. Les attentes sont élevées et le rythme est rapide, ce qui implique une forte croissance et la nécessité de recruter et de lancer de nouvelles équipes. L'une de ces nouvelles équipes devait être assemblée et lancée par moi.
Eh bien, vous voyez l'idée.
J'ai plongé dans une période de sélection réfléchie des candidats qui a duré un certain temps. J'ai fait connaissance avec des gens et, dans une conversation informelle, j'ai essayé de connaître leur point de vue sur diverses questions, mais avec une retraite complète et des dates différentes de lancement du projet, nous n'avons pas tous eu une bonne occasion de vraiment nous connaître. Néanmoins, la composition de «professionnels hautement motivés et transversaux» (nous travaillons en Scrum) a été progressivement recrutée.
Et, comme cela arrive souvent, à un moment donné, le volant a commencé à tourner de plus en plus vite, et maintenant il n'y a plus de temps pour expliquer, ni pour un coup d'envoi soigné. Vous devez saisir les personnes recrutées dans l'équipe et commencer rapidement. Dans le même temps, le régime pandémique a imposé une restriction sévère à la possibilité des événements notoires de consolidation d'équipe. Même s'il doit être inutile de le regretter: avec tous les préparatifs, nous n'avons toujours pas eu le temps pour une connaissance normale.
Donc, pour la première fois, nous ne nous sommes tous «vus» que lors de la première planification. Et comme il ne s'agissait pas seulement de planification, mais de PIP (Product Increment Planning - un événement dans SAFe dédié à la planification de haut niveau du travail des équipes pour les prochains sprints), nous avons dû résoudre beaucoup de choses dans un laps de temps limité.
Imaginez ce moment. C'est votre première expérience d'un tel événement. Vous vous retrouvez en conférence téléphonique avec neuf inconnus, et bien que vous veniez d'être déclaré «équipe», vous n'avez aucune idée de qui sont ces personnes, de quelles compétences elles ont réellement, et vous avez trois heures pour créer une «équipe» ensemble. plan de travail pour les trois prochains mois.
Vous avez également un peu peur de la tâche difficile, qu'il est proposé de décomposer en plusieurs points du plan, car la description n'est pas sans ambiguïté.
À propos, notre planification des incréments de produit, si elle était hors ligne, pourrait ressembler à ceci.
Au début, nous nous sommes littéralement tenus debout, nous nous sommes métaphoriquement entassés autour de l'arriéré existant et avons discuté de ce qui peut être fait. En réponse, l'équipe de développement n'a souvent répondu qu'au silence, le processus ne s'est pas déroulé facilement.
Et pourtant, moi, comme ce pompier, battant sans relâche pierre sur pierre encore et encore, j'ai continué à encourager l'équipe de développement de manière amicale. Comment une étincelle sculptée de manière inattendue s'est transformée en une petite flamme.
En réponse, l'un des développeurs a fait une pause et ... a juste exprimé tout ce qui inquiétait chacune des personnes présentes. Incertitude, maladresse, un niveau élevé d'incertitude ... Oui, tout cela est là, et nous le ressentons tous. Mais cela nous empêchera-t-il d'accomplir ce que nous avons rassemblé pour l'instant? Dis moi ça!
Soudain, un autre ingénieur avoua ses propres doutes. Et puis d'autres. Quelqu'un jugeait son niveau d'expertise insuffisant, quelqu'un hésitait à poser des questions de clarification «stupides». Quelqu'un s'est simplement senti mal à l'aise, car il venait de nous rencontrer et ne voulait pas donner la «mauvaise» impression.
Quand nous avons dit à haute voix toutes les sources de notre anxiété, il semblait qu'il était plus facile de respirer. Chacun de nous a fait sa propre confession et personne ne nous a condamnés. L'atmosphère se réchauffait. Il y avait des blagues.
Un feu timide s'enflamma dans une flamme brillante et confiante.
Notre groupe de personnes qui se connaissaient à peine se sentait très différent. Petit à petit, nous avons développé une stratégie d'analyse de l'arriéré. Les développeurs ont évalué les exigences et ont travaillé ensemble: ils ont discuté de ce qui doit être fait et des niveaux de décomposition nécessaires pour une tâche particulière. Tout cela a été immédiatement enregistré dans JIRA. Puis ils ont distribué le travail. Tout le monde a pris part à la discussion.
C'était incroyable de voir comment ils ont découvert en quelques minutes qu'ils faisaient tous partie de l'équipe.
Je suis tombé sur une conférence TED sur ce sujet beaucoup plus tard.
Pendant ce temps, le Product Owner travaillait aussi dur, malgré le fait qu'il avait fait une bonne partie du travail avant cette réunion: après tout, il avait préparé toutes les exigences. Il a expliqué les objectifs de haut niveau sur lesquels l'équipe devait se concentrer, mis à jour l'arriéré, répondu aux questions et clarifié tout ce qui pouvait être clarifié.
En tant que Scrum Master, j'ai dirigé le mouvement de la discussion lorsque cela était nécessaire, empêchant l'émergence du sentiment que la discussion elle-même atteint une impasse.
Après trois heures de travail acharné, l'équipe a terminé la construction d'une feuille de route en ligne avec ses objectifs pour les trois prochains mois, et a ainsi achevé la planification.
Le lendemain, le Product Owner a présenté ce plan aux parties prenantes et, en tenant compte de quelques petits commentaires sur le libellé, il a été approuvé et adopté.
Nous avons tous réussi à le faire en agissant ensemble. En nous entraidant, nous avons eu notre première expérience commune réussie avant même de commencer à travailler sur des tâches. Sur cette planification, notre équipe a trouvé une réalisation commune (bien sûr, la première d'une longue série). Nous sommes devenus les «conquérants de la planification PI», ce qui nous a donné le sentiment que nous étions certainement capables de mettre en œuvre avec succès toutes les autres parties de notre projet complexe.
Et si on me demandait: «Comment les équipes deviennent-elles des équipes? Est-ce un long processus? », Je répondrais qu'ils acquièrent une véritable identité de commandement lorsqu'ils« franchissent la barrière », c'est-à-dire surmontent la première difficulté en agissant de manière coordonnée et solidaire. Et c'est la responsabilité du leader de faire en sorte que cela se produise le plus tôt possible.
Et ce qu'il peut faire exactement pour cela ressemble à un sujet pour le prochain article :)