STEADY :
Construction produit en équipes agiles synchronisées

Le framework STEADY vise à faire travailler de concert sur le même produit un ensemble d’équipes agiles. Ce document présente la version 0.1 du framework STEADY.

Sommaire

Introduction — les “frameworks d’agilité à l’échelle”

Ces dernières années, de nombreux “frameworks d’agilité à l’échelle” ont fait apparition. De plus en plus d’organisations les ont expérimentées, avec des résultats variables. Comment l’expliquer ? Sans surprise, les organisations qui ont le mieux réussi sont celles qui ne se sont pas contenté de déployer un framework mais qui ont cherché à en vivre l’essence, notamment au travers des valeurs et en insufflant un véritablement changement de culture.

On peut se demander si ces frameworks sont agiles ou non, s’ils incitent à plus d’agilité ou non. La réponse est en demi-teinte : quand on part d’une organisation traditionnelle, en silos et qui se concentre sur la productivité plutôt que sur la création de valeur, ces frameworks amènent sans aucun doute plus d’agilité. Néanmoins, ces frameworks limitent aussi le niveau d’agilité qu’il est possible d’atteindre dès lors qu’ils servent à synchroniser ensemble fortement des dizaines ou centaines d’équipes.

Ce dernier point est à nuancer : en réalité, ce n’est pas tant ces frameworks qui limitent l’agilité que les environnements dans lesquels ils sont déployés. Quand un problème donné nécessite plusieurs dizaines ou centaines de personnes pour maintenir et faire évoluer sa solution, il n’est tout simplement pas possible d’être aussi agile que sur un problème intégralement géré par une équipe d’une petite dizaine de personnes.

L’approche la plus agile consisterait à découper le problème en plus petits problèmes, avec chaque problème géré par sa propre équipe agile indépendante. (”unscale the problem”) Malheureusement, il ne suffit pas de le décréter pour que cela arrive : c’est plus facile à dire qu’à faire. S’il faut donc bien garder cette approche en tête comme un idéal vers lequel on va essayer de toujours plus tendre, comment gérer la situation actuelle ?

Si vous vous reconnaissez dans cette description, vous êtes au bon endroit ! Dans ce document, nous vous proposons le framework STEADY qui vous permettra de synchroniser l’ensemble des personnes qui collaborent sur la conception et la production de la solution à un même problème.

STEADY est l’acronyme de Synchronized Teams for Agile Delivery.

Ce framework est gratuit et disponible librement. Aucune certification n’est nécessaire pour le mettre en place ou pour y former les organisations désirant le déployer.

Fonctionnement général

Pour faire collaborer plus d’une dizaine de personnes, le framework STEADY repose sur la structure en de multiples Agile Teams qui se synchroniseront à intervalles réguliers. Le regroupement de ces Agile Teams forme une plus grande équipe, la Product Team.

On a ainsi deux niveaux de cadences imbriquées : celle des itérations des Agile Teams, et celle de l’ensemble de la Product Team. Le but est de réduire au maximum les dépendances entre les Agile Teams tout en les gardant synchronisées pour leur permettre de collaborer sur la création du produit global de la Product Team.

Le but d’avoir ces deux cadences imbriquées est de :

  • Avoir des points de rencontre réguliers pour s’assurer d’un alignement vers un but et des enjeux communs tout en permettant un travail au quotidien en petites équipes les plus autonomes possible
  • Permettre et promouvoir une démarche d’amélioration continue globale et à tous les niveaux

Le but d’avoir ces deux cadences imbriquées n’est pas de :

  • Centraliser le travail d’exploration produit (”discovery”)
  • Centraliser le travail d’architecture technique
  • Centraliser la définition et l’évolution des process et modes de fonctionnement

Product Cycle (PC)

Les itérations au niveau de la Product Team s’appellent des Product Cycles ou PC.

Un Product Cycle correspond à l’enchaînement séquentiel des éléments suivants :

  1. Un PC Planning avec l’ensemble de la Product Team
  2. Plusieurs Agile Iterations par les Agile Teams
  3. Une Improve & Explore Iteration (IE Iteration) par les Agile Teams
  4. Un Continuous Improvement Forum (CIF) avec l’ensemble de la Product Team

Les Product Cycles s’enchainent à la suite. Exception faite du tout premier PC Planning, il fait donc suite au Continuous Improvement Forum du Product Cycle précédent.

PC Planning

Chaque Product Cycle commence par un événement global avec l’ensemble des membres de la Product Team pour cadrer les enjeux du PC, notamment en définissant les PC Goals. Cet événement s’appelle PC Planning.

Le but du PC Planning  est de :

  • Générer de l’engagement de l’ensemble de la Product Team autour d’enjeux communs
  • Aider les Agile Teams à réduire au maximum les dépendances entre elles
  • Garantir un rythme soutenable et un niveau de qualité élevé en laissant les Agile Teams décider du volume de travail qu’elles peuvent raisonnablement prendre

Le but du PC Planning  n’est pas de :

  • Prévoir avec exactitude ce qui sera livré d’ici la fin du PC
  • Définir un plan à suivre à la lettre par les Agile Teams
  • Synchroniser les dépendances entre les Agile Teams

Un PC Planning s’articule autour de plusieurs phases :

  1. Context Sharing
  2. PC Goals Candidates
  3. Agile Teams Planning
  4. Event Continuous Improvement

Context Sharing

Un PC Planning commence par une première phase où sont rappelés la vision produit et les enjeux pour l’organisation.

Sont également partagés les changements dans l’écosystème de l’organisation. Il peut s’agir de changements au sein de l’organisation, des nouveaux clients, de l’évolution du marché…

D’une manière générale, il est question d’aussi bien renforcer la raison d’être de la Product Team que de donner des éléments de contexte pour un bon déroulement de la suite du PC Planning.

PC Goals Candidates

À la fin du PC Planning, un ensemble de PC Goals seront sélectionnés par les différentes Agile Teams. Avant de laisser les Agile Teams faire ce travail lors du Agile Teams Planning qui suit, un premier ensemble de PC Goals est proposé.

Si le Context Sharing donnait la vision globale d’où il fallait emmener le produit (on parle de vision produit), cette liste provisoire de PC Goals constitue la stratégie produit qu’on envisage de suivre pendant ce Product Cycle.

Le but des PC Goals Candidates  est de :

  • Donner une première liste priorisée d’opportunités qui méritent d’être saisies
  • Poser un cadre permettant aux Agile Teams de s’auto-organiser lors du Agile Teams Planning qui suit

Le but des PC Goals Candidates  n’est pas de :

  • Lister précisément le travail qui sera attendu des Agile Teams

Agile Teams Planning

Au coeur du PC Planning il y a le Agile Teams Planning où chaque Agile Team travaille à construire un plan préliminaire pour le Product Cycle, listant les PC Goals auxquels contribuera l’équipe.

Pour y parvenir, chacun se concentre sur sa Agile Team tout en collaborant avec le reste de la Product Team. Un des enjeux majeurs du Agile Teams Planning est l’identification et la gestion des dépendances entre les Agile Teams. Il est crucial d’essayer de réduire au maximum les dépendances au sein de la Product Team.

Le Agile Teams Planning se déroule en plusieurs tours ou itérations. À la fin du tour, chaque Agile Team partage son plan préliminaire pour le PC ainsi que son vote de confiance dans l’atteinte de ses PC Goals. Un nouveau tour est lancé sur les votes de confiance des Agile Teams n’est pas élevé.

On imagine aisément que l’ensemble du PC Planning puisse prendre deux jours à une Product Team nouvellement créée. La phase d’Agile Teams Planning nécessite d’autant plus de tours que les Agile Teams n’ont pas l’aplomb de prendre moins de travail pour développer leur pluridisciplinarité et ainsi réduire les dépendances entre les Agile Teams. En effet, dans la plupart des organisations, les croyances établies vont à contre-sens de cette approche et il n’apparait pas comme une évidence que les dépendances entre équipes, et la synchronisation forte qu’elles requièrent, sont une des pires sources d’inefficacité.

À l’inverse, une Product Team habituée à ce mode de fonctionnement, et en particulier avec des Agile Teams qui ont su développer une véritable flexibilité, il devient normal de faire l’ensemble du PC Planning en moins d’une journée. Cela requiert des Agile Teams pluri-disciplinaires capables de développer de bout en bout des fonctionnalités. (”feature teams”)

Le but de l'Agile Teams Planning  est de :

  • Aider les Agile Teams à visualiser et réduire leurs dépendances
  • Faciliter la ré-allocation des éléments de travail entre les Agile Teams pour réduire leurs dépendances
  • Encourager les Agile Teams à acquérir de nouvelles compétences et connaissances pour les rendre plus flexibles et limiter les dépendances au sein de la Product Team
  • S’assurer d’un niveau de confiance élevé dans l’atteinte des PC Goals sélectionnés

Le but de l'Agile Teams Planning  n’est pas de :

  • Séquentialiser le travail des différentes Agile Teams, mais de trouver d’autres solutions impliquant moins d’Agile Teams, idéalement une seule

Event Continuous Improvement

Enfin, on clôture le PC Planning par une sorte de courte rétrospective sur le PC Planning lui-même.

D’une manière générale, tous les événements méritent d’y intégrer une mécanique d’amélioration continue. De par l’importance structurante du PC Planning, il est essentiel d’ainsi réserver du temps à sa fin pour confirmer qu’il s’est bien déroulé et voir ce qui pourrait être expérimenté la fois suivante.

Agile Iteration

Une Agile Iteration correspond à une itération effectuée par une Agile Team et se conclut par une Fully-Integrated Demo. La durée des Agile Iterations est fixée par avance. Elle est la même pour toutes les Agile Teams car elle définit la cadence à laquelle les Agile Teams vont se retrouver pour la Fully-Integrated Demo commune.

Fully-Integrated Demo

Lors d’une Fully-Integrated Demo, l’ensemble de la Product Team se réunit pour partager l’avancement des différentes Agile Teams mais aussi pour garantir que le travail de chaque Agile Team est bien intégré.

Le but des Fully-Integrated Demos  est de :

  • Garantir que les Agile Teams pratiquent l’intégration continue (”continuous integration”) et le déploiement continu (”continuous delivery”)
  • Donner une visibilité réelle sur l’état d’avancement en ne se basant que sur ce qui est réellement terminé — dixit un des principes du manifeste pour le développement agile de logiciels : Working software is the primary measure of progress.
  • Encourager au maximum les Agile Teams à découper leur travail en éléments de valeur de granularité fine ; limiter les éléments de travail purement techniques qui ne délivrent leur valeur que lorsque tout est terminé
  • Garder la vision de toute la Product Team sur la vision et sur le cap qui a été fixé pour le Product Cycle
  • Célébrer les réussites et partager les apprentissages
  • Maintenir une cohésion au travers de toute la Product Team

Le but des Fully-Integrated Demos  n’est pas de :

  • Montrer que les Agile Teams ont bien travaillé

Agile Team  en Scrum

Pour une Agile Team avec un fonctionnement apparenté à Scrum, la notion de Agile Iteration est de prime abord équivalente à la notion de Sprint dans Scrum. Pour une Agile Team Scrum qui aurait une durée de Sprint identique à la durée des Agile Iterations, la fin de ses Sprints consisterait en l’enchaînement des événements suivants : Sprint Retrospective, Sprint Review, Fully-Integrated Demo. La Sprint Review et la Fully-Integrated Demo ne sont pas redondants :

  • La Sprint Review sert à collecter du feedback pour co-construire le contenu du Sprint suivant de la Agile Team. C’est une véritable session de travail et c’est pourquoi Scrum recommande une timebox relativement conséquente, souvent de l’ordre de 2 heures pour un Sprint de 2 semaines et pour une seule Agile Team.
  • La Fully-Integrated Demo sert à maintenir une cohérence globale au sein de la Product Team. De par la présence de l’ensemble de la Product Team, mais aussi de par la durée relativement courte de 1 heure, il est plus difficile de collecter du feedback actionnable pour les Agile Teams.

Les Fully-Integrated Demos sont des points de rendez-vous. Les Agile Teams Scrum peuvent avoir des durées de Sprint différentes de la durée des Agile Iterations. Pour une meilleure compatibilité, il est recommandé de faire en sorte que l’imbrication des deux cadences tombe juste : par exemple, une durée de Sprint de 1 semaine fonctionnera bien pour des Agile Iterations de 2 semaines, chaque Agile Iteration correspondant à 2 Sprints.

Agile Team  en Kanban

Pour une Agile Team avec un fonctionnement apparenté à Kanban, qui fonctionne donc en flux continu, il n’y a pas de notion d’itération au sein de la Agile Team. La Agile Team Kanban doit par contre intégrer dans sa routine les Fully-Integrated Demos pour y participer.

Improve & Explore Iteration (IE Iteration)

La dernière itération du Product Cycle est différente des autres Agile Iterations. Il va accomplir les objectifs suivants :

  • Fournir un temps dédié à l’innovation et à l’amélioration continue, par exemple via l’organisation de hackathons au sein de la Agile Team ou pourquoi pas au niveau de l’ensemble de la Product Team
  • Faire le travail préliminaire d’exploration et de préparation au PC Planning, nécessaire à un déroulé fluide et efficace
  • Exceptionnellement et en dernier recours, elle peut servir de tampon pour terminer des éléments de travail critiques pour l’organisation ; cela doit être l’exception plutôt que la règle, sinon les Agile Teams ne pourront pas procéder aux autres activités ci-dessus, qui sont nécessaires pour atteindre un bon fonctionnement de l’ensemble de la Product Team
Le but de la Improve & Explore Iteration  est de :

  • Prendre le temps de finaliser les explorations préalables nécessaires à un bon déroulé du PC Planning
  • Donner du temps à l’ensemble de la Product Team pour se former et améliorer ses outils
  • Faire les derniers ajustements suite au feedback collecté lors de la précédente Agile Iteration

Le but de la Improve & Explore Iteration  n’est pas de :

  • Terminer tout ce qui n’a pas pu être terminé pendant les Agile Iterations
  • Mener l’intégralité des activités produit de “Discovery”, car elles doivent être faites en continu pendant les Agile Iterations

Pour des raisons pratiques, cette dernière itération est également plus courte de quelques jours. Le but est d’intégrer dans le calendrier le temps nécessaire au Continuous Improvement Forum et au PC Planning du Product Cycle suivant tout en ayant des Agile Iterations de même durée et démarrant le même jour.

Par exemple :

  • Soit un Product Cycle de 10 semaines
  • Avec des Agile Iterations de 2 semaines (soit 10 jours ouvrés)
  • Si le Continuous Improvement Forum dure une demi-journée et le PC Planning dure 1 jour
  • Alors la Improve & Explore Iteration dure 8,5 jours ouvrés

Continuous Improvement Forum (CIF)

Le Product Cycle se termine par un Continuous Improvement Forum. Un CIF se compose de trois parties :

  1. PC Fully-Integrated Demo
  2. Product Team Health Check
  3. Global Retrospective

PC Fully-Integrated Demo

Comme à la fin de chaque Agile Iteration, le Product Cycle se conclut par une Fully-Integrated Demo. Celle-ci a néanmoins une particularité : elle marque la fin de tout le Product Cycle et en tant que tel elle montrera donc l’ensemble du travail accompli.

C’est aussi le moment de comparer les PC Goals qui ont été définis en PC Planning avec ce que les Agile Teams ont effectivement fait.

Ainsi, la PC Fully-Integrated Demo touche généralement un public encore plus large que d’habitude.

Le but de la PC Fully-Integrated Demo  est de :

  • Communiquer largement au sein de l’organisation et de son écosystème (par exemple avec ses clients)
  • Clôturer proprement le Product Cycle, marquer le coup et célébrer

Le but de la PC Fully-Integrated Demo  n’est pas de :

  • Mesurer la productivité du système mais bien de se concentrer sur la valeur produite

Product Team Health Check

La deuxième partie du CIF est le Product Team Health Check. Durant ce dernier, les Agile Teams partagent et revoient un ensemble de métriques. Le but est de piloter par des données l’amélioration continue de l’ensemble de la Product Team.

Sont regardées les données par Agile Team mais également la vue d’ensemble agrégée de la Product Team.

Les métriques suivies sont à l’initiative de la Product Team.

Le but du Product Team Health Check  est de :

  • Uniformiser le suivi des Agile Teams pour avoir une vue globale de la Product Team et faire ainsi ressortir les tendances qui méritent d’être discutées lors de la Global Retrospective qui suit
  • Piloter l’amélioration continue de la Product Team par des données
  • Aligner toute la Product Team sur des critères communs d’évaluation de la santé des Agile Teams ; donner une définition concrète de ce qui doit être important pour les Agile Teams
  • Construire un référentiel permettant un suivi dans le temps pour faire apparaitre les évolutions, positives comme négatives

Le but du Product Team Health Check  n’est pas de :

  • Comparer les Agile Teams les unes avec les autres, mais bien de faire ressortir les tendances globales
  • Se concentrer uniquement sur le volume de travail effectué, mais d’avoir un ensemble de métriques qui, regardées ensemble, donnent une vue complète

Global Retrospective

La troisième et dernière partie du CIF est une Global Retrospective. Comme toute rétrospective, il existe de nombreux formats possibles. Toute la Product Team y prend part.

Les Agile Teams font généralement elles aussi des rétrospectives à la fin de chaque Agile Iteration. Par exemple, une Agile Team suivant un fonctionnement apparenté à Scrum fera des Sprint Retrospectives.

Pour s’assurer que les actions prises lors d’une Global Retrospectives sont bien mises en places, elles sont ajoutées au Opportunities Backlog de la Product Team. Leur résolution sera planifiée lors du PC Planning qui suit la Global Retrospective.

Le but de la Global Retrospective  est de :

  • Améliorer la Product Team comme un système complexe, en adressant des sujets au niveau global et pas uniquement via les Agile Teams
  • Remettre en question les fonctionnements établis au sein de la Product Team
  • Essaimer les succès et bonnes pratiques entre les Agile Teams, sans nécessairement les imposer comme des standards imposés à l’ensemble de la Product Team
  • Trouver des moyens pour réduire les dépendances entre les Agile Teams, et si possible voir comment découper la Product Team en plusieurs Product Teams indépendantes
  • Encourager les Agile Teams à expérimenter à leur niveau avec leurs modes de fonctionnement, en montrant l’exemple au niveau global de la Product Team

Le but de la Global Retrospective  n’est pas de :

  • Parler uniquement des problèmes et des points faibles de la Product Team, mais aussi de voir comment capitaliser sur ses forces et atouts
  • Piloter les process de la Product Team par un groupe restreint, mais d’impliquer l’ensemble des membres de la Product Team
  • Se limiter à un quelconque ensemble de pratiques et de modes de fonctionnement, mais d’aller jusqu’à remettre en question le framework lui-même

Rappelons que le framework STEADY est adapté à des environnements qui restreignent le niveau d’agilité qu’il est possible d’atteindre car nécessitant de nombreuses personnes pour définir et implémenter la solution à un problème donné.

Il est essentiel de garder cet état de fait en tête. Si le framework STEADY vous aide à gérer la situation, il ne doit pas vous faire perdre de vue que le système dans sa globalité a besoin d’être amélioré pour lever ces limites et permettre ainsi une plus grande agilité.

Les Global Retrospectives jouent un rôle critique dans cette démarche d’amélioration continue qui va au-delà des Agile Teams. L’un des enjeux majeurs des Global Retrospectives est de réussir à progressivement découper le problème dont est en charge la Product Team en plusieurs problèmes, plus petits et indépendants. Il devient alors possible de faire travailler plusieurs Product Teams en parallèle sur ces différents problèmes. Plus important encore, chaque Product Team travaille alors sur des problèmes de complexité réduite.

Ces nouvelles Product Teams, a priori plus petites, peuvent continuer d’utiliser STEADY ou se tourner vers d’autres frameworks, plus adaptés à leur nouvelle situation. Quand par exemple une Product Team fait la taille d’une Agile Team, il devient naturel d’utiliser uniquement Scrum ou Kanban. Plus les Product Teams sont petites, plus elles peuvent se contenter de processus légers et ainsi augmenter en efficacité.

Product Team

La Product Team comprend plusieurs Agile Teams ainsi qu’un certain nombre de Support Groups, des groupes transverses à ces dernières.

Les activités de la Product Team sont structurées à haut niveau au sein d’un Opportunities Backlog. Le but du PC Planning est de sélectionner les éléments du Opportunities Backlog sur lesquels les Agile Teams travailleront pendant le Product Cycle. Les PC Goals sont ces éléments qu’on a sélectionné du Opportunities Backlog.

Opportunities Backlog

La notion d’Opportunities Backlog est similaire à celle de Product Backlog en Scrum.

La différence princicpale est que l’Opportunities Backlog se place au niveau de toute la Product Team, quand le Product Backlog se place au niveau d’une Agile Team.

Il s’ensuit une différence significative de granularité des éléments : toujours comparé à Scrum, les éléments de l’Opportunities Backlog correspondent plutôt à des Sprint Goals en termes de taille.

Pour un bon fonctionnement de la Product Team, les éléments de l’Opportunities Backlog doivent décrire des problèmes à résoudre et non pas des fonctionnalités ou des solutions à implanter.

En effet, l’exploration produit (”discovery”) fait partie des activités que doivent effectuer en continu les Agile Teams. Les Product Cycles ne doivent pas être uniquement composées d’activités de livraison de solutions (”delivery”).

De plus, en parlant de problèmes à résoudre plutôt que de solutions à implanter, cela laisse ouvert le champ des possibles techniques. C’est un élément clé pour réussir à réduire les dépendances entre Agile Teams pendant le PC Planning. Cela rend par exemple plus facile pour les Agile Teams de se réattribuer les PC Goals lors du PC Planning plutôt que de travailler à plusieurs Agile Teams en même temps on séquentiellement sur le même PC Goal. Cela rend aussi possible d’avoir plusieurs Agile Teams qui contribuent au même PC Goal sans être pour autant en dépendance l’une avec l’autre, en abordant le problème à résoudre sous des angles différents ou avec des solutions techniques permettant de travailler indépendamment à plusieurs Agile Teams.

Enfin, un focus sur les problèmes à résoudre plutôt que sur les solutions à implanter permet de :

  • Ne jamais perdre de vue la valeur visée, c’est à dire le problème que l’on cherche à résoudre
  • Retarder les prises de décision au dernier moment raisonnable (un des principes du Lean)

Pour aider à la priorisation en PC Planning, il est essentiel qu’une notion d’impact soit formulée pour chaque élément de l’Opportunities Backlog. Que risque-t-on à ne pas le faire ?

Une approche du type coût du délai peut être très puissante : dans l’hypothèse où nous ne le faisons pas, que ne gagnons-nous pas ? Cette approche permet d’unifier aussi bien les opportunités de nouveaux revenus (par exemple via une nouvelle fonctionnalité), que la réduction de pertes de revenus (par exemple via la correction d’une anomalie, ou via l’optimisation des coûts opérationnels).

À noter que les éléments de l’Opportunities Backlog ne sont pas uniquement des éléments orientés utilisateur ou client. On y trouvera aussi des élément techniques comme la mise en place d’une nouvelle approche technique, ou des éléments organisationnels comme les actions prises lors de la Global Retrospective. Il s’agit tout autant d’opportunités à saisir que les éléments orientés utilisateur ou client. Là aussi, il faut parler de problème à résoudre et non pas de solution à implanter : quel est le problème ? Comme pour les autres éléments de l’Opportunities Backlog, il est essentiel de formuler l’impact de résoudre ce problème — ou au contraire, l’impact de ne pas le résoudre.

En pratique, les Support Groups de Product Management et de Product Architecture sont responsables de la bonne tenue de l’Opportunities Backlog. Cela ne veut pas dire pour autant que seuls ses membres peuvent y contribuer ; l’Opportunities Backlog reste un élément de travail fondamental et partagé avec tous les membres de la Product Team.

Le but de l'Opportunities Backlog  est de :

  • Structurer la stratégie produit de la *Product Team*
  • Donner de la visibilité sur les éléments qui seront échangés lors du PC Planning, et donc permettre aux Agile Teams de s’y préparer
  • Fournir des éléments permettant une priorisation lors des PC Plannings, en particulier via la notion d’impact
  • Insuffler à toute la Product Team ce mode de fonctionnement qui se concentre sur les problèmes à résoudre et sur l’impact qu’on veut générer, plutôt que d’essayer de livrer un maximum de fonctionnalités

Le but de l'Opportunities Backlog  n’est pas de :

  • Lister des fonctionnalités ou des chantiers techniques à implanter, mais des problèmes à résoudre
  • Faire l’essentiel du travail d’exploration produit (”discovery”) en dehors des Agile Teams et des Product Cycles
  • Donner une vision à long terme du produit (à plus de quelques Product Cycles d’avance) ni de remplacer la vision produit

Support Groups

Au sein d’une Product Team donné il existe 4 Support Groups différents :

  • Product Management
  • Product Architecture
  • Product Team Facilitation
  • Product Delivery Pipeline

Product Management

Les activités de gestion de produit (”product management”) sont au coeur de toute approche produit et de toute équipe agile. Néanmoins, dans le cadre d’une organisation nécessitant l’emploi d’un framework comme STEADY, c’est à dire dont la conception et la construction d’une solution nécessite la collaboration de plusieurs dizaines de personnes, ces activités ne peuvent pas être uniquement portées au sein des Agile Teams. C’est pourquoi un Support Group dédié au Product Management est nécessaire en transverse au niveau de la Product Team.

Si tous les membres de toutes les Agile Teams doivent se retrouver acteurs de la démarche produit de la Product Team, il est esssentiel d’apporter un focus global sur le produit dont est en charge la Product Team.

Le but du Support Group  de Product Management  est de :

  • Faciliter la démarche produit au sein des Agile Teams
  • Insuffler et garder un focus global sur le produit
  • Rappeler et renforcer la vision produit
  • S’assurer que tous les éléments de l’Opportunities Backlog formulent une notion d’impact
  • S’assurer d’une démarche d’apprentissage continue (veille) sur la gestion produit (”product management”)

Le but du Support Group  de Product Management  n’est pas de :

  • Centraliser le travail d’exploration produit (”discovery”) en dehors des Agile Teams et des Produt Cycles
  • Donner des ordres aux Agile Teams

Product Architecture

Si la Product Team valorise la saisie d’opportunités à court terme, elle doit aussi toujours garder en tête une vision long terme et en particulier la maintenabilité des solutions qu’elle conçoit. C’est la raison d’être du Support Group dédié à la Product Architecture : garder sous contrôle la dette technique, insuffler les bonnes pratiques techniques et en particulier la mise en place de la qualité intrinsèque (”built-in quality”), mais aussi identifier et prioriser les chantiers techniques nécessaires.

Si tous les membres de toutes les Agile Teams doivent se retrouver acteurs de l’excellence technique de la Product Team, il est esssentiel d’apporter un focus global sur les challenges techniques dont est en charge la Product Team. La Product Architecture n’est pas à opposer à la conception émergente (”emergent design”). Au contraire, la Product Architecture doit l’encourager. Les Agile Teams doivent pratiquer au maximum la conception émergente (”emergent design”), tout en adressant via la Product Architecture les points nécessitant une synchronisation de l’ensemble de la Product Team.

Le but du Support Group  de Product Architecture  est de :

  • Faciliter la démarche de qualité intrinsèque (”built-in quality”) et plus généralement l’excellence technique au sein des Agile Teams
  • Insuffler et garder un focus global sur la maintenabilité
  • Insuffler et faciliter la conception émergente (”emergent design”) au sein des Agile Teams
  • S’assurer que tous les éléments de l’Opportunities Backlog formulent une notion d’impact
  • S’assurer d’une démarche d’apprentissage continue (veille) sur l’excellence technique

Le but du Support Group  de Product Architecture  n’est pas de :

  • Centraliser le travail d’architecture en dehors des Agile Teams et des Produt Cycles
  • Donner des ordres aux Agile Teams

Product Team Facilitation

Le Support Group dédié à la Product Team Facilitation a pour rôle de fluidifier le fonctionnement global de la Product Team. La Product Team Facilitation insuffle au quotidien une dynamique d’amélioration continue, d’expérimentation et d’empirisme. À cet effet, une bonne animation de moments clés comme le PC Planning et le Continuous Improvement Forum est crucial.

Il est également question d’être le gardien de la Improve & Explore Iteration qui ne doit être qu’exceptionnellement utilisée comme tampon pour terminer des éléments de travail qui n’ont pas pu être terminées pendant les Agile Iterations.

De la même manière, la Product Team Facilitation s’assure que les indicateurs suivis lors du Product Team Healtch Check sont pertinents et aident à emmener la Product Team dans la bonne direction d’un point de vue dynamique d’équipe.

La Product Team Facilitation rappelle également à tout moment l’importance de réduire au maximum les dépendances entre les Agile Teams, qu’il s’agisse du PC Planning ou de la Global Retrospective.

Si tous les membres de toutes les Agile Teams doivent se retrouver acteurs du mode de fonctionnement de la Product Team, il est esssentiel d’apporter un focus global sur l’amélioration continue, aussi bien au niveau des Agile Teams qu’au niveau transverse de la Product Team.

De par les enjeux de transformation organisationnelle, il est courant d’avoir un facilitateur à temps plein au sein de la Product Team Facilitation. On l’appelle Product Team Coach (PTC). Un PTC est avant tout un Scrum Master ou coach agile expérimenté.

Le but du Support Group  de Product Team Facilitation  est de :

  • Faciliter la démarche d’amélioration continue au sein des Agile Teams
  • Insuffler et garder un focus global sur la réduction des dépendances
  • Assurer un bon déroulé des événements clés de la Product Team, dont en particulier le PC Planning et le Continuous Improvement Forum
  • Garantir que la Improve & Explore Iteration est utilisée à bon escient, et qu’elle ne sert qu’exceptionnellement de tampon pour terminer des éléments de travail
  • S’assurer d’une démarche d’apprentissage continue (veille) sur l’agilité et tous les sujets connexes

Le but du Support Group  de Product Team Facilitation  n’est pas de :

  • Centraliser l’amélioration continue en dehors des Agile Teams et des Produt Cycles
  • Donner des ordres aux Agile Teams

Product Delivery Pipeline

Parce que toutes les Agile Teams travaillent de concert sur le même produit, il est probable qu’elles aient de fortes adhérences techniques avec notamment de fortes problématiques d’intégration et de livraison. C’est le rôle du Support Group dédié à la Product Delivery Pipeline d’outiller et fluidifier le processus de livraison de valeur. De manière concrète, on y trouve toutes les pratiques et les outils d’intégration continue (”continuous integration”) et de déploiement continue (”continuous delivery”).

La Product Delivery Pipeline joue un rôle hybride, à la fois coach de l’ensemble des Agile Teams pour que tous ses membres montent en compétence sur ces sujets, et acteur qui fait fonctionner le processus de livraison de valeur actuel. Toute la difficulté de la Product Delivery Pipeline est de réussir à trouver le bon équilibre entre ces deux enjeux cruciaux, de réussir à améliorer le système sans passer par un arrêt brutal de son fonctionnement.

Il est ainsi courant, dans un premier temps, que la Product Delivery Pipeline soit composée d’une équipe dédiée et en dehors des Agile Teams pour pouvoir addresser de manière satisfaisante ces deux enjeux. À l’inverse, cela devrait poser des questions si au bout de plusieurs années la Product Delivery Pipeline existe toujours sous cette même forme. Le but d’une telle équipe dédiée est de se rendre progressivement dispensable puis de disparaitre, au profit d’une communauté de pratique.

Le but du Support Group  de Product Delivery Pipeline  est de :

  • Accompagner l’ensemble des membres des Agile Teams sur les problématiques d’intégration et de livraison pour essayer de réduire les adhérences entre équipes
  • S’assurer que le processus de livraison de valeur fonctionne et s’améliore continuellement avec le temps

Le but du Support Group  de Product Delivery Pipeline  n’est pas de :

  • Maintenir et faire évoluer le processus de livraison de valeur sans impliquer ni faire monter en compétence les membres des Agile Teams
  • Donner des ordres aux Agile Teams

Structure des Support Groups

En pratique, chacun de ces groupes peut prendre l’une des formes suivantes :

Une communauté de pratique : (”community of practices”, “chapter”) elle est composée de membres des Agile Teams. Chacun de ces membre fait donc simultanément partie de deux équipes en même temps, son Agile Team et le Support Group auquel il contribue. C’est le modèle à préférer quand la Product Team est suffisamment petite et qu’il n’y a pas d’enjeux forts pesant sur le Support Group.

Exemple : la Product Architecture pourrait être gérée comme une communauté de pratique impliquant des experts des différentes Agile Teams.

Communauté de pratique avec facilitateur à temps plein : pour les plus grandes Product Teams, ou en présence d’enjeux forts, la communauté de pratique peut avoir un facilitateur à temps plein. On l’appele Group Facilitator ou Group Coach. Ce dernier ne fait donc partie d’aucune Agile Team. Cette personne dédiée fait souvent la différence quand la Product Team évolue dans une organisation plutôt hostile à l’agilité.

Exemple : la Product Team Facilitation pourrait être composée des Scrum Masters des différentes Agile Teams ainsi que d’un Product Team Coach (PTC) dédié à sa facilitation, et plus généralement à l’animation du fonctionnement global de la Product Team. Il serait également un agent du changement vis-à-vis du reste de l’organisation.

Une équipe dédiée : pour les Product Teams avec des enjeux critiques sur la problématique du Support Group, une équipe dédiée peut devenir nécessaire. Cela doit être une solution de dernier recours, et qui se veut temporaire.

Exemple : la Product Delivery Pipeline pourrait être composée de membres dédiés et à temps plein. Leur rôle serait aussi bien de fournir des outils à l’ensemble de la Product Team que de s’assurer du bon fonctionnement du pipeline de déploiement continu partagé par toutes les Agile Teams. Plus important encore, leur rôle serait d’insuffler ces outils et pratiques au sein des Agile Teams pour embrayer progressivement vers le modèle de communauté de pratiques. Cet exemple est assez courant lorsque la Product Team n’a précédemment mis en place que peu de pratiques liées à la qualité intrinsèque (”built-in quality”). L’impact de ne pas avoir assez de tests automatiques de non-régression en place rend difficile voire impossible le fonctionnement de la Product Team sans équipe dédiée pour travailler sur la Product Delivery Pipeline. Il est alors essentiel que cette équipe travaille activement à insuffler ces éléments dans les Agile Teams, au risque de ne sinon jamais changer durablement les pratiques de développement de la Product Team.

Agile Team

La Agile Team est la brique de base de la Product Team, composée d’un ensemble d’Agile Teams et de Support Groups.

Chaque Agile Team est libre de définir son mode de fonctionnement, tant qu’il est compatible avec le reste de la Product Team.

Les deux modes de fonctionnement les plus courants sont Scrum et Kanban.

Rôles

Par analogie avec Scrum, toutes les Agile Teams ont généralement un Product Owner ou Product Manager et un Scrum Master ou coach agile.

Le Product Owner ou Product Manager prend part au Support Group de Product Management.

Le Scrum Master ou Team Coach prend part au Support Group de Product Team Facilitation.

Cadencement avec les Agile Iterations

Une Agile Team avec un fonctionnement apparenté à Scrum fera en sorte de caler sa durée de Sprint sur celle des Agile Iterations, ou alors sur des durées de Sprint plus courtes mais compatibles. Par exemple une durée de Sprint de 1 semaine pour des Agile Iterations de 2 semaines : la Agile Team clôture sa Agile Iteration tous les 2 Sprints.

Une Agile Team avec un fonctionnement apparenté à Kanban fera en sorte d’intégrer les événements de la Product Team dans sa routine, en étant présent et préparé à ces derniers.

PC Goals  versus Sprint Goals et apprentissage continu

Une équipe Scrum fixe un Sprint Goal à chaque Sprint.

Une Agile Team avec un fonctionnement apparenté à Scrum doit essayer de faire le lien avec les PC Goals qu’elle a choisi en PC Planning et les Sprint Goals de ses Sprints. Idéalement, il faudrait avoir exactement un seul PC Goal par Sprint, qui pourrait alors être le Sprint Goal du Sprint. Cela implique deux difficultés possibles :

  • Soit d’avoir des PC Goals trop petits, réalisables en moins d’un Sprint
  • Soit d’avoir des PC Goals trop gros, qui nécessitent plusieurs Sprints pour être réalisés

La Agile Team utilisera ses Sprint Plannings pour faire le travail nécessaire de découpage et de regroupement pour démarrer des Sprints avec exactement un seul Sprint Goal.

Ainsi, le résultat attendu en PC Planning n’est pas d’avoir une correspondance directe entre les PC Goals choisis par l’équipe et les Sprints de l’équipe. La Agile Team devrait faire ce travail d’affinage en continu pendant le PC, tout en se gardant de la marge pour prendre en compte ce qui sera découvert au fil des Agile Iterations.

En fin de Sprint, la Agile Team utilisera la Sprint Review pour inspecter le travail fait et les apprentissages associés. La Sprint Review doit nourrir les Sprints suivants, voire même remettre en question les PC Goals choisis par l’équipe.

Les Agile Teams ne se contentent pas d’exécuter un plan établi en PC Planning. Elles apprennent en continu. Elles ont la légitimité et l’obligation de remettre en question cette planification, si elles découvrent des éléments qui la rendent obsolète.

Feature Teams : développer la flexibilité et la pluri-disciplinarité

Un des enjeux majeurs du PC Planning est de réduire au maximum les dépendances entre les Agile Teams. Pour y arriver, il est essentiel que les Agile Teams développent la capacité à concevoir et à construire de bout en bout des fonctionnalités apportant de la valeur : on parle de Feature Teams.

Au-delà de limiter les dépendances, le modèle des Feature Teams augmente la flexibilité au sein de la Product Team. Cela rend la Product Team plus robuste. Cela donne aussi la possibilité de saisir plus d’opportunités en étant capable de mobiliser plus d’équipes sur un sujet donné.

Ce mode de fonctionnement nécessite un investissement conséquent dans les Agile Teams et dans les personnes les composant. Il faut vivre cette maxime : quand la spécialisation devient une contrainte, on prend le temps nécessaire pour apprendre.

Le Support Group de Product Team Facilitation a pour rôle d’inciter les Agile Teams à prendre ce temps nécessaire. Cela se verra en particulier pendant les PC Plannings, en encourageant les Agile Teams à choisir des PC Goals qui les forceront à monter en compétence, quitte à choisir moins de PC Goals. Cela se verra aussi durant la Improve & Explore Iteration dont les activités peuvent aussi servir à développer la flexibilité de l’équipe.

Vous souhaitez être informé(e) des évolutions du framework STEADY ?

En remplissant ce formulaire, vous consentez à ce que Scrum Life, en sa qualité de responsable de traitement, collecte vos données afin de vous envoyer des communications par voie électronique. Vous pourrez vous désabonner à tout moment. Pour faire valoir votre droit d’accès ou d’effacement, consultez notre politique de confidentialité.

Vous voulez nous donner du feedback sur le framework STEADY ?