Scrum pour les équipes de spécialistes

Scrum est le meilleur pour les équipes avec des membres généralistes, c'est-à-dire des équipes où 2 personnes au moins peuvent effectuer les mêmes tâches. Ma préoccupation principale est de trouver de bonnes solutions pour adapter la mêlée (que garder, que retirer, quoi améliorer) pour des équipes composées de spécialistes?

Supposons que vous ayez une équipe de 5 développeurs (pas réel, juste pour l'exemple):

1. Un mathématicien avec de solides compétences en C;
2. Un développeur DB;
3. Un développeur Web;
4. Un développeur UX / GUI;
5. Un architecte logiciel;

Ici, tous sont des spécialistes et personne ne peut remplacer quelqu'un d'autre (je me fiche des risques de construire une telle équipe, je veux me concentrer sur la mêlée). Donc, dans un contexte de mêlée, voici mes réflexions:

1. Planifications de printemps inutiles: en effet, lorsque le mathématicien dit qu'une tâche spécifique vaut 2 points, personne ne peut voter contre lui;
2. Métrique inutile de vitesse d'équipe: comme tout le monde peut allouer n'importe quel nombre de points à ses propres tâches, calculer la vitesse n'a pas de sens;
3. Remplacer les réunions de mêlée quotidiennes par des réunions de mêlée hebdomadaires (plus longues): comme chaque membre de l'équipe travaille sur ses propres tâches, les réunions de mêlée quotidiennes devraient être très importantes pour garder un "esprit d'équipe". Cependant, les réunions de mêlée quotidiennes devraient durer environ 15 minutes. Ce n'est clairement pas suffisant pour comprendre ce que font et feront les autres. De plus, le mathématicien répondra la plupart du temps aux mêmes choses: "Je fais toujours % & Lo (+? $$ + &)" ... Les réunions hebdomadaires donneraient plus de temps. Pour garder le même temps de réunion entre les réunions de mêlée «initiales» et les réunions de mêlée «hebdomadaires», chaque réunion de mêlée hebdomadaire devrait durer (5 jours par semaine, avec des sprints de 4 semaines, avec des réunions de sprint de 4 heures et des réunions quotidiennes de 15 minutes): (4 * 60 + 20 * 15) / 4 =>

Ou la mêlée est-elle toujours utilisable? Peut-être qu'une autre technique agile devrait être utilisée?

Scrum n'est pas une solution miracle. Tous les projets ne doivent pas utiliser Scrum pour réussir. La situation que vous décrivez semble cependant parfaitement adaptée à Lean / Kanban. Vous voudrez peut-être le vérifier.

Kanban vous demande essentiellement de ne faire que quelques choses, dont aucune ne va à l'encontre du type d'équipe que vous décrivez:

• Visualisez le flux de valeur, c'est-à-dire le tableau Kanban. Le tableau Scrum est une application spécifique d'un tableau Kanban; Il est possible de l'adapter pour permettre une spécialisation.
• Limitez le travail en cours (WIP), de sorte que la quantité de travail assignée à l'équipe soit juste suffisante pour que le travail continue à circuler, c'est-à-dire pas de "blocage" au début du flux (conception) ou à la fin (déploiement) .

Vous voudrez peut-être consulter quelques références sur Kanban:

• Un jour à Kanban Land
• Amorçage Kanban (EBook gratuit)

Vous vous concentrez un peu trop sur la mécanique de la mêlée / agile sans regarder ce que l'agile est censé offrir. Vous dites que si le gars en mathématiques estime 2 points, personne ne peut dire qu'il a tort. Ce n'est pas le but. Le but est de convenir d'un ensemble d'objectifs réalisables pour le prochain sprint. En tant qu'expert de cette tâche, il saura mieux combien de temps cela prendra.

"Alors, s'il ment ou se trompe?" vous dites. D'après mon expérience, les gens sous-estiment davantage parce qu'ils craignent d'être abattus pour avoir donné une estimation précise. D'autres sous-estimés ajoutent ensuite une marge de sécurité qui équilibre tout et le paresseux bizarre surestimera afin de ne pas avoir à se précipiter. Des trois, le premier sera capté par le suivi de la vélocité, le second, tout en sonnant mal, fonctionne et le troisième est quelque chose que vous devez gérer en dehors de la mêlée.

La réunion quotidienne offre toujours des avantages. Il existe des dépendances entre les membres de l'équipe même s'ils sont chacun des spécialistes. Le gars de l'interface peut attendre le gars du serveur pour corriger un bogue de notification. Le gars du serveur attend peut-être le gars des mathématiques pour comprendre pourquoi un calcul est incorrect. Il ne s'agit pas seulement de savoir comment leur travail vous affecte. Si un membre de l'équipe est constamment retardé à cause de la "Raison X" mais qu'il n'a pas pris le temps d'atténuer les futurs événements de la "Raison X", cela peut être contesté.

Si vous avez un spécialiste avec des qualifications comme celles que vous avez décrites, votre supposition que chacun travaille sur sa propre tâche, avec rarement besoin de communiquer aux autres, est à mon humble avis. En fait, pour réaliser une nouvelle fonctionnalité (une "user story"), vous devrez souvent

• changer votre base de données
• ajouter ou modifier l'interface graphique ou l'interface Web
• combinez cela avec la logique métier correcte (où, peut-être, votre "mathématicien" entre en jeu)
• assurez-vous que tous ces changements fonctionnent bien ensemble

Je suppose donc qu'ils devront communiquer beaucoup plus que dans une équipe de généralistes, où tout le monde pourrait travailler sur une application / histoire utilisateur différente, en apportant lui-même toutes les modifications nécessaires à toutes les couches d'application. Ainsi, toutes les activités d'équipe de Scrum que vous avez énumérées ci-dessus ont beaucoup de sens pour une telle équipe.

Scrum est certainement toujours approprié à votre situation, mais il en va de même pour d'autres cadres.

Pour proposer de nouvelles fonctionnalités, vous aurez probablement besoin de tout ou partie de ces compétences. Pour que l'équipe prenne des décisions qui s'influencent les unes les autres et travaillent ensemble, elle devra communiquer. Plus le temps entre les réunions Scrum est long, plus un plan négatif peut égarer l'équipe. En se réunissant quotidiennement, l'équipe peut traiter rapidement ces situations et proposer un nouveau plan.

Je voudrais également aborder certains sujets spécifiques que vous soulevez:

Équipes interfonctionnelles Une équipe serait considérée comme interfonctionnelle si elle possède toutes les compétences nécessaires pour atteindre un objectif de sprint et / ou un élément de backlog de produit. Cela ne signifie pas qu'il y a 2 personnes pour chaque emploi.

Dimensionnement Il est important de se rappeler que nous dimensionnons un problème ou un besoin métier, pas une solution ou une partie d'une solution. Par exemple, l'intégration des médias sociaux / Twitter dans notre site de commerce électronique est un problème qui nécessite UX, conception d'interface utilisateur, programmation, base de données et connaissance de l'API Twitter. Une équipe devrait dimensionner cela en tant qu'unité puisqu'ils, en tant qu'équipe, fourniront cette fonctionnalité. Cette taille ne sera pas exacte à 100%, mais nous constatons que, globalement, les prévisions basées sur un dimensionnement relatif sont plus précises. Cela signifie que certains seront élevés, certains seront faibles et, pris ensemble, la prévision calculée est plus précise que la durée estimée.

Planifications de printemps inutiles La planification du sprint est le moment de collaborer en tant qu'équipe Scrum (équipe de développement + propriétaire du produit + Scrum Master) pour déterminer ce qui doit être produit et élaborer un plan pour commencer. Certaines équipes décomposeront ces éléments de backlog de produit choisis en tâches tandis que d'autres trouveront leur propre façon de progresser, comme des tests qui doivent réussir (pensez XP).

Il s'agit d'une collaboration à double sens. Attribuer à l'équipe un ensemble de PBI et dire "go" est le rôle d'un dictateur. L'équipe négocie avec le Product Owner pour maximiser le temps dans le sprint.

Mesure de la vitesse de l'équipe inutile Avec les équipes qui évaluent les problèmes et les besoins de l'entreprise qui traversent l'architecture / le système et l'expérience passée nous indiquant combien de celles-ci ont été livrées dans une boîte de temps cohérente (sprint), nous pouvons maintenant fournir une prévision d'équipe pour le reste de l'arriéré.

Encore une fois, il n'y aura pas deux sprints identiques et plus le jeu d'échantillons d'articles Backlog produit que vous utilisez est petit, moins l'erreur dans les estimations sera étalée. Pensez-y comme à la bourse; il a toujours augmenté, mais cela ne veut pas dire que nous n'avons pas de baisse des années. Au total, vous pouvez gagner de l'argent, mais sur un mois, un trimestre ou une année donné, vous vous tromperez.

Remplacer les réunions de mêlée quotidiennes par des réunions de mêlée hebdomadaires (plus longues) La mêlée quotidienne est là pour fournir à l'équipe un cycle de rétroaction 24h et la possibilité de planifier pour les prochaines 24 heures. Ni plus ni moins. Les «trois questions» visent à faciliter cet effort.

Si vous n'avez pas de commentaires pendant 5 jours, je pense que vos tâches ne sont pas assez fines. C'est simplement mon opinion, mais elle est basée sur mon expérience en tant qu'entraîneur et membre de l'équipe. Les équipes devraient parler, planifier et intégrer leurs efforts FAR plus souvent.

Conclusion Scrum est destiné à faciliter l'apprentissage et à équilibrer cet apprentissage avec la livraison (où un véritable apprentissage se produit). Expérimentez avec vos processus et outils au fil du temps et utilisez Scrum pour inspecter l'impact. Essayez de passer de Scrums quotidiens à hebdomadaires et voyez si cela aide ou nuit à la capacité des équipes à fournir les bonnes fonctionnalités. Cela peut fonctionner pour vous.