coordinating-implementation-across-teams

Phase 5 (Implémentation) — guide approfondi pour un initiative shepherd. Tu ne fais pas l'implémentation. Tu habilites les équipes, maintiens la cohérence, assures la finalisation de l'initiative, et tu te retires une fois qu'elle est terminée. Budget de temps : 2–6 mois calendaires, 10–20 heures/mois de temps shepherd. Compose Skill(running-work-transitions) dans bitwarden-delivery-tools pour les phases Support Period, Pulse Check, Retrospective et Closure de l'Work Transition Playbook du côté origine.

Le modèle mental du document entonnoir :

Pense au shepherd comme :

• Un guide s'assurant que les équipes restent alignées avec la vision de l'initiative
• Un coordinateur gérant les dépendances inter-équipes et la communication
• Un expert disponible pour répondre aux questions sur l'approche
• Un rapporteur tenant le leadership informé de la progression
• Pas un chef de projet microgérant le travail quotidien
• Pas en train de faire des revues de code sur chaque PR (sauf si spécifiquement nécessaire pour valider l'approche)

Établir les canaux de communication (avant que l'implémentation ne commence)

Mets en place les mécanismes de coordination avant que les équipes ne commencent. Le document entonnoir spécifie :

• Canal Slack dédié optionnel (p. ex. #initiative-typescript-migration). Épingle les liens vers : PoC PR, ADR, architecture plan, dashboard Jira. À utiliser pour les questions, blocages et apprentissages entre équipes.
• Sync bi-hebdomadaire des tech leads avec tous les tech leads affectés. 30–45 minutes. Round-robin : progression, blocages, questions, dépendances inter-équipes.
• Permanences optionnelles (1–2 heures par semaine pour des questions en libre accès) ou utilise les permanences de l'entreprise.
• Mise à jour mensuelle de sync avec les parties prenantes pour le leadership d'ingénierie et d'architecture — 15 min, statut / pourcentage de completion / risques / décisions nécessaires.

Fixe explicitement les attentes de temps de réponse lorsque tu annonces le canal : « Questions sur Slack — viser 1 jour ouvrable de réponse. Préoccupations architecturales — même jour. »

Réunion de lancement

Quand les équipes sont prêtes à commencer (capacité allouée, stories en planification de sprint), organise un kickoff d'1 heure avec toutes les équipes. Selon le document entonnoir :

• Récapitule l'initiative. Problème, solution, résultats du PoC — pour les ingénieurs qui n'étaient pas aux réunions de transition.
• Passe en revue l'approche et les patterns clés. La PoC PR est le meilleur artefact pédagogique que tu as.
• Examine les dépendances inter-équipes. Rends-les visibles pour que les équipes sachent qui elles attendent et qui les attend.
• Présente les canaux de communication et la cadence. Quoi utiliser où ; quel temps de réponse s'attendre.
• Réponds aux questions et adresse les préoccupations.
• Célèbre le lancement.

Partage un paquet de ressources dans le canal Slack : PoC PR, ADR, architecture plan, FAQ (commence vide), ta disponibilité et ton temps de réponse.

Soutenir les équipes pendant l'exécution

Quatre activités, selon le document entonnoir :

1. Répondre aux questions

• Réponds dans le canal Slack en ~1 jour ouvrable.
• Saute sur Meets quand le texte ne suffit pas.
• Clarifie les cas limites ou scénarios que le PoC n'a pas couverts.
• Fournis des exemples ou des références à des implémentations similaires.

2. Vérifier la cohérence (pas une revue de code détaillée)

C'est la règle la plus souvent violée de Phase 5. Le document entonnoir est sans ambiguïté : « Fais confiance aux équipes pour la revue détaillée – interviens seulement pour les problèmes d'approche. »

• Surveille les PRs liées à l'initiative.
• Revise l'approche dans les premières PRs de chaque équipe pour assurer l'alignement avec le pattern du PoC.
• Fournis du feedback uniquement sur la déviation d'approche, pas sur le style, la nomination, la couverture de tests, ou autre chose que les propres reviewers de l'équipe gèrent.
• Le pattern d'exemple du document entonnoir : « C'est bon mais utilise des callbacks au lieu du pattern async/await du PoC — c'était intentionnel ? »

La ligne « Pas un reviewer pour les PRs de l'équipe » de navigating-the-initiative-funnel s'applique symétriquement ici : les tech leads s'attendent à ce que tu ne sois pas le reviewer de code de leur équipe. Respecte-le.

3. Dépanner les problèmes inattendus

Quand les équipes rencontrent des problèmes que la planification n'a pas anticipés :

• Aide à diagnostiquer : problème d'implémentation ou problème d'approche ?
• Pour les problèmes d'approche, escalade à l'Architecture Council si un ajustement fondamental est nécessaire.
• Documente les solutions dans la FAQ pour que les autres équipes puissent apprendre.

4. Débloquer les dépendances

• Suis quelles équipes attendent les autres (via le dashboard et la sync bi-hebdomadaire).
• Coordonne la communication entre les équipes dépendantes.
• Escalade au leadership d'ingénierie quand les blocages ne peuvent pas être résolus au niveau de l'équipe.
• Ajuste la séquence si le plan original s'avère problématique.

Maintenir la cohérence inter-équipes

Le document entonnoir appelle cela « l'une des responsabilités les plus critiques du shepherd. » Quatre sous-activités :

• Détection précoce de la divergence. Remarque quand les équipes interprètent le pattern différemment. Distingue les variations légitimes des incompréhensions. Revise 1–2 premières PRs par équipe pour attraper les problèmes avant qu'ils se multiplient.
• Partage les apprentissages entre équipes. Poste sur Slack quand une équipe résout un problème commun. Mets à jour la FAQ à mesure que les patterns émergent. Mets en avant de bons exemples : « La PR #567 de l'équipe X montre une façon propre de gérer ce cas limite. »
• Affine les directives si nécessaire. Si les équipes peinent régulièrement, les directives pourraient avoir besoin d'amélioration. Mets à jour le plan d'architecture ou crée des guides supplémentaires. Organise des sessions de travail ad-hoc si plusieurs équipes rencontrent le même problème.
• Prends des jugements sur les variations acceptables. Une certaine variation est appropriée selon le contexte (p. ex. « Les apps mobiles utilisent la variation A en raison de contraintes de plateforme ; le web doit utiliser le pattern standard »). Une certaine variation est une dérive qui sape la cohérence. Documente les jugements.

Suivre et rendre compte de la progression

Le document entonnoir spécifie plusieurs cadences :

Hebdomadaire (ton suivi interne)

• Revise le dashboard Jira : complété, en cours, bloqué.
• Vérifie le canal Slack pour les questions non résolues ou les préoccupations.
• Note les risques ou les tendances (p. ex., plusieurs équipes signalant le même problème).

Sync bi-hebdomadaire des tech leads

• Réunion de 30–45 minutes avec les tech leads de toutes les équipes affectées.
• Mise à jour round-robin : progression, blocages, questions.
• Coordination sur les dépendances.
• Identifier les besoins d'input de l'Architecture Council.

Mise à jour mensuelle du leadership

Créneau de 15 minutes dans une sync avec les parties prenantes. Couvre :

• Statut : on track / at risk / bloqué.
• Pourcentage de completion (stories faites / stories totales).
• Calendrier révisé si nécessaire.
• Escalades ou décisions nécessaires.

Formulation d'exemple du document entonnoir :

« La migration TypeScript est à 60 %, 3 des 6 équipes ont terminé leurs épics. L'équipe Vault a été retardée de 2 semaines en raison d'un correctif de sécurité de plus haute priorité. Toujours on track pour la completion Q3. »

Célébrer les jalons

• La première équipe termine son épic — reconnaissance sur Slack / réunion d'équipe.
• 50 % de completion — mise à jour aux all-hands de l'entreprise.
• Dernière PR fusionnée — célèbre avec tous les impliqués.

Gérer la documentation

La documentation ne doit pas attendre jusqu'à la fin. Selon le document entonnoir :

• Brouillon tôt. Crée la structure de documentation (outline / squelette) à mesure que l'implémentation commence.
• Ajoute du contenu progressivement. À mesure que les patterns se stabilisent et que les équipes produisent des implémentations réelles, ajoute à la docs.
• Laisse les équipes contribuer des exemples de leurs propres implémentations.

La documentation vit dans deux endroits selon Documentation Patterns. Ce qui va où :

Proche du code (aux côtés du code de l'équipe, dans le repository) :

• Mise à jour du framework / pattern README.md à mesure que le pattern se stabilise entre équipes. Le README initial du PoC évolue avec ce que les équipes découvrent lors du déploiement.
• Notes au niveau des dossiers dans la zone adoptée de chaque équipe pointant vers le framework README et l'ADR.
• Docs inline (JSDoc/commentaires XML pour TypeScript/Angular/.NET ; rustdoc pour Rust) selon le rubric par-stack dans Documentation Patterns.
• Mises à jour CLAUDE.md au niveau root et dossier où le nouveau pattern change comment les ingénieurs (et les outils Claude) devraient travailler. Utilise la syntaxe @ pour lier les fichiers README.md qui portent le pattern canonique.

Centralisé (dans bitwarden/contributing-docs, rendu à contributing.bitwarden.com) :

• Mises à jour ADR — statut final (Accepted → Implemented si ton système de numérotation l'utilise), leçons apprises, calendrier réel vs. prédit. Édite le même fichier ADR que tu as ouvert lors du PoC ; ne crée pas de nouveau.
• Guide de migration — comment convertir de l'ancien pattern au nouveau. C'est du contenu logistique / how-to et appartient centralement pour qu'il soit trouvable entre les repos.
• Mises à jour du guide de contribution — nouveaux standards ou patterns qui devraient gouverner les codes futurs au-delà de cette initiative.
• Runbooks — si l'initiative impliquait des changements opérationnels ou d'infrastructure, le contenu runbook vit généralement ici aussi (ou dans le home de SRE selon le cas).

Calendrier selon le document entonnoir :

• Brouillon du guide technique quand 2–3 équipes ont terminé l'implémentation.
• Finalise toute la documentation avant de marquer l'initiative comme complète.
• Prévois que la documentation soit prête 1–2 semaines avant que la dernière PR ne soit fusionnée.

Transfert de connaissances

Selon le document entonnoir, assure-toi que les résultats de l'initiative vivent au-delà de ton implication. Pendant les dernières semaines :

• Tech talk ou brown bag (45–60 min) pour l'intégralité de l'org d'ingénierie, possiblement à une session de permanences ou un créneau de l'Architecture Council.
• Matériaux d'onboarding pour les nouveaux ingénieurs.
• Mets à jour les runbooks d'équipe avec les nouveaux patterns.
• Considère d'enregistrer une vidéo de walkthrough.

Structure de tech talk (document entonnoir) :

Le 30-Day Pulse Check (Work Transition Playbook Phase 4)

Composant le playbook du côté origine — c'est le checkpoint déterminant qui prévient « nous l'avons transféré » de devenir « il n'a jamais été repris. » L'Work Transition Playbook est sans ambiguïté : le 30-day pulse check est la seule phase qui ne devrait pas être ignorée indépendamment de comment le reste est adapté.

Une conversation de 15–30 minutes, ou un thread asynchrone. Couvre :

• L'équipe a-t-elle commencé à travailler avec le matériel transféré ? Si non, qu'est-ce qui bloque ?
• Questions sans réponse ou zones de documentation insuffisantes ?
• L'équipe est-elle à l'aise avec l'approche, ou crée-t-elle des contournements ?
• Le support period a-t-il besoin d'ajustement ?

Si une équipe n'a pas du tout commencé, escalade conjointement avec l'équipe recevante — pas de manière punitive. Problème de capacité, conflit de priorité, ou gap de transition ? Comprends avant d'assumer.

Correction de trajectoire en vol

L'exemple du document entonnoir : découverte mid-implémentation de problèmes de performance des GraphQL resolvers. La réponse du shepherd :

• Escalade immédiatement à l'Architecture Council.
• Pause le travail des équipes affectées lors de l'investigation.
• Travaille avec une équipe pour tester une approche révisée.
• Mets à jour les directives avec les nouvelles conclusions.
• Communique clairement : « Pause, n'abandonne pas, nous corrigeons cela. »
• Étends le calendrier si nécessaire.

La leçon : un bon shepherding inclut reconnaître quand faire pause, ajuster, et communiquer — pas juste avancer indépendamment.

Completion et clôture

Critères de sortie

Selon le document entonnoir, l'initiative est complète quand :

• Toutes les stories sont complétées et fusionnées à main.
• Tous les épics des équipes sont marqués complets dans Jira.
• La documentation est écrite, révisée et publiée.
• Le transfert de connaissances est complété.
• La rétrospective a été menée.

Rétrospective (Work Transition Playbook Phase 5, ~90 jours)

Planifie dans les 2 semaines après completion, tandis que les souvenirs sont frais. 1,5 heures, toi + tech leads de toutes les équipes affectées. Selon l'agenda du document entonnoir :

• Qu'est-ce qui s'est bien passé ? Processus qui ont fonctionné, victoires de coordination, ce à répéter.
• Qu'aurait pu aller mieux ? Points de friction, délais, mauvaises assomptions, ce à faire différemment.
• Améliorations de processus. Ajustements de communication, changements de scoping ou d'estimation.
• Le travail a-t-il été assez bien compris pour être exécuté ? Quelles équipes étaient proches dans les estimations ? Lesquelles étaient loin ? Qu'est-ce qui a causé la variance ?

Documente les conclusions et les action items. Mets à jour la documentation du processus entonnoir avec les apprentissages — l'entonnoir de Bitwarden s'améliore quand les shepherds ajoutent ce qu'ils ont appris.

Clôture (Work Transition Playbook Phase 6)

• Marque l'initiative BW comme complète dans Jira.
• Archive le canal Slack (ou le rends read-only comme référence).
• Assure-toi que toute la documentation est trouvable.
• Mets à jour les runbooks ou matériaux d'onboarding associés.
• Soumets les améliorations du processus entonnoir basées sur les apprentissages.
• Mets à jour le statut de l'idée ARCH à son statut final de completion dans JPD.

Reconnais les contributeurs publiquement (all-hands, Slack), dans les revues de performance, avec un post case-study si justifié.

Le cadrage du Work Transition Playbook sur la clôture s'applique ici : ne traîne pas comme un reviewer « just-in-case » passé la clôture — c'est une forme douce de refus de lâcher prise.

Mesure d'impact (3–6 mois après completion)

Selon le document entonnoir, revisites les métriques de succès définies lors du Scoping :

• Métriques quantitatives (si définies) : réduction de bugs avant/après, améliorations de performance, économies de temps. Exemple du document : « Réduction prédite de 30 % des bugs de gestion d'erreurs ; réduction réelle : 42 %. »
• Feedback qualitatif : sonde les équipes — le nouveau pattern est-il mieux que l'ancien ? Qu'est-ce qui fonctionne, qu'est-ce qui ne fonctionne pas ?
• Suivi de l'adoption : Le nouveau code suit-il le pattern ? Les équipes adoptent-elles par défaut la nouvelle approche ? Dérive vers les anciens patterns ?

Documente les résultats :

• Mets à jour l'ADR avec les résultats réels vs. prédits.
• Ajoute un résumé d'impact au plan d'architecture.
• Partage les résultats avec l'org d'ingénierie.

Mises à jour de l'initiative BW

Pendant l'implémentation (voir Idea-Based Initiatives) :

• Le suivi du statut se fait principalement via les épics enfants et leurs stories — l'initiative elle-même ne nécessite pas de mises à jour fréquentes de champs.
• Commentaires : Événements de coordination significatifs — résolution de dépendances inter-équipes, corrections de trajectoire, réalisations de jalons, escalades. Les commentaires deviennent la chronologie narrative utilisée à la rétrospective.
• Liens : Ajoute le nouveau travail associé qui émerge — tickets opérationnels, rapports de bugs, pages de documentation, initiatives adjacentes.
• Description : Mets à jour seulement si le scope ou l'approche a changé matériellement.
• Statut de l'idée ARCH : Mets à jour à « 5️⃣ Implementation » au kickoff, puis à son statut final à la completion.

Erreurs courantes

• Faire une revue de code détaillée. Tu n'es pas le reviewer de l'équipe. Alignement d'approche uniquement.
• Laisser la divergence s'accumuler. Attrape la divergence dans les PRs 1–2 par équipe, pas 10–20.
• Ignorer le 30-day pulse check. L'Work Transition Playbook est explicite — c'est le checkpoint déterminant. Ignore-le et les modes de défaillance silencieuse deviennent invisibles.
• Traiter la documentation comme un artefact de fin de phase. Les patterns dérivent entre l'implémentation et la rédaction. Documente progressivement.
• Reprendre silencieusement le travail parce qu'une équipe ne le reprend pas. Selon le playbook, c'est une conversation de leadership, pas une opportunité d'héroïsme.
• Traîner après la clôture. Rends le travail à la cadence régulière de l'équipe et retire-toi. Le signal a de l'importance.
• Ignorer la rétrospective. C'est le seul mécanisme qui améliore l'entonnoir lui-même.

Référence

• Software Initiative Funnel §5 — description canonique de phase, exemples d'implémentations réussies, en difficulté, et corrigeant la trajectoire.
• Work Transition Playbook — transition canonique à six phases ; Phase 5 de l'entonnoir est la portion support-period-through-closure du côté origine.
• Documentation Patterns — close-to-code vs. centralisé contributing-docs, best practices par-tech-stack, conventions CLAUDE.md.
• Idea-Based Initiatives — comment mettre à jour l'initiative BW à travers l'implémentation.
• Associé : Skill(shepherding-an-initiative) pour le playbook de parapluie ; Skill(running-work-transitions) (dans bitwarden-delivery-tools) pour la guidance support-period du côté origine ; Skill(scoping-and-handing-off-to-teams) pour la phase qui remet le travail à celui-ci.