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.
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.
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.
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 :
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.
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.
Un PC Planning s’articule autour de plusieurs phases :
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.
À 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.
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”)
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.
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.
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é.
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 :
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.
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.
La dernière itération du Product Cycle est différente des autres Agile Iterations. Il va accomplir les objectifs suivants :
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 :
Le Product Cycle se termine par un Continuous Improvement Forum. Un CIF se compose de trois parties :
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.
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.
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.
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é.
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.
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 :
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.
Au sein d’une Product Team donné il existe 4 Support Groups différents :
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.
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 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é.
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.
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.
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.
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.
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.
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 :
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.
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.
