Vous entendez parler partout d'agilité mais vous ne comprenez pas vraiment de quoi il retourne ? Les rumeurs courent en effet autant que le gruyère sur les pizzas des tortues ninja. Avec l'aide du sage et avisé Maître Splinter, démêlons le vrai du faux et revenons aux bases de l'agile-jutsu.
Avant de parler plus en détail des projets et des types d’organisations adaptés à l’agilité, parlons méthodologie de travail basée sur l'adaptabilité.
Les méthodes agiles font référence à des pratiques de pilotage et de réalisation de projets, initialement IT. Elles ont vu le jour en 2001 avec pour origine le manifeste Agile et ont pour fondement un cycle de développement itératif (basé sur la répétition). L’idée étant de s’appuyer sur ces itérations pour adapter l’organisation et le développement dans une optique de constante amélioration. Autant d’un point de vue humain que technique.
Quatre valeurs fondamentales sont prônées par le manifeste Agile :
Les individus et leurs interactions plus que le processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Ces notions doivent permettre (autant dans le pilotage que dans la réalisation du produit) de replacer au coeur du projet le client et son besoin, afin de permettre une construction main dans la main entre les différents partis impliqués.
Les cycles courts de développement imposés par l’approche agile permettent d’éviter un effet tunnel où les client n’auraient aucune visibilité de ce qui est imaginé par l’équipe de développement, et ainsi de se retrouver avec un rejet du livrable final développé pendant plusieurs mois.
L'adaptabilité défendue par l'Agilité nécessite une vraie rigueur. De nombreuses méthodologies et approches permettent de cadrer jour après jour le développement du produit. La force de l’agilité est justement de pouvoir adapter cette rigueur à tout obstacle ou changement de direction qui pourrait se présenter.
Pour n’en citer qu’un, Scrum est probablement LE framework le plus utilisé aujourd’hui pour du lean project dans la gestion de projet informatique. Pour les non-initiés, le Lean Project est un type de management de projet centré sur le besoin client, et dont le but est de produire le plus de valeur possible avec le moins de perte de temps et de développement possibles.
Sans entrer dans le détail des actions menées par chaque membre de l’équipe opérationnelle (PO, Scrum Master, Dev, UX), le principe de Scrum réside dans le découpage des développements en “sprints”. Un sprint peut durer d’1 à 4 semaines, et commence par une estimation et une planification des développements. Il se termine par une démonstration ainsi qu’une rétrospective. Cette dernière cérémonie a beaucoup d’importance pour l’amélioration continue du projet : il s’agit d’analyser le déroulement du sprint achevé et d’en tirer les leçons pour améliorer ses pratiques.
Il existe en fait de nombreux autres frameworks agiles. Chacun avec sa particularité et sa méthodologie, parfois plus adaptées à certaines structures que d’autres. Mais tous partagent les valeurs de transparence à travers un langage commun entre équipe développement et client, la volonté de détecter les problématiques, et celle de s’adapter pour remettre le processus sur les rails si nécessaire.
Originellement, l’agilité a été créée pour la gestion de projet logiciel et informatique. Aujourd’hui, on retrouve cependant de plus en plus de projets dans l’industrie ou encore dans la R&D qui sont passés aux approches Agiles. Quels sont leurs points communs ? Quelles en sont les limites ?
Premier élément distinctif d’un projet qui gagnerait à adopter une approche agile : sa complexité, autant technique que organisationnelle.
Je m’explique : les projets informatiques par définition sont complexes techniquement. On ne maîtrise pas à l’avance tous les effets des développements. L’équipe doit au jour le jour faire face à de nouvelles problématiques. Une méthodologie adaptative pour pouvoir réagir rapidement est essentielle.
La complexité organisationnelle peut, elle aussi, être gérée beaucoup plus efficacement par l’agilité : notamment quand on doit gérer du multi-sites ou encore des équipes nombreuses qui ne communiquent habituellement pas entre elles et sont cloisonnées.
Les projets très innovants type R&D -tous secteurs confondus- se prêtent beaucoup à l’approche Agile, et c'est un autre élément distinctif d’un projet type adapté à l'agilité. Les nombreuses variables inconnues, qui sont découvertes petit à petit pendant les phases de développement les rendent complexes à gérer, pouvant engranger des délais supplémentaires et des budgets supplémentaires. Il est donc capital que l’organisation de l’entreprise puisse suivre derrière. Nous aborderons ce sujet là précisément dans le chapitre suivant.
L’agilité peut également être une très bonne approche quand les équipes sont noyées par les priorités qui se chevauchent. Elle rétablit un ordre et permet surtout de changer de priorités très facilement en fonction du besoin, à chaque nouvelle itération.
Il arrive très fréquemment que des idées arrivent après le lancement d’un projet, quand le produit est déjà en cours de réalisation. Idées qui peuvent aussi faire prendre des virages à l’objectif du produit.
Si votre projet rentre dans ces cas-là, l’agilité est idéale.
Cependant, l’agilité n’est pas adaptée à tous types de projets (même si cela se fait de plus en plus avec des adaptations de l'agile), et en particulier aux productions répétitives.
Pour prendre exemple sur le secteur automobile et faire un parallèle avec un pour et un contre à l’approche agile.
Si on se lançait dans un projet de recherche & développement d’une voiture automobile volante, une approche agile aurait tout son intérêt pour les raisons citées précédemment (besoin de s’adapter, de tester, de revenir en arrière...).
Par contre, pour la construction en chaîne de voitures déjà modélisées, déjà créées des milliers de fois, l’approche agile n’aurait pas de valeur ajoutée. On sait exactement ce que l’on souhaite, comment on le souhaite et on connaît le temps de réalisation pour chaque assemblage. Ces données sont connues et fixes.
Également, le côté trop simpliste ou court de certains produits limite les apports que pourrait avoir la méthode Agile. On peut penser par exemple à la réalisation d’une nouvelle pièce pour améliorer les performances d’une voiture ou corriger une défaillance, ou encore à l’intégration d’un formulaire de contact sur un site web : ces produits ne nécessitent pas la mise en place d’une méthodologie Agile pour être menés à bien.
Techniquement, les approches agiles peuvent donc s’adapter sans problèmes à tous types de projets répondant aux critères “recommandés”, en passant même par des services plus qu’à des secteurs comme le recrutement, le marketing ou le business. On retrouve aussi de plus en plus de monde s’intéressant à l’agilité et mettant en place des méthodologies pour des projets personnels comme le mariage, l’organisation des tâches ménagères, les activités des enfants, etc...
Cependant le projet s’inscrit dans un environnement organisationnel plus grand que lui-même : le métier, le sponsor, les services transverses, les directions des entreprises… Tous ces acteurs qui pivotent autour du projet et composent son environnement sont tout autant de critères de réussite ou d’échec à l’intégration d’une approche Agile.
Quand on transitionne vers une gestion de projet agile c’est toute l’organisation de l’entreprise qui doit être transformée. Et ça… C’est bien loin d’être simple, car on touche à la culture de l’entreprise !
Déjà, il est factuellement plus simple pour une petite organisation d’intégrer l’agilité dans son fonctionnement de A à Z qu’une très grande. Plus il y a d’acteurs, plus il y a de réticences au changement.
Ce qui ne veut en aucun cas dire que le challenge ne peut pas être relevé.
La liste ci-dessous explique des mindsets organisationnels, de manière non exhaustive, mais importants pour toute organisation qui se veut agile, ou qui souhaite le devenir.
Cela ne concerne pas uniquement l’équipe développement composée du product owner, du scrum master et des développeurs. Mais bien une collaboration basée sur la transparence et la confiance entre toutes les parties prenantes : que ce soit les représentants métiers, les sponsors du projet, le pôle business dont l’environnement peut-être impacté par le produit développé, etc...
Il n’est plus question de pointer du doigt une erreur, un acteur du projet, ou de se cacher derrière une information qui n’aurait pas été communiquée. Il s'agit de remettre en question le processus, les fonctionnalités, ou le développement dans le but de l’améliorer pour le bien du produit et du quotidien du projet. Les objectifs sont partagés, et non plus verticaux entre seulement quelques intervenants, ou chacun à son niveau.
Dans le fonctionnement d’un projet Agile, les acteurs s’auto-organisent. Il n’y a pas de dépendance managériale entre eux à proprement parler. Le Product Owner ne sera en aucun cas manager des développeurs, comme le Scrum Master ne sera en aucun cas manager du reste de l’équipe de développement.
Le Sponsor, le représentant métier ou encore les utilisateurs finaux vont exprimer leurs besoins, et l’équipe de développement va proposer les réponses qui semblent les plus adaptées. Un choix et une orientation seront donnés en accord avec tous les acteurs. Il s’agit d’une collaboration.
Par ailleurs, la responsabilisation de chacun dans son champ d’actions permet une plus forte implication. Tout le monde est écouté et apporte une vision pertinente et unique en fonction de sa propre expertise.
Autre point très important dans le fonctionnement agile d’une entreprise, c'est d'accepter de se tromper. Il est crucial de ne pas voir l’échec comme une fin.
Revenir en arrière sur une décision fonctionnelle ou technique est au contraire un moyen de se rendre compte que ce n’était pas la bonne voie à prendre. Que ça a permis d’avoir une vision plus claire et d’améliorer le produit.
Il en va de même pour l’organisation de l’équipe : quand on a un loupé sur une recette qui n’était pas parfaite et qui a laissé passer un bug, quand une estimation était totalement à côté de la plaque ou quand on pensait qu’une feature serait géniale pour l’utilisateur alors qu’elle n’a finalement aucune valeur ajoutée, se tromper n’est qu’un moyen de s’améliorer.
Une organisation ou un produit ne pourra jamais être parfait dès sa première itération.
Pour terminer, un point qui pose souvent problème à beaucoup d’organisations, c'est le manque de dates précises pour les livraisons et les mises en production.
Il faut en effet pouvoir accepter une certaine flexibilité, surtout en début de projet (et c’est souvent là que ça coince…).
Il est compliqué pour les équipes de réussir à estimer le temps de développement un sprint en avance au moment de la découverte et de la montée en compétences sur un environnement technique. D’autant plus que les problématiques qui vont survenir le seront pour la première fois, et demanderont plus de temps pour être fixés.
Donc à vision de plusieurs mois sur le projet, les estimations restent forcément macro. Plus la connaissance du produit par l’équipe sera forte, plus un affinement des délais pourra se dessiner et des dates de releases pourront être affirmées sur un moyen terme, et envisagées sur du long terme. Les égouts de la ville de Rome ne se sont pas construits en un jour, votre futur produit ne le sera pas non plus.
Je pense que le plus important pour pouvoir mettre en place une approche agile dans un projet et faire bouger l’organisation de l’entreprise, est d’avoir des ambassadeurs. Des personnes qui seront prête à former et à cadrer les équipes en leur insufflant la méthodologie et le mindset qu’apportent l’approche agile. C’est eux qui réussiront à convaincre et à embarquer vos équipes.
Appliquer une approche Lean UX pour mettre en place l’agile au sein des équipes peut être une démarche efficiente. Elle permet de lier ensemble les différents acteurs : en amont pendant la phase d’idéation, de prendre en compte les besoins business, de pouvoir expérimenter et explorer à tous les niveaux de votre organisation, et de continuer à alimenter votre équipe projet pure en nouvelles idées. En les rendants interdépendants à travers tout le processus, vos acteurs seront tous engagés dans des objectifs communs vers un produit commun.
De nombreuses entreprises, petites et grandes et de secteurs totalement différents, se sont prêtées avec succès à l’exercice de transformer leur organisation vers une approche agile.
On peut penser notamment à Revenu Quec, entreprise du secteur public au canada (https://savoiragile.com/2016/06/13/transformation-agile/), à PSA et la Société Générale dans l’automobile et la banque (https://tech4exec.fr/entreprise-agile-en-2018/ ) ou encore évidemment à Spotify pour le secteur digital, succès de transformation d’organisation aujourd’hui mondialement connu. Attention tout de même, recopier à l’itération près ce qui à été mis en place dans ces sociétés ne pourra vous mener qu’à l’échec, ou à une transformation très mitigée. Comme chaque être humain est différent, chaque organisation l'est aussi. Le fonctionnement de vos équipes sera forcément différent, et nécessitera une organisation agile propre et adaptée.
La clé de leur succès revient à l’agile à l’échelle, ou “Agile at scale”. L’agilité à l’échelle a pour force de pouvoir s’adapter aux fonctionnements des organisations, et non plus avoir à sens unique les organisations qui s’adaptent à l’agilité.
L’idée est de pouvoir découper les organisations en plus petites équipes, qui auront chacun un plus petit projet ou produit à réaliser. On parle également de “Feature teams” dans le cadre d’un produit découpé en grosses fonctionnalités, qui même interdépendantes peuvent travailler en autonomie avec leur propre objectif.
Évidemment la mise en place de l’agilité à l’échelle nécessite de forts ambassadeurs, et des personnes clés qui permettront l’horizontalisation de l’information à travers toutes les équipes.
De nombreux frameworks existent pour répondre à l’organisation et la mise en place d’une agilité à l’échelle : Scrum@Scale, Nexus, SAFe, LeSS, ou encore le Kanban.
Pour conclure, l’agilité est une approche puissante, avec pour objectif un gain de productivité passant par la motivation et la responsabilisation des équipes. Elle apporte un engagement fort de bout en bout de la chaîne de l’organisation.
Il est important d’avoir conscience que chaque organisation fait comme elle peut, qu’il n’y a pas de solution miracle, et que c’est sur la durée que cette transformation peut être menée. Par ailleurs, aujourd'hui, de nombreuses organisations embarquent des projets agiles et ne sont en aucun cas des organisations full agiles. Elles réussissent tout de même à faire fonctionner, à l’échelle des projets, l’approche Agile. Ce n’est pas optimal, de nombreuses contraintes et challenges se présentent, mais c’est aussi la réalité de la gestion de projet aujourd’hui.
Auteur(s)
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
La qualité est un enjeu très important dans le développement logiciel, cet article vous permettra de (re)découvrir les impacts de la non-qualité, les bienfaits de la qualité et les bonnes pratiques qualité.
Aujourd’hui on parle de product management pour qualifier tout et n’importe quoi, ce qui entraîne la mise en place d’organisations produits sur des bases bancales. Quelles sont les principales erreurs commises ? Comment les éviter ? La liste n’est pas exhaustive mais vous permettra assurément de mieux appréhender votre méthodologie produit.
Cet article présente mes méthodes préférées pour bien appréhender un nouvel environnement de travail, incluant des outils pratiques comme le rapport d'étonnement, le Value Stream Mapping, le mandat de mission, la matrice des attendus et les Moving Motivators, afin de faciliter l'intégration, améliorer les processus et renforcer la collaboration au sein de l'équipe