Votre navigateur ne supporte pas JavaScript !
  • LinkedIn
  • YouTube
  • RSS

L'équipe Scrum

L'équipe Scrum est composée des personnes qui travaillent réellement sur les projets suivants Éléments du carnet de commandes du produit au cours d'une SprintL'unité fondamentale de Scrum est une petite équipe de personnes, l'équipe Scrum. L'équipe Scrum est composée d'un Scrum Master, un Product Owneret Developers (toute personne travaillant sur le sprint incrément). Au sein d'une équipe Scrum, il n'y a pas de sous-équipes ni de hiérarchies. Il s'agit d'une unité cohésive de professionnels qui se concentrent sur un seul objectif à la fois, la Objectif du produit.

Les équipes Scrum sont interfonctionnelles, ce qui signifie qu'elles possèdent toutes les compétences nécessaires pour créer de la valeur pour chaque Sprint. Elles sont également autogérées, ce qui signifie qu'elles décident en interne qui fait quoi, quand et comment. L'équipe Scrum est responsable de toutes les activités liées au produit, qu'il s'agisse de la collaboration avec les parties prenantes, de la vérification, de la maintenance, de l'exploitation, de l'expérimentation, de la recherche et du développement ou de toute autre activité nécessaire. L'ensemble de l'équipe Scrum est responsable de la création d'un incrément précieux et utile à chaque sprint.

Temps estimé pour ce cours: 30 minutes
Audience: Débutant
Prérequis suggérésScrum Cadre

À l'issue de la formation, vous serez en mesure de

  • Comprendre le rôle de l'équipe dans Scrum
  • Connaître les 3 attributs les plus importants d'une équipe Scrum
  • Découvrez l'histoire des équipes Scrum
Vue d'ensemble de l'équipe Scrum

Dans l'original Harvard Business Review qui a inspiré la création de Scrum, "Le nouveau jeu du développement de nouveaux produitsLes professeurs Hirotaka Takeuchi et Ikujiro Nonaka ont observé que les grandes équipes étaient.. :

1. Transcendant: Ils ont un but qui dépasse l'ordinaire. Cet objectif qu'ils réalisent eux-mêmes leur permet de passer de l'ordinaire à l'extraordinaire. D'une manière très concrète, la décision même de ne pas être dans la moyenne, mais d'être génial, change la façon dont ils se perçoivent et ce dont ils sont capables.

2. Autonome: Les équipes sont auto-organisées et autogérées, elles ont le pouvoir de prendre leurs propres décisions sur la manière dont elles font leur travail et sont habilitées à faire appliquer ces décisions.

3. Fonctionnalité transversalel : Les équipes possèdent toutes les compétences nécessaires pour mener à bien le projet. Planification, conception, production, vente, distribution. Et ces compétences se nourrissent et se renforcent mutuellement. C'est ce que décrit un membre de l'équipe qui a conçu un nouvel appareil photo révolutionnaire pour Canon : "Lorsque tous les membres de l'équipe se trouvent dans une grande pièce, les informations de quelqu'un deviennent les vôtres, sans même que l'on s'y efforce. Vous commencez alors à penser en termes de ce qui est le mieux ou le moins bien pour l'ensemble du groupe et pas seulement pour vous."

L'idée de transcendance pose parfois problème. La transcendance est l'esprit d'équipe. Au début de chaque réunion quotidienne, la première équipe Scrum a visionné une vidéo sur les thèmes suivants Les All Blacks de Nouvelle-Zélande l'équipe de rugby. L'énergie de cette équipe est palpable. Ils sont unis dans un même but. La première équipe de Scrum a voulu capturer cet esprit : la détermination d'écraser tout obstacle, l'esprit de célébrer chaque succès, l'objectif de la victoire. C'est la transcendance de l'équipe, qu'il s'agisse d'une équipe sportive ou de la fourniture de produits ou de services de qualité.

Si vous êtes intéressé par une formation plus approfondie sur ce sujet, suivez notre Scrum Startup for Teams cours en ligne et obtenir le titre de compétence Scrum Team Member. 

Voir et télécharger les diapositives du cours

 

[slideshow_deploy id='11817']

En savoir plus sur les équipes

Au début des années 1990, Jim Coplien a été invité à évaluer un projet de la Borland Software Corporation. Il s'agissait de créer un nouveau tableur appelé Quattro Pro pour Windows. Le logiciel comptait plus d'un million de lignes de code, a nécessité trente et un mois de travail et une équipe de huit personnes. Cela signifie que chaque membre de l'équipe a produit mille lignes de code par semaine. C'est plus de code en moins de temps que n'importe quelle autre équipe. (Voir l'article de Coplien dans l'onglet Papiers et modèles).

Pour comprendre pourquoi l'équipe de Borland était si rapide, Coplien a cartographié tous les flux de communication au sein de l'équipe - qui parlait à qui, où l'information circulait et où elle ne circulait pas. Ce type de cartographie est un outil classique qui peut être utilisé pour repérer les goulets d'étranglement ou les accumulateurs d'informations. Plus la saturation de la communication est grande, plus tout le monde sait tout, plus l'équipe est rapide. En fait, l'indicateur issu de ce type d'analyse mesure à quel point chacun sait ce qu'il a besoin de savoir pour accomplir son travail. L'équipe de Borland a toujours obtenu la note la plus élevée : 90 %. La plupart des entreprises tournent autour de 20 %.

La saturation de la communication est entravée par la spécialisation, c'est-à-dire le nombre de rôles et de titres au sein d'un groupe. Si les gens ont un titre spécifique, ils ont tendance à n'effectuer que les tâches qui correspondent à ce titre. Et pour protéger le pouvoir de ce rôle, ils ont tendance à s'accrocher à des connaissances spécialisées. C'est pourquoi le Scrum n'a que trois rôles : une personne est soit membre de l'équipe, soit du Scrum Master, soit du Product Owner. Cela peut s'avérer difficile pour les organisations traditionnelles, mais c'est essentiel pour obtenir le type d'augmentation de la productivité que Scrum peut apporter.

Tout comme le nombre de rôles a un impact sur les performances, le nombre de personnes au sein d'une équipe a également un effet dramatique. La dynamique d'équipe ne fonctionne bien que dans les petites équipes. La formule classique est de sept personnes, plus ou moins deux, mais les équipes les plus rapides tournent généralement autour de cinq personnes. Ce qui est fascinant, c'est que la Les données montrent que si une équipe compte plus de neuf personnes, la vélocité ralentit.. Il est surprenant de constater qu'un plus grand nombre de ressources permet aux équipes d'être plus performantes. plus lent.

Dans le domaine du développement de logiciels, il existe une expression appelée "loi de Brooks". Fred Brooks l'a inventé pour la première fois dans son livre fondateur de 1975, intitulé Le mois de l'homme mythique. En d'autres termes, Loi de Brooks déclare "l'ajout de main-d'œuvre à un projet logiciel tardif le rend plus tardif." Cela a été confirmé étude après étude. Lawrence Putnam, figure légendaire du développement de logiciels, a consacré sa vie à étudier le temps nécessaire à la fabrication des produits et les raisons de ce temps. Ses travaux n'ont cessé de montrer que les projets auxquels participaient vingt personnes ou plus nécessitaient plus d'efforts que ceux auxquels participaient cinq personnes ou moins. Pas seulement un peu, mais beaucoup. Une grande équipe prend environ cinq fois plus d'heures qu'une petite équipe. Ayant constaté ce phénomène à maintes reprises, il a décidé, au milieu des années 1990, de mener une étude à grande échelle pour déterminer la taille adéquate d'une équipe. Il a donc examiné 491 projets de taille moyenne dans des centaines d'entreprises différentes. Il s'agissait de projets qui nécessitaient la création de nouveaux produits ou de nouvelles fonctionnalités, et non la réadaptation d'anciennes versions. Il a divisé les projets en fonction de la taille de l'équipe et a tout de suite remarqué quelque chose. Dès que les équipes dépassaient huit personnes, elles mettaient beaucoup plus de temps à travailler. Les groupes composés de trois à sept personnes nécessitaient environ 25 % de l'effort des groupes de neuf à vingt personnes pour accomplir la même quantité de travail. Ce résultat s'est répété sur des centaines et des centaines de projets. Le fait que les grandes équipes accomplissent moins de choses que les petites semble être une règle absolue de la nature humaine. (Voir l'onglet Diapositives)

Transversalité et jumelage

Trop souvent, il y a des tâches qu'une seule personne de l'équipe peut accomplir. Cette situation est fréquente dans les équipes Scrum débutantes. Il convient d'y remédier le plus rapidement possible. En effet, si une seule personne peut effectuer le travail et que cette personne n'est pas disponible, c'est toute l'équipe qui s'arrête. Les gens tombent malades, les gens changent d'emploi ; vous ne pouvez pas vous permettre que votre organisation soit prise en otage par un seul ensemble de compétences.

Les bonnes équipes Scrum veillent à ce qu'au moins deux personnes, et idéalement plus, puissent effectuer une tâche. Les équipes qui résolvent ce problème ont tendance à augmenter leur nombre d'heures de travail. Vélocité. La raison en est que c'est le savoir collectif, et non les compétences individuelles, qui améliore la rapidité de l'équipe. Les individus peuvent faiblir, mais si le reste de l'équipe peut continuer, la productivité n'en souffre pas.

La meilleure façon de s'assurer que votre équipe n'est pas limitée est peut-être le jumelage et la formation croisée. S'il n'y a qu'une seule personne capable d'effectuer une tâche, assurez-vous que la prochaine fois que cette tâche se présentera, elle sera jumelée avec quelqu'un d'autre afin que cette personne puisse apprendre. Encouragez tous vos employés à suivre des formations croisées dans divers domaines de compétences. Non seulement vous en récolterez les fruits, mais ils seront plus engagés et enthousiastes à mesure qu'ils acquièrent de nouvelles compétences.

Papiers et motifs

Papier : Document de Borland sur les équipes

Modèle : Équipe autonome

Modèle : Équipe stable

Le Scrum Pattern Language of Programing : Le mouvement PLoP codifie des pratiques Agiles bien connues qui ont fait leurs preuves.ly implemented à plusieurs reprises.

 

fr_FRFrench
Actions