Deux Clés Pour Une Transformation Agile Sans Frustration

17 Avril 2019
agilité actualité SAFe
Le monde actuel pousse les DSI, tout comme les entreprises en général à devenir plus adaptables, flexibles mais aussi plus réactives face à un marché en constante évolution. Les méthodes Agiles offrent une réponse possible. Cependant, appliquer une méthode Agile SCRUM dans une petite équipe est totalement différent vis-à-vis d’une même mise en place à l’échelle d’une entreprise de plus de 50 salariés. Cela nécessite d’autres modèles comme, par exemple, SAFe.

C’est dans ce contexte de transformation agile, du passage d’un modèle SCRUM appliqué à plusieurs équipes à un modèle SAFe que cet article se placera.

Après avoir vécu trois Program Increments (PI) et une transformation agile, je vous partage dans cet article deux clés à utiliser afin de faciliter l’implémentation de SAFe dans une organisation. Ces clés reposent sur deux des valeurs du Manifeste Agile :

  • les individus et leurs interactions plus que les processus et les outils ;

  • l’adaptation au changement plus que le suivi d’un plan.

Elles vous permettront d’éviter les frustrations, le désengagement et la non-implication au sein de la SCRUM TEAM (Product Owner, ScrumMaster, Dev Team).

 

Qu’est-ce que SAFe ?

SAFe (Scaled Agile Framework) est un framework qui a été créée en 2011 dans le but d’accompagner les entreprises dans leur volonté de mise en pratique d’agilité à l’échelle. La problématique principale de ce changement de niveau est de faire converger une multitude d’équipes, de techniques, de processus et autres contextes vers la même finalité. Cela est permis grâce à l’insertion d’un framework lean-agile.

Il permet de faire travailler plusieurs équipes agiles ensemble au sein d’une même structure. La particularité de SAFe est qu’il impacte tous les niveaux d’organisation d’une entreprise du Top Management au Middle Management, jusqu’à la Team Technique.

Dans SAFe, la strate Top Management peut être rattachée au niveau « Portfolio », le Niveau Program à la Strate Middle Management et le niveau Team représente la strate opérationnelle de l’entreprise. La Strate Large Solution n’est qu’une extension du niveau Program.

Le schéma ci-dessous représente la base de SAFe. Il est disponible sur le site officiel où il est possible de cliquer sur chacune des parties afin de comprendre leur rôle.

schéma_methode_safe

Généralement, le contexte d’une transformation agile entraîne dans les faits une concentration sur la transformation et le modèle à implémenter (la technique) alors que le focus devrait être pointé sur les valeurs, malheureuses oubliées du changement. Avant d’être un framework, SAFe est « Agile ». Or, qui dit Agile, dit Manifeste Agile.

Le Manifeste Agile repose sur quatre valeurs :

  • Les individus et leurs interactions plus que les processus et les outils.

  • Un logiciel qui fonctionne plus qu’une documentation exhaustive.

  • La collaboration avec les clients plus que la négociation contractuelle.

  • L’adaptation au changement plus que le suivi d’un plan.

Ici, nous nous focaliserons sur les deux valeurs qui ont été le plus source de problèmes durant la transformation que j’ai vécue.

 

Les individus et leurs interactions   

Lorsqu’on effectue le passage du modèle SCRUM au modèle SAFe, il faut prendre en compte les individus et leurs interactions. C’est-à-dire qu’il faut être au courant des interactions qui existaient avant la transformation, savoir que la transformation va forcément impacter les rôles et qu’il faudra s’adapter en adoptant notamment une écoute active.

  • Avant SAFe, une équipe full SCRUM :

La Scrum Team est composé de trois rôles : Dev Team, ScrumMaster, Product Owner (PO).

En plus de définir les critères d’acceptation et de construire le Backlog Produit, l’une des principales responsabilités du Product Owner est de comprendre les besoins et les priorités des Stakeholders.

En effet, le Product Owner, dont la fonction principale est d’écrire les User Stories, les Features (fonctionnalités) et les Epics, représente les Stakeholders. Parmi ces derniers, on retrouve notamment le Program Management, Partner, Business Owner, Sponsor, utilisateurs et autres.

Voici un schéma qui résume les relations du PO :

methode SAFe schéma
  • Arrivée du changement avec SAFe

Dans SAFe, de nouveaux rôles apparaissent comme ceux du Product Manager, du Release Train Engineer… Leurs fonctions impactent celles de certains membres de la ScrumTeam et notamment le rôle du Product Owner.

Le RTE (Release Train Engineer) est le Super ScrumMaster au niveau du Train (visible sur le schéma préalablement montré et représentant SAFe).

Le Product Owner sera en charge de l’écriture des User Stories, il ne sera plus en charge des Features.

Le Product Manager sera désormais en charge des Features et travaillera donc en étroite relation avec le Product Owner afin de les alimenter. Il se situera plutôt au niveau Program comme suggère le schéma ci-dessous.

methode SAFe schema 2

En ce qui concerne leur relations (PM-PO-Team) elle est traduite par ce graphique :

methode_SAFe_relations_PO

La première frustration à surveiller est donc celle du Product Owner (PO), due au changement de fonction à cause de l’arrivée du Product Manager (PM). Minimiser ses frustrations peut avoir un impact dans la productivité de vos équipes.

J’ai observé ces frustrations durant mon premier PI planning.

Les Product Owners étaient lassés car ils n’étaient plus en charge des Features. Ils n’étaient alors plus complètement en relation avec les métiers, ce qu’ils percevaient comme une diminution de leur périmètre. On observait un manque d’implication lors des réunions et de l’animosité envers les Product Managers. Cela s’est traduit par une baisse de la productivité en fin de PI et une Feature non terminée due à une incompréhension entre les deux rôles.

Une écoute active de la part du RTE (Release Train Engineer) est alors nécessaire pour corriger ce problème. Il est bénéfique d’organiser un atelier « Rôle Responsabilité entre PO, PM » afin que chacun connaisse ce qu’attend l’autre. En résultent une suppression des ambiguïtés et un assainissement des relations.

Utiliser ce type d’atelier en amont du lancement du premier Program Incrément préparera les Product Owners à ce changement mais créera aussi un échange entre le couple Product Owner-Product Manager sur ce qu’ils attendent l’un de l’autre.

 

L’adaptation au changement plus que le suivi d’un plan.

En plus de prendre en compte les interactions, la mise en place d’un modèle nécessite une adaptation par rapport au contexte.

Avec la mise en place de SAFe, de nouvelles cérémonies prennent naissance au niveau Program en plus des cérémonies habituelles (Sprint planning, Revue, Rétrospective, Refinement).

Les événements au niveau Team Events sont identiques aux cérémonies de SCRUM, la différence se situe uniquement au niveau du nom :

programm execution events_SAFe

Chacun des événements a un objectif précis et une organisation claire dont les détails sont explicités ici. Au niveau Program, on va retrouver la System Demo, qui a lieu à la fin de chaque Sprint pourvu que la Feature soit terminée. Lors de cet événement est effectuée la démonstration d’une fonctionnalité déployée dans l’environnement de Staging.

Les Product Owners effectuent la démo de la Feature Done face au Product Managers/Product Owner, à la System Team, aux Business Owners, aux executive sponsors, aux customers, au RTE et au System Architect/Engineering. Et c’est là que la frustration naît.

En Sprint Review, l’équipe de Dev Team effectuait la démo de Feature au Product Owner et aux Stakeholders. Le feedback était partagé directement auprès des concepteurs et c’est cette équipe qui récoltait les lauriers.

Avec la System Demo, cette cérémonie (Review) est modifiée et les Stakeholders n’y prennent plus part. C’est désormais un échange entre la Dev Team et le PO uniquement. Les Stakeholders rencontrent quant à eux le PO pendant la System Demo, événement lors duquel sont échangés les commentaires sur la réalisation de la Feature. Dans un environnement SAFe, le PO représente le nouvel intermédiaire entre Stakeholders et Dev Team. L’équipe technique ne reçoit plus les critiques directement alors qu’elle est à l’origine de la conception de la Feature.

Dans mon expérience précédente, cet événement avait frustré beaucoup de Dev Teams. En effet, ils avaient effectué toute la réalisation et c’était les Product Owners qui recevaient les compliments. Dans notre cas, l’absence de changement et d’adaptation n’avait que renforcé la frustration de la Dev Team, alors insatisfaite et désengagée. On note ici l’importance d’adapter le plan d’action au contexte organisationnel quand on passe de SCRUM à SAFe.

La solution préconisée ici est d’inviter au moins un représentant de la Dev Team à cette cérémonie. Un Lead Tech est approprié.

 

En résumé …

Tout changement organisationnel s’accompagne de frustrations. Mais celles-ci peuvent être atténuées grâce à une gestion en amont du problème et à l’utilisation de certains leviers.

Dans le cas du passage de plusieurs équipes en SCRUM à l’intégration dans un train SAFe, il est primordial de prendre en compte deux valeurs du Manifeste Agile et de les activer en organisant un atelier « Rôle et Responsabilité » en amont du premier PI Planning ainsi qu’en invitant des Lead Tech à la System Demo.  Ces deux clés permettront sûrement d’atténuer les frustrations du Product Owner mais aussi celui de la Dev Team.

 

Lionel NGANTSELE BOUNSANA

L’auteur :

Lionel NGANTSELE BOUNSANA est un passionné d'agilité. De ce fait, il a suivi une formation agile, est désormais certifié PO PM SAFe/Psm1 et évolue en tant que Coach Agile.

 

 

 

 

 

Aussi n’hésitez pas à visiter notre page web dédiée à l’Agilité.

Parlons ensemble de vos projets. 

contact