BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Implémenter l'Agile sur des Projets Non-Logiciels

Implémenter l'Agile sur des Projets Non-Logiciels

"Comment allez-vous lancer votre initiative en utilisant un modèle Agile ?" demanda Elle, une exaspération certaine dans la voix, "où est le logiciel opérationnel, et comment allez-vous montrer une valeur métier immédiate ?"

Le contexte de cette conversation était une initiative de transformation majeure effectuée par MotoClaim & Co. pour adopter une philosophie d’entreprise orientée service. Elle était Delivery Manager pour l’initiative globale et n’était pas étrangère à l’Agile. J’étais l'architecte process, consultant pour le programme. Nous venions juste de sortir d’une réunion de direction où il avait été décidé que la première phase du programme inclurait l'élaboration d’une stratégie pour effectuer toute la transformation et le développement des bases d'architecture nécessaires. Dans cette réunion, malgré le grand scepticisme du management, Elle incluse, j’ai poussé pour exécuter la première phase en Agile.

La question d’Elle n’est pas du tout spécifique à MotoClaim & Co. Dans mes 10 dernières années de consulting Agile, j’ai été dans ce débat de nombreuses fois avec mes clients et parties-prenantes, même ceux possédant une maturité considérable dans la livraison Agile. Généralement, les personnes acceptent d'adopter au plus une approche itérative lorsqu’il s’agit d’initiatives non-logicielles. Par initiatives non-logicielles, je me réfère à ces projets IT qui n’ont pas pour objectif de livrer un logiciel opérationnel en production comme des projets de définition de stratégie, des projets d’architecture, des initiatives d’évaluation internes et des initiatives de consulting. Bien que ces projets puissent représenter une grande valeur intrinsèque pour l’organisation, ils sont typiquement invisibles pour les utilisateurs finaux et n’affectent pas leurs habitudes.

Alors, quel est le problème dans l’utilisation de la livraison Agile pour un projet non-logiciel ? Pour commencer, si l’on regarde la littérature Agile disponible aujourd’hui, la majorité, en commençant par les principes Agiles, se concentrent sur la livraison d’un "logiciel oérationnel" tôt et fréquemment – et le logiciel est sans doute lié aux projets qui livrent du logiciel en production. Vu que les projets non-logiciels ne livrent pas de logiciel opérationnel, il est difficile de percevoir comment ils vont s’aligner aux principes fondamentaux Agile de satisfaction client par la livraison tôt et continue d’un logiciel de valeur, livraison fréquente d'un "logiciel opérationnel", et de faire du "logiciel opérationnel" la principale mesure d’avancement. Une autre raison clé est l’appartenance multiple, surtout pour les projets de stratégie, qui ont typiquement de nombreux acteurs de haut-niveau avec des intérêts divergents. L’indisponibilité des métriques du marché pour mesurer les projets non-logiciels est un troisième aspect.

"Alors, à quoi ça sert ?", vous pourriez demander, "pourquoi est-il nécessaire d’utiliser l’Agile pour ces projets non-logiciels ? Typiquement, ce sont des projets à court-terme qui durent entre trois mois et un an. Pourquoi ne peut-on pas simplememt suivre une approche en cascade ou une approche itérative ?" Pour répondre à cela, nous allons devoir retourner aux bases de l'adoption Agile.

Nous comprenons bien que tous les projets n’ont pas besoin de livraison Agile. Donc, quels sont les critères d’adoption de l’Agile pour un projet ? En utilisant l’illustration fournie par Ogunnaike et Ray1, on dit que tout projet qui tombe en dehors de la zone simple doit être Agile. Ceux qui sont dans la zone simple vont peu varier et présentent donc peu d'intérêt à l'utilisation de l’Agile. Pour identifier si le projet est simple, on conduit typiquement des Agile Readiness Assessments (ARA - Evaluation de Maturité à l'Agile, NdT) pour des projets comportant différents paramètres afin de vérifier quatre facteurs clés :

  1. Dans quelle mesure les parties prenantes connaissent-elles leurs besoins ?
  2. Dans quelle mesure les parties prenantes connaissent-elles leur technologie ?
  3. Y a-t-il des intérêts divergents parmi les différentes parties prenantes ?
  4. Y a-t-il un grand risque d’échec ?

Inutile de dire qu’une majorité de stratégies, architectures et projets de consulting vont venir avec des risques forts sur l’ensemble des quatre points, et vont donc nécessiter d’avoir une grande visibilité, une couverture initiale des risques, une adaptabilité à changer continuellement et une démonstration rapide de valeur business. L’utilisation de l’Agile ici est indéniable. En fait, j’argumenterais que les méthodes Agile conviennent d’autant mieux aux projets non-logiciels qu’aux autres.

La question évidente suivante est, "Comment faire en sorte que cela se produise ?". A mon avis, dès que les organisations arrêteront de pratiquer de "l’Agile prescriptif". Bien que les fondements de l’Agile soient l'adaptabilité et non la prescription, l’Agile prescriptif est une des oxymores majeures dans le paysage de la livraison Agile aujourd’hui. Dans son article inspirant, Abraham Kiggundu écrit :

J’en suis venu à croire que la raison principale de l’échec de nombreux efforts vers l’Agile est que les praticiens ont tendance à oublier que le manifeste est l’énoncé d’idéaux impossibles à atteindre. Toute pratique prescriptive qui en vient comme Scrum et Kanban sont simplement des tentatives d'implémentation pour avancer vers cet idéal, mais étant donné la nature du principe, aucune de ces pratiques ne pourra jamais vraiment y parvenir.

L’article de Arijit Sarbagna2 souligne également ce concept : "Si vous pratiquez de l’Agile, vous devez avoir rencontré l'éternel nouveau démon appelé Scrum Prescriptif".

Un acteur célèbre dans un film indien populaire dit que, "La religion est omniprésente. Elle ne peut pas être dissipée. Si vous essayez de dissiper une religion, vous allez 'être' la religion". Pendant plusieurs années, l’industrie logicielle a pratiqué religieusement l’approche en cascade maintenant démodée, jusqu’à ce que les méthodes Agile ne lui montrent la puissance des livraisons plus rapides et de l’auto-organisation des équipes. Alors que les méthodes Agile dissipaient avec succès la lente approche en cascade, de nombreuses organisations ont maintenant adopté l’Agile comme une religion. Le Processus dont le manifeste déclarait "Les personnes plus que les Processus" est maintenant devenu un processus prescriptif standardisé en lui-même.

La seule pratique prescriptive dont vous avez besoin pour livrer un projet en Agile avec succès est "d’être Agile" et les projets non-logiciels n'y font pas exception.

Pour exécuter des projets non-logiciels avec succès en Agile, j’ai défini un chemin de cinq points pour mon propre travail. S'il n'est pas LA solution, il m’a aidé à définir des attentes claires avec les parties prenantes, à appaiser l’exécution du projet, et à exploiter les bénéfices de l’Agile. Même si ces principes peuvent ressembler à ceux d'un projet de livraison logicielle Agile, leurs applications sont bien différentes lorsque l’on en vient à des projets non-logiciels.

  1. Définissez "Logiciel opérationnel" : Bien que ce terme soit généralement perçu comme une application exécutable, il peut être utilisé pour se référer à tout livrable qui est produit par le projet et apportant de la valeur aux clients. Par exemple, cela peut être une feuille de route d’amélioration, un prototype d’architecture, un document de stratégie, ou une analyse coûts-bénéfices.
  2. Définir "Client" : Dans un monde de développement, il est facile de voir qui est le client final. Cependant, dans un contexte non-logiciel, l’identification des clients peut être plus ardue. Typiquement, ce sont les parties prenantes qui ont un intérêt direct ou indirect à l’initiative. Cependant, à la différence des utilisateurs finaux d’un système, cet ensemble de clients pourrait avoir des priorités différentes, des biais internes ou des notions préconçues. Certains d’entre-eux sont des responsables expérimentés, voire même des cadres dirigeants, ce qui rend la tâche encore plus difficile. Choisir le 'bon' Product Owner, pouvant gérer ces complexités, est donc crucial.
  3. Définir le "Terminé" : Travaillez avec les sponsors et le product owner pour définir le "Terminé" pour chaque story/livrable. Vu qu’une assurance qualité formelle ne serait pas applicable pour nombre de livrables de projets non-logiciels, il est important de s’assurer des conditions de succès. Par exemple, les critères de succès d’un prototype d’architecture pourraient être une revue de design critique suivie d’une démonstration. La difficulté ici est que la plupart de ces livrables vont être implémentés plus tard au travers d’un projet de développement logiciel, donc les parties prenantes peuvent remettre leur validation au moment où le livrable sera utilisé avec succès dans un futur projet de développement. Ceci revient à préparer l'échec des deux projets. Et si la stratégie échoue ? Maintenant, nous avons 2 échecs à gérer : le projet non-logiciel déjà clôturé dont le livrable de stratégie n’a pas fonctionné, et le projet de développement en cours qui ne peut être continué à cause d’une stratégie incorrecte.
  4. Mesurer la Valeur Business : Mesurer ou établir la valeur business du travail terminé est une clé pour tout projet non-logiciel. Vu que la plupart des livrables existent sous forme de théories ou de prototypes, il est important de préparer un cas business au début de l’initiative qui fournira clairement les coûts, bénéfices pour cette initiative suivi par l’articulation des bénéfices accomplis à intervalles réguliers, de préférence à la fin des itérations. Les métriques pour mesurer les initiatives de ces projets non-logiciels doivent être identifiées et institutionnalisées. Par exemple, une équipe de développement d’architecture pourrait adopter des métriques telles que le facteur de couverture de risques, le coût total de possession proposé, les économies totales proposées, le taux de stabilité de l’architecture.
  5. S’attendre à l’inattendu : Les projets de stratégie ou de conseil sont connus pour des changements sauvages. C’est normal vu que les sponsors et le management sont encore en mode brainstorming. Le périmètre du projet, ses objectifs vont changer fréquemment et drastiquement. Ainsi, allez vers des itérations plus courtes, des ateliers joints, un développement en paire des livrables, des revues en continu par des experts et les pairs, et une socialisation propre des théories et idées. Avoir des stratèges séniors, architectes, ou consultants est utile, surtout s'ils ont une expérience approfondie du sujet ainsi qu’avec l’organisation entière.

Une fois que le calendrier est établi, l’initiative entière peut facilement être lancée sous un modèle Agile avec Scrum ou d’autres processus. Vous serez surpris de voir comme des techniques agiles standard telles que le pair-programming, le développement piloté par les tests et le refactoring s'appliquent bien aux projets non-logiciels. J’ai eu la possibilité d’utiliser ce fonctionnement avec succès pour différents types de projets non-logiciels incluant l’élaboration de stratégies, le développement d’architecture d’entreprise, l’optimisation de processus métiers, la définition et l’institutionnalisation de processus et le développement de métriques. Quelques expériences sont fournies ci-dessous comme cas d’études :

Cas d'études

Cas d'étude 1 : Développement d’une base d’architecture

L’organisation avait entrepris un grand programme de transformation pour moderniser ses plateformes legacy existantes afin d'aller vers le paradigme orienté service. Vu que tous les éléments d’architecture existants au sein de l’organisation étaient spécifiques au legacy, la direction des systèmes d’information voulait une phase initiale d’identification, acquisition et établissement d’une base d’architecture pour les livraisons orientées services. Une période d’un an avait été estimée par les architectes senior pour mettre en place les éléments d’architecture minimum de base nécessaires pour le développement de services. Etant un exercice à haut-risque, la direction des systèmes d’information a voulu que cette initiative soit lancée dans un mode Agile de manière à ce que les risques puissent être couverts tôt et qu’une visibilité complète puisse être établie à tous les niveaux.

En tant que membre de l’initiative pour construire la vision, j’ai travaillé avec les parties prenantes clés pour établir l’agenda en cinq points.

  1. Définir "Logiciel opérationnel" : Chaque livrable majeur était un ‘logiciel opérationnel’ pour nous. Identifier les livrables majeurs était une activité essentielle vu que les backlogs étaient rapidement remplis avec tout ce que les parties prenantes et l’équipe aspiraient à fournir au travers de cette initiative, des éléments de fondations basiques aux capacités de haute maturité. Nous avons priorisé avec soin et nous nous sommes accordés à livrer un élément de travail, seulement si l’équipe sentait que cela ajoutait une valeur business suffisante à l’organisation, et que l’organisation était prête à accepter ce changement. La mise en place d’une infrastructure technologique/d’outils pour différents environnements ; le développement de documents de conception ; et les preuves de technologies/concepts étaient les types clés de logiciel opérationnel.
  2. Définir "Client" : Puisque cette initiative était une initiative à l’échelle de l’entreprise, nous avions un grand nombre d’acteurs avec qui travailler. Nous avons développé une "grille d’influence-intérêt3" qui nous a aidés à comprendre le besoin en communication et la potentielle résistance au changement. Nous avons désigné l’un de nos acteurs clés ‘Grand-intérêt, Haute-influence’ comme Product Owner. L’influence du Product Owner, qui était un assistant du vice-président pour la division, a aidé à prioriser correctement notre backlog, à nous obtenir la socialisation et l’engagement dont nous avions besoin.
  3. Définir "Terminé" : Chaque "logiciel opérationnel" était associé à des critères de "terminé", qui étaient fixés sur la base de nos discussions avec les différentes parties prenantes. Par exemple, pour la mise en place de l’infrastructure, nous avons travaillé avec l’équipe support de l’infrastructure d’entreprise pour définir un ensemble de cas de tests et un échantillon de données de test qui pourrait être utilisé pour vérifier la bonne installation de l’infrastructure. Pour les documents de conception, nous avions des revues critiques de conceptions par le conseil d’architecture d’entreprise (CAE). Nous avons travaillé avec les examinateurs désignés par le CAE pour définir une checklist avec laquelle ils vérifieraient les documents.
  4. Mesurer la Valeur Business : Avant même que l’initiative n’ait commencé, une étude de cas avec une analyse de coûts-bénéfices était présentée au management, articulant le retour sur investissement (ROI). A chaque sprint, nous avons fourni une mesure de haut niveau (parfois quantitative, parfois qualitative) sur l'alignement avec le ROI promis. Par exemple, après avoir mis en place le registre de service, nous avons démontré la valeur de réutilisation qui avait été réalisée dans le cas business.
  5. S'attendre à l'inattendu : C’était plus comme une culture adoptée par l’équipe. Nous avions des sprints de quatre semaines et nous examinions nos objectifs continuellement avec les Product Owners. En tant que Scrum Master, je maintenais de manière assidue les logs de risques et de blocages, et j’avais de fréquents rendez-vous individuels avec les sponsors. Le fait d’avoir un Product owner avec une grande influence organisationnelle a aidé puisque nous étions toujours mis au courant des changements de stratégie de haut niveau qui s'opéraient au sein de l’organisation et pouvions ainsi nous y préparer. Nous avons également établi des procédures formelles de gestion de changements organisationnels, de manière à ce que les changements de périmètre de projet et d’objectif puissent être convenablement socialisés et articulés.

Avec l’agenda en cinq points établi, nous avons utilisé Scrum et un nombre de pratiques d’XP et de DSDM pour compléter le projet avec succès en moins de temps que prévu. Aujourd’hui, l’organisation est bien établie comme un fournisseur de solution orientée service et a été évaluée au Niveau 5 de l’Open Group Service Integration Maturity Model4 (OSIMM).

Cas d'étude 2 : Optimisation de Processus Business

Après avoir livré un nombre de mises à jour infructueuses à sa chaîne de valeur, cette organisation a initié un programme majeur pour remodeler complètement ses processus business de bout en bout. La première phase de cette initiative consistait principalement à du travail d’architecture business où les processus d’état cible seraient conçus. C’était une initiative critique puisque les changements impacteraient presque tous les membres de l’organisation, ainsi que les clients finaux. En tant que Coach en processus, on m’a demandé d’aider l’équipe à exécuter cette initiative en utilisant un modèle Agile.

Encore une fois, j’ai travaillé avec les acteurs clés pour établir l’agenda en cinq points.

  1. Définir "Logiciel opérationnel" : Naturellement, les candidats clés pour le logiciel opérationnel étaient les modèles de processus cibles. Pour les processus plus grands et plus complexes, l’équipe les a découpés en étapes logiques et chacun était considéré comme un logiciel opérationnel. Le livrable était un modèle de processus créé en utilisant le Business Process Engineering Language (BPEL).
  2. Définir "Client" : Bien que la définition du client était simple, et pouvait être identifiée depuis le mapping acteur-processus, le véritable challenge était d’aligner leurs attentes. Le nombre de clients était large et avait des besoins très divergents de l’état cible. Alors que certains d’entre eux voulaient plus de contrôle, d’autres préféraient une plus grande autonomie. Alors que le département marketing voulait plus de flexibilité du produit pour augmenter leurs ventes, le département des réclamations préférait des produits moins flexibles de manière à ce que la gestion des réclamations soit plus rapide. Nous savions que les Product Owners allaient être l’une des directions métier, mais que chaque direction s’occupait d’une division spécifique et était donc intéressée aux besoins de cette division. Pour la première fois, dans ma longue carrière de coach Agile, nous nous sommes lancés avec un ensemble de trois Product Owners pour couvrir la chaîne de valeur en entier. Parlons donc "d’être agile". Cependant, des règles de base étaient définies. Premièrement, l’équipe recevrait toujours une direction cohérente de la part des trois Product Owners. Deuxièmement, chaque différence d’opinion entre les Product Owners devrait être résolue en interne et l’équipe restant en dehors de la dispute. Troisièmement, les Product Owners seraient limités en temps avec leurs tâches et décisions.
  3. Définir "Terminé" : C’était la partie facile. Les Product Owners intéragissaient avec leur propre département pour préparer une liste exhaustive de "fontionnalités" dont ils avaient besoin pour le nouveau système. Ces dernières étaient alors filtrées et priorisées pour créer une liste plus petite. Cette shortlist était utilisée par les responsables métier et les utilisateurs finaux pendant la présentation de revue de sprint, où l’équipe présentait le déroulement du processus théorique dans l’outil BPEL. Toute nouvelle fonctionnalité émergeant de ce rendez-vous était ajoutée au backlog et priorisée dans le sprint suivant.
  4. Mesurer la Valeur Business : Mesurer la valeur business n’était pas très complexe à effectuer. Le modèle existant des processus business actuels venait avec le meilleur temps, le pire et le moyen pris par chaque activité. Cela faisait partie d’un travail de recherche précédent effectué par l’organisation. Lorsque le modèle cible fut créé, nous pouvions identifier des réductions de temps finies et d’autres améliorations d’efficacité. Par exemple, si la gestion des réclamations prenait deux semaines dans le processus existant, nous pouvions montrer dans le processus cible, grâce à l’automatisation des règles de gestion, que le temps de gestion chuterait à quatre jours. La projection de la valeur business de cette manière assure un intérêt continu de la communauté d’utilisateur et du support de l’initiative.
  5. S'attendre à l'inattendu : Encore une fois, cela a été suivi plus comme une culture. Nous avions des sprints de quatre semaines et examinions nos objectifs continuellement avec les trois Product Owners. Les logs de risques et de blocages étaient maintenus soigneusement. Tout nouveau besoin ou changement à ceux existants étaient les bienvenus. Cependant, une attente claire était définie sur le fait que l'inclusion de ce changement dépendrait de sa priorisation. Le Backlog Produit et le Burn-Down étaient disponibles à la vue de tous les clients. Nous avons également établi des procédures formelles de gestion des changements organisationnels, de manière à ce que les changements au périmètre et objectif du projet puissent être convenablement socialisés et articulés.

Conclusion

Comme les deux cas l’illustrent, l’Agile peut être utilisé au-delà des limites disciplinaires de manière très efficace. Plus loin, la livraison Agile est impérative pour les projets non-logiciels, du fait de leurs risques et complexités inhérentes. Les modèles peuvent varier, mais pas les concepts de l’Agile. Au lieu de s’aligner sur des méthodologies Agile prescriptives, nous avons besoin de nous aligner au Manifeste Agile dans sa globalité en choisissant :

  • Les individus et leurs interactions, plus que les processus et les outils
  • Un logiciel opérationnel (ou livrable avec valeur business), plus qu’une documentation exhaustive
  • La collaboration avec le client, plus que la négociation contractuelle
  • L’adaptation au changement, plus que le suivi d’un plan

Rappelez-vous – « Soyez Agiles, Soyez Adaptables ».

Références

1 Process Dynamics, Modeling, and Control, Oxford University, 1992

2 Prescriptive Scrum – Is It the Need of the Hour or Doomsday? published in Scrum Alliance community

3 Mitchell, R. K., B. R. Agle, and D.J. Wood. (1997). "Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What really Counts." in: Academy of Management Review 22(4): 853 - 888.

4 Open Group Service Integration Maturity Model 

A propos de l'Auteur

Dipanjan Munshi est Consultant Processus et Qualité Sénior chez Tata Consultancy Services (TCS), avec plus de 17 ans d’expérience dans l’IT au travers de domaines variés tels que l’assurance, les services financiers, l’industrie, les systèmes embarqués, le transport et les hôpitaux. Il détient un Master en applications logicielles de l’Université d’Utkal, Orissa, Inde.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT