Systematix

Pourquoi choisir l’Agilité?

Pour des gestionnaires qui connaissent peu les technologies de l’information, l’approche Agile est une réponse à leurs doléances annuelles envoyées au CIO: « Nous allons pouvoir développer plus vite, avec plus de qualité et par la même occasion, sauver des coûts. »

Néanmoins, il ne faut pas voir l’approche Agile pour économiser, car ce n’est pas le cas. Évidemment, en livrant des fonctionnalités par itération, il est plus facile d’identifier si ce qui est livré correspond à ce qui est attendu et faire les ajustements plus rapidement au besoin.

Toutefois, comme les projets Agiles ont plus de chance de succès selon le Chaos Report du Standish Group (2020), on peut supposer que les coûts engendrés par des projets sans résultats seront moindres.

La même logique peut s’applique au niveau de la rapidité de livraison. L’expression « Fail fast, Learn Faster » — Échouez vite, apprenez plus rapidement — est souvent reprise dans le monde Agile. En effet, avec cette approche, on peut livrer plus rapidement et du même coup, se reprendre rapidement, si les besoins ont été mal compris. Dans les faits, ce n’est pas le code qu’on développe plus rapidement en Agile, mais plutôt de la valeur!

Pour les quelque 40.000 répondants du 14e rapport annuel sur l’état de l’Agilité, voici les raisons citées pour l’adoption de l’approche Agile :

Il est évidemment intéressant d’apporter de la valeur rapidement dans un projet, mais une mise en garde s’impose: il n’y aura pas de valeur rapide sans design efficace. Un démarrage rapide dans la phase développement, sans vision globale, pourrait ressembler à ce triangle bien parfaitement équilatéral, mais qui ne tiendra jamais debout, s’il repose sur un de ses sommets.

Les statistiques ne mentent pas, Agile est la « nouvelle normalité », mais force est de reconnaître que ce n’est pas Agile qui veut !! Il est facile d’imaginer que dans les organisations publiques plus traditionnelles ou dans les grandes entreprises, il faudra beaucoup plus d’efforts pour gérer les changements afin que les projets Agiles soient livrés avec succès. Tout le monde saute dans le train Agile, mais comment s’assurer d’arriver à la bonne destination ?

L’article du McKinsey Group « The Five Trademarks of Agile Organizations » identifie cinq caractéristiques clés pour une transition réussie vers l’approche Agile.

• Stratégie : Une vision polarisée à travers l’organisation
  Voir et saisir les opportunités, avoir de la flexibilité pour l’allocation des ressources
• Structure : Un réseau d’équipes autonomes et responsabilisées
  Une structure claire sans trop de hiérarchie, une équipe maîtrisant la gouvernance du projet
• Processus : décisions rapides et apprentissage
  La transparence dans la communication, un processus décisionnel orienté vers l’action
• People : Des gens dynamiques et passionnés
  Des équipes soudées, polyvalentes et dédiées au projet
• Technologie : des outils à la fine pointe de la technologie
  Les bons outils de gestion et les bons outils de développement

Bien sûr, on peut dire à la lecture de ces critères, que peu importe la méthode de développement, il faut toujours viser à mettre ces caractéristiques en place. Dans les cycles de développement Agile, par Sprints de 2 à 4 semaines, ces critères sont incontournables.

Avant de prioriser l’approche Agile dans votre organisation, nous suggérons deux points importants pour une transition réussie :

• Si vous en êtes à vos premiers pas et que vous n’avez personne dans votre organisation avec une expérience Agile, faites-vous accompagner par des coachs Agile avant de démarrer votre projet.
• Choisissez le bon projet, et la bonne équipe ! Ce dernier point peut sembler évident, mais il est tout aussi important que le premier.

Bien qu’Agile soit une excellente approche pour développer des projets, lorsque la portée et les besoins évoluent rapidement, la méthode traditionnelle en cascade doit toujours être envisagée et conservée dans certains cas.

Par exemple, lorsque les besoins sont clairement définis et que des documents de spécifications clairs doivent être disponibles, dans des domaines spécifiques et bien réglementés, l’approche traditionnelle a ses avantages.

• La planification du projet est plus facilement prévisible.
• L’équipe de production se concentre sur le développement de la solution, sans passer régulièrement en revue les besoins.
• Le résultat de la livraison est plus facile à prévoir.

Il est également important de comprendre que l’introduction de l’approche Agile dans des systèmes patrimoniaux ou à intégrations multiples n’est pas toujours évidente, ni même applicable.

L’approche Agile apporte certes de nombreux avantages mais elle n’est pas sans faiblesses.

• Le client (Product Owner) doit être impliqué dans le projet.
• La documentation n’est pas un livrable prédéterminé dans l’approche Agile.
• Une relation de confiance doit s’établir entre tous les membres de l’équipe, ce qui n’est pas toujours facile.
• Il faut s’attendre à refaire des fonctions déjà livrées avec des besoins évolutifs.

Pour reprendre un exemple de l’industrie musicale utilisé précédemment, Spotify, un leader mondial du streaming audio, a adapté le modèle Agile et développé son propre modèle d’évolutivité, avec des équipes, des tribus, des chapitres et d’autres concepts.

Tous ces concepts étaient toujours basés sur l’autonomie de l’équipe. Cependant, alors que beaucoup ont loué l’approche de Spotify (en raison du succès de l’entreprise), il semble que l’approche ait été semée d’embûches. Dans cet article intéressant de Jeremiah Lee, s’attardant sur les dessous de cette approche, on peut mieux comprendre les enjeux que les équipes de Spotify ont dû traverser. Il y a plusieurs passages dans cette analyse pour faire réfléchir, notamment ces deux commentaires :

• Il n’y a pas d’autonomie sans direction et responsabilité;
• La collaboration ne garantit pas la compétence.

En tant que l’une des quatre valeurs fondamentales du Manifeste Agile, qui préconise la livraison avant la documentation « complète », beaucoup peuvent penser que la documentation des projets Agile est déficiente. De plus, comme les développeurs sont généralement peu focalisés sur l’écriture et qu’ils sont fortement impliqués dans les spécifications produits avec les métiers, la question est légitime.

Il est faux de prétendre que l’approche Agile est contre la documentation. Il existe 4 règles, souvent utilisées pour la documentation Agile, qui assurent un niveau de documentation adéquat :

• Avoir le minimum nécessaire (Just Barely Good Enough – JDBG) ;
• Ecrire au bon moment (Just In Time – JIT) ;
• Centraliser toute la documentation ;
• Produisez-le en collaboration avec tous les membres de l’équipe.

Pour illustrer les règles ci-dessus, les projets Agile visent à « voyager léger » pour le composant de documentation.

La documentation Agile est régulièrement présentée sous forme de User Stories. Ces ‘Stories’ ressemblent à : En tant que « qui », je veux « quoi », afin de « pourquoi ». Dans les cas plus complexes, nous appelons cela une « User Epic », qui peut être définie comme un groupe de user stories.

Comme dans tout projet, Agile ou Waterfall, il y aura d’autres documents à exécuter. Celles-ci iront d’une charte de projet à des guides d’utilisation. Pour être clair : Agile n’a pas supprimé le besoin de documents de référence.

Encore une fois, l’importance clé lorsque vous tirez parti de la prémisse de « l’agilité pragmatique » est d’adapter l’approche Agile à vos façons de faire pour garantir l’adhésion de tous.

Quand on regarde la documentation de l’approche Agile, pour les petites équipes (10-15), il y a régulièrement trois rôles :

• Propriétaire du produit
  – Définit les fonctionnalités du produit (Product Backlog) ;
  – Décide et priorise le contenu des sprints ;
  – Ajuste les fonctionnalités à chaque itération ;
  – Accepte ou refuse les fonctionnalités effectuées ;
  – Gère les communications avec les parties prenantes.
• Maître de mêlée
  – Aide le propriétaire du produit à gérer la valeur des fonctionnalités ;
  – S’assure que l’équipe est opérationnelle et productive;
  – Bâtir la collaboration entre les membres de l’équipe;
  – Enlever les obstacles;
  – Suit le processus Agile.
• Équipe de développement
  – Assiste le Product Owner dans la rédaction des user stories et des tests d’acceptation ;
  – Nous nous référons ici à des rôles tels que l’analyste d’affaires.
  – Fabrique et teste les fonctionnalités du produit;
  – Nous faisons référence ici à des rôles tels que les développeurs et les analystes QA.
  – Présente les résultats au Product Owner ;
  – Tenir à jour les spécifications;
  – Gère les versions et les déploiements.

Dans l’image ci-dessus, nous ne voyons aucun chef de projet. De plus, on voit que la gestion du sprint est réalisée par l’équipe. Certains lecteurs observeront probablement que le suivi budgétaire est totalement absent des responsabilités de tous les rôles. En revanche, rien n’empêche un PM dans un projet Agile de petite voire moyenne taille de jouer le rôle de Scrum Master tout en gérant le budget.

Bien que le modèle ci-dessus fonctionne très bien pour les petites équipes, pour les grands projets et pour les organisations qui ont fait une immersion totale dans le modèle Agile, l’approche SAFe (Scaled Agile Framework) est la plus populaire. Dans ce cas, la gestion de projet réapparaîtra, une fois de plus.

Quand on regarde le schéma ci-dessus, on sent une certaine lourdeur et un éventuel manque de souplesse, ce qui va à l’encontre des principes de base de l’Agile. Encore une fois, la chose importante à retenir est qu’il n’y a pas de solution miracle. Les méthodologies agiles doivent être adaptées au contexte de votre organisation.