Maintenant que nous savons d’où nous partons et où nous souhaitons aller, il faut choisir le chemin.
Que pouvons-nous apprendre de notre expérience passée ?
Dans un premier temps, il nous a semblé important de regarder en arrière en analysant nos tentatives de transformation passées. Ainsi nous pouvions voir ce qui avait bien fonctionné et ce qui avait moins bien fonctionné afin d’apprendre de ces expériences.
Invivoo avait, par le passé, initié plusieurs tentatives dans le monde de l’agilité pour répondre à un besoin de changement et d’adaptation. Nous avons essuyé quelques échecs avant d’acquérir la maturité nécessaire.
En analyse de rétrospective de nos tentatives passées, des manques ont été remontés et ont entrainé un essoufflement de l’initiative :
- Des tentatives initiées par une partie de l’équipe de développement, de façon isolée et non portée par l’organisation entière, et c’est certainement le facteur d’échec prédominant,
- Une Scrum team incomplète (pas de Product Owner ou peu présent et aucun Scrum Master),
- Pas d’accompagnement par un Coach agile ou Scrum Master expérimenté,
- Une application trop superficielle des pratiques agiles.
Faire porter la transformation par l’organisation permet un lancement dans les meilleures conditions et d’insuffler une énergie collective, et c’est le principal enseignement que nous retenons de nos expériences passées.
Pourquoi persister dans l’agilité et le choix d’implémenter Scrum ?
Lors de notre réflexion, l’agilité s’est imposée naturellement pour plusieurs raisons :
- Les valeurs portées par l’agilité étaient en adéquation avec notre volonté de renforcer l’échange et la transparence au sein de nos équipes. Surtout dans le contexte où nous nous trouvions et dans lequel les interactions inter-équipes et inter-individus allaient se multiplier.
- Les principes d’application de l’agilité étaient compatibles avec notre activité d’édition de logiciels. En effet, le propre de cette activité, pour perdurer dans le temps, est de s’adapter à un environnement combinant IT et finance en perpétuel mouvement. Donc quoi de mieux que l’agilité pour répondre à ce besoin d’adaptabilité ?
- La connaissance et l’utilisation de certaines pratiques agiles (ex : daily stand-up meeting) par notre équipe de développement et l’accompagnement par le manager de notre expertise « Méthodologies et pratiques agiles » étaient des facilitateurs dans la mise en place de l’agilité.
Le choix du Scrum a été moins spontané.
Le Kanban et le Lean ont été vite écartés car peu adaptés si l’on veut apporter de la valeur par incrément et donner un cadre plus structuré à la production de chaque incrément de produit. Le choix était en suspend sur l’application de Scrum versus Scrum de Scrum ou d’autres frameworks d’agilité à l’échelle (SAFe, LeSS, …).
Notre décision a été finalement conduit par la réflexion sur l’organisation de l’équipe de développement. Devions-nous créer une Scrum team (Product Owner + Scrum Master + Equipe de développement) par produit ou une unique équipe de développement multi produits accompagnée par un PO par produit et un Scrum Master ?
Comment avons-nous implémenté Scrum ?
La proposition d’avoir une équipe par produit a d’abord était la solution privilégiée. Elle a l’avantage de bien segmenter les projets et de faciliter la priorisation et le suivi de chaque produit. Chaque produit a une product backlog dédiée, alimentée et priorisée par un unique PO. Mais au fur et à mesure des discussions, les besoins se sont affinés. Il en est ressorti :
- La nécessité de préserver une équipe multi compétences/multi produits de façon à diffuser au maximum la compétence sur l’ensemble des développeurs
- La fluctuation de priorité entre produits était peu compatible avec le maintien d’une capacité constante entre équipes
- L’importance de limiter au maximum l’effet silotage dans l’organisation pour maximiser la force du collectif dans la création de valeur
- L’impossibilité d’avoir un unique Product Owner pour l’ensemble des produits du fait de l’ampleur du périmètre et un manque de scalabilité dans un contexte de croissance de ce catalogue. Ce rôle de Product Owner partagé par plusieurs personnes, certes chacun sur un périmètre défini, nous a imposé d’instaurer une cérémonie d’arbitrage des priorités entre Product Owners avant chaque sprint planning
- La nécessité d’avoir une backlog unique multi produits qui allait servir à la fois d’artefact de communication entre toutes les parties prenantes et d’outil pour tendre vers une plateforme unifiée rassemblant l’ensemble de nos produits
Le choix n’a pas été simple mais l’important était d’aboutir à l’acceptation par tous du modèle d’organisation pour faciliter au maximum l’acceptation du changement. Cette décision a été prise par consentement et non consensus pour faciliter et accélérer cette prise de décision (Pour plus d’information sur les processus de prise de décision, cf. la présentation « Protocoles de prise de décision » par Olivier Albiez (@olivieralbiez) et Dragos Dreptate (@ddreptate) à Agile Grenoble 2017). Il a donc été décidé de commencer avec une unique équipe de développement. Ce choix n’est bien sûr pas définitif et nous nous laissons la possibilité de modifier le modèle dans le futur.
Le fait de s’organiser autour d’une seule et unique équipe de développement a donc écarté la mise en place de de l’agilité à l’échelle, tout du moins dans un premier temps.
Pour conclure
Ce troisième épisode conclut la première trilogie relatant la genèse de notre chemin vers le côté lumineux de la force. Ce qui est important de retenir, c’est que se lancer dans un chantier de transformation nécessite :
- De savoir d’où l’on part,
- De lister les raisons qui poussent à se transformer et d’être conscient de ses points faibles,
- De savoir quels objectifs on veut atteindre en se transformant,
- D’arriver à une acceptation par tous sur la méthodologie à mettre en place pour fédérer les parties prenantes autour de ce projet de transformation,
- D’être soutenu et accompagné dans ce changement.
Ce constat peut paraitre évident mais on ne peut que constater qu’un grand nombre d’échecs (complet ou partiel) dans la mise en place d’une méthodologie (agile ou autre) est dû à l’omission d’un des points clés listés ci-dessus.
En tant que lecteur, si tu veux réagir sur ces trois premiers articles, nous poser des questions ou même partager ta propre expérience, n’hésites pas à nous laisser un commentaire.
Nous te donnons rendez-vous très bientôt pour la deuxième trilogie de notre aventure. Ce deuxième volet traitera les aspects suivants :
- La définition des rôles et la sensibilisation des personnes à leur responsabilités
- L’accompagnement de nos padawans Product Owners dans la construction de leur product backlog
- Le lancement du 1er sprint
Le mot du Coach Agile
