Direction informatique invite, à chaque parution, un chroniqueur qui traite d’un sujet lié aux technologies de l’information en entreprise. Pour cette édition, Jean-René Rousseau, de Pyxis Technologies, parle des méthodes de développement agile.
À la grandeur de la province, les projets réalisés à l’aide d’une approche de développement basée sur Scrum ou tout autre cadre méthodologique Agile se multiplient. Certaines organisations sont en mode exploratoire alors que d’autres soutiennent de véritables initiatives de changement organisationnel en s’appuyant sur les principes et valeurs de l’Agilité.
Si vous envisagez d’adopter Scrum pour vos projets de développement logiciel, sans doute avez-vous déjà une bonne idée des gains envisagés et des impacts d’un tel changement(1). Mais vous vous demandez peut-être comment démarrer un tel chantier. Quelles stratégies adopter? Quels sont les pièges à éviter? Dans cet article, je ferai le tour de la question en vous proposant une feuille de route ponctuée de trucs et outils pour vous aider à démarrer votre transition Agile du bon pied.
Par où commencer?
Avant toute chose, il faut faire un constat critique de votre situation actuelle et déceler les opportunités d’amélioration à l’intérieur de votre organisation. L’objectif de cette première étape est de vous permettre de répondre à une question fondamentale que l’on doit se poser à l’aube de tout changement : pourquoi devons-nous changer? Cette prise de conscience vous permettra de positionner la transition Agile comme un moyen pour améliorer l’efficacité de l’organisation (voir encadré) et non pas comme une fin en soi. De plus, en déterminant les objectifs que vous désirez atteindre, vous serez en mesure de communiquer les résultats de la transition de façon plus objective, et ce, tout au long du processus.
Par la suite vient l’étape d’analyse d’impact qui vous permettra de déceler d’éventuels obstacles à la transition et d’atténuer les risques associés à ceux-ci. Processus de développement actuel, rôles et responsabilités, pratiques de gouvernance, relations avec les clients et fournisseurs, aménagement physique de l’espace de travail… tout doit être considéré. L’idée est de mettre en lumière les freins et les accélérateurs de votre transition. Attention cependant, rien ne sert de faire une analyse très approfondie car la véritable découverte des obstacles liés à la mise en place de Scrum aura lieu au fil des itérations des premiers projets pilotes.
Révolution ou évolution?
L’Agilité est un immense coffre à outils : tests automatisés, gestion de projet à portée variable, conception émergente, documentation simplifiée, équipe fixe, mise en production fréquente, et bien d’autres pratiques encore. Doit-on mettre tout ça en place pour avoir du succès?
L’expérience des dix dernières années nous montre qu’un nombre minimal de pratiques doit être implémenté pour espérer atteindre les objectifs d’efficacité que l’on recherche. Il ne suffit pas de se parler quinze minutes le matin pour être Agiles! On en vient donc à faire la distinction entre les pratiques obligatoires et les pratiques optionnelles, et surtout à bien comprendre les principes derrière chacune de ces pratiques.
Pour moi, le minimum à mettre en place est Scrum. Scrum est léger, simple et il permet d’établir la cadence du développement empirique et de créer l’espace pour laisser émerger tout le reste. Ce n’est pas pour rien que 75 % des organisations qui se lancent dans l’Agilité utilisent Scrum(2).
En fait, l’intensité avec laquelle vous vous lancerez dans l’aventure Agile dépendra surtout de l’urgence avec laquelle l’organisation doit changer ainsi que de la culture de l’entreprise(3). La majorité des organisations que l’on rencontre possède une bonne maturité en développement logiciel et, en général, a du succès dans ses projets. Pour ces organisations, l’arrivée de l’Agilité est considérée comme une évolution de leurs pratiques actuelles et non pas une révolution complète de leurs façons de faire. Pour d’autres, la situation est plus critique. L’amélioration de l’efficacité des équipes de développement devient alors une question de survie, et ces organisations démontreront plus de volonté à adopter l’ensemble des pratiques Agiles suggérées.
À ce stade-ci, vous avez en main des objectifs d’efficacité, une analyse d’impact, un plan de communication et un aperçu des pratiques Agiles à mettre en place. Vous êtes prêts à passer aux choses sérieuses…
La vie après le pilotage
L’étape du pilotage vous en apprendra beaucoup sur votre organisation. La pression de livrer un incrément logiciel de qualité production à chaque itération rendra visible plusieurs inefficacités dont certaines sont déjà fort connues depuis trop longtemps. Parmi ces inefficacités, il y aura ce qu’on appelle des « obstacles organisationnels », c’est-à-dire des éléments qui ne peuvent être abordés par les équipes et qui nécessitent la prise en charge par la direction. Encore une fois, la volonté de prendre en charge ces éléments dépendra des objectifs attendus de la transition Agile et de l’urgence de changer.
Une chose est certaine, pour poursuivre l’adoption de l’Agilité dans l’organisation et éviter que les équipes innovent en silo, vous aurez besoin d’un groupe de travail fédérateur que l’on appelle « bureau d’amélioration continue ». Ce groupe aura comme mission de soutenir les initiatives Agiles, de canaliser l’innovation qui émerge des équipes et d’aider l’organisation à surmonter les obstacles organisationnels.
Bien choisir son premier projet Agile (5)
Il y a souvent beaucoup d’attention autour des premières initiatives Agiles dans une organisation. On fonde beaucoup d’attentes envers ces projets dits « pilotes », et le succès (ou l’échec) de ceux-ci influencera beaucoup la suite des choses. Il faut donc bien choisir ces premiers projets. Pour ce faire, Mike Cohn, l’Agiliste bien connu(4), nous propose 4 dimensions à évaluer pour choisir un bon projet pilote.
Durée : Si vous sélectionnez un projet qui est trop court, il sera difficile de bien sentir les effets de l’Agilité au bout de 2 ou 3 sprints seulement. D’un autre côté, si vous sélectionnez un projet qui est trop long, vous risquez de ne pas pouvoir déclarer le succès du projet avant qu’il ne soit terminé. Selon moi, un projet de 5 à 7 mois est une durée idéale pour commencer.
Taille : L’Agilité appliquée à un contexte à équipes multiples ou ayant une équipe distribuée est drôlement plus complexe qu’un projet où l’on retrouve une seule équipe colocalisée. Si vous le pouvez, limitez-vous à un projet ne comportant qu’une seule équipe (ou deux) composée de 6 à 8 personnes.
Importance : Un projet qui n’est pas important pour l’organisation ne fera pas un bon projet pilote, car il n’obtiendra pas l’attention et l’engagement qu’il mérite. Une équipe dédiée et engagée, des réponses rapides pour contourner les obstacles et un soutien entier de la gouvernance sont des facteurs de succès à ne pas négliger en mode « Agile ». Il y a plus de chances de retrouver ces conditions dans un projet important pour l’organisation.
Engagement du secteur d’affaires (sponsor métier) : L’un des changements majeurs en Agilité est le niveau de collaboration requis entre l’équipe de développement et le secteur d’affaires par leur représentant appelé « Product Owner ». Si le secteur d’affaires n’est pas de la partie, vous verrez l’efficacité du mode Agile diminuer grandement.
Le bon projet pilote se situe à l’intersection de ces 4 dimensions (voir tableau ci-dessus). À cela s’ajoute la composition de l’équipe de ces premiers projets, car ne l’oubliez pas, une transition Agile est avant tout un défi humain. Je recommande de trouver un bon équilibre entre une équipe de champions et une équipe de débutants. Vous ne voulez pas vous faire reprocher que « ça fonctionne juste avec des champions », mais vous ne voulez pas non plus vous retrouver avec une équipe qui ne sait pas comment se débrouiller dans un contexte où le leadership et la débrouillardise sont valorisés.
Références: (1) L’approche de développement logiciel démystifiée (http://myi.tw/U6) (2) State of Agile survey 2010 (3) Pour en savoir plus sur l’Agilité et les types de cultures d’entreprise (http://collectiveedgecoaching.com/2010/07/agile__culture /) (4) Bien choisir un projet pilote (http://blog.mountaingoatsoftware.com/four-attributes-of-the-ideal-pilot-project) (5) Traduction du schéma de Mike Cohn par Fabrice Amietti (http://www.fabrice-aimetti.fr)
Pour consulter l’édition numérique du magazine de mai de Direction informatique, cliquez ici
