Dans la première partie, nous avons examiné les symptômes alarmants et les moyens possibles de «traiter» le Product Owner dans une mêlée «mécanique». Nous poursuivons l'analyse des rôles et le prochain en ligne est l'équipe.
Néanmoins, ils connaissent le mantra selon lequel l'équipe doit être auto-organisée et interfonctionnelle, cela ressemble à la partie la plus simple de la mêlée: nous prenons des personnes avec les compétences nécessaires, nous leur disons: «vous êtes une équipe», et volez! Mais en réalité, tout est un peu plus compliqué.
Auto-organisation
Symptôme : il existe une hiérarchie explicite (soumission de directive) à l'extérieur, ou pire à l'intérieur d'une équipe. C'est-à-dire en fait, un développeur de produit peut avoir une tâche qui n'est pas directement liée à l'équipe. Ou, à l'intérieur de l'équipe, les gens ne sont pas libres de choisir un travail pour atteindre l'objectif de sprint, mais reçoivent des tâches du «leader».
Ce qui est mauvais :
Toutes limites - limit @ CEP
Lorsqu'une personne est coincée par la description de poste, la hiérarchie de soumission, etc., cela l'empêche d'être révélé. La force de l'équipe Scrum est d'ouvrir des opportunités aux gens. Il y a une tâche, prenez courage et soyez responsable de sa mise en œuvre. Une personne doit décider par elle-même de ce qu'elle fera pour atteindre l'objectif du sprint. S'ils lui disent quoi faire, alors ce n'est pas de l'auto-organisation et pas de la mêlée.
Comment traiter : Pour les membres de l'équipe, toutes les descriptions de travail et les hiérarchies sont annulées, la structure a tendance à être plate.
Tous les membres de l'équipe sont les
développeurs du produit (le
guide Scrum ne permet pas d'autres rôles ). Il n'y a qu'un leadership situationnel et les gens décident à quel point ils sont à l'aise pour travailler afin d'être efficaces. Bien sûr, il existe des règles générales du jeu dans l'entreprise, l'équipe ne les viole en aucune façon (
bien que cela puisse affecter le changement au niveau de l'entreprise ), mais elle est responsable de toutes les choses internes. S'il existe de sérieux obstacles à la levée des restrictions pour les développeurs, cela vaut la peine de porter le problème à ceux qui ont décidé de mettre en œuvre Scrum et la transformation agile. Vous pouvez essayer d'exécuter une structure plate, comme une expérience pour plusieurs sprints, puis mener une rétrospective approfondie, où toutes les parties intéressées discutent des résultats de l'expérience.
Symptôme : Les personnes, en plus de travailler en équipe, doivent effectuer d'autres tâches fonctionnelles dans l'entreprise. Par exemple: 50% du temps exécute les tâches de l'équipe, 50% - les tâches du département (développement, tests, etc.).
Que de mal : l'une des valeurs de Scrum est la concentration. L'équipe se concentre sur l'objectif du sprint et se dirige vers lui. Si, en plus de travailler en équipe, une personne doit faire autre chose, la concentration est perdue. En conséquence, le résultat sera pire. Il est difficile de maintenir l'esprit d'équipe dans de telles conditions.
Comment traiter : Nous devons nous assurer que les membres de l'équipe travaillent UNIQUEMENT dans cette équipe. Pour ce faire, il convient de comprendre la nature du travail qui est tombé sur les développeurs de l'équipe de l'extérieur et de trouver des moyens de le faire sans rompre la mêlée. Certes, ce travail est nécessaire pour l'entreprise, donc, selon les spécificités du travail, vous pouvez:
- soit mettre le travail dans l'arriéré de l'équipe, puis cela se fera selon un workflow unique.
- ou le transférer à d'autres employés en dehors de l'équipe. Par exemple: toute l'entreprise ne travaille pas sur Scrum, et vous devez effectuer un travail régulier à un moment précis, alors ce travail ne convient plus aux employés Scrum.
- ou une équipe spéciale peut être créée et un produit sélectionné qui collectera tout le travail de ce type.
- ou, s'il s'agit d'une fonction unique réalisée par une seule personne pour plusieurs équipes en raison d'un manque de spécialistes. Ensuite, cela vaut la peine de retirer la personne de toutes les équipes et de construire pour elle un autre processus qui ne casse pas le reste de la mêlée ( par exemple: une file d'attente de tâches prioritaire ), jusqu'à ce que des spécialistes de ces équipes de mêlée soient trouvés.
Fonctionnalité croisée
Symptôme : les membres de l'équipe ne font qu'un certain travail, il y a une spécialisation claire. Pire encore quand il est encore couvert par les devoirs officiels, les règlements et autres bureaucraties. L'absence (vacances, congés de maladie, etc.) d'un membre de l'équipe réduit la fonctionnalité de l'équipe. Salut, facteur de bus .
Ce qui est mauvais : si une équipe dépend des compétences d'un de ses membres, c'est une équipe instable aux changements. Il est difficile d'établir une communication avec elle, car vous devez comprendre ses fonctionnalités actuelles et vous souvenir des risques associés à ce niveau de tolérance aux pannes. La spécialisation étroite des développeurs complique considérablement le travail d'organisation de l'équipe: lors de la planification, vous devez réfléchir à qui fera quoi; toutes les tâches ne nécessitent pas des proportions prédéterminées de compétences d'équipe, il est donc difficile d'assembler un sprint équilibré; dans un tel schéma, un "col étroit" apparaît nécessairement, réduisant la vitesse globale de l'équipe.
Que faire : il est nécessaire de promouvoir et de soutenir les compétences en forme de T. Pour garder l'équipe flexible, il est important qu'une fonction ou des connaissances particulières ne soient pas concentrées sur une seule personne. Il est nécessaire de stimuler et d'encourager le développement continu. Il est important de s'assurer que l'équipe s'améliore, en cherchant des moyens d'améliorer les processus. En tant qu'options de développement en forme de T: organiser des séminaires internes, où les membres de l'équipe partagent leurs connaissances; adopter la règle d'exécution des tâches non essentielles à chaque sprint par chaque membre de l'équipe; travail en binôme sur des tâches, etc. Vous pouvez stimuler artificiellement une équipe en «éteignant» ses membres pendant un certain temps: vacances, séminaires, formations, voyages d'affaires, etc.
Symptôme : dans la chaîne de valeur, l'équipe n'est responsable (influence) que d'une petite partie de celle-ci et, par conséquent, elle ne peut pas émettre seule d'incréments.
Tant pis : si l'équipe a peu d'effet sur la livraison de l'incrément ( sortie du produit ), alors Scrum perd également son essence: les sorties se produisent avec un retard, le retour se produit avec un retard encore plus grand. En général, il n'y a pas de rythme, donc de vitesse. Pas de vitesse - pas de flexibilité. Une telle équipe ne sent pas son appartenance, c'est juste une vis fonctionnelle dans une grosse voiture. La fonctionnalité de l'équipe devrait être suffisante pour fermer la majeure partie de la chaîne de valeur, sinon l'équipe ne fournira tout simplement pas de valeur, mais traitera simplement un type de «pièce» dans un autre et le transférera plus loin.
Nous illustrons cela avec un exemple tiré du Web. Lorsque simplifié, la création d'une nouvelle fonctionnalité comprend les étapes suivantes:
- Développement de prototypes UI / UX
- développement de conception
- création d'une API RESTful
- Création de SPA
- rédaction de tests d'intégration
- assemblage et coulée sur l'environnement de combat
Pour ces travaux, différentes compétences sont requises. Un exemple de division infructueuse en équipes: pour séparer l'
équipe A de l'interface utilisateur / UX, des concepteurs et du développement frontend, ils préparent leur incrément sous forme de SPA; mais ils dépendent du moment où le backend préparera l'API pour que la nouvelle fonctionnalité fonctionne; attendez que QA vérifie tout et intègre les tests; puis ils s'attendent toujours à ce que DevOps fasse tout cela au combat. Il est difficile pour une telle
équipe A d'être responsable de la libération et de la livraison de la valeur, elle coupe simplement le «vide» - SPA.
Comment traiter : Nous déterminons les compétences qui manquent à l'équipe pour délivrer l'incrément. Nous dotons l'équipe de ces compétences en formant les membres de l'équipe existants ou en ajoutant de nouveaux joueurs à l'équipe. Parce que trouver / enseigner aux gens n'est pas la tâche la plus facile et la plus rapide, alors vous pouvez établir une communication avec les équipes / départements voisins, leur expliquer les valeurs de mêlée et convenir avec eux de règles spéciales / règles d'interaction en vertu desquelles ils ne briseront pas la mêlée à votre équipe. Il convient de souligner le processus d'extension des fonctionnalités de l'équipe: après la première rétrospective et l'identification des compétences manquantes, vous pouvez les imprimer et les placer devant l'équipe. Lorsqu'une équipe fait face à un manque de compétence (
appris; un nouveau membre de l'équipe; établir une communication efficace avec une autre équipe, etc. ), nous suspendons une solution au-dessus de la compétence manquante auparavant. Au fil du temps, l'équipe devrait s'efforcer d'élargir ses fonctionnalités pour couvrir complètement la chaîne de valeur.
Équipe et produit
Symptôme : il y a une équipe, mais pas de produit. Pas de bon de commande, pas d'arriéré. C'est juste que les gens font des tâches qui viennent de différentes directions.
Que du mal : ce n'est pas de la mêlée. Lorsqu'un produit n'est pas affecté à une équipe, il est peu probable que l'équipe «brûle» avec le travail. Lorsqu'il y a un objectif global ( vision / stratégie / feuille de route de développement de produit ), vous voulez y aller. Vous faites le travail, obtenez des commentaires, réfléchissez et passez à l'étape suivante. Sans sentiment d'appartenance, vous courez le risque d'être dans une routine: vous n'avez pas vraiment besoin de commentaires, l'équipe devient juste un outil pour transformer les savoirs traditionnels en fonctionnalités.
Comment traiter : l'équipe doit avoir son propre produit avec carnet de commandes et bon de commande, ce qui peut enflammer l'équipe avec le produit et le transporter - c'est l'essence même. Besoin de comprendre pourquoi avez-vous besoin de mêlée? Vous comprenez d'où vient l'équipe? Comprenez-vous s'il y a un «produit» parmi ce flux? Choisissez parmi les équipes «clients» une et faites-en le propriétaire du produit , en lui donnant le droit exclusif de répondre à l'arriéré. Il peut être nécessaire de diviser l'équipe en une équipe de mêlée travaillant avec un PO ( cela peut être une équipe de mêlée «pilote» ) et une deuxième équipe, tout en travaillant de la même manière avec le reste des «clients». Offrant une transparence maximale des processus et des résultats qui se produisent dans la nouvelle équipe Scrum, vous pouvez jeter les bases d'une plus grande distribution de Scrum et Agile dans l'organisation.
Symptôme : l'équipe n'a aucune influence sur le composant du produit: elle ne décide pas "comment faire?", L'équipe dit simplement "que faire?" Les savoirs traditionnels entrent en ligne de compte et l'équipe est considérée comme une unité fonctionnelle.
Plus que mal : c'est une option très dangereuse si l'entreprise proclame vraiment les valeurs de l'agilité et de la mêlée. Cela implique généralement que tous les employés sont des professionnels sympas qui peuvent résoudre tous les problèmes qui n'ont pas peur de prendre des décisions et d'assumer des responsabilités. Mais s'ils ne sont pas autorisés à prendre des décisions sur les produits, alors toute la liberté de création de l'équipe s'étend généralement du produit à la technologie. Puisque l'équipe n'est pas autorisée à décider comment faciliter la vie de l'utilisateur, le monde est meilleur et le produit est plus utile; puis l'équipe commence à développer une base de code, à essayer de nouvelles technologies / outils / frameworks, etc. Il y a un conflit d'intérêts entre le PO et l'équipe, l'équipe commence à vendre du "refactoring", des "optimisations", des "balles d'argent" sous la forme d'une nouvelle pile, etc. Et cela est principalement affecté par l'utilisateur et le produit. Dans le processus de passage de modèles de gestion directifs à des modèles agiles, il existe un risque de rester coincé dans la compréhension de l'équipe en tant qu'unité fonctionnelle (l' équipe n'avait pas pris de décision auparavant ). Cela se heurte au fait que soit nous tuons l'initiative de l'équipe, soit nous arrivons à une situation où l'équipe est plus intéressée par la technologie que par le produit.
Comment traiter : vous devez identifier la cause de la méfiance à l'égard de l'équipe ou de son indécision: pourquoi l'équipe ne recherche pas une solution, mais travaille uniquement avec une tâche technique détaillée? Après avoir trouvé la cause, vous pouvez l'éliminer progressivement. Par exemple:
- L'équipe manque de compétences ou d'expérience. : Quelqu'un travaille sur des solutions et écrit des savoirs traditionnels, vous pouvez soit ajouter cette personne à l'équipe, soit la laisser travailler sur certaines tâches avec l'équipe, transférant ainsi une partie de ses compétences et de son expérience à l'équipe. Alors, progressivement, l'équipe apprendra et s'habituera à résoudre les problèmes de produits.
- La direction craint que l'équipe ne fasse une erreur. : C'est la pierre angulaire de la transition vers l'agilité, mais sans la surmonter, vous ne pourrez pas gagner toute la force de l'équipe Scrum. L'équipe ne peut que se tromper, car tout le monde se trompe. Mais une erreur est une source d'expérience et de compétence. Il est plus utile lorsqu'une équipe fait une erreur, parce qu'elle en a décidé ainsi, et non à cause d'un savoir traditionnel externe incorrect. Scrum est rythme: a rapidement pris la décision de tester une hypothèse; Réactions reçues réalisé qu'ils ont fait fausse route; a rejeté la décision. Le coût d'une erreur est fortement réduit ( passé un sprint, pas un trimestre / an / votre période de sortie ), ce qui vous permet de dépasser la peur de l'erreur.
Symptôme : les membres de l'équipe n'ont pas librement accès aux artefacts de l'équipe. Par exemple, tout le monde ne voit pas un sprint ou un backlog général, ou il y a des difficultés avec la possibilité de mettre à jour son statut.
Ce qui est mauvais : Scrum est basé sur la transparence, les artefacts aident à augmenter la transparence. Si les membres de l'équipe ont du mal à travailler avec ces artefacts, alors les membres de l'équipe eux-mêmes n'ont pas de transparence dans le travail d'équipe, et pour les autres parties intéressées, la situation sera encore pire: il n'est pas clair qui fait quoi et pourquoi. Il n'est pas clair où l'équipe se dirige vers le but.
Comment traiter : Il est nécessaire de déterminer les formats des artefacts de mêlée dans une équipe et de les fabriquer ( vous pouvez consacrer cette rétrospective ), puis de les placer de sorte que l'équipe soit à l'aise de travailler avec eux. C'est génial si vous pouvez créer un espace séparé pour l'équipe, les conditions dans lesquelles l'équipe travaillera côte à côte (épaule contre épaule) en même temps. Cela réduira les frais de communication. Et dans l'espace commun, il est facile de tout visualiser ( tableaux à feuilles mobiles, autocollants, marqueurs sont les outils préférés d'Agile ), l'essentiel est qu'il soit pratique, pas stressant pour l'équipe. Les artefacts devraient aider et ne pas interférer avec le travail de l'équipe, pas le bureaucratiser. L'interaction verbale est bonne pour le travail d'équipe. S'il y a des difficultés avec l'organisation du travail local de l'équipe ( par exemple, distribué ou à distance ), vous devez maximiser l'effet du travail d'équipe et de l'unité. Par exemple, des canaux de présence vidéo, des tableaux de mêlée interactifs en vue directe de chaque membre de l'équipe, etc.
Conclusion
Dans la partie suivante, nous continuons à considérer les rôles de la mêlée et nous arrivons enfin au maître de mêlée. Rappelez- vous brièvement quoi faire avec les symptômes:
- Sélectionnez les symptômes qui s'appliquent à votre situation.
- Parmi ceux-ci, choisissez le plus net.
- Prenez conscience de cette douleur.
- Vous venez avec une solution d'équipe ( vous pouvez prendre des cas de l'article comme point de départ ).
- Mettez en œuvre votre décision.
- Passez à l'étape 1.
Merci d'avoir lu, j'aimerais voir les "symptômes" que vous connaissez dans les commentaires.
Merci à Sai Kin pour l'illustration.
La prochaine partie sur l'Assistant Scrum