Où positionner le manager dans un contexte agile ?

La clé du succès d’un projet agile n’est pas la prouesse informatique, mais bien le facteur humain. Pour réussir, le manager agile doit être capable d’adopter un fonctionnement bottom-up, et favoriser autant que possible l’autogestion des équipes. Cette méthode de management a fait ses preuves, et des acteurs non issus de l’univers des systèmes d’information pourraient peut-être se l'approprier un jour.

Cette méthode de management a fait ses preuves, et des acteurs non issus de l’univers des systèmes d’information pourraient peut-être se l'approprier un jour.
« Agilité ». Dans les DSI, le terme est sur toutes les lèvres. Mais qu’est-ce au juste ? Si l’on s’en tient à une définition stricto sensu, les méthodes agiles sont itératives et incrémentales sur la base d’un affinement fonctionnel et technique du besoin mis en œuvre dans des fonctionnalités en cours de réalisation ou, parfois, déjà réalisées, ce dans le but d’optimiser le ROI du produit développé.
L’agilité n’est pas une mode. Elle marque au contraire une révolution dans l’approche projet. Reposant sur un principe de conception et d’amélioration en continu, impliquant très fortement le maître d’ouvrage de grands projets d’ingénierie logicielle et permettant une grande réactivité à ses demandes, voilà une méthode qui fait ses preuves. Car les méthodes agiles atteignent leur but dans les faits : le besoin du client est mieux qualifié, la qualité logicielle du rendu est améliorée, le contrôle de la qualité s’effectue en continu et en temps réel, le gain de productivité est important et le budget de maintenance est réduit. De son côté, le prestataire agile se différencie par sa capacité à mettre en œuvre une approche novatrice, à proposer un produit ajustable en continu, en forte adhérence avec le besoin du client, et gagne ainsi, in fine, des parts de marché. Sont ainsi contournés les écueils des cycles en V, où 70% des projets n’arrivent pas à terme, où le décalage entre le projet initial et le projet final livré est parfois criant…
Initialement développées dans le cadre de petites structures, les méthodes agiles sont désormais privilégiées par de grands acteurs du CAC 40, tel par exemple EADS dans le cadre du projet de centrale inertielle de l’A380, réalisée en agile, ou, très récemment, par une structure aussi dense et complexe que l’AP-HP, l’Assistance Publique-Hôpitaux de Paris, pour la mise en œuvre de projets informatiques de haute criticité. Un signe qui ne trompe pas.
Mais l’agilité est bien plus qu’une méthode. Elle est un état d’esprit, où la visibilité globale du projet n’est jamais réellement possible, où l’utilisateur final, et non le process, est au centre du projet, où l’on se soucie de la satisfaction réelle d’un besoin client – qui de surcroît n’est jamais complètement stabilisé – plutôt que des termes d'un contrat de développement.
Dès lors, le client, traditionnellement guidé par une logique de contrôle de gestion (besoin, coût, délai), doit être capable – et le prestataire peut l’y aider – de bousculer ses repères pour admettre la mise en œuvre d’une méthode parfois perçue, de prime abord, comme déstructurante, non maitrisée, et accepter qu’un projet au forfait puisse être contractualisé sur un périmètre mouvant. Quant au prestataire, il doit savoir privilégier l’approche empirique, l’expérimentation au service d’un apprentissage progressif et collectif, constater plutôt que prévoir, contextualiser un projet, accepter la critique et parfois même accepter de… rebasculer en cycle en V. La méthode agile implique donc, tant pour le prestataire que pour le client, un profond changement dans la façon de travailler.
Tous les esprits ont-ils la capacité à intégrer ces changements ? Nombreux sont les développeurs perfectionnistes qui estiment que la qualité logicielle de leur travail n’est pas négociable. Mais force est de constater que la « surqualité » des développements entraine parfois certaines dérives dans la conduite du projet... Certes la qualité des architectures est irréprochable. Mais est-ce justifié au regard de l’investissement du client ? Comment expliquer que la qualité logicielle n’est pas une fin en soi, mais une simple variable d’ajustement au service de la valeur métier du livrable ?
La clé, en fait, est managériale. Pour relever le défi, le manager agile doit posséder des qualités et capacités bien spécifiques. Exposé au risque d’un durcissement des équipes, ou de tensions en leur sein si les opinions divergent quant à la pertinence des méthodes agiles, il doit être capable d’amener l’ensemble de ses collaborateurs à partager l’état d’esprit agile, tout en veillant à rester en phase avec les exigences du client. Concrètement, le manager, ou scrum master, peut jouer le rôle de  chef de projet le temps que l’équipe soit autonome. Puis il doit réduire progressivement son contrôle, responsabiliser les équipes, favoriser l’écoute et le dialogue, jusqu’à laisser ses équipes s’autogérer. Le manager agile devient alors un « facilitateur », un coach, chargé d’accompagner l’équipe et de la protéger des perturbations extérieures. En aucun cas il ne doit être directif. En amont, il aura veillé à recruter des personnalités susceptibles, directement ou potentiellement, d’acquérir l’esprit agile.
Autogérées, engagées, responsables et matures, les équipes s’approprient le projet sur le terrain, deviennent force de réflexion et de proposition. Elles peuvent parfaitement être amenées à remettre en cause le manager lui-même, une démarche iconoclaste dans un système classique, mais naturelle dans un cycle agile. Il se pourrait que ce soit même là la meilleure preuve de la réussite du manager.
Voie nouvelle, médiane, entre management « bottom-up » et « top-down », le management agile fait son chemin. Et si, fort de ses succès, il était adopté au-delà de la sphère informatique ?