Dans l'article how to create the agile enterprise, l'analyste principal Michael Azoff résume le point de vue d'Ovum sur la création d'une entreprise agile. Michael explique que les concepts et les buts d'une entreprise agile sont :
Le concept d'une entreprise agile vient des pratiques qui embrassent des principes et des valeurs naturels, comme mettre en plus haute priorité la livraison de valeur pour l'utilisateur et de produits de haute qualité.
Le but ultime est l'agilité du business, où les processus métiers principaux ont adopté une manière de travailler agile et où l'utilisation de l'informatique est optimisée, depuis "faire tourner l'entreprise" à l'innovation, et de prérequis tactiques à des prérequis stratégiques sur le long terme qui auront un impact sur le futur du business.
D'après Ovum, les grandes entreprises rencontrent trois défis principaux :
(...) premièrement, l'entreprise ayant le plus de réussite se retrouve finalement face au mur de l'innovation et se demande comment le dépasser pour continuer à innover et se comporter avec autant de rapidité et de créativité qu'une start-up. Deuxièmement, le défi de faire face à des conditions de marché changeantes et maintenir la stratégie de l'organisation en accord avec ces changements est entravé par le processus de la budgétisation annuelle. Troisièmement, le développement d'application a été transformé par les méthodologies agiles et la prochaine étape est de transformer l'intégralité du département informatique.
Le rapport d'Ovum "Agile and Lean Business Transformation" fournit des indications sur comment transformer un business en utilisant des principes agiles/lean. InfoQ a interviewé Michael Azoff d'Ovum:
InfoQ : Merci Michael d'avoir accepté de faire une interview avec InfoQ. Pouvez-vous en quelques mots vous présentez aux lecteurs d'InfoQ ?
Michael : J'ai débuté dans le milieu universitaire en travaillant dans le domaine de l'électronique puis je suis passé à la R&D industrielle et aux réseaux neuronaux. Après une période en entreprise et en consulting en informatique j'ai commencé à travailler en tant qu'analyste en informatique industrielle en 2003. Mes collègues les plus proches sont restés plus ou moins les mêmes pendant les dix dernières années bien qu'à travers une série d'acquisitions le nom de la société ait changé : nous sommes maintenant Ovum, au sein du groupe Informa. Chez Ovum je suis un Analyste Principale et dirige la recherche sur le développement d'application et la gestion de cycle de vie, ce qui inclut les méthodologies et processus, en particulier ceux en rapport avec l'agilité et le Lean.
InfoQ : Le rapport d'Ovum explore trois thématiques pour la création d'une entreprise agile : la gestion de l'innovation, la gestion de l'organisation, et l'agilité du département informatique. Pourquoi ces thèmes sont-ils tellement importants ?
Michael : Ils sont importants parce qu'ils représentent les trois frontières que les organisations doivent franchir aujourd'hui pour survivre dans le climat économique actuel; pas seulement vis-à-vis de la récente crise financière mais également par rapport à la compétition croissante des économies au niveau mondiale et des changements au commerce qu'Internet introduit aujourd'hui. Richard N Foster a examiné la longévité des entreprises du S&P 500 et elle est passée d'une moyenne de 70 ans dans les années 1950 à 18 ans, en décroissance aujourd'hui. Ainsi si les entreprises qui ont du succès veulent continuer, l'innovation doit être une haute priorité. Ce qui a retenu mon attention dernièrement est l'innovation dans le processus de l'innovation, comme Lean Startup. Le second thème, la gestion de l'organisation, est un autre grand sujet dans son bon droit avec sa pléiade de gourous du management et ses cours de MBA colportant leurs versions de la vérité - ce que je trouve intéressant est qu'il existe un mouvement appelé Beyond Budgeting (au-delà du budget) qui a beaucoup en commun avec les façons de penser agile et lean, et qui me parait être la culture d'entreprise juste qui pourrait faire la différence dans la survie au-delà de ces 18 années. Enfin, l'agilité au sein du département informatique est critique pour les entreprises étant donné le rôle pivot qu'a l'informatique dans le monde des affaires aujourd'hui; être agile peut améliorer le lien entre la stratégie et vision et la réalité de ce qui est livré. Les pratiques agiles viennent des développeurs et est en train de grandir dans le reste du département par le mouvement DevOps - le résultat final étant idéalement l'agilité et le lean à travers l'ensemble de l'informatique.
InfoQ : L'approche lean startup, utilisée par de petites start-ups, est mentionnée comme une solution pour la gestion de l'innovation. Comment peut-on appliquer lean startup dans une entreprise ?
Michael : Vous avez besoin de commencer avec un champion à un niveau suffisamment haut pour obtenir un budget et être autorisé à mettre en place un incubateur indépendant. Il faut qu'il y est des lignes de démarcation claires pour protéger la réputation et réduire le risque vis-à-vis de l'image de marque de l'entreprise, afin que ce que l'incubateur est autorisé à faire et comment le faire puisse être pensé. Une fois que la relation entre l'entreprise "parente" et les incubateurs (il peut y en avoir plusieurs) est définie, alors les incubateurs ont la liberté de se comporter comme des startups. Dans mon étude de cas d'Adobe, ce qui a fait la différence entre l'innovation dans des groupes de produit déjà existant et l'incubateur lean startup était que les groupes innovaient rarement au-delà des limites de leurs produits existant, alors que l'incubateur a utilisé sa liberté pour créer de tous nouveaux produits.
InfoQ : Votre blog mentionne "le développement du client avant le développement du produit", qu'est-ce que cela veut dire et comment cela peut-il être achevé ?
Michael : C'est une idée clé qu'a eu Steve Blank et qui a influencé Eric Reis et ses idées Lean Startup. Essentiellement, lorsque vous imaginez un nouveau produit, vous devez découvrir qui est le client : il y a plein d'exemples de produits ratés où l'on n'a pas réussi à déterminer si quelqu'un voudrait l'acheter. Entre parenthèses, plein d'entreprises n'enregistrent pas leurs propres échecs et avec le changement de personnel et le passage du temps, elles peuvent répéter ces erreurs, d'où le succès d'un musée de produits ratés (principalement des produits de supermarché) : ils achètent simplement chaque nouveau produit qui apparaît dans les rayons du supermarché. Le yogourt shampoing en est un exemple. Le développement du client traite donc de se convaincre qu'il y a un véritable marché pour votre nouveau produit et qu'il possède la courbe d'évolution que vous souhaitez. Le processus Lean Startup pourra éventuellement changer le produit d'origine qui a démarrer le cycle d'innovation; c'est l'objectif de l'approche "le développement du client avant le développement du produit", d'empêcher le gaspillage de ressource sur une idée non testée de produit. Dans le cas où vous pensez que ce n'est qu'une étude de marché - le modèle Lean Startup du développement du client est conçu comme une expérience scientifique pour tester les idées et être dirigé par les données et les preuves : si l'idée échoue, alors vous avez besoin d'une nouvelle inspiration pour la prochaine itération.
Comment cela est mis en place dépend de votre marché, ainsi pour les entreprises web une bonne approche est l'analyse de cohortes, qui suivent des groupes d'utilisateurs de votre nouveau site web et examinent leurs comportements. A mesure que vous faites des changements au site vous pouvez voir l'effet qu'ils ont sur les utilisateurs et affiner le service/produit pour atteindre le niveau désiré d'utilisation et de revenu.
InfoQ : Une fois que vous avez une meilleure compréhension de vos clients, existe-t-il des moyens d'avoir plus d'informations sur les potentielles ouvertures de marché des produits ou services que vous voulez développer en utilisant lean startup ?
Michael : Lorsque les entreprises font des recherches sur de nouveaux produits elles évaluent soigneusement le niveau de retour qu'elles sont susceptibles de gagner : les grandes entreprises de l'industrie informatique peuvent arrêter des produits ou des services parfaitement viables, que les autres entreprises meurent d'envie d'avoir, simplement parce que le retour sur investissement n'est pas suffisamment haut étant donné les ressources et les efforts nécessaires. Un métrique clé dans Lean Startup est le pourcentage de croissance qui doit correspondre aux attentes du marché. Mesurer ce métrique objectivement est ce que Ries appelle la Comptabilité d'Innovation et l'analyse de cohorte aide à en interpréter les résultats.
InfoQ : La budgétisation annuelle dans les entreprises peut entraver leur réponse au changement du marché, comme vous l'avez mentionné. Y a-t-il des solutions alternatives sur la façon dont est faite cette budgétisation ?
Michael : J'aime l'analogie qui décrit le processus de budgétisation annuelle comme étant une banque qui n'est ouverte qu'une semaine à l'année. Les défauts de cette approche peuvent être résumés comme :
- Un grand nombre de ressources qui vont dans le processus sont gâchés parce qu'à mesure que le temps passe, la déconnexion grandit entre les hypothèses du budget et la réalité.
- De la même façon les objectifs qui sont basés sur les prévisions du budget deviennent dépassés.
- Limité l'allocation de budget à une petite partie de l'année limite l'habilité à répondre aux changements du marché.
Les entreprises ont utilisé une variété d'approches alternatives, comme l'utilisation d'une projection roulante avec des budgets trimestriels. L'équipe derrière Beyong Budgeting a enquêté certaines entreprises avec les meilleures alternatives, et ont réunis ces idées afin d'aller au-delà de la budgétisation mais également dans la transformation du management des entreprises.
InfoQ : Pouvez-vous expliquer ce qu'est Beyond Budgetting, et comment cela peut aider les entreprises ?
Michael : Beyond Budgeting (BB) couvre beaucoup de thèmes, mais pour résumer : le point de départ est l'abandon du cycle de budgétisation annuelle. Bien sûr il y a toujours des rapports périodiques dont les entreprises ont besoin de publier pour des raisons de conformité, mais en interne la budgétisation peut être faite de manière continue, basée sur les besoins et les opportunités, liée au roulement, ou mieux encore, aux projections dynamiques. Deuxièmement, BB encourage un processus de management orienté par le client, en contraste avec le command and control - donc il s'agit de changer la culture de l'organisation, de donner aux managers en première ligne une plus grande liberté de prendre des décisions sans que tout ne revienne vers le centre et soit en attente d'approbation. Troisièmement, BB améliore l'environnement de travail pour la plupart des gens dans une organisation - il crée une force de travail plus motivée. Ca aide aussi les entreprises en s'occupant des trois principaux défauts de la budgétisation traditionnelle décrite plus haut.
InfoQ : Changer le processus de budgétisation peut être difficile dans des organisations de grande taille. A-t-on vraiment besoin de le faire, quels bénéfices peut-on en tirer ?
Michael : Il est juste de dire que la budgétisation annuelle traditionnelle est pour un grand nombre d'entreprises un exercice douloureux et coûteux en temps, donc il y a déjà une envie d'alternative. Aller plus loin et laisser tomber la culture du command and control dépend du PDG et de sa vision pour le futur de l'entreprise, tout comme le chemin à parcourir pour que la culture existante devienne une culture BB. Cette question de la culture d'entreprise sera traitée dans un autre rapport Ovum - mais pour l'instant disons qu'il n'y a pas de recette simple et qu'il n'est pas toujours juste d'abandonner le command et control si cela briserait la compagnie - ça n'a pas de sens, vous devez avancer avec la main d'œuvre. Les entreprises généralement commencent avec BB en prenant un sous-ensemble d'idées et les essaient avant d'explorer plus avant.
InfoQ : Vous parlez d'appliquer "l'agilité et lean à tout le département informatique", mais qu'en est-il des organisations qui n'ont pas encore commencé avec les équipes de développement agile. Doivent-elles d'abord changer leur façon de développer leurs logiciels, ou est-il meilleur de démarré en adoptant l'agilité et lean à toute l'organisation IT, d'un bout à l'autre ?
Michael : La première chose à dire est que si ce n'est pas cassé, ne le réparez pas. Si le cycle en V fonctionne pour vous, c'est acceptable. Le point ici est que le cycle en V est un problème pour de nombreuses équipes de développement qui l'utilisent, donc les idées agiles et lean ont un public réceptif. (La même chose peut être dite du processus de budgétisation annuelle). Un département informatique agile signifie que l'agilité dans le développement, DevOps dans les opérations, et l'établissement de l'agilité/lean de tous les silos restants : ingénieurs réseaux, administrateurs de bases de données, services informatiques, web designers etc, en plus de leurs managers. Les développeurs pratiquant l'agilité peuvent agir comme un catalyseur, et généralement ce sont les DevOps qui suivent une fois que les développeurs agiles sont en train d'augmenter la fréquence des livraisons en production et que les opérations sont sous une pression croissante d'améliorer leur efficacité. Etre un département informatique agile efficace requiert une relation plus proche avec le courant métier principal qu'il n'existe traditionnellement aujourd'hui. Ceci est facilement compris par les entreprises technologique dont le métier principal est l'informatique, mais pour d'autres industries la synergie qui vient de l'agilité et du lean à travers tout l'organisation est rarement coordonnée - il est plus commun que les développeurs agiles et les défenseurs du BB à l'intérieur d'une organisation se découvrent par une heureuse coïncidence. La budgétisation annuelle traditionnelle est un processus semblable à un big bang ou à un cycle en V qui perturbe la façon qu'à l'entreprise de financer ses projets informatiques. Donc il y un grand nombre d'opportunités pour que des processus avec un engagement amélioré soient créés qui réduiront l'écart entre le métier et l'informatique, aligneront mieux les stratégies informatiques et métiers, etc. Ceci a été un objectif depuis des années mais nous avons maintenant une opportunité de comprendre comment le faire.
InfoQ : Les racines des méthodologies agiles se trouvent dans le développement d'applications. Quand l'intégralité du département informatique doit devenir agile et lean, cela signifie-t-il que l'agilité a grandi des équipes aux départements et aux équipes de gestion (du bas vers les haut) ? Les méthodologies agiles sont-elles applicables dans ce cas ?
Michael : L'agilité dans le département informatique au-delà du développement ne suit pas nécessairement Scrum ou une autre méthodologie de développement à la lettre. C'est avant tout à propos du partage de valeurs et de principes communs, desquels peuvent découler de nouvelles idées de processus. Dans le cas de DevOps où les opérateurs doivent écrire, disons des scripts Perl exécutant des milliers de lignes de code, il est possible d'appliquer directement une méthodologie agile de développement. Aussi, certaines organisations ont adapté Scrum à des processus métiers. La clé est de réfléchir à comment appliquer les idées agile et lean dans une nouvelle situation.
InfoQ : Quelles sont les plus grandes barrières lorsque vous voulez adopter l'agilité et lean ? Comment gérez-vous ces barrières ?
Michael : Il faut qu'il y ait des raisons de changer n'importe quel processus existant utilisé. Les points de douleur existants doivent être identifiés et un nouveau processus définit qui se chargera de ces points. Donc avoir une vision et une compréhension partagée de pourquoi un changement est en train d'être implémenté va surmonter l'inertie du changement qui souvent tue les initiatives de changement des entreprises. S'il y a une forte motivation au plus bas niveau mais que le management n'est pas impliqué et/ou indifférent alors le changement sera limité. Au minimum vous avez besoin d'individus motivés au niveau de la direction et au niveau des applicatifs, sans quoi le risque d'échec est haut. Avec un tel support il y aura toujours des défis mais il existe des moyens de les traiter. L'obstacle le plus critique pour tout changement dans l'organisation est sa culture et la compatibilité du nouveau processus avec cette culture. Changer une culture d'entreprise est un défi séparé de la transition à l'agilité/lean, et une activité à haut risque.
InfoQ : On parle actuellement beaucoup de DevOps. Comment DevOps peut-il aider l'adoption de l'agilité en entreprise ?
Michael : Le mouvement DevOps est inspiré par l'activité agile dans le développement et aide à briser le mur du silo qui existe traditionnellement entre le développement et les opérations. Il a aussi amené à une nouvelle façon d'aborder l'amélioration des opérations, comme par exemple de nouveaux outils dans la gestion des livraisons et l'automatisation est apparue. Donc DevOps aide à transmettre le message agile (comme il se trouve dans le Manifeste Agile) et aide énormément la transformation agile de l'intégralité du département informatique.
InfoQ : Si une organisation souhaite passer à la prochaine étape pour devenir plus agile et lean, quel serait votre conseil pour l'accomplir ?
Michael : Idéalement le mieux est que l'initiative vienne du plus haut niveau, mais si ce n'est pas le cas il faudra gagner son support. Donc avec le support du plus haut niveau de l'organisation alors la prochaine étape serait de mettre au point un plan de gestion du changement. Ceci peut être fait de manière agile, voyez par exemple ce qui dit Mike Cohn sur la gestion du changement agile. L'organisation doit faire venir des experts et des coaches agiles et lean pour entraîner et encadrer la main d'œuvre. J'utilise une métaphore dans mon rapport, représentant l'entreprise agile comme une montagne, avec différents sentiers vers le sommet. Choisir la combinaison de Lean Startup pour la gestion de l'innovation, Beyond Budgeting pour la gestion de l'organisation, et l'adoption de l'agilité et de lean à travers le département informatique, est un chemin escaladant cette montagne pour obtenir une entreprise agile.
InfoQ : Vous avez mentionné que l'on peut mener ce changement de manière agile, mais commencer par le plus haut niveau de l'organisation pour aller à l'étape suivante me semble une approche descendante et me rappelle le cycle en V. Existe-t-il une manière alternative (et plus rapide ?) pour amener l'entreprise à changer ?
Michael : Cela dépend de si vous parlez d'un changement global au niveau de l'entreprise vers l'agilité ou juste d'une transformation du département informatique. Dans le premier cas vous devez avoir l'appui du plus haut niveau, donc oui c'est descendant, du moins au départ. Le processus de changement peut être très agile, par exemple en interagissant plus profondément avec les personnes affectés par le changement, en appliquant les changements de manière itérative, en étant transparent etc... Dans le dernier cas vous pouvez avancer une certaine distance sans que le conseil de direction soit impliqué, mais ça aide d'avoir des sponsors au sommet.
Concernant la question de la vitesse à laquelle on peut introduire le changement vers l'agilité, selon que vous ayez une révolution d'un jour à l'autre ou que vous introduisiez des changements incrémentalement dépend de la compatibilité de la culture existante avec les changements proposés et également de considérations pratiques. Par exemple Statoil est passé à la budgétisation continue soudainement parmi ses multiples divisions parce que faire cohabiter deux processus de budgétisation différents dans la même entreprise aurait signifié le double de travail et de confusion.
Dernière pensée : pour une gestion du changement réussie vous avez besoin d'individus motivés partout dans l'organisation et à tous les niveaux, qui ont la vision. Aucun processus de changement ne fonctionnera sans personnes partageant la vision.
A propos de la personne interrogée
Michael Azoff (PhD, MIEEE) travaille comme un analyste informatique depuis 2003, apportant plus de 20 ans d'expérience en recherche pure et appliquée et en consulting dans l'industrie informatique. Chez Ovum il dirige les recherches sur le développement d'application et la gestion de cycle de vie (DAGCV) et en ce moment se concentre sur les pratiques agiles et lean dans le développement d'application, englobant les initiatives de transformation agile d'entreprise, DevOps, DAGCV lié au Cloud, gestion de performance d'application, et le développement mobile en entreprise.