Scrum et XP depuis les Tranchées

Si traiter avec plusieurs équipes Scrum est si dur, pourquoi s'embêter ? Pourquoi ne pas mettre tout le monde dans la même équipe ?

La plus grosse équipe Scrum que nous avons eu faisait environ 11 personnes. Ca fonctionnait, mais pas très bien. Les mêlées quotidiennes avaient tendance à trainer au-delà de 15 minutes. Les membres de l'équipe ne savaient pas ce que les autres faisaient, il pouvait y avoir de la confusion. C'était difficile pour le Scrum master de garder tout le monde concentré sur l'objectif, et de trouver le temps d'adresser tous les obstacles qui étaient remontés.

L'alternative est de diviser l'équipe en deux. Mais est-ce mieux ? Pas nécessairement.

Si l'équipe est expérimentée et confortable avec Scrum, et s'il y a une approche logique de découper la feuille de route en deux pistes distinctes, et que les deux pistes ne concernent pas le même code source, alors je dirais que c'est une bonne idée de diviser l'équipe. Sinon je considérerais de rester avec une équipe, malgré le désavantage des grosses équipes.

Mon expérience est qu'il est préférable d'avoir peu d'équipes même trop grosses que d'avoir plein de petites équipes qui interfèrent les unes les autres. Créez de petites équipes seulement si elles n'ont pas besoin d'interagir entre elles !

15-1-1. Equipes virtuelles▲

Comment savoir si vous prenez la bonne ou mauvaise décision par rapport au compromis entre « grosses équipes » vs « beaucoup d'équipes » ?

Si vous gardez les yeux et les oreilles ouvertes vous aurez remarqué la formule « équipes virtuelles ».

Exemple 1 : Vous choisissez d'avoir une grande équipe. Mais quand vous regardez qui parle à qui pendant l'itération, vous notez que l'équipe est effectivement divisée en deux sous-équipes.

Exemple 2 : Vous choisissez d'avoir trois équipes plus petites. Mais quand vous regardez qui parle à qui pendant l'itération, vous notez que les équipes 1 et 2 discutent entre elles tout le temps, tandis que l'équipe 3 travaille de manière isolée.

Qu'est-ce que ça signifie ? Que votre stratégie de division des équipes n'est pas bonne ? Oui, si les équipes virtuelles semblent plutôt permanentes. Non, si vos équipes virtuelles semblent être temporaires.

Regardez l'exemple 1. Si les deux sous-équipes virtuelles ont tendance à changer de temps en temps (c'est-à-dire que les personnes bougent entre les sous-équipes virtuelles) alors vous avez probablement pris la bonne décision en les regroupant dans une équipe Scrum unique. Si les deux sous-équipes restent les mêmes pendant toute l'itération, vous voudrez probablement les séparer en deux vraies équipes Scrum pour la prochaine itération.

Maintenant regardez l'exemple 2. Si l'équipe 1 et 2 discutent entre elles (mais pas l'équipe 3) durant toute l'itération, vous voudrez probablement regrouper l'équipe 1 et l'équipe 2 en une équipe Scrum unique à la prochaine itération. Si l'équipe 1 et l'équipe 2 discutent beaucoup entre elles pendant la première moitié de l'itération, et qu'ensuite l'équipe 1 et l'équipe 3 discutent entre elles pendant la seconde moitié de l'itération, alors vous devriez considérer de fusionner les trois équipes en une, ou juste les laisser en trois équipes. Abordez la question durant la rétrospective d'itération et laissez les équipes décider elles-mêmes.

La division des équipes est l'une des parties vraiment difficiles de Scrum. Ne réfléchissez pas trop ou n'optimisez pas trop. Expérimentez, gardez un oeil sur les équipes virtuelles, et soyez sûr que vous prenez suffisamment de temps pour discuter de ce genre de choses pendant les rétrospectives. Tôt ou tard vous trouverez la bonne solution à votre situation. Le plus important est que les équipes soient confortables et n'hésitez pas entre les deux trop souvent.

15-1-2. La taille optimale de l'équipe▲

La plupart des livres que j'ai lus affirment que la taille « optimale » de l'équipe est quelque part autour de 5 - 9 personnes.

D'après ce que j'ai vu jusqu'ici je ne peux qu'être d'accord. Même si je dirai plutôt 3 - 8 personnes. En fait, je crois que ça vaut le coût d'atteindre des équipes de cette taille.

Disons que vous avez une unique équipe Scrum de 10 personnes. Considérons que l'on éjecte les deux membres les plus médiocres. Oups, ai-je vraiment dit ça ?

Disons que vous avez deux produits différents, avec une équipe de 3 personnes par produit, et les deux avancent trop lentement. Ca peut être une bonne idée de les fusionner en une seule équipe de 6 personnes responsable des deux produits. Dans ce cas laissez partir l'un des deux directeurs de produit (ou donnez lui un rôle consultatif ou autre chose).

Disons que vous avez une seule équipe Scrum de 12 personnes, car le code est dans un état tellement lamentable qu'il n'y a pas moyen pour 2 équipes différentes de travailler dessus indépendamment. Faites de sérieux efforts pour corriger le code (au lieu de construire de nouvelles fonctionnalités) jusqu'à ce que vous puissiez diviser l'équipe. Cet investissement sera probablement amorti rapidement.

Disons que vous avez trois équipes Scrum qui travaillent sur le même projet. Leurs sprints devraient-ils être synchronisés, c'est-à-dire commencer ou finir ensemble ? Ou devraient-ils se chevaucher ?

Notre première approche était les sprints qui se chevauchent (en respectant les durées).

Ca sonne bien. A n'importe quel moment il y aurait un sprint sur le point de finir et un nouveau sprint sur le point de commencer. La charge de travail du directeur de produit serait également répartie dans le temps. Il y aurait des nouvelles versions en continu. Des démonstrations toutes les semaines. Alléluia.

Oui, je sais, mais ça semblait vraiment convaincant à l'époque !

Nous avions juste commencé à faire ça quand un jour j'ai eu l'opportunité de parler avec Ken Schwaber (en conjonction avec ma certification Scrum). Il fit remarquer que c'était une mauvaise idée, qu'il serait tellement mieux de synchroniser les sprints. Je ne me rappelle pas ces arguments exacts, mais après la discussion j'étais convaincu.

C'est la solution que nous avons utilisée depuis, et nous ne l'avons jamais regretté. Je ne saurai jamais si la stratégie des sprints qui se chevauchent aurait échouée, mais je pense que oui. Les avantages des sprints synchronisés sont :

• Il y a un moment naturel où l'on peut réarranger les équipes - entre les sprints ! En chevauchant les sprints, il n'y a pas moyen de réarranger les équipes sans perturber au moins une équipe au milieu du sprint.
• Toutes les équipes peuvent travailler vers un objectif commun sur un sprint et faire les réunions de planification de sprint ensemble, ce qui mène à une meilleure collaboration entre équipes.
• Il y a moins de travail administratif, c'est-à-dire moins de réunions de planification de sprint, de démonstrations de sprint, et de releases.

Disons que nous avons un seul produit avec trois équipes.

Le gars en rouge marqué P est le Directeur de produit. Les gars en noir marqués S sont les Scrum Masters. Les autres sont les troufions... euh... les membres respectables d'équipe.

Avec cette constellation, qui décide quelles personnes devraient être dans quelle équipe ? Le directeur de produit ? Les trois Scrum masters ensemble ? Ou chaque personne choisit son équipe ? Mais alors que faire si tout le monde veut être dans l'équipe 1 (parce que le Scrum master 1 est tellement avenant) ?

Que faire si plus tard il s'avère impossible d'avoir plus de deux équipes en parallèle sur ce code, et qu'il soit nécessaire de les transformer en 2 équipes de 9 personnes au lieu de des équipes de 6 personnes. Cela signifie 2 Scrum masters. Alors lequel des 3 Scrum masters sera relevé de sa fonction ?

Dans beaucoup d'entreprises ce sont des questions assez sensibles.

Il est tentant de laisser le directeur de produit faire les affectations et réaffectations. Mais ce n'est pas vraiment le travail du directeur de produit, n'est-ce pas ? Le directeur de produit est l'expert métier qui dit à l'équipe dans quelle direction elle doit courir. Il ne devrait pas vraiment être impliqué dans les détails. Surtout s'il s'agit d'un « poulet » (si vous avez entendu la métaphore du poulet et du cochon, sinon tapez « chicken and pig » sous google).

Nous avons résolu ce problème en introduisant le rôle du « meneur d'équipes ». Cela correspond à ce que vous pourriez appeler le « Scrum des Scrum masters » ou « le chef » ou le « Scrum master principal » etc. Il n'a à mener aucune équipe, mais il est responsable des problèmes transverses aux équipes comme qui devrait être le Scrum master pour chaque équipe, combien de personnes devraient être divisées en équipes, etc.

Nous avons eu du mal à trouver un bon nom pour ce rôle. Le « meneur d'équipes » était le moins mauvais nom que nous avons pu trouver.

Cette solution a bien marché pour nous et je peux la recommander (indépendamment du nom que vous choisissez pour ce rôle).

Il y a deux grandes stratégies pour affecter les personnes aux équipes, lorsque vous avez de multiples équipes sur le même produit.

• Laisser une personne désignée faire l'affectation, par exemple le « meneur d'équipes » que j'ai mentionné ci-dessus, le directeur de produit, ou le manager fonctionnel (s'il est assez impliqué pour pouvoir prendre de bonnes décisions).
• Laisser les équipes le faire eux-mêmes.

Nous les avons essayées toutes les trois. Trois ? Oui. Stratégie 1, Stratégie 2 et une combinaison des deux.

Nous avons trouvé que la combinaison des deux fonctionnait mieux.

Avant la réunion de planification de sprint, le meneur d'équipes lance une réunion d'affectation des équipes avec le directeur de produit et tous les Scrum masters. Nous discutons du dernier sprint et décidons si une réaffectation est nécessaire. Peut-être voulons-nous fusionner deux équipes, ou transférer des personnes d'une équipe vers une autre. Nous nous décidons sur quelque chose et nous le mettons par écrit comme une proposition d'affectation d'équipe, que nous apportons à la réunion de planification du sprint.

La première chose que nous faisons pendant la réunion de planification de sprint est de parcourir les éléments de plus haute priorité dans le backlog de produit. Le meneur d'équipe dit ensuite quelque chose dans le genre :

« Bonjour tout le monde. Nous suggérons l'affectation d'équipe suivante pour le prochain sprint. »

« Comme vous le voyez, cela signifierait une réduction du nombre d'équipes, passant de 4 à 3. Nous avons listé les membres pour chaque équipe. Groupez-vous s'il-vous-plaît et mettez-vous devant une section du mur. »

(le meneur d'équipes attend pendant que les personnes se baladent dans la pièce, après un moment il y a 3 groupes, chacun se tenant devant une section du mur vide).

« Maintenant cette division d'équipes est préliminaire ! C'est juste un point de départ, pour gagner du temps. Au fur et à mesure que la réunion de planification de sprint progresse vous êtes libre de vous balader vers une autre équipe, de diviser votre équipe en deux, fusionner avec une autre équipe, ou ce que vous voulez. Faites preuve de bon sens en vous basant sur les priorités du directeur de produit. »

C'est ce que nous avons trouvé qui fonctionne le mieux. Un certain niveau de contrôle centralisé au début, suivi par un certain niveau d'optimisations décentralisées après.

Disons que votre technologie consiste en trois principaux composants :

Et disons que vous avez 15 personnes travaillant sur le produit, aussi vous ne voulez vraiment pas en faire une seule équipe Scrum. Quelles équipes créez-vous ?

15-5-1. Approche n°1 : équipes spécialisées par composant▲

Une approche est de créer des équipes spécialisées par composant telles qu'une « équipe client », une « équipe serveur » et une « équipe BD ».

C'est comme ça que nous avons commencé. Ca ne fonctionnait pas très bien, du moins pas quand la plupart des histoires impliquaient plusieurs composants.

Par exemple disons que nous avons une histoire appelée « tableau d'affichage où les utilisateurs peuvent poster des messages aux autres ». Cette fonctionnalité de tableau d'affichage impliquerait de mettre à jour l'interface utilisateur côté client, ajouter la logique côté serveur, et ajouter des tables dans la base de données.

Cela signifie que les trois équipes - l'équipe client, l'équipe serveur, et l'équipe BD - doivent collaborer pour que cette histoire soit terminée. Pas terrible.

15-5-2. Approche n°2 : équipes transversales aux composants▲

Une seconde approche est de créer des équipes transversales aux composants, c'est-à-dire des équipes qui ne sont liées à aucun composant.

Si beaucoup de vos histoires impliquent plusieurs composants cette stratégie de division d'équipes fonctionnera mieux. Chaque équipe peut implémenter une histoire complète incluant la partie client, la partie serveur et la partie base de données. Les équipes peuvent ainsi travailler plus indépendamment des autres, ce qui est une Bonne Chose.

L'une des premières choses que nous faisons quand nous avons introduit Scrum était de démanteler ces équipes spécialisées par composant (approche 1) et de créer des équipes transversales aux composants à la place (approche 2). Cela réduit le nombre de cas où « nous ne pouvons finir cet élément parce que nous attendons que les gars côté serveur fassent leur partie. »

Cependant, nous assemblons parfois des équipes temporaires spécialisées par composant quand le besoin est fort.

Chaque sprint est généralement assez différent des autres, selon le type des histoires qui ont la plus haute priorité à ce moment particulier. Par conséquent, la création de l'équipe optimale peut être différente pour chaque sprint.

En fait, presque tous les sprints nous disions quelque chose comme « ce sprint n'était pas vraiment un sprint normal parce que (bla bla bla)....». Après quelques temps nous avons abandonné la notion de sprint « normal ». Il n'y a pas de sprint normal. Comme il n'y a pas de famille « normale » ou de personne « normale ».

Sur un sprint ce peut être une bonne idée d'avoir une équipe client seulement, constituée de tous ceux qui connaissent bien le code client. Au prochain sprint ce peut être une bonne idée d'avoir deux équipes transversales en divisant le groupe client.

L'un des aspects clés de Scrum est la « formation de l'équipe », c'est-à-dire si une équipe apprend à travailler ensemble au cours des sprints ils deviendront généralement très proches. Ils apprendront à obtenir un flux de groupe et atteindront un niveau de productivité incroyable. Mais cela prend quelques sprints pour y parvenir. Si vous n'arrêtez pas de changer les équipes nous n'obtiendrez jamais une équipe vraiment soudée.

Aussi si vous voulez réarranger les équipes, soyez sûr de mesurer les conséquences. Est-ce un changement à long terme ou à court terme ? Si c'est un changement à court terme considérez de le laisser tomber. Si c'est un changement long terme, allez-y.

Une exception lorsque vous commencez à appliquer Scrum avec une grande équipe pour la première fois. Dans ce cas il vaut probablement mieux expérimenter un peu avec les divisions d'équipes jusqu'à ce que vous trouviez quelque chose de confortable pour tous. Assurez-vous que tout le monde comprenne que c'est OK d'avoir tout faux les quelques premières fois, du moment que vous continuez de vous améliorer.

Je ne peux que confirmer ce que les livres Scrum disent - avoir des membres d'une équipe Scrum à temps partiel n'est généralement pas une bonne idée.

Disons que vous êtes sur le point de prendre Joe en tant que membre à temps partiel dans votre équipe Scrum. Réfléchissez bien avant. Avez-vous vraiment besoin de Joe dans votre équipe ? Etes-vous sûr de ne pas pouvoir prendre Joe à temps plein ? Quels sont ses autres engagements ? Est-ce que quelqu'un d'autre peut prendre le relai sur les autres engagements de Joe et laisser à Joe un rôle plus passif, de support, tout en respectant ses engagements ? Est-ce que Joe peut rejoindre votre équipe à plein temps pour le prochain sprint, et dans le même temps transférer ses autres responsabilités à quelqu'un d'autre ?

Parfois il n'y a pas de solution. Vous avez désespérément besoin de Joe parce que c'est le seul DBA de l'immeuble, mais les autres équipes ont autant besoin de lui alors il ne sera jamais affecté à plein temps sur votre équipe, et la société ne peut prendre plus de DBAs. Très bien. C'est un cas valide pour l'avoir à temps partiel (c'est d'ailleurs exactement ce qui s'est passé pour nous). Mais assurez-vous de faire cette évaluation à chaque fois.

En général je préfère avoir une équipe de 3 personnes à plein temps que de 8 à temps partiel.

Si vous avez une personne qui va partager son temps entre plusieurs équipes, comme le DBA mentionné plus haut, c'est une bonne idée de l'assigner à l'origine à une équipe. Trouvez l'équipe qui aura le plus besoin de lui, et faites-en son « équipe maison ». Quand personne d'autre ne l'embarque, il assistera aux mêlées quotidiennes de cette équipe, aux réunions de planification de sprint, aux rétrospectives, etc.

Le Scrum-des-Scrums est simplement une réunion régulière dans laquelle tous les Scrum masters se rassemblent pour parler.

A un moment donné, nous avions quatre produits, dont trois d'entre eux avait une seule équipe Scrum, et le dernier avait 25 personnes réparties dans plusieurs équipes Scrum. Quelque chose comme ceci :

Cela signifie que nous avions 2 niveaux de Scrums-de-Scrum. Nous avions un Scrum-de-Scrums de « niveau produit » composé des équipes du produit D, et un Scrum-de-Scrums « niveau global » composé de tous les produits.

15-8-1. Scrum-de-Scrums de niveau produit▲

15-8-2. Scrum-de-Scrums de niveau global▲

Si vous avez beaucoup d'équipes Scrum pour un seul produit, et qu'ils font tous la mêlée quotidienne en même temps, vous avez un problème. Le directeur de produit (et les gens fouineurs comme moi) peuvent seulement assister à une mêlée quotidienne par jour.

Nous demandons alors aux équipes d'éviter d'avoir les mêlées quotidiennes en même temps.

L'exemple de calendrier ci-dessus correspond à la période durant laquelle nous avions des mêlées quotidienne dans des bureaux séparés, plutôt que dans le bureau des équipes. Les réunions durent normalement 15 minutes mais chaque équipe se réserve un espace de 30 minutes au cas où il y aurait besoin de dépasser légèrement.

C'est extrêmement intéressant pour deux raisons :

• Les gens comme le directeur de produit et moi-même pouvons visiter toutes les mêlées quotidiennes dans une seule matinée. Il n'y a pas de meilleur moyen d'obtenir une vision réaliste de l'état du sprint, et des menaces clés.
• Les équipes peuvent visiter les mêlées quotidiennes des autres équipes. Cela n'arrive pas trop souvent, mais de temps en temps deux équipes vont travailler sur une zone similaire, et ainsi quelques membres se rendent visite dans les mêlées pour rester synchronisés.

L'inconvénient c'est moins de liberté pour l'équipe - ils ne peuvent pas choisir le moment qu'ils préfèrent pour la mêlée. Toutefois cela ne s'est pas révélé être un véritable problème pour nous.

Nous avons eu une situation ou un gros produit était incapable d'adopter Scrum parce que les membres de l'équipe passaient beaucoup trop de temps à faire les pompiers, c'est-à-dire à corriger des bugs dans la panique dans leur système livré prématurément. C'était un vrai cercle vicieux, ils étaient si occupés à éteindre les incendies qu'ils n'avaient pas le temps de travailler proactivement pour prévenir les feux (c'est-à-dire améliorer la conception, automatiser les tests, créer des outils de surveillance, des outils d'alarme, etc.).

Nous avons géré ce problème en créant une équipe de pompiers dédiée, et une équipe Scrum dédiée.

Le travail de l'équipe Scrum était (avec la bénédiction du directeur de produit) d'essayer de stabiliser le système, et effectivement de prévenir les incendies.
L'équipe de pompiers (nous les appelons «support» en réalité) avait deux boulots :

• Combattre les incendies.
• Protéger l'équipe Scrum de toutes les sortes de perturbations, ce qui inclut des choses comme parer des demandes de nouvelles fonctionnalités ad-hoc provenant de nulle part.

L'équipe de pompiers était placée au plus près de la porte ; l'équipe Scrum était placée au fond de la pièce. Ainsi l'équipe de pompiers pouvait en fait protéger physiquement l'équipe Scrum des perturbations venant par exemple de vendeurs impatients ou de clients mécontents.

Des développeurs seniors étaient placés dans les deux équipes, de telle sorte qu'une équipe ne soit pas trop dépendante des compétences clés de l'autre équipe.

C'était en fait une tentative de résoudre un problème d'amorçage de Scrum. Comment pouvons nous commencer Scrum si l'équipe n'a aucune chance de planifier son travail plus d'un jour à l'avance ? Notre stratégie a donc été, comme mentionné ci-dessus, de partager le groupe.

Cela a plutôt bien fonctionné. Comme l'équipe Scrum avait reçu du temps pour travailler de manière proactive, ils ont finalement réussi à stabiliser le système. Pendant ce temps l'équipe de pompiers avait complètement abandonné la notion d'être capable de planifier à l'avance, ils travaillaient uniquement de manière réactive, et corrigeaient juste la crise en cours.

Bien sûr l'équipe Scrum n'était pas complètement à l'abri des perturbations. Fréquemment l'équipe de pompiers devait impliquer des personnes clés de l'équipe Scrum, ou au pire l'équipe en entier.

Néanmoins, après quelques mois, le système était suffisamment stable pour que nous puissions enterrer l'équipe de pompiers et créer des équipes Scrum supplémentaires à la place. Les pompiers étaient plutôt heureux de ranger leurs casques abimés et de rejoindre des équipes Scrum à la place.

Disons que vous avez un produit et deux équipes Scrum. Combien de backlogs de produit devriez-vous avoir ? Combien de directeurs de produit ? Nous avons évalué trois modèles pour cela. Le choix a un gros effet sur la manière dont les réunions de planning de sprint sont conduites.

15-11-1. Stratégie 1 : un directeur de produit, un backlog▲

C'est le modèle « Il n'en restera qu'Un ». Notre modèle préféré.

Le bon côté de ce modèle est qu'il laisse les équipes se former à peu près elles-mêmes sur la base des priorités actuelles du directeur de produit. Le directeur de produit peut se concentrer sur ce dont il a besoin, et peut laisser les équipes décider comment partager le travail.

Pour être plus concret, voici comment la réunion de planning de sprint fonctionne pour cette équipe :

La réunion de planning de sprint a lieu dans un centre de conférence externe.

Juste avant la réunion, le directeur de produit désigne un mur comme le « mur du backlog de produit » et y fixe des histoires d'utilisateur (fiches cartonnées), ordonnées par priorité relative.
Il continue à en ajouter jusqu'à ce que le mur soit rempli, ce qui habituellement constitue plus de travail que possible pour un sprint.

Chaque équipe Scrum sélectionne une section de mur vide pour elle, et y poste son nom d'équipe. C'est leur « mur d'équipe ». Chaque équipe prend alors des histoires sur le mur de backlog de produit, en commençant par les histoires de plus haute priorité, et place les fiches cartonnées sur son propre mur d'équipe.

C'est illustré par le diagramme ci-dessous, avec les flèches jaunes qui symbolisent le flux des fiches depuis le mur de backlog de produit vers les murs des équipes.

Au fur et à mesure de la progression de la réunion, le directeur de produit et les équipes marchandent sur les fiches cartonnées, les déplacent entre les équipes, les déplacent vers le haut ou le bas pour changer les priorités, les découpent en éléments plus petits, etc. Après une heure environ, chaque équipe a une première version candidate de backlog de sprint sur leur mur d'équipe. Après cela, les équipes travaillent indépendamment, et font la décomposition en tâches et l'estimation en temps.

C'est bordélique et chaotique et épuisant, mais également efficace et amusant et social. Quand le temps imparti est écoulé, toutes les équipes ont généralement suffisamment d'informations pour commencer leur sprint.

15-11-2. Stratégie 2: un directeur de produit, plusieurs backlogs▲

15-11-3. Stratégie 3 : plusieurs directeurs de produit, un backlog par directeur▲

C'est comme la seconde stratégie, un backlog de produit par équipe, mais avec un directeur de produit par équipe également !

Nous n'avons jamais fait cela, et nous ne le ferons probablement jamais.

Si les deux backlogs de produit impliquent la même base de code, cela va probablement causer de sérieux conflits d'intérêt entre les deux directeurs de produit.

Si les deux backlogs de produit impliquent des bases de code séparées, alors cela revient à partager le produit total en sous-produits séparés, et à les gérer indépendamment. Cela signifie que nous sommes revenus à la situation « une équipe un produit », ce qui est élégant et facile.

Avec plusieurs équipes qui travaillent sur la même base de code, il est inévitable d'avoir à gérer des branches de code dans le système de gestion de configurations. Il y a beaucoup de livres et d'articles sur la manière de gérer plusieurs personnes travaillant sur la même base de code, donc je n'irais pas dans les détails ici. Je n'ai rien de nouveau ou de révolutionnaire à ajouter. Toutefois je vais résumer quelques unes des plus importantes leçons que nos équipes ont apprises jusque là.

• Soyez strict et gardez la ligne principale (ou tronc) dans un état cohérent. Cela signifie, au minimum, que tout devrait compiler et que tous les tests unitaires devraient passer. Il devrait être possible de créer une version livrable fonctionnelle à n'importe quel moment. De préférence, le système de build en continu devrait construire et déployer automatiquement sur un environnement de test toutes les nuits.
• Etiquetez chaque version livrée. Chaque fois que vous livrez une version pour les tests d'acceptation ou pour la production, assurez-vous qu'il y a une étiquette de version sur votre ligne principale, étiquette qui identifie exactement ce qui a été livré. Cela signifie que vous pouvez, à n'importe quel point dans le futur, revenir en arrière et créer une branche de maintenance depuis cette étiquette.
• Créez de nouvelles branches uniquement quand c'est nécessaire. Une bonne règle empirique est de créer une nouvelle branche de code uniquement quand vous ne pouvez pas utiliser une ligne de code existante sans violer la politique de cette ligne. En cas de doute, ne créez pas de branche. Pourquoi ? Parce que chaque branche active est couteuse en administration et complexité.
• Utilisez les branches principalement pour séparer différents cycles de vie. Vous pouvez décider ou non d'avoir chaque équipe Scrum sur a propre ligne de code. Mais si vous mélangez des corrections à court terme avec des changements à long terme dans la même ligne de code, vous trouverez très difficile de livrez les corrections à court terme !
• Synchronisez souvent. Si vous travaillez sur une branche, synchronisez avec la ligne principale chaque fois que vous quelque chose qui compile. Tous les matins quand vous arrivez au travail, synchronisez depuis la ligne principale sur votre branche, de telle sorte que votre branche soit à jour par rapport aux modifications des autres équipes. Si fusionner c'est l'enfer, acceptez simplement le fait que cela aurait été bien pire d'attendre.

Comment faisons nous les rétrospectives de sprint quand plusieurs équipes travaillent sur le même produit ?

Immédiatement après la démonstration du sprint, après les applaudissements et le mélange général, chaque équipe part dans une pièce réservée pour elle, ou pour un endroit confortable à l'extérieur. Elles font leurs rétrospectives à peu près comme je l'ai décrit page 82 « Comment nous faisons les rétrospectives de sprint ».

Durant la réunion de planning de sprint (à laquelle toutes les équipes participent, puisque nous faisons des sprints synchronisés pour chaque produit), la première chose que nous faisons est de laisser un porte-parole par équipe faire un résumé des points clés de leur rétrospective. Cela prend environ 5 minutes par équipe. Ensuite nous avons une discussion ouverte pendant 10 à 20 minutes. Puis nous faisons une pause. Ensuite nous commençons le planning de sprint proprement dit.

Nous n'avons pas essayé d'autres manières, ceci marche suffisamment bien. Le plus gros inconvénient est qu'il n'y a pas de temps libre après la rétrospective, et avant le planning. (voir page 88 « Relâcher le rythme entre les sprints »)

Pour les produits à une seule équipe, nous ne faisons pas ce résumé de rétrospective durant la réunion de planning de sprint. Cela n'est pas nécessaire, puisque tout le monde était présent lors de la rétrospective du sprint.