L'équipe Scrum

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)

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.

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.