Mustafa REKIK, BIA IT Services
Le DW/BI Agile, né depuis quelques années, adresse la nécessité d’augmenter la flexibilité des entreprises en accélérant le cycle de livraison des projets DW/BI apporteurs de la valeur.
Qu’il s’agisse de BI self-service, BI en mode SAAS ou Cloud, l’objectif est d’offrir aux utilisateurs et partenaires un accès aux données et des fonctionnalités plus rapidement tout en étant suffisamment flexible vis-à-vis des évolutions/changements de besoins à tout moment.
Ralph KIMBALL et Bill INMON, définis comme les créateurs du DW/BI, avaient effectivement décrit dans les années 90 des processus et approches (descendante, ascendante, …) de mise en œuvre qui peuvent nécessiter l’engagement de beaucoup de temps et de ressources.
En même temps, peut-on imaginer, en 2017, un projet DW/BI avec un délai de première mise en production estimé en années ? difficile d’y croire …
Ken W. Collier a joliment, comparé dans son livre « Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing » l’évolution des méthodes de management de projets (cycle en cascade, en V, Agile) avec la modernisation des méthodes d’alpinisme entre les années 60 et Aujourd’hui en passant :
1- D’ascensions groupées avec des moyens logistiques conséquents, subissant une organisation rigide (qui se rapproche du commandement militaire) et une planification de plusieurs mois de préparation avant l’ultime affrontement du sommet ciblé qui peut arriver ou pas…
2- Vers des expéditions plus fréquentes avec moins de moyens, des équipes moins nombreuses, une organisation plus flexible et moins de protocole, offrant la possibilité d’atteindre le sommet en quelques jours/semaines. La répétition des tentatives d’atteinte du sommet ciblé par la même équipe (si les conditions météo ne le permettent pas par exemple, …) est, désormais faisable en mobilisant beaucoup moins de ressources/moyens, ce qui augmente les chances de succès.
Il faut surtout retenir que l’Agile est un compromis entre flexibilité et structuration. Il est simple à mettre en œuvre mais pas facile ! car basé sur des principes simples qui nécessitent un niveau élevé de rigueur.
Il n’est pas possible d’évoquer l’Agilité sans faire référence au manifeste Agile avec ses 12 principes fondateurs qui constituent une riche source d’inspiration afin de réfléchir à une méthodologie projet Agile adaptée par rapport aux spécificités de notre environnement (culture d’entreprise, processus existants, expérience des acteurs projets, …). Plusieurs méthodologies projet Agile reconnues existent, comme : Scrum (qui signifie la mêlée du rugby), XP (eXterme Programming), Lean Agile, APM (Agile Projet Management), … la liste est longue, mais les deux premières sont les plus connues et appliquées ; D’ailleurs, on retrouve pas mal de mixte entre ces méthodologies dans les entreprises, ce qui est plutôt un bon phénomène, preuve de comptabilité avec l’esprit de l’Agilité.
Beaucoup d’entités DW/BI ont franchi le pas et mènent, depuis quelques années, des projets en mode Agile avec des : Product Owner, Scrum Master, Product Backlog, Sprint Backlog, Pocker Planning, Daily Meeting, Review, Retrospective, Post-it Progress, …
Plus globalement, la communauté du DW/BI s’est intéressée à l’Agile et à son potentiel dans différents domaines : Intégration de données, Architecture, Modélisation de données, Science de données, Reporting, Gouvernance de données, … et a constaté qu’il y a, incontestablement, d’innombrables bénéfices à l’application de l’Agile dans le DW/BI, notamment, l’apport de plus de qualité, moins de risques et plus de responsabilisation des différents acteurs. Néanmoins, il est nécessaire de soulever les bonnes questions avant de se lancer dans un ou plusieurs projets en mode Agile au sein d’une entreprise donnée :
1- Est-ce que l’Agile pourrait convenir à l’environnement DW/BI de cette entreprise pour apporter de la valeur ?
2- Quels sont les bénéfices attendus, perçus par les décideurs de cette entreprise ? et ceux vraiment réalisables ?
3- Quels sont les éventuels freins à l’application de l’Agile au sein de cette entreprise ? et comment les surmonter ?
Pour tenter de répondre à ces questions, je vous propose de relire quelques principes du manifeste Agile et trouver des déclinaisons liées aux spécificités du DW/BI :
1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée :
Il s’agit d’effectuer des livraisons DW/BI suivant un cycle de vie plus court que les méthodologies classiques. Il faut avouer que les livraisons itératives et incrémentales sont assez fréquentes dans le domaine du DW/BI, l’enjeu serait de les rendre régulières et réduire leur durée.
Le but ultime de ce principe n’est pas du tout anodin, surtout que la majorité des causes d’échec des projets DW/BI est liée à la satisfaction client (fonctionnalités non ou mal implémentées, performances insatisfaisantes, manque de disponibilité de données, faible qualité de données, rapports et tableaux de bord jugés pauvres, …).
2. Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client :
Ce principe implique une révolution dans la manière d’appréhender un besoin métier, y compris dans les bonnes pratiques traditionnelles de construction de système DW/BI.
Au lieu d’être surpris (en sachant que ça arrive souvent dans les approches traditionnelles de management de projets) devant des changements de besoin la veille du déploiement prévu depuis des mois … l’idée est de considérer ce genre de situation comme « normale » et de travailler main dans la main entre MOE/MOA/Métier pour gérer l’impact sur le Backlog sans que cela génère une perte de contrôle sur le projet.
3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines et une préférence pour les plus courts :
Cela nécessite de raccourcir les cycles traditionnels de livraison et surtout impliquer le métier d’avantage (recette, participation aux différentes réunions, …). La relation MOE/MOA/Métier devra évoluer et les rôles aussi, chaque indisponibilité devient porteuse d’un risque élevé.
4. ET 5. MOE, MOA et Métier doivent travailler ensemble quotidiennement tout au long du projet ET La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe IT et à l’intérieur de celle-ci est le dialogue en face à face :
Des 12 principes de l’Agilité, ceux-là sont les plus simples à appliquer car le DW/BI est un domaine IT nativement proche du métier et il faut dire aussi qu’il a peu souffert de l’offshorring comparé aux autres domaines IT.
En outre, cette proximité Métier/IT a été prônée dès les débuts du DW/BI et devrait déjà exister en entreprise d’une manière ou d’une autre.
6. Un logiciel opérationnel est la meilleure preuve d’avancement :
Autrement dit, il faut privilégier la livraison logicielle par rapport à la documentation.
Il est difficile de définir avec précision le bon seuil d’équilibre entre livraisons logicielle et documentaire dans un projet DW/BI, il est difficile d’imaginer une livraison sans aucune documentation ni avec une quantité de documents qui mettrait en péril la qualité globale du projet.
Le degré d’exigence des différentes méthodologies de l’Agile (Scrum, XP, Lean Agile, …) varie sur ce point... Il est recommandé d’en discuter lors des différentes instances du projet DW/BI (et d’opérer des ajustements, si nécessaire par la suite).
7. Les meilleures architectures, spécifications et conceptions émergent d'équipes autonomes
Un DW/BI avec une gouvernance externe de données qui suit des processus lents, des décisions et arbitrages qui viennent en permanence d’en haut est un Décisionnel mourant, incapable d’être une locomotive de la valeur et risque de constituer un boulet de ralentissement de toute l’entreprise.
Les managers de proximité et les équipes doivent détenir une bonne marge d’autonomie afin d’être (vraiment) Agile et pouvoir supporter la cadence des cycles courts de livraison.
Afin de bien mener la réflexion autour de ces principes et faire le bon choix de la méthodologie Agile à adopter, voici quelques facilitateurs et pièges à éviter :
1- Ne pas être trop rigide et se recentrer sur la création de valeur :
L’Agilité est par définition contraire à la définition d’une référence projet absolue à respecter à la lettre. Le manifeste Agile est composé de « principes » qui prônent le bon sens et poussent à être plutôt pragmatique en entreprise.
Martin FOWLER a écrit, à propos des mesures du succès d’un projet (traditionnellement axées sur la qualité/cout/délai) : « La réussite du projet dépend davantage de savoir si le logiciel réalisé fournit une valeur supérieure au coût des ressources mises en œuvre … »
La mesure de la valeur est certes plus difficile, mais cela change les priorités dans le management de projets.
2- Ne pas utiliser le DW/BI comme première application de l’Agile :
La première raison est que les méthodologies Agile aient connu leurs premiers succès à travers d’autres domaines IT, la deuxième est qu’un DW/BI est difficile à mettre en œuvre présente un taux d’échec de ses projets plus élevé que les autres domaines IT.
Il est, donc préférable de commencer par un autre domaine IT, d’acquérir de l’expérience et emmagasiner les premiers succès avant d’étendre l’Agile aux projets DW/BI.
3- Ne pas démarrer de nouveaux sprints de développement sur un existant DW/BI trop instable :
Si les fondations de votre DW/BI sont instables, autrement dit, si les mappings d’intégration de données et/ou scénarii d’exploration de données et/ou modèles de données sont récents, fragiles et n’ont pas encore atteint un niveau de maturité minimum, alors il vaut mieux prioriser les tâches du backlog qui concernent la consolidation du socle de base du DW/BI par rapport à celles qui consistent à ajouter de nouveaux développements.
Parce ce qu’il ne faut pas mélanger vitesse et précipitation et parce qu’il est toujours plus facile de se redresser et rectifier le tir après une légère chute qu’un fiasco, il vaut mieux résister aux éventuelles pressions d’aller trop vite au risque de se retrouver obligé de construire de nouveaux étages sur un immeuble dont les fondations ne pourront pas supporter pas dans l’immédiat …
En outre, la mise en œuvre d’une nouvelle User-Story qui impliquerait de nouveaux développements nécessitera de passer tôt ou tard par une phase de refactoring (modèle de données, mapping de données, …) et si la vélocité du système et/ou l’équipe projet n’est pas suffisamment mature, cela risque de décrédibiliser la totalité du projet.
4- Investir dans des outils et techniques d’automatisation :
Généralement, les outils de développement BI sont graphiques (basés sur le principe : What you see is what you get) et moins adaptées aux outils standard de versioning de code ou automatisation des scénarii de tests.
Il s’agit, donc, là d’un facteur clé de succès de l’Agile DW/BI parce qu’il sera difficile de s’en sortir sans automatisation de tout ce qui automatisable.
Les cycles courts de livraison d’un MVP (Minimum Viable Product) impliquent de se concentrer sur l’essentiel pour optimiser l’avancement du sprint. Il faudra s’outiller pour que des actions de type : répétition de tests, génération d’échantillon représentatif de données et stable dans le temps, exécution en mode incrémental ou en mode initialisation, … prennent le moins de temps possible.
5- Ouvrir le DW/BI, y compris les couches traditionnellement fermées aux utilisateurs :
Généralement, seules les couches finales d’un DW/BI (appelées : datamarts, couche de présentation, restitution de données, cockpit, …) sont ouvertes aux consommateurs de la donnée.
D’un côté, il n’est plus possible d’attendre longtemps entre l’expression de besoin d’injecter une nouvelle donnée et son exploitation en sortie du système DW/BI ; D’un autre côté, le repositionnement de la donnée au cœur de la stratégie d’entreprise fait que les systèmes qui la valorisent sont attendues par beaucoup plus d’acteurs qu’avant et à différents niveaux.
Il est, donc, temps (si ce n’est pas déjà fait) d’injecter plus de données, plus souvent et d’ouvrir plus d’étages du système (Staging Area, Operational Data Store, Batch Layer, …) afin de donner accès à la donnée le plus tôt possible (par exemple : via du Reporting ad-hoc pour des utilisateurs avertis, …).
Avouons qu’il est possible, et c’est tout à fait dans l’esprit de l’Agilité, que nous ne sachions pas suffisamment à l’avance ce que nous pourrons faire d’une donnée… la voir, la manipuler pourrait être aussi un moyen de découverte de son potentiel d’apport de la valeur.
6- Promouvoir le temps-réel :
Le choc de sortie d’un système DW/BI du mode Batch (en phase avec les anciens systèmes sources Batch …) vers une production continue de la donnée peut être compliqué, voir fatal … l’Agile peut aussi être vendu comme une opportunité d’aborder la transition en limitant les risques, assurant la montée en compétences des ressources humaines ainsi que la rénovation des outils et amélioration des pratiques et processus.
Qu’il s’agisse de BI self-service, BI en mode SAAS ou Cloud, l’objectif est d’offrir aux utilisateurs et partenaires un accès aux données et des fonctionnalités plus rapidement tout en étant suffisamment flexible vis-à-vis des évolutions/changements de besoins à tout moment.
Ralph KIMBALL et Bill INMON, définis comme les créateurs du DW/BI, avaient effectivement décrit dans les années 90 des processus et approches (descendante, ascendante, …) de mise en œuvre qui peuvent nécessiter l’engagement de beaucoup de temps et de ressources.
En même temps, peut-on imaginer, en 2017, un projet DW/BI avec un délai de première mise en production estimé en années ? difficile d’y croire …
Ken W. Collier a joliment, comparé dans son livre « Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing » l’évolution des méthodes de management de projets (cycle en cascade, en V, Agile) avec la modernisation des méthodes d’alpinisme entre les années 60 et Aujourd’hui en passant :
1- D’ascensions groupées avec des moyens logistiques conséquents, subissant une organisation rigide (qui se rapproche du commandement militaire) et une planification de plusieurs mois de préparation avant l’ultime affrontement du sommet ciblé qui peut arriver ou pas…
2- Vers des expéditions plus fréquentes avec moins de moyens, des équipes moins nombreuses, une organisation plus flexible et moins de protocole, offrant la possibilité d’atteindre le sommet en quelques jours/semaines. La répétition des tentatives d’atteinte du sommet ciblé par la même équipe (si les conditions météo ne le permettent pas par exemple, …) est, désormais faisable en mobilisant beaucoup moins de ressources/moyens, ce qui augmente les chances de succès.
Il faut surtout retenir que l’Agile est un compromis entre flexibilité et structuration. Il est simple à mettre en œuvre mais pas facile ! car basé sur des principes simples qui nécessitent un niveau élevé de rigueur.
Il n’est pas possible d’évoquer l’Agilité sans faire référence au manifeste Agile avec ses 12 principes fondateurs qui constituent une riche source d’inspiration afin de réfléchir à une méthodologie projet Agile adaptée par rapport aux spécificités de notre environnement (culture d’entreprise, processus existants, expérience des acteurs projets, …). Plusieurs méthodologies projet Agile reconnues existent, comme : Scrum (qui signifie la mêlée du rugby), XP (eXterme Programming), Lean Agile, APM (Agile Projet Management), … la liste est longue, mais les deux premières sont les plus connues et appliquées ; D’ailleurs, on retrouve pas mal de mixte entre ces méthodologies dans les entreprises, ce qui est plutôt un bon phénomène, preuve de comptabilité avec l’esprit de l’Agilité.
Beaucoup d’entités DW/BI ont franchi le pas et mènent, depuis quelques années, des projets en mode Agile avec des : Product Owner, Scrum Master, Product Backlog, Sprint Backlog, Pocker Planning, Daily Meeting, Review, Retrospective, Post-it Progress, …
Plus globalement, la communauté du DW/BI s’est intéressée à l’Agile et à son potentiel dans différents domaines : Intégration de données, Architecture, Modélisation de données, Science de données, Reporting, Gouvernance de données, … et a constaté qu’il y a, incontestablement, d’innombrables bénéfices à l’application de l’Agile dans le DW/BI, notamment, l’apport de plus de qualité, moins de risques et plus de responsabilisation des différents acteurs. Néanmoins, il est nécessaire de soulever les bonnes questions avant de se lancer dans un ou plusieurs projets en mode Agile au sein d’une entreprise donnée :
1- Est-ce que l’Agile pourrait convenir à l’environnement DW/BI de cette entreprise pour apporter de la valeur ?
2- Quels sont les bénéfices attendus, perçus par les décideurs de cette entreprise ? et ceux vraiment réalisables ?
3- Quels sont les éventuels freins à l’application de l’Agile au sein de cette entreprise ? et comment les surmonter ?
Pour tenter de répondre à ces questions, je vous propose de relire quelques principes du manifeste Agile et trouver des déclinaisons liées aux spécificités du DW/BI :
1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée :
Il s’agit d’effectuer des livraisons DW/BI suivant un cycle de vie plus court que les méthodologies classiques. Il faut avouer que les livraisons itératives et incrémentales sont assez fréquentes dans le domaine du DW/BI, l’enjeu serait de les rendre régulières et réduire leur durée.
Le but ultime de ce principe n’est pas du tout anodin, surtout que la majorité des causes d’échec des projets DW/BI est liée à la satisfaction client (fonctionnalités non ou mal implémentées, performances insatisfaisantes, manque de disponibilité de données, faible qualité de données, rapports et tableaux de bord jugés pauvres, …).
2. Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client :
Ce principe implique une révolution dans la manière d’appréhender un besoin métier, y compris dans les bonnes pratiques traditionnelles de construction de système DW/BI.
Au lieu d’être surpris (en sachant que ça arrive souvent dans les approches traditionnelles de management de projets) devant des changements de besoin la veille du déploiement prévu depuis des mois … l’idée est de considérer ce genre de situation comme « normale » et de travailler main dans la main entre MOE/MOA/Métier pour gérer l’impact sur le Backlog sans que cela génère une perte de contrôle sur le projet.
3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines et une préférence pour les plus courts :
Cela nécessite de raccourcir les cycles traditionnels de livraison et surtout impliquer le métier d’avantage (recette, participation aux différentes réunions, …). La relation MOE/MOA/Métier devra évoluer et les rôles aussi, chaque indisponibilité devient porteuse d’un risque élevé.
4. ET 5. MOE, MOA et Métier doivent travailler ensemble quotidiennement tout au long du projet ET La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe IT et à l’intérieur de celle-ci est le dialogue en face à face :
Des 12 principes de l’Agilité, ceux-là sont les plus simples à appliquer car le DW/BI est un domaine IT nativement proche du métier et il faut dire aussi qu’il a peu souffert de l’offshorring comparé aux autres domaines IT.
En outre, cette proximité Métier/IT a été prônée dès les débuts du DW/BI et devrait déjà exister en entreprise d’une manière ou d’une autre.
6. Un logiciel opérationnel est la meilleure preuve d’avancement :
Autrement dit, il faut privilégier la livraison logicielle par rapport à la documentation.
Il est difficile de définir avec précision le bon seuil d’équilibre entre livraisons logicielle et documentaire dans un projet DW/BI, il est difficile d’imaginer une livraison sans aucune documentation ni avec une quantité de documents qui mettrait en péril la qualité globale du projet.
Le degré d’exigence des différentes méthodologies de l’Agile (Scrum, XP, Lean Agile, …) varie sur ce point... Il est recommandé d’en discuter lors des différentes instances du projet DW/BI (et d’opérer des ajustements, si nécessaire par la suite).
7. Les meilleures architectures, spécifications et conceptions émergent d'équipes autonomes
Un DW/BI avec une gouvernance externe de données qui suit des processus lents, des décisions et arbitrages qui viennent en permanence d’en haut est un Décisionnel mourant, incapable d’être une locomotive de la valeur et risque de constituer un boulet de ralentissement de toute l’entreprise.
Les managers de proximité et les équipes doivent détenir une bonne marge d’autonomie afin d’être (vraiment) Agile et pouvoir supporter la cadence des cycles courts de livraison.
Afin de bien mener la réflexion autour de ces principes et faire le bon choix de la méthodologie Agile à adopter, voici quelques facilitateurs et pièges à éviter :
1- Ne pas être trop rigide et se recentrer sur la création de valeur :
L’Agilité est par définition contraire à la définition d’une référence projet absolue à respecter à la lettre. Le manifeste Agile est composé de « principes » qui prônent le bon sens et poussent à être plutôt pragmatique en entreprise.
Martin FOWLER a écrit, à propos des mesures du succès d’un projet (traditionnellement axées sur la qualité/cout/délai) : « La réussite du projet dépend davantage de savoir si le logiciel réalisé fournit une valeur supérieure au coût des ressources mises en œuvre … »
La mesure de la valeur est certes plus difficile, mais cela change les priorités dans le management de projets.
2- Ne pas utiliser le DW/BI comme première application de l’Agile :
La première raison est que les méthodologies Agile aient connu leurs premiers succès à travers d’autres domaines IT, la deuxième est qu’un DW/BI est difficile à mettre en œuvre présente un taux d’échec de ses projets plus élevé que les autres domaines IT.
Il est, donc préférable de commencer par un autre domaine IT, d’acquérir de l’expérience et emmagasiner les premiers succès avant d’étendre l’Agile aux projets DW/BI.
3- Ne pas démarrer de nouveaux sprints de développement sur un existant DW/BI trop instable :
Si les fondations de votre DW/BI sont instables, autrement dit, si les mappings d’intégration de données et/ou scénarii d’exploration de données et/ou modèles de données sont récents, fragiles et n’ont pas encore atteint un niveau de maturité minimum, alors il vaut mieux prioriser les tâches du backlog qui concernent la consolidation du socle de base du DW/BI par rapport à celles qui consistent à ajouter de nouveaux développements.
Parce ce qu’il ne faut pas mélanger vitesse et précipitation et parce qu’il est toujours plus facile de se redresser et rectifier le tir après une légère chute qu’un fiasco, il vaut mieux résister aux éventuelles pressions d’aller trop vite au risque de se retrouver obligé de construire de nouveaux étages sur un immeuble dont les fondations ne pourront pas supporter pas dans l’immédiat …
En outre, la mise en œuvre d’une nouvelle User-Story qui impliquerait de nouveaux développements nécessitera de passer tôt ou tard par une phase de refactoring (modèle de données, mapping de données, …) et si la vélocité du système et/ou l’équipe projet n’est pas suffisamment mature, cela risque de décrédibiliser la totalité du projet.
4- Investir dans des outils et techniques d’automatisation :
Généralement, les outils de développement BI sont graphiques (basés sur le principe : What you see is what you get) et moins adaptées aux outils standard de versioning de code ou automatisation des scénarii de tests.
Il s’agit, donc, là d’un facteur clé de succès de l’Agile DW/BI parce qu’il sera difficile de s’en sortir sans automatisation de tout ce qui automatisable.
Les cycles courts de livraison d’un MVP (Minimum Viable Product) impliquent de se concentrer sur l’essentiel pour optimiser l’avancement du sprint. Il faudra s’outiller pour que des actions de type : répétition de tests, génération d’échantillon représentatif de données et stable dans le temps, exécution en mode incrémental ou en mode initialisation, … prennent le moins de temps possible.
5- Ouvrir le DW/BI, y compris les couches traditionnellement fermées aux utilisateurs :
Généralement, seules les couches finales d’un DW/BI (appelées : datamarts, couche de présentation, restitution de données, cockpit, …) sont ouvertes aux consommateurs de la donnée.
D’un côté, il n’est plus possible d’attendre longtemps entre l’expression de besoin d’injecter une nouvelle donnée et son exploitation en sortie du système DW/BI ; D’un autre côté, le repositionnement de la donnée au cœur de la stratégie d’entreprise fait que les systèmes qui la valorisent sont attendues par beaucoup plus d’acteurs qu’avant et à différents niveaux.
Il est, donc, temps (si ce n’est pas déjà fait) d’injecter plus de données, plus souvent et d’ouvrir plus d’étages du système (Staging Area, Operational Data Store, Batch Layer, …) afin de donner accès à la donnée le plus tôt possible (par exemple : via du Reporting ad-hoc pour des utilisateurs avertis, …).
Avouons qu’il est possible, et c’est tout à fait dans l’esprit de l’Agilité, que nous ne sachions pas suffisamment à l’avance ce que nous pourrons faire d’une donnée… la voir, la manipuler pourrait être aussi un moyen de découverte de son potentiel d’apport de la valeur.
6- Promouvoir le temps-réel :
Le choc de sortie d’un système DW/BI du mode Batch (en phase avec les anciens systèmes sources Batch …) vers une production continue de la donnée peut être compliqué, voir fatal … l’Agile peut aussi être vendu comme une opportunité d’aborder la transition en limitant les risques, assurant la montée en compétences des ressources humaines ainsi que la rénovation des outils et amélioration des pratiques et processus.