Plusieurs équipes Scrum passent à un seul carnet de commandes

Nous avons actuellement 5 équipes Scrum qui travaillent sur leur propre carnet de produit pour l'année écoulée. Chaque équipe travaille sur son propre système dédié mais la technologie sous-jacente est le même .Net.

Il y a eu beaucoup de discussions sur le passage à des équipes basées sur des fonctionnalités travaillant sur un seul backlog. La raison en est que l'un de nos principaux systèmes a une quantité importante de travail à venir et leur capacité n'est pas suffisante pour fournir tout le travail dans l'année. L'autre raison qui, selon moi, est la plus importante est qu'elle donne une plus grande flexibilité pour s'adapter rapidement aux changements dans le portefeuille.

La décision a été prise de changer deux équipes pour travailler sur un seul backlog mais les développeurs n'ont pas d'expérience sur les autres systèmes. Une des choses que nous faisons est de développer les compétences croisées en déplaçant un développeur de système d'expérience au sein de l'équipe.

Ma question est la suivante: avez-vous expérimenté le passage à un seul backlog pour deux systèmes différents ou plus. Quels ont été vos défis? De quoi aviez-vous besoin pour le faire fonctionner?

Nous gérons environ une demi-douzaine de projets en utilisant un seul backlog. Je dis «à propos» car cela dépend de la façon dont vous souhaitez différencier les projets.

En gros, nous avons cinq ou six propriétaires de produits, dont certains possèdent plus d'un produit. Nous avons une équipe assez petite avec sept développeurs et un chef d'équipe qui code également quand il a le temps. Et nous avons quelques évangélisateurs qui travaillent avec nos gens du processus pour déplacer des idées dans le pipeline. Bien sûr, plusieurs personnes portent plusieurs chapeaux, ce qui brouille les choses, mais je vais ignorer cela pour ma réponse. Fait intéressant, nous n'avons pas de maître de mêlée officiel.

Nous n'avons pas eu à fusionner les arriérés, mais cela semble être une tâche simple de votre côté.

Garder les choses organisées peut être une vraie douleur, alors voici quelques points que vous voudrez considérer.

• La gouvernance est la clé. Tous ceux qui ont un doigt administratif dans le gâteau doivent communiquer avec les autres avant d'apporter des changements importants. Et / ou ceux qui apportent des changements doivent être à l'aise avec leur autorité pour le faire (et être prêts à prendre la chaleur d'un mauvais changement). Nos responsables du changement bénéficient d'un solide soutien de la part des dirigeants et les lignes sont assez clairement dessinées autour des domaines. Mais quand il y a un doute, nous demandons avant de changer.

• Il peut y avoir plus de frais généraux liés à la préparation du backlog, à la priorisation et aux lancements. La priorisation en tant que rituel souffre le plus car il est difficile de réunir régulièrement tous les propriétaires. Nous utilisons un certain nombre d'intermédiaires pour négocier la priorité et / ou annoncer la mauvaise nouvelle de ne pas faire la priorité.

• Une grande partie de notre travail est motivée par un engagement extérieur. Cela enlève une partie de l'autonomie de nos décisions, mais c'est la réalité des affaires. Vos développeurs doivent cependant être conscients de ce changement. Les plumes peuvent être ébouriffées en cas de perte de contrôle. Nous essayons de ne pas trop nous engager, et nous avons dû dire «non» à certains propriétaires de produits qui étaient sur le point de passer au sprint.

• Nous utilisons généralement deux méthodes pour baliser le produit auquel appartient un élément de backlog de produit. Nous utilisons les deux simplement parce que cela facilite le toilettage et d'autres tâches.

  1. Nous ferons précéder le titre PBI du nom du produit ou de la version abrégée.
  2. Nous avons un champ séparé qui indique le produit global, et qui doit également être rempli.

• Nous devons déployer des efforts conscients dans la formation croisée et veiller à ce que tout le monde prenne la main dans les différents domaines. Nous avons une très grande base de code par rapport à notre équipe de développement. Une partie du code que nous faisons est également très spécialisée. Notre chef d'équipe est génial à cet égard et il va pousser notre niveau d'engagement d'un cran afin que nous puissions nous permettre les inefficacités qui découlent de la formation croisée. Il est essentiel à cet égard d'avoir un solide leadership d'équipe.

• Nous faisons de notre mieux pour maintenir nos délais de sprint. Les projets complexes avec de nouveaux membres de l'équipe se traduisent par des débordements non rares avec des engagements. Le processus autour de votre ramification sera vraiment utile ici. Tout notre travail est effectué contre une branche qui est ensuite fusionnée vers une version de tronc. Nous avons également un serveur de génération qui s'exécute tous les soirs en plus des déclencheurs ad hoc. Les développeurs qui interrompent la construction connaissent et résolvent le problème dans les 24 heures. Période. Si vous ne parvenez pas à résoudre le problème dans les 24 heures, votre engagement est annulé et les développeurs seniors leur font du chagrin. Et les développeurs seniors sont les plus durs envers eux-mêmes quand il s'agit de maintenir la build.

• Les révisions et revues de code deviennent encore plus critiques. Il permet de tenir tout le monde au courant de ce qui change dans les différents domaines.

• De même, le standup quotidien implique tous les développeurs et nos utilisateurs de l'interface utilisateur. Nous sommes au bord de la communication collaborative bénéfique et de l'inefficacité de trop de gens. Mais nous maintenons le standup à moins de 15 minutes et nous passerons rapidement des discussions parallèles. Habituellement, nous avons terminé en 5 à 10 minutes.

• Je ne peux pas parler des effets sur les paramètres tels que la vitesse ou l'engagement global et les taux de burndown. Ces aspects n'ont tout simplement pas été suffisamment importants pour que nous puissions suivre de près. YMMV, alors prenez cela en considération. Cela suppose également que chaque équipe a une définition raisonnablement similaire du point d'histoire. Sinon, cela va gâcher les estimations initiales après la fusion. Cela générera également des problèmes pour les comparaisons historiques, car vous n'utilisez pas la même unité de mesure qu'auparavant. La solution la plus simple consiste à simplement la déclarer "nouvelle équipe" pour les mesures et à commencer à rassembler les données après la fusion.

• Nous avons vu un avantage significatif de cette approche. Nous avons eu des sprints où toutes les mains sont concentrées sur un seul domaine et nous pouvons éliminer beaucoup de changements en peu de temps. Vous ne devez pas sous-estimer la valeur qui vient de pouvoir appliquer rapidement le double du nombre normal de développeurs sur un projet particulier. Mais vous devez mettre en place la formation croisée à l'avance. Cela signifie également que nous n'avons jamais de développeurs avec "rien à faire" à cause des cycles de test ou du toilettage ou autre. Nous avons toujours un arriéré à régler.

• Consacrer du temps aux projets de R&D. Sinon, il leur est trop facile de passer à travers les mailles du filet et vous perdez la possibilité d'investir dans ces domaines.

• Travaillez vraiment sur le codage sans ego et que même si vous avez des experts dans un domaine, vous n'avez pas de propriétaires de zone de code. Il est important d'empêcher la possibilité d'ego meurtri lorsque différents styles sont introduits dans une zone. Tant que le nouveau code répond aux normes de l'équipe et est fonctionnel, il devrait être bon. Tout simplement parce que ce n'est pas comme cela que l'expert aurait fait, cela n'a pas d'importance.

• Assurez-vous que les équipes impliquées utilisent les mêmes conventions de codage et le même style. Rien de tel qu'une incohérence ici pour faire des ravages sur vos tentatives d'intégration.

• Gardez vos rétrospectives et tenez-les en groupe. Il est important d'obtenir les commentaires de tout le monde sur ce qui fonctionne, ce qui ne fonctionne pas et ce qui doit être essayé différemment. Cela contribue à créer un sentiment de camaraderie au sein de l'équipe et donne un sentiment d'appropriation du processus de développement.

La bonne réponse Scrum est "Demandez aux équipes". C'est le principe de l'auto-organisation où ils devraient pouvoir se restructurer pour faire le travail rapidement. Vous voyez que beaucoup de gens dans les équipes ont plus de connaissances contextuelles qu'un étranger et ils savent ce qui est le mieux. Cela inclut également le propriétaire du produit.

Je suppose que vous êtes venu ici et avez posé la question, car il y a quelque chose qui ne va pas et vous avez des préoccupations cachées. Je vais donc vous donner quelques conseils pour discuter avec l'équipe afin de prendre la bonne décision.

Propriétaire du produit

Il n'y a qu'un seul propriétaire de produit pour un carnet de commandes et il doit s'agir d'un homme d'affaires ou d'une personne représentant l'entreprise. Il ne doit pas s'agir de gestion informatique. Un gros carnet de commandes comporte de nombreux éléments et avec plusieurs équipes, il pourrait être trop difficile de gérer un seul bon de commande. Vous souhaiterez peut-être garder les backlogs séparés pour cette raison.

S'il y a plusieurs bons de commande, vous avez certainement besoin de plusieurs backlogs car les équipes doivent être dédiées dans un sprint à un seul bon de commande et backlog. La raison en est qu'une équipe n'a pas besoin de gérer les conflits entre les priorités des propriétaires de produits.

Développement de produits contre maintenance

Les équipes de maintenance travaillent sur de nombreuses petites améliorations, des bugs sur plusieurs produits différents et éventuellement avec plusieurs propriétaires de produits. Ces équipes BAU ont besoin du soutien de la direction informatique pour planifier et gérer les conflits entre plusieurs propriétaires de produits.

Les équipes de projet doivent se concentrer sur un produit à la fois pour minimiser le changement de contexte et fournir un excellent produit à la fois. Le changement de contexte pourrait entraîner la livraison de nombreux produits médiocres avec un certain degré de dette technique.

Changement de contexte

Travailler sur plusieurs produits ou différentes fonctionnalités entraîne un changement de contexte qui ralentit la productivité des équipes. Le PO devrait en tenir compte lors de l'élaboration de la prochaine étape et de l'équipe qui devrait travailler sur quel travail. La quantité de changement n'est pas négligeable et pas seulement un problème théorique, c'est réel et j'ai vu une équipe perdre jusqu'à 80% de productivité à cause de cela.

Un bon PO essaiera les fonctionnalités de groupe et le type de travail pour aider les équipes à faire moins de changement de contexte, améliorant ainsi leurs performances.

Risque

Malheureusement, la direction essaie de mettre le risque de temps, d'argent, de budget et de pression commerciale sur l'équipe; et les équipes l'acceptent en acceptant cela. En tant que professionnel du développement, vous devez simplement énoncer les faits et les impacts des décisions et faire en sorte que l'entreprise assume ses propres risques.

Exemples

• Accepter un moment ridicule. Dites plutôt quels efforts cela va prendre pour faire le travail correctement et faire en sorte que les entreprises gèrent le problème de temps

• Estimations. Les entreprises attendent des équipes qu'elles évaluent avec précision dans un monde de complexité et d'incertitude. Les équipes doivent demander aux entreprises ce qu'elles font pour atténuer si les estimations sont dépassées en raison de défis imprévus, qui sont très probables. Les équipes ne devraient pas prendre en compte la graisse, mais les entreprises devraient le faire.

• Dette technique. Les équipes doivent estimer la réalisation d'un code de haute qualité entièrement testé et estimer cela, c'est-à-dire arrêter d'écrire les défauts dus aux pressions. Si les entreprises veulent une qualité inférieure, c'est leur risque à prendre et quand les choses tournent mal, c'est leur problème.

Professionnalisme

Soyez un professionnel en déclarant construire les bonnes choses à la qualité convenue. Estimez votre meilleure capacité en fonction des faits à portée de main. Lorsque ces faits changent, communiquez-le et ajustez l'estimation. En tant qu'équipe de développement, construisez d'excellents produits et ne prenez aucun risque commercial. Communiquer et gérer les attentes.

Inspecter et adapter

Les équipes devraient toujours chercher des moyens de s'améliorer et si elles estiment que cela va améliorer les choses, elles devraient l'essayer. Inspectez ensuite pour voir s'il y a des améliorations. Enfin, ils doivent adapter et améliorer leur nouvelle approche ou l'abandonner s'ils ne fonctionnent pas. L'intention derrière la recherche d'amélioration devrait toujours être là.

Bottom Line

En fin de compte, la gestion de l'arriéré est le choix du bon de commande. La manière dont il souhaite gérer la file d'attente de travail lui appartient. La seule pensée est qu'ils DOIVENT garder le pipeline de travail pour TOUTES les équipes en bonne santé et en bon état. Il appartient donc au PO de décider.

Le contrat

Dans les sessions de planification de sprint, l'équipe doit s'attendre à une liste d'éléments de backlog de produits soignés qui sont clairs, sans ambiguïté et ordonnés. Après une brève discussion avec l'OP, l'équipe devrait savoir exactement ce que l'OP veut; le QUOI . L'équipe se concentre ensuite sur la façon dont elle va construire.

Si le bon de commande arrive à la réunion de planification bien préparé, qui se soucie de la façon dont l'arriéré est géré. Si le PO n'est pas préparé à la réunion de planification du sprint, cela devrait être traité par le SM et rendu très visible car c'est totalement inacceptable et pas un problème d'équipe à assumer.

Nous avons récemment absorbé le carnet de commandes d'une autre équipe. L'équipe n'avait qu'un seul membre (pas beaucoup d'une équipe, je sais), mais il y a un travail réel sur leur arriéré. Nous ne connaissons pas très bien leur travail et ils ne connaissent pas très bien le nôtre.

Même si vos arriérés sont fusionnés, cela ne signifie pas que tout le monde doit travailler sur tout immédiatement. Il n'est pas raisonnable de s'attendre à cela, alors ne vous inquiétez pas trop pour que tout le monde puisse tout faire dans les deux arriérés immédiatement.

Au lieu de cela, commencez par faire travailler les deux équipes sur ce sur quoi elles travaillaient auparavant; la seule différence est que tout est dans le même arriéré.

Ensuite, à chaque itération / sprint, certains membres de chaque équipe travaillent sur des histoires de l'autre backlog. En ne faisant pas travailler tout le monde sur des éléments inconnus en même temps, vous répartissez le coût de l'apprentissage des systèmes des autres . Au fil du temps, votre équipe absorbera progressivement les connaissances des autres.

Si vous faites tout l'apprentissage à l'avance, il y aura des pénalités de performance importantes. Quelqu'un dans la haute direction le remarquera sûrement, et vous serez obligé d'absorber l'arriéré d'une autre équipe dans l'espoir qu'une nouvelle équipe puisse compenser les mauvaises performances ... :) Blagues à part, cependant, ce serait ma recommandation.

Je suppose que la raison pour laquelle vous (ou la direction) souhaitez créer un backlog fusionné pour deux équipes est que vous voulez pouvoir sélectionner uniquement les éléments de backlog pour l'un des systèmes et que les deux équipes y travaillent.

Dans ce cas, attendez-vous à beaucoup de frictions de la part de l'équipe contrainte de travailler sur le système qu'elle ne connaît pas. Attendez-vous à ce que l'équipe prenne chaque paille (c'est-à-dire un petit élément de carnet de commandes lié à son système "domestique") pour continuer à travailler sur le système sur lequel elle travaillait auparavant. Qui doit leur en vouloir? Ce n'est pas amusant de travailler sur quelque chose que vous n'êtes pas bon. Et le fait que l'autre équipe soit bonne comme quelque chose que vous n'êtes pas bon ne fait qu'empirer les choses - car cela vous rend encore plus stupide.

Ainsi, la seule façon de réussir est de diviser les deux équipes et de les former en deux équipes mixtes. Alors seulement, il y a une chance que tous les développeurs soient rapidement mis à jour sur le système (actuellement) "important".

Ce n'est pas très bon de procéder ainsi. Mon entreprise précédente est passée en mode mono-produit et en équipe unique, car dans une grande entreprise, nous avions différentes personnes travaillant sur différentes choses.

Passer d'un projet à un autre coûte également des efforts, et s'il y a une nouvelle personne pour commencer à développer les frais généraux, c'est vraiment énorme. Il faut obtenir les droits d'accès au système développé, à différents référentiels, etc.

Je préfère la spécialisation, les gens savent ce qu'ils font, ont toutes les informations nécessaires, connaissent les pièges du projet et les gens n'ont pas le sentiment que vous devez les abandonner d'un projet à l'autre pour les faire travailler, pour aspirer chaque centime de leur.

Même s'ils tournent au ralenti dans leur projet, ils sont beaucoup plus productifs dans ce qu'ils connaissent bien que de sauter de projet en projet.