Le PI Planning est l’événement le plus symbolique du framework d’agilité à grande échelle SAFe. Il regroupe l’intégralité des équipes agiles, le management et les parties prenantes du programme. C’est souvent une centaine voire des centaines de personnes qui collaborent intensivement pour organiser les travaux de l’incrément de programme sur lequel ils doivent travailler pendant plusieurs semaines.
Pour un manager n’ayant jamais vécu un tel événement, il est souvent perçu comme une dépense énorme alors que son ROI est tout juste incroyable !

Les clés pour réussir cet événement sont pourtant simples :

1. Garder en tète en permanence l’objectif de l’événement
2. Soigner sa préparation
3. Commencer par appliquer l’agenda standard puis l’améliorer
4. Veiller à la motivation de toutes les parties prenantes

Garder en tète en permanence l’objectif de l’événement

Le PI Planning a pour objectif d’aligner toutes les équipes du programme ou des programmes entre elles, de les engager sur des objectifs construits et partagés durant le planning, de les faire travailler sur leurs Backlogs de Sprints respectives et d’identifier leurs dépendances structurantes.

Ce PI planning repose sur le principe du manifeste agile qui pousse à privilégier la communication directe entre tous les membres du programme en un temps très réduit pour obtenir un consensus sur l’incrément à venir.

Les équipes sortent de l’événement avec une première version de leurs backlogs de sprints pour les itérations de l’incrément de programme et des objectifs pour chacun de leurs sprints.

Le management du programme sort avec un Program Board traduisant l’engagement des équipes à livrer leurs features lors des sprints de l’incrément de programme, des objectifs synthétisant cet engagement des équipes et une liste de risques à piloter durant l’incrément.

Les porteurs métier sortent eux en ayant l’assurance de l’engagement et de la compréhension des équipes par rapport à leurs enjeux.

L’important est donc de focaliser les équipes sur l’analyse de leurs features et leur découpage en stories, l’analyse de ces stories à un premier niveau de maille permettant d’en estimer la complexité. Ce travail doit leur permettre rapidement de construire leur Sprint Boards, d ‘identifier les dépendances avec les autres équipes et d’identifier les risques à adresser.

Il faut faut veiller à ce que les équipes ne fasse pas un travail trop en profondeur pour une partie de leurs travaux et ne soient pas en capacité d’avoir une vision large de leurs travaux.

L’événement dure 2 jours complets, mais les bénéfices sont énormes : à la sortie du premier PI Planning auquel j’ai assisté, un des directeurs informatique nous a dit :

« Nous n’avons jamais pris autant de décisions en si peu de temps, si nous avions dû programmer des réunions pour nous caler, nous aurions mis des semaines pour nous accorder et cela aurait couté extrêmement cher ! »

En effet, du fait de la présence de tous les acteurs en un même endroit, les décisions sont prises extrêmement rapidement et en ayant toutes informations pour être prises de manière éclairées.

Soigner la préparation de l’événement

Le PI planning regroupant l’intégralité des équipes agiles et le management, on ne peut se permettre de le rater, sa préparation doit être impeccable et les équipes ne doivent pas être freinées durant leurs travaux par des problèmes de logistique ou de disponibilité d’acteurs clé pour décider.

Concernant la logistique, la salle doit être suffisamment grande pour accueillir tout le monde et doit disposer de surfaces murales permettant de travailler directement dessus avec les Postits géants. Les fournitures à prévoir et à pré organiser sont elles aussi assez nombreuses, l’idéal étant de se référer à l’ART Launch Pack fourni par Scaled Agile pour calculer au plus juste les éléments à préparer si vous ne l’avez jamais fait.

La disponibilité des personnes clé permettant d’arbitrer, de découvrir, de comprendre les features que les équipes doivent s’approprier est fondamentale. L’événement étant à une fréquence connue à l’avance, il faut bien veiller à la présence des Epic Owners, des Product Managers, des Business Owners et de toute personne étant utile aux équipes, la qualité du travail des équipes et leur capacité à s’engager dépend grandement de la présence de ces personnes durant les travaux en équipes.

Pour faciliter la présentation et rappeler à tout le monde le fonctionnement du PI Planning au fur et à mesure, nous vous recommandons de créer un jeu de slides tout préparé que vous pouvez utiliser d’un PI à un autre et qui préciser pour chaque partie de l’agenda le fonctionnement et les règles d’acceptation du travail produit.

Commencer par appliquer l’agenda standard puis l’améliorer

Selon mon expérience, Scaled Agile dispose de suffisamment de recul pour proposer un fonctionnement qui doit marcher du premier coup dans tous les contextes. Il est très tentant d’essayer d’optimiser le PI Planning en cherchant notamment à en réduire le cout en réduisant la durée, les équipes présentes, mais le résultat est très rapidement décevant et l’on se retrouve face à un gâchis.

Commencez donc par suivre à la lettre ce qui est proposé et profitez de la rétrospective en fin de chaque PI Planning pour l’améliorer et le contextualiser à votre organisation.

Veiller à la motivation de toutes les parties prenantes

Le PI Planning est un exercice de transparence et d’explication à grande échelle. Le management vient expliquer les enjeux de l’entreprise qui sont adressés par l’incrément de programme, les Thèmes Stratégiques qui couvrent ces enjeux, les Epics sélectionnés qui réalisent les Thèmes Stratégiques et enfin les Features de l’incrément de programme sur lesquels les équipes vont travailler et qui contribuent aux Epics sélectionnés.

Cette compréhension de bout en bout de la valeur des travaux de chacune des équipes et chacun des équipiers est fondamentale pour leur motivation. L’émulation créée par le travail collaboratif durant ces deux jours à la fois au sein de chaque équipe et entre les équipes crée un réel esprit de corps qui s’aligne à réaliser les objectifs de l’incrément.

Pour atteindre cette motivation, le management doit travailler son leadership, sa pédagogie relationnelle et laisser les équipes autonomes pour travailler selon la vision proposée. Attention à l’interventionnisme, ou au reflexes de commande / contrôle issus des méthodes traditionnelles. La réunion de management en foin de première journée doit être expliquée le lendemain avec pédagogie et les solutions trouvées ou proposées de manière collaborative avec les équipes.

L’idéal pour réussir cet événement est de s’appuyer sur un SAFe Program Consultant expérimenté apte à vous guider dans sa préparation et son déroulé, vu l’enjeu de l’événement vous ne pouvez vous permettre de le rater.

En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.

SAFe 4.0, avec la maturité, l’agilité change une nouvelle fois d’échelle

Avec la sortie de SAFe 4.0, Scaled Agile Inc frappe fort et nous propose une version 4.0 du framework d’agilité à grande échelle qui apporte une réponse aux grandes différences d’échelles auxquels il est utilisé et qui fusionne enfin les versions logicielle et d’ingénierie système du framework.

En synthèse

La version 4.0 apporte ainsi le support d’un niveau permettant de gérer des milliers de personnes et de construire des systèmes complets incluant du logiciel et du matériel. Cette version apporte une plus grande modularité dans son adaptation au contexte spécifique dans lequel il est déployé en faisant figurer clairement les stratégies d’adaptation à partir de principes de base. Très fortement employé au sein des équipes agiles, SAFe 4.0 fait la part belle au système de Kanban à tous les niveaux du framework. Enfin SAFe 4.0 réaffirme très fort l’implication nécessaire des managers leaders comme porteurs du changement et comme support des équipes.

Un quatrième niveau “chaine de valeur” optionnel

SAFe 4.0 ajoute un niveau optionnel intermédiaire qui porte les chaines de valeur de l’entreprise. Il permet aux très grandes organisations de structurer leurs ARTs (grandes équipes agiles au sens de SAFe) sur ces chaines de valeur de l’entreprise et de les aligner sur une vision commune. Ce niveau, qui permet maintenant de gérer plusieurs milliers de personnes, a pour objectif de construire une solution complètement intégrée reposant sur un assemblage de logiciel et de matériel pour un client. Le client est encore mis plus au coeur de la construction itérative de la solution que l’on construit pour lui.
SAFe 4.0 distingue les chaines de valeur opérationnelles (ex. la chaine de valeur de commande ou la facturation), des chaines de valeur de développement des systèmes qui supportent ces chaines de valeur opérationnelles. La coordination entre chaines de valeur dépendantes est maintenant assurée par ce niveau chaine de valeur en introduisant la notion de points d’intégration entre chaines de valeur. Cette coordination est assurée par les trois rôles Value Stream Engineer (VSE), Solution Management et les Solution Architects. La coordination à proprement dite est assurée par deux points : pré-PI Planning et Post-PI Planning pour valider les dépendances et l’alignement sur les capacités à développer dans la backlog de chaine de valeur qui est répartie entre les multiples équipes programme.
Le framework introduit une évolution du framework de pilotage économique permettant de prendre des décisions éclairées à niveau de maille chaine de valeur. Pour préserver les différentes options au cours de la construction de la solution, SAFe 4.0 introduit la notion  de “Solution Intent” qui définit un système de balance entre architecture intentionnelle et exploration d’architecture au fur et à mesure de la construction.
Enfin, ce niveau ajoute le support et l’intégration de fournisseurs dans la construction de cette chaine de valeur.

Un niveau portefeuille ajusté pour gérer les chaines de valeurs multiples et les très grandes équipes

Pour tenir compte du niveau chaine de valeur, le niveau portefeuille accepte maintenant la gestion de portefeuilles multiples avec pour chacun une allocation budgétaire dédiée et un système d’allocation commun à tous.
Les thèmes stratégiques servent maintenant de pivot entre le top management et les responsables du portefeuille. Sur le terrain, j’ai effectivement constaté que la manipulation des Epics par le Top Management est impossible car trop fin. Le Top Management alloue maintenant des budgets sur ces thèmes stratégiques, la déclinaison opérationnelle étant à la charge du portefeuille et de(s) l’ART(s). Le budget du portefeuille n’est plus alloué au ART mais directement au chaines de valeur.

Une simplification des trois niveaux de SAFe

La version standard de SAFe à trois niveaux a été simplifiée pour tenir compte des remarques de la communauté, notamment sur le vocabulaire employé. Par exemple le Release Planning devient le PI Planning ce qui semble plus logique.
La Big Picture peut-être visionnée avec 3 ou 4 niveaux permettant ainsi de se balader entre les deux vues très simplement.
Les fondations de SAFe ont été ajoutée directement sur la “Big Picture” permettant ainsi d’affirmer leur importance avec notamment l’introduction des “SAFe principles” et du “Implementing 1, 2, 3” vous guidant dans le déploiement et l’adaptation de SAFe à votre contexte.
Les pratiques Kanban de niveau équipe ont été intégrées de manière beaucoup plus poussées que dans les versions précédentes permettant ainsi de mixer des équipes Scrum et des équipes fonctionnant en Kanban.

Introduction des communautés de pratiques

Présentes dans le modèle Spotify, les communautés de pratiques faisaient défaut dans SAFe jusque là. Elles permettent de tenir compte de l’organisation en réseau nécessaire aux équipes agiles pour diffuser le savoir entre des équipiers, Scrum Master ou Product Owner répartis dans des équipes agiles différentes. Cette pratique favorise la capitalisation des savoirs faire et participe à l’alignement global des équipes.

Un système de Kanban de bout en bout

Le system de Kanban, initialement au niveau portefeuille, est maintenant étendu aux niveaux chaine de valeur et programme assurant ansi une gestion du flux et des limites de travail en cours de manière homogène de bout en bout. Déjà très souvent utilisé au niveau équipe en ScrumBan ou Kanban direct, le kanban est aussi introduit au niveau programme pour gérer notamment l’état de complétude des features avant de les proposer aux équipes (Definition Of Ready du Feature).

Une gestion des exigences de bout en bout revue

L’introduction du niveau chaine de valeur a imposé d’introduire des éléments de backlogs supplémentaires et de les mettre en cohérence les uns avec les autres. Le triptyque simple de départ Epic, Feature, Story avait déjà été étendu en cas de multiples ART avec les quatre éléments Portfolio Epic, Program Epic, Feature et Story. Maintenant si vous utilisez le version à 4 niveaux de SAFe, vous avez Epics / Capacities / Features / Stories.

Introduction de la “Spanning Palette”

Tous les éléments ou les fonctions qui sont utilisables à plusieurs niveaux de SAFe sont regroupées dans cette nouvelle “Spanning Palette”. Elle regroupe d’une part les artefacts d’alignement tels que la Vision, la Roadmap, les Métriques, les milestones et les releases et d’autre part les équipes transverses telles que les DevOps, la System Team, le Release Management, la User Experience et les services partagés (experts intervenant au besoin). Vous pouvez décider d’utiliser ces éléments aux niveaux portefeuille, chaine de valeur, programme ou équipe selon vos besoins, le framework n’impose rien ici.

Introduction de la notion d’enabler pour regrouper les contributions techniques

Cette notion chapeau d’enabler regroupe les anciennes notions d’epic technique, de feature d’architecture et de spike. Elle a pour objet de montrer que ces éléments n’apportent pas de valeur intrinsèque, mais qu’ils servent bien à construire les éléments à valeur ajoutée métier qui les utilisent. A partir de maintenant la hiérarchie d’exigences techniques s’exprime ainsi : Enabler Epics – Niveau Portefeuille, Enabler Capability – Niveau Chaine de valeur, Enabler Features – niveau Programme, Enabler Stories – Niveau Equipe. Les enablers peuvent être catégorisés en exploratoire, architecture ou infrastructure.

Dores et déjà les grands éditeurs qui supportent le framework proposent de nouvelles version de leurs suites d’outils :

• CA Agile Dev, ex Rally Software, annonce le support de SAFe 4.0 dans sa suite CA Agile Central ici.
• Version One annonce son support de SAFe 4.0 ici.

Pour les SAFe Program Consultant (SPC) comme moi-même, cette version impose un retour par la case certification.

En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.

Le digital impose un nouveau rythme et redéfinit les organisations, les processus, la culture, les valeurs, les pratiques et les comportements. Les entreprises agiles, capables de tirer partie de l’innovation, s’adaptent mieux à ces bouleversements. L’agilité ne se réduit toutefois pas à la capacité d’anticiper,
d’innover et de coopérer.

L’entreprise véritablement agile place la valeur au centre de son processus décisionnel ce qui implique de mettre en place un modèle de contractualisation et un mode de pilotage des projets centrés sur la valeur créée.

Les méthodes agiles de pilotage de programme ou projet privilégient la réalité opérationnelle et invitent à appréhender différemment la négociation contractuelle et la gestion des projets informatiques, dans une démarche collaborative entre client et prestataire. Rompant avec les contrats de développement ou d’intégration classiques qui réservent à l’expression initiale des besoins un rôle déterminant, les contrats agiles permettent d’éviter de nombreux effets pervers : une gestion des ressources à l’économie par le prestataire au détriment de la qualité, une renégociation systématique en cours de projet à chaque changement fonctionnel et la poursuite d’un projet qui dérive. Les méthodes agiles ont ainsi libéré les contrats de développement et d’intégration de leur carcan trop rigide et formaliste. Cependant, même lorsqu’elles ont entamé leur transformation vers l’agilité, les entreprises continuent bien souvent de contractualiser les projets selon deux formes basiques : la régie (mise à disposition de ressources) ou le forfait (engagement du prestataire sur un périmètre et un délai de réalisation pour un montant global), avec la variante de la régie forfaitisée (mise à disposition de ressources dans la limite d’un montant global).

Dans les deux cas, les projets sont abordés sous l’angle de leur coût et non de la valeur qu’ils apportent à l’entreprise et celle-ci n’est donc pas prise en compte dans la relation entre les parties. En régie, le coût est directement proportionnel au temps passé. Au forfait, le coût anticipé repose sur la connaissance a priori du périmètre du projet et de sa stabilité dans le temps, cette analyse prédictive étant particulièrement délicate à manier. Au rythme des changements auxquels sont soumises les organisations, la stabilité du périmètre est devenue un leurre qui fait dériver les projets ou mène au contentieux. Sous la pression des directions achats , la régie tend à disparaître au profit du forfait censé offrir davantage de visibilité.
Néanmoins, l’ambiguïté de ce modèle est qu’il repose bien souvent sur un marché de dupe lié aux incertitudes du périmètre, quand bien même le risque serait réduit en mode agile par la pratique du mini-forfait couvrant un sprint ou des fonctionnalités identifiées.

Replacer la valeur au centre de la relation contractuelle

Dans la perspective de replacer la valeur au centre de la relation contractuelle, quel modèle contractuel faut-il alors mettre en place ?
Le principe est d’adopter un modèle contractuel qui fixe le délai et le coût en fonction de la valeur à produire et de la valeur effectivement produite, en faisant varier le périmètre fonctionnel. Afin de maximiser la valeur produite dans le temps, en suivant le rythme des changements (réglementaires,
concurrentiels, etc.). Selon ce modèle contractuel agile, le projet doit permettre d’atteindre un seuil minimum de valeur acquise lequel peut d’ailleurs fluctuer au cours de l’avancée du projet. Le projet s’arrête lorsque le client estime que suffisamment de valeur a été créée et non plus quand le périmètre est intégralement réalisé avec le risque de dépenser trop et de retarder inutilement la fin du projet. Comme tout contrat agile, ce modèle suppose de manier les concepts de l’agilité pour contractualiser et piloter sereinement les projets (story point , sprint , incrément , done , coût du story point , etc.) mais en gardant à l’esprit que l’enjeu derrière ces indicateurs est de motiver le prestataire à produire de la valeur, en favorisant le changement et l’équilibre entre les intérêts du client et de son prestataire.
Partant de l’idée que le client ne peut obtenir que ce qu’il mesure, il est déterminant de contractualiser et de piloter les projets à partir d’indicateurs pertinents de la création de valeur.

La mesure de la valeur

Si le coût du Story Point est un indicateur pertinent de pilotage des projets, il ne permet toutefois pas de mesurer la valeur créée. Le ROI (ratio valeur / effort), mêlant un indicateur client et un indicateur prestataire, permet de fixer un objectif mais s’adapte mal aux multiples changements qui interviennent au cours des projets et notamment au mécanisme de « change for free » des projets agiles. En revanche, le cost of delay qui représente la valeur et l’envisage dans toutes ses dimensions (valeur métier, criticité temporelle et réduction de risque ou opportunité dégagée) permet de piloter les projets par la valeur et de suivre cet indicateur au fil du temps.
Ce concept permet en effet de modéliser la valeur, tout en permettant de valoriser le bénéfice à réaliser un projet par rapport au gain manqué en cas de non-réalisation et permet donc de comparer différents projets d’un même portefeuille. Concrètement, le cost of delay est déterminé de manière
collaborative entre les représentants métier et l’équipe projet et permet de chiffrer et de suivre la réalisation d’un objectif exprimé en valeur relative pour un projet donné. Le cost of delay ne tient cependant pas compte de l’effort à fournir par le prestataire pour développer la solution qui s’estime par le Story Point. Les Story Points permettent en effet de déterminer initialement l’effort à produire, tant au niveau de la fonctionnalité à développer qu’au niveau des incréments. En général, les Story Points sont estimés de manière collaborative par les équipes qui ont la compétence pour réaliser les incréments. Il s’agit d’évaluer une unité relative qui serve de référence pour évaluer l’effort, indépendamment du facteur temporel pris en compte dans la détermination du nombre et de la durée des Sprints.
La priorisation des projets ou des fonctionnalités s’effectue ensuite en rapprochant le cost of delay et le Story Point ; les projets ou fonctionnalités apportant le plus de valeur pour un moindre effort seront réalisés en priorité.
Enfin, les parties peuvent convenir de faire varier le coût du Story Point en fonction de la valeur créée ce qui permet d’associer pleinement le prestataire
à la réussite du projet et de l’inciter à créer de la valeur.

La contractualisation sur la valeur

Si agilité et contractualisation ne vont pas naturellement de pair, le contrat demeure l’instrument indispensable de la sécurité juridique des projets.
Simplement, le contrat ne doit pas constituer un frein à l’agilité mais  être flexible, s’adapter à ce type de projets. Le contrat a vocation à porter ce type de pilotage par la valeur et à définir les droits et obligations des parties
dans ce contexte. L’articulation entre un contrat-cadre fixant et des contrats d’application permet de piloter un projet par la valeur.
Le contrat-cadre définit les clauses contractuelles générales, la collaboration, la gouvernance et les mécanismes d’arbitrage et de gestion du changement, que ces changements soient à l’initiative du client (évolution de périmètre) ou du  prestataire (évolution de sa performance). Par exemple, le contrat-cadre détermine la capacité à produire du prestataire avec une marge de manœuvre suffisante pour absorber les changements sans nécessité de renégocier le contrat. Le contrat-cadre fixe également la durée du contrat, les cas de sortie et les conséquences de la résiliation du contrat. Il définit enfin le nombre d’itérations par contrat d’application et leur longueur pour inscrire le projet dans une temporalité faite de courtes itérations et faciliter la sortie du projet, en fonction de la valeur créée ou en cas d’échec en associant des mécanismes financiers adaptés au modèle économique du prestataire.
Le contrat d’application formalise une valeur cible, valorisée en cost of delay, ainsi qu’une valeur minimum à produire. Le contrat d’application décrit également le périmètre sous forme de fonctionnalités ou de user stories, valorisées en story point.
Ce périmètre permet de piloter les changements et leur impact sur la valeur produite et corrélativement, le coût du story point.
La contractualisation agile sur la valeur substitue ainsi des mécanismes de partage des bénéfices de la valeur produite, d’arbitrage et de gestion du changement aux mécanismes classiques dont la négociation peut s’avérer longue et difficile. C’est particulièrement le cas des clauses « dures » relatives à la responsabilité, aux pénalités et à la nature de l’obligation du prestataire, à la définition du périmètre et aux cas de résiliation du contrat. Côté client, les mécanismes d’arbitrage et de « change for free » couplés aux mécanismes de gestion du changement et de sortie facilitée du contrat fixent les bornes de manière souple. Côté prestataire, un engagement de valeur acquise minimum vient se substituer à l’obligation de résultat avec une variation du prix de l’unité d’effort en fonction de la valeur produite par itération et de sa qualité. Le prestataire est ainsi incité à augmenter sa productivité et sa capacité à faire pour livrer au plus tôt de la valeur. Attention toutefois à ne pas vouloir pousser à l’excès la vélocité au risque de mettre en péril la qualité !
C’est bien à l’équipe de décider des éléments sur lesquels elle s’engage en début de sprint sur la base d’une vélocité acceptable.

Agilité, flexibilité et création de valeur

Pour être pleinement agiles, les équipes opérationnelles, les acheteurs et les directions juridiques doivent faire évoluer leurs modèles et sortir des mécanismes classiques pour adopter une approche centrée sur la création de valeur au sein de l’entreprise. Mettre en place ce type de contrat, étroitement lié au pilotage des projets, implique une conduite du changement et un accompagnement juridique des acteurs (opérationnelles, juristes, acheteurs) car elle implique une transformation des processus et une plus grande collaboration. Dès lors que l’ensemble des acteurs partage les concepts et les indicateurs, les négociations sont facilitées, la collaboration peut primer sur la négociation contractuelle et cette approche pragmatique se révèle alors extrêmement productive.

En collaboration avec Eléonore Varet.

Découvrez nos offres pour chief légal officer et juriste informatique

Le numérique dans toutes ses formes s’impose comme la troisième révolution industrielle, remettant en cause radicalement nos modèles d’organisation encore très souvent hiérarchiques et tayloriens. Entreprises, institutions publiques, associations sont à la recherche de nouveaux relais de croissance ou simplement de solutions pour survivre. La taille est de moins en moins gage de pérennité.

De plus en plus de technologies de l’information deviennent des commodités au même titre que la nourriture, l’eau et l’énergie. Notre société de l’information se caractérise par une croissance exponentielle des données échangées. Les rythmes d’évolution sont tels que les modèles de prédiction traditionnels ne fonctionnent plus, l’incertitude quant au retour sur investissement est immense. Et un échec à grande échelle est très difficile à corriger. « Durant les deux dernières années, il s’est créé neuf fois plus de données que durant tout le reste de l’histoire de l’humanité. » – Exponential Organisations.

Le logiciel s’invite dans tous les secteurs d’activité et grignote rapidement les activités traditionnelles : le Digital impose son rythme et ses règles, redéfinissant à la fois les organisations, les processus, la culture, les valeurs, les pratiques et les comportements. Cette tendance est poussée par la montée de l’individualisme qui sous-tend les pratiques de consommation et tire le marché d’une logique d’offre unique vers une logique de « sur-mesure de masse ». Cette approche nécessite des outils de personnalisation et une chaine logistique extrêmement performante et reconfigurable capable de soutenir la diversité des produits et services.

Quelle organisation peut survivre aux 20 prochaines années ?

Difficile à dire, mais nous observons que les petites et moyennes organisations ayant une gestion long terme semblent mieux s’accommoder des changements que les grandes organisations cotées en bourse pour lesquelles la stratégie, basée sur le résultat, est plutôt tournée vers une logique de court terme. Dans ces structures plus lourdes et soumises à des objectifs plus stricts, il est naturellement complexe de remettre en question les organisations et les modèles économiques sur lesquels sont basés les actifs de l’entreprise. Les organisations hiérarchiques traditionnelles sont conçues pour s’accommoder de croissances linéaires et ne peuvent se transformer rapidement. Désormais, la cosmétique de surface ne suffit plus. Ceux qui n’auront pas acquis des capacités d’anticipation et d’adaptation mourront.

A contrario, les Entreprises Digitales, celles qui tirent aujourd’hui une grande partie de l’innovation, sont nativement conçues pour s’adapter et anticiper les transformations à un rythme soutenu. L’Entreprise Digitale et l’Entreprise Agile portent les mêmes gênes. L’Entreprise Agile délivre de nombreux enseignements sur les moyens d’opérer la mutation digitale des organisations.

Seules les startups sont-elles agiles ?

La réponse est assurément non. Les mouvements comme le Lean Startup prouvent que l’on peut créer les conditions de succès d’une startup dans une société établie. Mais cela requiert une transformation agile : la tentation est alors grande de créer de nouvelles directions et de laisser mourir les anciennes. Pourtant n’existe-t-il pas de solutions moins radicales ?
L’exemple General Electric démontre le contraire. En adoptant Lean Startup sur 40 000 de ses collaborateurs, l’entreprise a réussi à développer plus rapidement ses produits et à moindre coût.

[su_heading]L’agilité n’est pas une option, elle ne se décrète pas, elle nécessite une vraie conviction de la Direction Générale et doit être utilisée comme un facteur de différenciation.[/su_heading]

L’Entreprise Digitale est une Entreprise Agile

Devenir une Entreprise Digitale nécessite de repenser son modèle opérationnel

L’Entreprise Digitale ne se limite pas à intégrer des technologies de pointe dans les processus – préexistants ou non – de l’entreprise. Il ne s’agit là que d’une transformation de surface, qui est déjà en cours dans bon nombre d’organisations. L’Entreprise Digitale s’appuie sur des principes forts : aller vite et penser loin, penser client, penser en rupture, s’attacher à la valeur créée plus qu’à la préservation des actifs existants, détenir les talents et les protéger de la tentation de complexité. Pour ce faire, l’entreprise a besoin d’innover, d’expérimenter et de satisfaire les besoins clients dans des délais souvent courts. Trustée par les Digital natives de la génération Y, l’Entreprise Digitale se doit d’en adopter les codes et notamment les codes sociaux, éthiques et managériaux.

Dans la plupart des entreprises, l’organisation, les processus et les structures de gouvernance existants ne sont pas encore adaptés pour réaliser les ambitions de l’Entreprise Digitale.

L’Entreprise Agile comme moyen de parvenir à l’Entreprise Digitale

« Face à un environnement turbulent, l’agilité est la capacité à anticiper et bouger avec justesse et de manière coordonnée pour aller dans un même sens ». – Jérôme BARRAND (1)

L’Entreprise Agile apporte des réponses aux besoins de l’Entreprise Digitale. Elle s’impose même comme le modèle opérationnel répondant au mieux aux enjeux de la transformation digitale.

Une entreprise agile se caractérise par trois marqueurs principaux :

• Sa capacité à anticiper les conséquences de ses actions et décisions en prévoyant, planifiant et construisant des scénarios ;
• Sa capacité à innover de manière juste pour s’améliorer, faire la différence et ne changer que ce qui est nécessaire, c’est-à-dire à éviter la surenchère inutile d’innovation ;
• Sa capacité à coopérer avec son écosystème en s’alignant sur un sens commun et à favoriser la coopération des individus qui la composent en interne.

La performance de l’Entreprise Agile repose sur l’équilibre entre la satisfaction des clients, des collaborateurs et celle des actionnaires. Les décisions sont prises en tenant compte de l’équilibre entre ces trois dimensions.

Ses trois marqueurs reposent sur un constat : l’organisation peut être représentée comme un système complexe formé de ses collaborateurs et de leurs relations. Ce système collabore avec des partenaires, fournisseurs et des clients qui forment un système plus étendu. Cette approche systémique de l’organisation permet de mieux en appréhender les fonctionnements complexes et d’adopter une approche radicalement différente pour sa transformation.

Une Entreprise Agile (EA) :

• Est fortement orientée client: les équipes sont en prise directe avec leur client et possèdent toute la latitude pour décider ce qui est bon pour la performance globale ;
• Encourage l’expérimentation: l’EA inscrit dans ses gènes l’analyse de chemins alternatifs pour développer une solution et maximiser la performance globale.
• Accepte l’échec: l’échec rapide est admis comme conséquence naturelle de l’expérimentation (« fail fast »).
• Encourage l’innovation. L’EA encourage l’initiative individuelle en accordant du temps aux salariés pour développer leurs propres projets et innover. Par exemple Google ou Atlassian accordent du temps à leurs employés de manière régulière pour faire émerger les innovations de demain. La majorité des ruptures majeures sont issues de ces temps de réflexion. L’innovation n’est pas le fruit d’une seule personne mais bien un effort de tous quelle que soit sa position dans l’entreprise. L’arrivée de la génération Y pousse elle aussi les organisations à revoir leur modèle et intégrer ses caractéristiques. Ainsi par exemple 78% d’entre eux considèrent l’innovation comme un facteur discriminant de leur motivation (Deloitte Millenial Survey 2014).
• Développe et respecte ses collaborateurs: l’EA se repose sur des managers qui développent leurs équipes en libérant les talents de chacun. Elle place ses collaborateurs au centre de sa création de valeur.
• Base ses décisions sur la valeur créée pour l’organisation : l’EA pilote par la valeur toutes ses décisions opérationnelles et analyse leurs conséquences sur le long terme.

Une Entreprise Digitale se doit nativement et sans ambiguïté d’être une Entreprise Agile

Les bénéfices pour l’Entreprise Digitale d’être une Entreprise Agile sont multiples :

 

L’agilité pour toute l’entreprise ?

Quelles directions sont impactées par l’agilité ?

De façon naturelle, l’agilité a commencé à se déployer au niveau des projets de développement informatiques. Le mouvement DevOps l’a étendue aux équipes de production informatique. L’Agile Marketing Manifesto l’a ensuite adapté aux directions marketing et digitales. Enfin, le Lean Startup les a étendues aux directions innovation et R&D et les directions opérationnelles. Le contexte mouvant et la nécessité d’expérimentation poussent toutes ces directions à collaborer et valider la pertinence des concepts qu’elles ont imaginés avant de les généraliser : l’agilité devient le pivot de cette relation transversale entre les directions.

L’agilité impacte également les directions supports. Pour les entreprises qui sous-traitent une partie de leurs projets, les directions juridiques et achat doivent se transformer pour adopter un système de contractualisation agile qui vient soutenir le système de pilotage par la valeur utilisé par les directions opérationnelles. Les directions financières doivent revoir leur modalité de contrôle budgétaire pour qu’il ne devienne pas un frein aux besoins d’adaptation permanente, en s’inspirant par exemple d’un mouvement tel que « Beyond budgeting ». Elles doivent également s’approprier des modèles issus du capital-risque pour financer des innovations au ROI incertain. Enfin, les directions des ressources humaines se retrouvent au cœur du dispositif pour recruter des talents adaptés à la transformation et accompagner le changement au niveau des équipes existantes.

Quelles populations sont impactées par l’agilité ?

L’agilité touche les collaborateurs dans leur quotidien. L’autonomie qui leur est donnée bouleverse leur rapport au travail et vient bousculer le rapport traditionnel avec leur hiérarchie.

Les managers intermédiaires doivent quant à eux se transformer en profondeur et adopter de nouvelles postures et de nouveaux comportements qui favorisent le travail de leurs équipes. On parle de « leader développeur » de ses collaborateurs.

Tout ceci ne peut fonctionner sans un leadership à haut niveau qui insuffle les valeurs de l’agilité dans toute l’organisation et porte l’étendard au-delà des frontières de l’entreprise pour transformer les relations avec les partenaires et les clients. Ces leaders comprennent l’avantage concurrentiel d’être agile et savent transcender les barrières classiques de l’organisation.

Dimensions d’une transformation agile d’entreprise

A quelle échelle déployer l’agilité ?

L’agilité permet de réduire le temps entre l’identification d’une idée et sa mise sur le marché. Plus la chaine traitée par l’agilité est large, plus les gains en termes de Time To Market, de productivité et de qualité perçue sont importants.

Naturellement, on optimise le cycle de développement avec l’agilité, mais cela reste de l’optimisation locale. Démarrer l’optimisation dès l’identification de l’idée, l’expression de besoin et sa qualification permet de réduire bien plus fortement le temps de cycle.

On constate ainsi sur certaines organisations que plus des trois quarts du temps de cycle sont consacrés aux phases en amont de la réalisation !

Plus la transformation agile est large, plus les bénéfices en sont importants.

Les dimensions d’une transformation agile

Une Entreprise Agile repose à la fois sur un modèle opérationnel agile,
un SI agile et des comportements agiles de ses collaborateurs

L’agilité touche aux processus, aux pratiques, à l’organisation et la gouvernance de l’entreprise : c’est-à-dire à l’ensemble de son modèle opérationnel.

Les principaux processus touchés sont ceux de la dorsale « Concept To Cash », de l’idée à sa mise sur le marché). Il s’agit des processus de gestion de la demande, gestion de portefeuille, gestion de programme, gestion de projet, gestion budgétaire et d’allocation des ressources qui sont touchés par la mise en place de pratiques agiles.

Le Scaled Agile Framework

Il existe un corpus de pratiques agiles qui permet de couvrir l’ensemble de ces processus : le Scaled Agile Framework. Ce framework apparaît aujourd’hui le plus abouti, dispose de nombreuses références et fait état d’importants gains business de 20 à 50% en matière de délai de mise sur le marché, de productivité et de qualité.

Le Scaled Agile Framework a été déployé avec succès chez plusieurs grands comptes français pour répondre à d’importants enjeux de réduction de Time To Market et de digitalisation de leurs activités.

Le Scaled Agile Framework étend largement les pratiques issues de Scrum aux dimensions portefeuille, gestion de programme et équipe tout en conservant les caractéristiques d’autonomie des équipes. Il repose sur des fondamentaux Lean et fait une part importante au management agile et à son impact sur les collaborateurs. Au départ conçu pour l’informatique, il peut facilement être étendu à d’autres directions.

L’Agilité fait émerger de nouveaux rôles et des structures adaptatives en réseau

La transformation de ces processus fait émerger de nouveaux rôles dans l’organisation, mais nécessite aussi de revoir les rattachements hiérarchiques et les structures pour favoriser l’autonomie des équipes à taille réduite. On citera par exemple le nouveau rôle de Product Manager dans le cas d’une approche centrée produit à l’instar d’Arkea (Informatique du Crédit Mutuel de Bretagne) qui a mis en place ce type d’organisation.

Une gouvernance révisée pour favoriser la prise de décision au bon niveau

La gouvernance est revue pour en décentraliser les décisions qui peuvent être prises au niveau des équipes et les règles les plus rigides sont remplacées par des conventions plus souples négociées entre les parties.

Par exemple à la DSI, pour des décisions d’architecture simple, la gouvernance agile propose d’éviter les passages en comité d’architecture tous les mois alors que les équipes fonctionnent sur des rythmes de deux semaines.

Le comportement agile des collaborateurs et managers

Transformer son modèle opérationnel ne peut pas se faire de façon immédiate. Il est nécessaire d’opérer la transformation de manière douce et contrôlée. Là encore, le déploiement de l’agilité en amélioration continue se fait en appliquant les principes même de l’agilité.

Adopter ces nouveaux modèles opérationnels, ces organisations et cette gouvernance passe par la transformation des comportements des collaborateurs et des managers. Afin d’éviter tout rejet, il est même préférable de s’attaquer à ce sujet de gestion du changement le plus tôt possible et de l’adosser à une vrai démarche d’analyse du contexte de l’entreprise. Il est important d’étudier sa culture, ses valeurs et les comportements systémiques dominants. On peut s’appuyer par exemple sur l’Agile Profile de la société Agil’OA pour évaluer les comportements individuels ou de groupes qui peuvent être des freins à l’adoption de l’agilité. On peut ainsi mesurer l’agilité comportementale sur 6 axes (Empathie systémique, Synchronisation, Intelligence de situation, Proaction, Rébellion constructive et Pédagogie relationnelle).

Outre les collaborateurs, les managers sont les plus impactés par la mise en place de l’agilité. Leur mission et leur posture vis-à-vis des collaborateurs est profondément transformée : d’un rôle de gestionnaire ou d’expert ils doivent passer à un rôle de développeur de leurs collaborateurs et porter une vision pour les guider. Il est difficile de se transformer ainsi sans accompagnement. Le Framework Management 3.0 adresse toutes les dimensions de cette transformation et aide les managers à adopter les nouveaux comportements de manager agile.

Le Système d’information agile

Un modèle opérationnel repose sur un système d’information qui doit lui-même se transformer pour ne pas devenir un frein à la recherche d’un maximum d’agilité.

Cette transformation s’applique à 3 niveaux :

• Une urbanisation des SI métiers mise en œuvre graduellement en combinant des approches orientées services/API pour faciliter la réutilisation des fonctions cœur de métier et des solutions Saas pour les processus non différentiant,
• L’automatisation de toute la chaine de production applicative dans une approche DevOps pour réduire le temps entre l’idée et sa mise en production ;
• Un plan de résolution de la dette technique pour favoriser la vélocité des développements.

Par où commencer sa transformation digitale et agile ?

Définissez le sens de votre transformation

L’agilité n’est qu’un moyen de rendre plus rapidement opérationnelle une stratégie : commencez donc par bien définir le sens de votre transformation vers l’agilité. Quels en sont les objectifs ? En quoi cela sert-il la stratégie de votre entreprise ? En quoi cela va-t-il vous rendre différent sur votre marché ? En quoi chaque collaborateur va-t-il être concerné et impliqué dans cette transformation ?

Le sens étant l’un des moteurs principaux de la motivation des collaborateurs, cette étape est primordiale pour mettre le système en mouvement.

Démarrez en adoptant des comportements plus agiles

Afin de sécuriser l’adoption de l’agilité et de minimiser l’impact sur le modèle opérationnel dans un premier temps, analysez les comportements en vigueur, identifiez les freins à l’adoption de l’agilité et mettez en place les actions sur l’environnement ou les collaborateurs pour en transformer les comportements afin de les aligner avec votre besoin propre d’agilité.

Concentrez-vous sur la chaine « concept to cash »

Optimisez la chaine « concept to cash » dans sa globalité ; trop souvent, nous avons vu des optimisations locales qui certes affichent des gains, mais qui sont largement inférieurs à une révision plus large de la chaine.

Déployez les chantiers par vagues successives

Déployer l’agilité en utilisant l’agilité : constituez des backlogs priorisées et valorisées de vos transformations de modèles opérationnel, SI et de Changement et synchronisez les sur une même cadence afin d’en aligner les objectifs.

Démarrez votre backlog de transformation du SI par les projets digitaux et innovants.

Référence :

(1) : Jérôme Barrand est l’auteur de Développer l’agilité dans l’entreprise, l’Entreprise Agile, Le manager Agile. Professeur à Grenoble École de management et Fondateur de l’Institut d’Agilité des Organisations.