La présence de plusieurs équipes agiles devant travailler ensemble au sein d’un même programme (l’agile à l’échelle) par exemple induit une complexité qu’il est nécessaire d’appréhender au travers d’un dispositif à la fois adaptatif et rigoureux; juste ce qu’il faut de dispositif pour être et rester agile sur le long terme.
Je me souviens d’un des premiers principes de LeSS (Large Scale Scrum) confié par Craig Larman il y a quelques années lors d’un de ses passages à Paris
Large Scale Scrum is Scrum – Craig Larman
J’avoue que c’est mon point de départ quand je suis amené à travailler dans un contexte « Agile@Scale »:
l’agile à l’échelle c’est d’abord et avant tout de l’Agile!
Dés lors, comment procéder dans ce type de contexte? ET bien restons simple et…
- Revenons à l’essentiel: valeurs & principes
- Travaillons les basics agile avec chacune des Equipes (au sens large, j’inclus Product Owners et ScrumMasters)
- Appuyons nous sur les événements Scrum (c’est simple et cela marche quand c’est bien fait) enrichis avec Less pour la partie Multi Equipes (en particulier pour la conduite des Sprint Planning, Revues de Sprint et Backlog Refinement)
- Complétons le tout par ce « Juste ce qu’il faut de dispositif adapté au contexte » c’est à dire 4 éléments qui m’ont prouvé leur efficacité ces dernières années, et que je retrouve pour l’essentiel dans SAFe, LeSS ou dans le nouveau Scum@Scale de Jeff Sutherland
Tout cela nous permettra, si tout le monde joue le jeu, de :
- Favoriser l’alignement,
- Garantir la cohérence tant d’un point de vue produit qu’architectural
- Optimiser la coopération
- Faciliter la collaboration de tous les acteurs du programme
- Intégrer avec efficacité et transparence les expertises (UX, Techniques, Architecture)
- Préserver l’autonomie et la dynamique Agile de chaque Equipe
Élément 1 de ce Juste ce qu’il faut de dispositif : le Programme Planning*
ou PI Planning si vous préférez!
- Quand? Une fois par trimestre
- Durée: De 1,5 à 2 jours
- Qui est présent: TOUT LE MONDE, c’est ce qui fait sa richesse
L’inspiration nous vient directement de Safe avec le PI Planning (l’essentiel des REX SAfe porte sur ce RDV: il marque les esprits… 🙂 et de LeSS avec l’Initial Product Backlog Refinement.
Cet événement est en effet tellement précieux! Il nécessite une vraie préparation, de la logistique, une bonne dose de facilitation et l’engagement de tous mais c’est du temps gagné pour chaque personne, chaque équipe et toute l’organisation.
L’enjeu est de taille : obtenir un alignement entre tous les acteurs du programme, formalisés sous formes de buts communs au niveau du programme et de chaque équipe. Dans des contextes où des architectes ou autres experts sont partagés entre plusieurs équipes, ce RDV est utile pour identifier les besoins, contributions ou autres dépendances vis à vis de ceux-ci.
Les objectifs du Programme Planning:
- Fixer les objectifs du programme sur 1 quarter
- Partager les Roadmap de chaque équipe produit
- Synchroniser le travail des différentes équipes en termes de priorisation et de dépendances
- Créer le management visuel Programme en anticipant les livraisons de chaque sprint pour chaque Equipe:
Élément 2 de ce Juste ce qu’il faut de dispositif : le Management Visuel
Le management visuel est un élément clé. L’obeya room du programme devient trés vite une évidence. Y sera affiché un large radiateur d’informations cumulant des données propre à chaque équipe ainsi et surtout Le Programme Board qui va permettre de visualiser en un seul lieu les features, dépendances et contributions de TOUS pour les prochains sprints.
Résultat concret du Programme Planning, ce board physique, mis à jour en continu, servira de point d’appui des deux éléments, RDV suivants…
Élément 3 de ce Juste ce qu’il faut de dispositif : la Synchronisation Produit
- Quand? Une à deux fois par sprint
- Durée: De 45 min à 2h
- Qui est présent: Le pilote du Programme – Tous les profils Produit (les Product Owners de chaque produit accompagné ou non de leur Business Analyst ainsi que le(s) expert(s) UX) – Representant Marketing et / ou Utilisateurs – Architecte
Il s’appellera « Synchronisation produit », « Comité Produit » ou comme vous voudrez, c’est un moment fort d’échanges sur le produit et un RDV essentiel pour s’assurer de la cohérence globale de celui-ci sur le programme !
Les objectifs de cette synchronisation produit
- Synchroniser les Backlogs de Produit des différentes équipes en termes de priorisation et de dépendances (évidemment)
- Savoir ce qui se passe du côté de chaque Equipe sous l’angle produit (j’aime bien quand les PO font le Pitch devant le Radiateur d’information)
- Prendre connaissance des Retours Marketing, Retours Terrains (Tests Utilisateurs, Interviews Client) , Validation des Hypothéses et s’Ajuster...
- Anticiper les sprints N+2; n+3 en termes de besoins fonctionnels, métiers ou architecturaux, et plus largment discuter du Futur du produit
- Actualiser le management visuel
Élément 4 de ce Juste ce qu’il faut de dispositif : le Scrum of Scrum
- Quand? Une à deux fois par semaine
- Durée: De 15 à 30 minutes (max)
- Qui est présent: Pilote du Programme – Les ScrumMasters (en tant que représentant de l’équipe) – Un représentant pour chaque expertise clé du programme (Expertise Technique; Architecture: UX)
Mon premier Scrum of Scrum … je l’ai mis en place chez Michelin, c’était en 2009. J’ai toujours eu une position ambivalente à son égard, cherchant souvent à m’en débarrasser au profit par exemple de Backlog Refinement Commun, multi équipes.
Mais cet événement « à l’échelle » plutôt populaire au sein de la communauté agile m’a toujours rattrapé, démontrant de mon point de vue plus d’avantages que d’inconvénient quand il était bien cadré et animé. Sans lui, il y avait comme un petit manque, pour de bonnes ou de mauvaises raisons…
Au final , je l’intègre dans une version légère au sein de mon dispositif de base. Les échanges sont source de valeur: chaque personne a sa checklist (5 questions) et met à jour si nécessaire le poster Scrum of Scrum avec liste des blocages et la liste des besoins affiché au mur, dans l’obeya. Une fois le tour de paroles passé ( représentant d’équipe puis experts), la liste des obstacles est revue rapidement: »Qui dans la salle peut aider à lever le blocage? »
Les maîtres-mots de cette agilité à l’échelle: Bon Sens – Simplicité – Collaboration – Amélioration Continue. L’élément Bonus: Les Communautés de pratiques…
Enfin cher lecteur, si vous êtes parvenus jusque là, bravo ! laissez-vous simplement inspirer par cette jolie citation
Apprenez vos théories aussi bien que vous le pouvez puis mettez les de côté quand vous entrez en contact avec le vivant miracle de l’âme humaine C.G Jung
… en tout cas, celle-ci me guide bien quand il s’agit d’agilité à l’Échelle!
D’abord se fier à sa propre intuition et faire confiance aux équipes: tous ces frameworks @scale sont bien petits à l’échelle de la vie 🙂
Plus d’éléments sur ce dispositif Agile@scale dans le chapitre 4 de mon nouveau livre :
Jean Claude GROSJEAN, je suis l’auteur de ce Blog Professionnel, créé en 2007, et consacré au Coaching Agile, à la Facilitation, au Management Agile (dit 3.0) et aux techniques Agile UX / LeanUX. Speaker reconnu, j’interviens régulièrement dans des conférences sur ces mêmes thématiques.
J’ai par ailleurs crée en 2016 mon propre cabinet de coaching, le cabinet Eveil Agile, spécialisé notamment dans la transformation agile des Entreprises. J’interviens à Paris, Genève et Lausanne.
Pour me contacter : 06.20.98.58.40
Bonjour,
Très bon article.
Je vais en puiser des parties pour aider à améliorer notre organisation.
Nous sommes en SAFe depuis 2 ans. Nous sommes très proche de l’organisation présentée dans cet article, mais avec des améliorations possible en terme de communication, synchronisation et planification.
Merci beaucoup pour ce retour d’expérience.
Agilement votre,
MV/