Depuis quelques années, la méthode Agile s’impose comme une méthodologie « innovante » qui contribue à renouveler les pratiques de gestion de projet SI et les relations entre le Métier et la DSI.
Un des dangers que nous voyons apparaître chez nos clients, est la tentation de « faire de l’Agile » soit par effet de mode soit en croyant au « guichet magique qui résout tous les problèmes », ce qui peut se traduire de façon caricaturale :
- Dans la tête de l’utilisateur : « on n’aura plus de documentation interminable et inutile à produire pour faire plaisir aux informaticiens » ;
- Dans la tête du développeur : « je vais enfin pouvoir faire ce que j’ai envie de faire, sans trop de contraintes ».
Mais une démarche Agile ne s’improvise pas. Elle doit d’abord et durablement être partagée avec le métier pour réussir. Une équipe SI ne doit pas lancer cette démarche sans l’implication concrète d’interlocuteurs du métier et le sponsoring du Management (aussi bien SI que Métier) ;
Sans reprendre les points du manifeste Agile, nous vous proposons quelques principes pour favoriser vos succès dans les projets et renforcer l’Agilité de vos équipes :
« Savoir renoncer à l’Agile »
Pour servir, une méthodologie ne doit pas être une fin en soi. Certains projets doivent pouvoir être menés selon d’autres méthodologies, sans dogmatisme a priori.
- L’Agile (notamment SCRUM) est peu appropriée aux très petites équipes (1-2 personnes) et aux très petits projets (1-2 sprint). De même, pour les trop grosses équipes. Si le nombre total de développeurs est grand, il faut les découper en équipes ~7 personnes, et lotir le projet en « SCRUM de SCRUM ». Les équipes retrouvent alors l’agilité et gagnent en vélocité sur leur périmètre ;
- Si le même type de projet a déjà été réalisé avec succès et qu’il porte peu de complexité fonctionnelle, comme par exemple un projet essentiellement technique faisant intervenir de nombreux sous-traitants, les méthodologies classiques (plus Tayloriennes, de type cycle en V) sont plus efficaces.
En outre, mettre en place une méthodologie Agile implique de s’approprier les concepts et de les adapter à son contexte. Il faut parfois savoir s’écarter de la théorie, pour faire ce qui fonctionne dans un jeu de contraintes particulier. Le cadre théorique de l’Agile est un idéal vers lequel toute organisation doit tendre, mais il ne s’agit pas de se dire « c’est tout ou rien ». Mettre en place une démarche Agile est un cheminement orienté vers l’amélioration continue. Tout ne peut pas être « parfait » dès le 1er jour.
Positionner l’Agile en démarche collective continue (ou supprimer le fantasme du « guichet magique »)
- L’Agile est un état d’esprit quotidien au sein d’une équipe au service d’une entreprise, et pas une compétence individuelle définitive, acquise après une formation théorique. La méthode agile (y compris sa certification) ne règle pas tous les problèmes !
- L’expérience individuelle acquise sur projet doit être prise en compte lors de la constitution d’une équipe, mais c’est surtout l’expérience de l’équipe qui sert d’indicateur de progrès au fur et à mesure du projet ;
- Cette expérience collective acquise lors d’un projet Agile doit également servir à améliorer continuellement les pratiques, pour augmenter la performance des équipes sur les autres projets ;
- Enfin, les équipes Agiles doivent être intégrées de manière constructive au reste de la DSI sans marginalisation, ni favoritisme.
Documenter l’utile en pensant aux suivants
Comme toute méthode qui dure et s’industrialise, la méthode des cycles en V et les méthodes d’intégration de progiciel ont développé des batteries documentaires à l’utilité parfois discutable.
- L’équipe Agile ne doit pas renoncer, voire rejeter, la documentation : elle se concentre sur la documentation utile, qui a de la valeur, c’est-à-dire les documents qui permettent soit d’éclaircir un point au sein de l’équipe ou auprès des utilisateurs, soit de tracer un choix pour les suivants ;
- La méthode étant centrée sur la collaboration, les outils de type Wiki sont particulièrement adaptés pour constituer la documentation utile aux projets Agiles
- Enfin, l’équipe Agile n’est pas un groupuscule de technophiles isolés des pratiques de gestion du travail collectif. Si l’auto-organisation de l’équipe peut dérouter au départ, elle n’affranchit pas le projet de reporting. En revanche, les tableaux de bord sont simples, affichés aux yeux de tous sur le plateau projet, et répondent aux besoins de coordination de l’équipe avant de faire plaisir à un « amoureux de MS project ».
Sélectionner une équipe impliquée et stable
- Le premier critère de succès d’un projet Agile (ou d’une démarche plus large de mise en œuvre de la méthode agile) est l’équipe qui la porte. Une attention particulière doit être portée à la constitution de l’équipe pour éviter le « staffing par défaut » ou en « plus du reste ». L’équipe doit être formée de membres compétents, disponibles et pérennes dans la démarche. Si cette évidence est facile à écrire, elle est parfois compliquée à mettre en place dans la « vraie vie »…
- Les rétrospectives et le Scrum master servent à débloquer les problèmes rencontrés sur les projets. Comme dans toute autre situation d’entreprise, les relations inter-personnelles contribuent à la réussite de l’équipe. Elles doivent être traitées au quotidien et approfondies lors des rétrospectives pour ne pas devenir une source de dysfonctionnements. En cas de handicap au bon fonctionnement de l’équipe, la réaffectation de certaines ressources doit être envisagée ;
- A l’image des effets vertueux du Pair Programming pour les développeurs, l’équipe peut profiter d’un binôme métier pour maximiser l‘effet du Product Owner : binôme de Product Owner et Product Manager ou binôme de PO et Proxy PO, par exemple.
Faciliter le travail de l’équipe et répondre vite
- Les sprints sont intenses pour l’équipe, qui doit donc avoir les moyens matériels de travailler, sans attendre trois jours pour qu’on lui ouvre un environnement nécessaire, ou être bloquée deux semaines pour une précision sur le besoin du métier. Ces évidences écrites sont souvent compliquées à mettre en œuvre. Au-delà des moments internes à l’équipe, le Product Owner doit en permanence faire les arbitrages, sans jamais baisser les bras devant les besoins métiers apparemment complexes à développer ;
- Les équipes partenaires doivent également développer un état d’esprit « moins séquentiel ». Le management du métier doit non seulement accepter de dédier véritablement des ressources au projet (a minima un PO représentatif et disponible), mais être capable d’accueillir les questions de l’équipe pour les traiter de manière rapide ;
- Les équipes métier doivent également accepter que le PO les représente et qu’il prenne les décisions lors des sprints sur l’interprétation du besoin en répondant aux développeurs. L’équipe avance sur le produit applicatif sans être soumise à la production de tableaux de bords ou être absorbée dans la préparation de supports de présentations.
Redéfinir le contrat de projet entre le métier et les équipes SI
- Les décideurs doivent accepter de ne pas tout savoir au démarrage du projet : une des valeurs ajoutées de l’Agile est de donner au métier les moyens de faire évoluer son besoin au fur et à mesure du développement du produit applicatif (avec le backlog entre les sprints, pas en cours de sprint) ;
- Le projet peut être arrêté à chaque itération (soit parce que la solution livrée est suffisante, soit parce qu’on se rend compte que le projet doit être stoppé) : les équipes SI peuvent donc être amenées à être réaffectées plus rapidement que sur des projets de cycle en V. La DSI doit intégrer ce changement dans sa gouvernance avec les métiers (portefeuille des projets), ainsi que dans la gestion de ses développeurs (internes et externes) ;
- Enfin, les équipes SI acceptent de « soulever le capot » à échéances rapprochées. Contrairement à d’autres méthodologies, l’utilisateur voit rapidement les écrans, et réagit donc par rapport à l’application qui lui est concrètement proposée (et plus uniquement sur des formulations dans des documents papier).
Repositionner les relations avec les prestataires sur la confiance plus que sur le contrôle a priori
- Suite aux demi-succès de certains projets SI et avec la consolidation d’une industrie SSII aux prestations plus matures, les grandes entreprises ont privilégié l’achat d’unités d’œuvre standards entre sociétés externes au travers de forfaits aux livrables très détaillés à l’avance. Cette profusion de détails et de contrôles à l’avance n’est pas applicable aux projets Agiles ;
- Les Achats doivent donc convenir d’un cadre de confiance avec leurs prestataires, sur la base d’unités moins détaillées, mais mesurables et identifiables pour tous (ex : un sprint). Les partenaires peuvent en contrepartie convenir de clauses de sortie rapide en cas de rupture de cette confiance (ex : sortie en fin de sprint, avec préavis de deux semaines).
Article co-rédigé avec Nicolas Montens
Nos autres articles sur les méthodes agiles
