Le monde est en perpétuelle évolution, mais le développement des produits et des services requiert un travail de longue haleine. Bien qu’une année soit courte pour développer une nouvelle solution, les opérations commerciales peuvent souffrir de nombreux changements pendant ce laps de temps : le lancement de nouveaux produits, l’ouverture de nouvelles chaînes de services ou la conquête de nouveaux marchés. Les besoins et les préférences des clients peuvent évoluer. Les concurrents peuvent changer la donne. Les personnes clés peuvent être remplacées. Les changements influent sur les fonctionnalités nécessaires à la solution en cours de développement.

« Lorsque l’on travaille agilement, le développement est suffisamment fractionné et on le réalise petit à petit. Cela permet alors de réagir à tous les changements » affirme Heikki Koskela, Head of Projects de Bonsky Digital.

Un modèle opérationnel agile se base sur la division du travail en courtes itérations. On examine continuellement les activités et leurs résultats, ce qui permet de tirer des leçons et de modifier le projet au besoin avant d’aller trop loin dans la mauvaise direction.

Comment orienter des pratiques agiles dans la bonne direction ?

Mais alors, comment s’assurer que le travail de développement avance dans la bonne direction à long terme ? N’accuse-t-on pas régulièrement les entreprises de ne pas voir plus loin que la fin du trimestre dans leur stratégies ? M. Koskela a la solution :

« Le développement doit être axé sur les besoins commerciaux. Il faut constamment comparer l’orientation des activités et du projet de développement avec les objectifs de l’entreprise. Lorsque les objectifs sont clairs, on sait quelle direction prendre.

Le coach agile de Vincit, Eetu Kaivola, explique comment avancer dans la bonne direction, malgré des échecs ou des déviations ponctuels :

« Un développeur agile n’a pas la certitude d’aller dans la bonne direction à chaque étape. Mais les itérations rapides permettent cependant d’apprendre promptement et d’augmenter les chances d’aller dans le bon sens. Autrefois, lorsque les hommes se sont rendus compte que voyager à cheval était bien plus rapide, ils ont commencé à domestiquer les chevaux. Ils avaient un objectif défini, mais ne savaient pas comment y parvenir. Ils ont eu probablement beaucoup de ratés avant de trouver un modèle qui fonctionne. »

L’agilité ne signifie donc pas agir sur des coups de tête, les actions sont dirigées par un besoin ou un objectif clairement définis. Le cœur d’un plan de développement agile se base sur des buts mesurables et les résultats sont rigoureusement comparés à ces objectifs. La cible doit être clairement définie. Et il faut malgré tout savoir accepter que l’expérience accumulée et les changements environnementaux vont modifier les besoins de développement et par là même le plan de développement, voire même son objectif central.

« La réalité est la force motrice des opérations et les objectifs sont des outils de réflexion » résume M. Kaivola.

Il faut cependant veiller à ce que le processus entier aille dans la bonne direction, car ceci est une tâche extrêmement ardue et le modèle opérationnel agile n’a pas de réponse automatique à cela. Par exemple, il est possible d’optimiser la ligne de production et la rendre très agile et avancée. Le développement produit peut également être innovant et agile. Et pourtant l’entreprise peut complètement échouer.

«  Il faut du courage pour voir une réalité et des changements en désaccord avec notre perception du monde ou qui menacent nos activités actuelles. » réfléchit l’Agile Coach de Vincit Marko Hirsimäki et continue : « Si vous comptez descendre les chutes du Niagara dans un tonneau, molletonner ce tonneau n’amortira pas la chute. Si on a avancé dans la mauvaise direction depuis des années, il se peut que tout soit perdu. Mais même une grande organisation peut changer de cap si les problèmes sont détectés à temps.

Un autre facteur permettant de rester sur la bonne voie est l’expertise et l’autodiscipline de l’équipe de développement. On peut lancer de folles idées en l’air, mais les experts sauront décider quelles sont les idées qui en valent la peine. Avec un modèle agile, on peut tester une idée en quelques heures et continuer uniquement si le début est prometteur. Le travail de l’équipe se base sur l’évaluation, l’argumentation, la recherche d’expériences empiriques, la réévaluation et l’apprentissage.

« Parfois, il en découle du matériel complètement inutile, mais si on en tire des leçons, il y a aussi de la valeur » insiste Hirsimäki.

S’adapter au changement est important, mais insuffisant. Les gagnant sont ceux qui ne se contentent pas de réagir au changement, mais qui sont à la base de celui-ci.

« La direction d’entreprise peut également adopter le modèle opérationnel agile. À l’image des services que l’on peut modeler et réaliser agilement, on peut développer les activités commerciales agilement, avec des opérations innovantes, par exemple. Lorsqu’on fournit des solutions pour le développement, les activités commerciales peuvent gérer les changements au sein de l’organisation. » explique M. Koskela.

Le client décide de votre succès

Une entreprise typique pense bien maîtriser les besoins des clients et savoir leur proposer des produits et services qui fonctionnent. Cependant, pendant la phase de commercialisation, il arrive que l’entreprise se rende compte qu’elle ne sait pas expliquer la valeur de son produit auprès des clients et qu’il n’y ait pas autant de consommateurs prêts à payer que ce qui était espéré.

Le développeur agile a un pas d’avance, car la méthode agile se base sur la pensée créatrice et la collaboration avec les clients ou les utilisateurs finaux. Lorsque le client final ou l’utilisateur est fortement impliqué dans le projet de développement, les développeurs peuvent comprendre son monde et la solution répondra vraisemblablement mieux à ses besoins. Une conception centrée sur les clients est particulièrement importante dans les entreprises industrielles où l’on crée des solutions pour un groupe de clients relativement limité.

Un souci récurrent de la conception de service est que le client dit souhaiter une chose alors qu’il a vraiment besoin d’autre chose. Souvent, l’utilisateur final souhaite de la facilité d’utilisation, par exemple, alors qu’il aurait réellement besoin d’adopter un comportement dont il ne soupçonne même pas l’existence. C’est pourquoi la conception de services qui relève de la conceptualisation de solutions définit les objectifs, les besoins, les points sensibles et les habitudes des clients avec des méthodes qualitatives qui permettent de comprendre profondément les personnes derrière leurs souhaits apparents.

Pendant le développement du concept, on présente au client des solutions alternatives basées sur ses besoins et il choisit lesquelles tester. Petit à petit, le consommateur final comprend les possibilités qui s’ouvrent à lui et le concept se peaufine. Cependant, il faut passer rapidement du concept à la production et à un véritable feedback du marché.

« Parfois le sondage client est positif, mais les clients n’achètent pas. Lorsque le client doit véritablement faire une décision d’achat, les critères peuvent être tout autres que ce qui avait été prédit pendant la phase de concept » explique M. Kaivola.

M. Koskela ajoute cependant un autre point de vue important : dans le commerce interentreprises, effectuer le travail de développement en collaboration avec le client peut offrir une valeur surprenante.

« Les clients finaux qui travaillent en collaboration avec l’équipe de développement et affrontent les défis avec eux créent un lien émotionnel avec le fournisseur de solution. Les relations deviennent plus profondes et il se crée de la confiance, ce qui peut aider les affaires. »

La même livraison, mais plus rapide ?

De nombreux managers semblent espérer que la méthode agile leur donnera tout ce qu’ils désirent, mais plus vite. Mais la méthode agile ne permet pas de transformer les rêves en réalité en un coup de baguette magique, la réalité est plus complexe. De plus, il surgit toujours davantage de problèmes que prévu.

La base de l’agilité en soi est de ne pas décider dès le début quel sera le résultat final et l’ampleur du projet.

« N’essayez pas de deviner toutes les solutions dont vous aurez besoin » résume M. Koskela.

L’agilité en soi n’est pas une méthode meilleure ou plus rapide. Ce qui est fondamental, c’est de baser les décisions d’un projet en cours sur l’expérience accumulée, les objectifs établis pour le projet dans son ensemble et les besoins identifiés de l’utilisateur. C’est ainsi que naît une solution optimale pour les activités commerciales de manière relativement efficace.

Les besoins sont souvent infinis et génèrent des idées de développement loin dans l’avenir, mais les ressources en temps et en argent sont généralement limitées. Pendant la phase de développement, il est donc important d’accorder la priorité aux fonctionnalités du cycle de vie du produit, qui correspondent le mieux aux objectifs établis et aux besoins des utilisateurs, et ce avec les ressources disponibles. Pour commencer, seules les fonctionnalités les plus importantes seront réalisées.

La durée préétablie, l’emploi du temps inflexible et le budget fixe d’un projet de développement traditionnel se traduisent souvent par des réalisations à la hâte, des problèmes enterrés et des tests repoussés. Le résultat d’un modèle opérationnel agile se traduit par une réalisation de meilleure qualité.

« Pour une équipe agile, il est naturel de corriger les erreurs le plus rapidement possible et d’investir dans des tests à répétition afin d’apprendre des erreurs et ne plus les répéter » insiste M. Hirsimäki.

Un projet agile = un chèque en blanc ?

L’agilité est d’une popularité croissante même si on ne comprend rien à ses principes. Le client peut souhaiter « quelque chose d’agile tant que le résultat est le même à ce prix ». En d’autres termes, on peut facilement admirer l’agilité, mais payer pour cette méthode peut paraître insurmontable.

« Je pense qu’acheter l’agilité est difficile, en effet, il faut expliquer au client que l’on pourra peut-être effectuer le projet dans le temps imparti, mais que cela dépendra des modifications qui surgiront en cours de route » décrit M. Kaivola.

« Devenir agile implique de comprendre correctement la méthode et d’y croire. En outre, agir agilement se base en partie sur la confiance, ce qui rend sa vente encore plus difficile » complète M. Hirsimäki.

Si l’on décide de rénover notre salle de bain, on accepte facilement que les frais de rénovation dépendront des éventuels dégâts dus à l’humidité ou à d’autres problèmes découverts pendant les travaux. Pour un projet informatique, on peut également donner une estimation de la quantité de travail, à un trimestre près en cas de petit projet et à une année près en cas de projet plus important.

« Il faut également tenir compte du fait que les entreprises informatiques n’ont pas d’assurance pour couvrir un développeur qui « ferait un trou dans la tuyauterie par erreur  » rajoute M. Kaivola.

Dans la pratique, le problème relève souvent du fait que la direction chargée de signer le chèque ne comprend pas les bénéfices et les conditions de l’agilité, contrairement aux personnes chargée du projet. Il est naturel que la direction responsable de l’entreprise ait peur de perdre le contrôle et craigne que les employés perdent du temps à divaguer au bureau au lieu de travailler. La direction peut aussi faire pression sur le propriétaire du projet pour ne pas donner de « chèque en blanc » au partenaire de développement.

« Lorsqu’on achète un pack à prix fixe, on sait exactement ce qu’on obtient et à quel prix, mais ce n’est que beaucoup plus tard que l’on réalise si cela correspond à nos besoins. Alors pourquoi ne pas dépenser la même somme dans un service ou produit qui corresponde à coup sûr à nos besoins » réfléchit M. Koskela.

« Si vous souhaitez acheter un projet informatique tout inclus, alors il faut au moins rajouter un zéro et l’informaticien sera quand même terrifié » affirme M. Hirsimäki.

Parfois, il peut être plus facile d’acheter de l’agilité en signant un contrat mensuel à la fois. Afin de construire un climat de confiance, Vincit fournit une garantie de qualité. Le plus important est de guider la direction de l’entreprise vers une pensée agile.

« Ceci est un grand défi pour nous, les fournisseurs. Nous devons aider les décideurs à comprendre les avantages de l’agilité et les convaincre d’acheter un modèle opérationnel qui peut leur être étranger. Notre devoir est de démontrer où va leur argent et comment mesurer le succès. Ce qui m’intéresse le plus est de savoir quand le client estime que le projet est réussi » dit M. Koskela.

Une solution réconfortante pour la direction peut être de se mettre d’accord à l’avance sur le calendrier et le budget du développement, même avec un modèle agile, sans toutefois décider de l’ampleur du projet. Par exemple, s’il s’agit de renouveler un système d’accès, on sait exactement quand il devra être opérationnel. Même si toutes les solutions ne sont pas définies à l’avance, on peut instaurer une date limite. Avec un modèle agile, chaque décision se fait toujours en toute transparence avec le client. 

« La transparence du modèle agile est extrêmement précieuse pour la direction, cela permet de mieux évaluer chaque étape » insiste M. Kaivola.

Une production de valeur rapide avec le modèle agile

« Lorsqu’on produit de la valeur et qu’on la déploie en de courtes itérations, nous ne la stockons pas, mais nous la réalisons le plus vite possible » commente M. Hirsimäki.

Il convient d’être prudent en estimant la valeur conférée par l’agilité. Dans un petit projet de développement, le bénéfice de la méthode agile est souvent relativement important, car les solutions qui créent de la valeur sont rapidement produites. En revanche, au sein d’un grand projet, les modifications peuvent prendre tellement de temps que le bénéfice immédiat est relativement plus faible. Si l’on considère la valeur créée au sein de l’entreprise dans son ensemble, les avantages de l’agilité ne sont pas immédiatement perceptibles, même si à long terme, ils seront vitaux pour le succès de l’organisation. Par exemple, les innovations sont un investissement qui vise la création de valeur à long terme. L’échelle est un autre aspect devant être pris en compte : si la totalité des activités commerciales augmente d’un demi pourcent, la valeur peut être plus significative que de gros progrès dans le développement d’une petite solution. 

Malgré tout, on se concentre souvent uniquement sur les frais du projet de développement lorsque l’on se penche sur la valeur.

« Quand il s’agit de numériser les affaires, la valeur du projet n’a rien à voir avec son prix. La valeur doit se baser sur les résultats de la solution au niveau des affaires, et non pas sur la minimisation des dépenses individuelles » résume Koskela.

L’agilité n’est pas une balle en argent

Rester coincé dans une phase de planification sans fin et le status quo est extrêmement risqué, mais les méthodes agiles et les échecs qu’elles impliquent peuvent aussi paraître redoutables pour la qualité des processus et des systèmes. On essaie généralement de développer la qualité et les processus avec ses propres méthodes de gestion, comme la gestion de la qualité. Il est judicieux de discuter et de vérifier si les méthodes opérationnelles agiles sont contradictoires avec les autres modèles de développement dans certaines situations, ou si l’agilité présente des risques qui pourraient être évités.

En principe, des activités agiles soutiennent tous types d’opérations où l’on souhaite se développer au fil du temps et où l’apprentissage est utile. Dans ce sens, l’agilité n’est pas contradictoire avec le développement de la qualité ou des processus. M. Koskela ajoute que l’agilité est particulièrement bien adaptée aux environnements dynamiques et aux problèmes complexes où l’on ne peut pas prévoir à l’avance tous les facteurs influant sur la solution ou analyser toutes les alternatives sans une approche expérimentale.

Il faut cependant reconnaître les risques de l’agilité dans le développement d’opérations cruciales dont la fonctionnalité doit être garantie à tous moments. Malgré tout, ces systèmes peuvent être construits de manière modulaire, afin d’utiliser les méthodes de développement agiles au sein de ces modules.

L’agilité, un concept plus familier qu’il n’y paraît

Dans les entreprises industrielles, l’agilité est souvent perçue comme une nouvelle notion étrangère, mais cela n’est pas forcément le cas.

« Les activités opérationnelles rentables se basent souvent sur les principes Lean de Toyota, dont découlent de nombreux principes fondateurs de l’agilité » commente M. Hirsimäki.

Dans de nombreuses entreprises industrielles, le développement des processus opérationnels est déjà agile.

« On essaie par exemple de cerner la manière la plus efficace d’utiliser un marteau dans la ligne de production, en écoutant l’utilisateur du marteau et en tirant des leçons de l’expérience » continue M. Kaivola.

De nombreuses entreprises ressentent le besoin d’avoir deux systèmes parallèles en place : des activités opérationnelles rentables et des actions expérimentales innovantes. Les deux systèmes peuvent cependant être agiles.

« L’innovation, cela peut être de créer énormément de concepts expérimentaux et d’observer ce qui fonctionne, tandis que l’agilité, c’est déplacer le marteau si cela a un avantage » explique M. Kaivola.

« L’agilité se concentre sur la qualité et vise à apprendre et à développer «  résume M. Hirsimäki. En fin de compte, ce n’est pas aussi étranger et nouveau qu’on le pense généralement. »

La structure et la culture d’une entreprise influent sur les opportunités agiles 

La structure et la culture d’une organisation influent sur les manifestations agiles au sein d’une organisation.

« Passer à un modèle agile bouleverse généralement la manière de penser, la budgétisation, la direction et la prise de décision, les mesures de performance, les rapports et les récompenses «  énumère M. Koskela. Outre cela, l’agilité requiert souvent de détruire des structures organisationnelles et de rassembler et impliquer du personnel de différentes sections pour atteindre des objectifs de développement communs. La première phase de cette implication est de définir ensemble les objectifs et de s’assurer que tout le monde les comprend. »

Une organisation traditionnelle autoritaire et hiérarchique peut être un obstacle à l’agilité, par exemple si les prises de décision sont trop lentes au sein d’une longue chaîne hiérarchique ou que l’on n’ose pas dévoiler les erreurs.

« Cependant, l’armée, par exemple, peut agir de manière autoritaire et agile ; le commandant des troupes peut ordonner à ses soldats d’occuper certains postes, mais une fois que l’intelligence reçoit de nouvelles informations, il peut modifier ses plans » clarifie M. Kaivola.

L’agilité change aussi le rôle de leader.

« Un directeur agile peut dicter un objectif et une direction, tant qu’il ne détermine pas comment y arriver «  raconte M. Hirsimäki. Si le directeur a l’habitude d’avoir réponse à tout, le changement de rôle pourra être extrêmement difficile.

M. Koskela fait remarquer que l’agilité convient très bien aux équipes autogérées, avec un pouvoir de décision, centrées sur les clients et qui apprennent vite.

« L’équipe devrait disposer de son propre budget et être responsable de sa gestion du temps. » ajoute-t-il.

Même dans les organisations autogérées, il y a un responsable au bout du compte et donc une personne avec le pouvoir de décision final. Cependant, une autorité supérieure n’est nécessaire que dans des situations particulières où l’équipe ne pourrait pas avancer autrement.

De nouvelles compétences pour de nouveaux rôles

On ne peut pas passer à des méthodes de travail agiles subitement, sans savoir-faire. L’agilité requiert de la discipline, de l’organisation et des compétences collaboratives de la part de toute l’équipe de développement, ainsi que de comprendre le monde du client. Même si le plan de réalisation de la solution n’est pas défini à l’avance, il faut savoir comment gérer la planification pendant la réalisation et comment évaluer continuellement les résultats. Les aptitudes humaines sont importantes pour une collaboration transparente avec le client.

Le savoir-faire de l’équipe de développement est la clé du succès. Cependant, il n’est pas nécessaire de réunir toutes les compétences au sein de l’entreprise, on peut les acquérir en cours de route, là où elles se trouvent. Avoir de bons partenaires permet de se lancer et, par la même occasion, de diviser les risques.

Dans un modèle agile, le client collabore avec une équipe pluridisciplinaire. Le rôle des développeurs, ou Devs, au sein de l’équipe est le plus facile à comprendre, mais d’autres rôles sont nécessaires. Par exemple, les concepteurs de service facilitent la collaboration entre différents experts, aident à identifier les besoins de l’entreprise et des utilisateurs et permettent de proposer des solutions en fonction de ces besoins. Le Scrum Master est également un rôle clé, il permet en effet à l’équipe de travailler sans interruption. Il se charge notamment de régler les éventuels problèmes lorsque l’équipe n’y arrive pas.

Selon Koskela, le rôle le plus important d’un projet de développement est cependant le Product Owner, qui représente le client et qui se charge d’harmoniser les exigences du projet en cours et celles des activités commerciales. Il fait également le lien entre les exigences opérationnelles des parties prenantes et les exigences techniques des solutions, et donne la priorité à celles qui permettent de développer les activités commerciales.

« Un bon Product Owner est précieux. Il comprend les besoins de développement du point de vue de l’entreprise et sait organiser les priorités en fonction de ceux-ci. Un partenaire peut fournir du soutien de nombreuses manières, mais au final, c’est le client qui a le pouvoir et la responsabilité concernant les solutions. » déclare M. Koskela.

Quelle méthode agile choisir ?

Il existe de nombreuses méthodes agiles, par exemple Scrum et Kanba sont souvent utilisées par les développeurs techniques. Scaled Agile Framework (SAFe) fournit un cadre de développement agile à toute l’entreprise. Le choix de la méthode n’est cependant pas essentiel du point de vue de l’agilité. Toutes les méthodes agiles se basent sur les mêmes principes, où les conceptions sont déployées petit à petit au niveau de la production, afin de modeler le résultat final en cours de route.

M. Koskela fait remarquer que quelle que soit la méthode, des canaux et des plateformes communs sont nécessaires, afin de pouvoir communiquer aisément, collecter des idées, documenter et suivre l’avancement des phases de travail. Un bon outil électronique permet de suivre en temps réel la liste de travail de l’équipe et le travail restant, fournissant ainsi un aperçu rapide de l’avancement du projet. À l’heure actuelle, la grande majorité des équipes utilise Jira et Confluence.

« Les outils de travail de l’équipe doivent soutenir les objectifs et les processus » conseille M. Hirsimäki.

Quel que soit le cadre en place, organiser régulièrement des rétros est une bonne pratique au sein de l’entreprise. Ces rétrospectives permettent aux membres de l’équipe de réfléchir ensemble à leur travail et à leurs réussites ensemble. Ils peuvent ainsi discuter des bons et mauvais côtés de leurs expériences et des points à améliorer. Les expériences permettent d’apprendre ensemble et de définir les futures priorités ensemble.

Assurer l’apprentissage est effectivement l’une des tâches les plus complexes à organiser.

« Il n’y a pas de réponse facile à cela, admet M. Koskela et poursuit : mais la clé de l’apprentissage est de ne pointer personne du doigt en cas d’échec. Il faut oser faire part des problèmes et des erreurs, qui devront être traités avec ouverture d’esprit, afin d’en tirer les leçons. Cependant, apprendre de ses erreurs n’équivaut pas à les accepter. Le plus difficile est de transmettre ces apprentissages à toute l’entreprise. C’est un point que nous tentons, nous aussi, d’améliorer et je serais intéressé d’entendre comment les autres entreprises ont su répondre à ce défi. »

Comment adopter un modèle de développement agile pas à pas :

  1. Les bénéfices révolutionnaires de l’agilité pour les activités commerciales surgissent lorsqu’elle s’applique à l’entreprise toute entière, depuis le développement des activités commerciales au développement de solutions, en passant par le développement technique quotidien. La première étape est la compréhension des avantages et des modèles agiles par la direction.
  2. Un développement agile n’essaie pas de prévoir à l’avance tous les objectifs et tous les besoins du projet. L’ampleur du projet se précise au fil des actions, lorsque l’on obtient des informations sur les besoins des parties prenantes et les possibilités de réalisation des fonctionnalités. Les choix sont guidés par les besoins des activités commerciales et les objectifs du projet. Lorsque le cycle de développement est suffisamment court, il est possible de corriger le tir à temps. 
  3. Le développement agile est plus efficace lorsque les structures, la culture et le savoir-faire de l’entreprise soutiennent l’autogestion, l’orientation client et l’apprentissage de l’équipe de développement. 
  4. Un bon partenaire de développement partage les risques et fournit de l’aide au début, même si l’équipe ne possède pas tous les savoir-faire et ni toutes les compétences.

Vincit et Bonsky ont uni leurs forces afin d’aider les entreprises industrielles à affronter l’avenir avec confiance et sérénité grâce à leurs approches innovantes. Vincit se concentre sur la transformation et la numérisation des opérations commerciales, notamment la gestion de changements grâce à des choix stratégiques, de nouveaux modèles d’opérations commerciales et un leadership éclairé. Bonsky Digital se charge de développer des activités et une architecture numériques avec des méthodes de design agiles qui impliquent les clients.

Experts :

Heikki Koskela, Head of Projects, Partenaire, Bonsky Digital Oy

Eetu Kaivola, Agile Coach, Vincit Oyj

Marko Hirsimäki, Agile Coach, Vincit Oyj

Auteurs : Anna Ruutiainen, Bonsky Digital Oy