L'agilité, une exclusivité des TI?

Dans mon rôle de Project Manager et de Scrum Master, j’ai eu la chance ces dernières années d’être impliqué dans une multitude de projets novateurs, et ce, pour une foule de clients et de lignes d’affaires différentes. J’ai ainsi pu expérimenter et mettre en place la méthode agile de toutes sortes de manières différentes, selon le contexte et le projet. Grâce à ces multiples projets dans divers secteurs, j'ai pu constater une tendance assez marquée en ce qui concerne l'agilité. Pour les plus curieux, nous vous invitons à découvrir les différences entre les méthodes agile et waterfall dans un projet BI.

Les TI, un département à part?

C’est un fait: le département TI est, par nature, toujours impliqué dans les projets technologiques ou techniques, dans lesquels le changement est chose courante.

Pour pouvoir opérer ces changements de manière optimale, de nombreux départements TI ont adopté un mode de fonctionnement basé sur la méthodologie agile qui met l'accent sur la nécessité de communication entre les acteurs pour assurer la réussite d'un projet. Mais est-ce que cela veut dire que l’agilité n’est qu’une affaire de TI? Est-ce que ce mode de livraison ne doit rester au sein que d’un seul département?

Lors de mes discussions avec les lignes d’affaires, combien de fois ai-je entendu des phrases du type “Le département TI fait peur! Ce ne sont pas des gens avec qui il est facile de discuter. On dirait qu’ils parlent une autre langue! Ils se prennent pour des mini-Google” ? Comment remédier à cette vision erronée ?

En fait, à mon avis, la meilleure façon de réduire ce clivage entre TI et lignes d’affaires, c’est selon moi, justement d'impliquer ces mêmes lignes d’affaires dans les projets en tant que directeur de produit (Product Owner ou PO).

Voilà comment mes clients ont réalisé les avantages incontournables de l’agilité.

De cette manière, j’ai eu de beaux succès dans les projets avec des besoins exploratoires et imprécis. En effet, travailler en agilité permet de présenter rapidement un premier livrable au client ce qui permet de clarifier ou de faire évoluer le besoin initial.

Méthode agile et projets informatiques, quels sont les pièges à éviter?

Appliquer le framework agile, c’est la promesse d'apporter de la valeur aux lignes d’affaires à chaque sprint. Toutefois, pour faire en sorte de maximiser les bénéfices de l’agilité aux projets, il convient d’éviter certains pièges. En voici trois, tirées de mes derniers projets clients.

Une approche big bang!

J’ai connu des projets qui ont fait l’erreur de laisser l’équipe de réalisation s’occuper de la livraison en mode SCRUM, sans vouloir offrir la solution en cours de développement aux utilisateurs finaux. Résultats: beaucoup de demandes de changement à la fin du projet et une gestion du changement difficile, car les utilisateurs se sont sentis moins impliqués. Bien que les Product Owners tentent de penser à tout, il est inévitable que les utilisateurs finaux fassent des demandes d’ajustement ou d’ajout de fonctionnalité, et ce afin de pouvoir utiliser le produit de façon optimale.

Les PO proxy

Il arrive que certaines lignes d’affaires choisissent de remplacer ponctuellement le PO par une sorte de “bras droit”, le PO proxy. Cette stratégie, souvent employée par des PO trop occupés, ne fonctionne que si la ou les personnes désignées ont le pouvoir décisionnel sur l’ordonnancement du backlog de produit. Trop souvent les PO proxy n’ont pas le “pouvoir” politique pour prendre les décisions. Il en résulte en une perte de temps tant pour les lignes d’affaires que pour les équipes de développement.

Une approche pour les gouverner tous!

Une autre erreur qui, selon moi, est à éviter c’est d’imposer le cadre Scrum sans prendre en compte le contexte du projet ou la maturité de l’organisation avec l’agilité. Il faut se rappeler que SCRUM n’est pas une méthodologie à appliquer aveuglément. Il s’agit d’un cadre offrant des outils pour permettre de réduire le time to market et livrer de la valeur en continu. Cela peut paraître séduisant pour les entreprises, mais dans mon expérience lorsque le contexte le demande, il est important de pouvoir ajuster nos façons de faire pour permettre plus de flexibilité dans la livraison. Puisque des exemples valent mieux que des mots, on pourrait imaginer utiliser la méthode Kanban avec l’équipe d’infrastructure, bien souvent très occupée et en proie à gérer les urgences quotidiennes. Ou bien, on pourrait négocier habilement avec le Product Owner lorsque celui-ci tente de faire bouger le scope du sprint en cours.

La direction de l’innovation, des ambassadeurs de l’agilité ?

Plus récemment, j’ai vu apparaître sur le marché l’émergence des Directions/Départements de l’innovation. Ces départements, chargés d’identifier et d’apporter les avantages compétitifs de demain, doivent par nature être des ambassadeurs de l’agilité, meilleure garante de la livraison rapide de projets qui apportent de la valeur.

En effet, dans le contexte dans lequel nous évoluons aujourd’hui, il devient de plus en plus critique de réduire le time to market des solutions innovantes développées. Il devient alors évident que la chimie entre département TI et lignes d’affaires se doit d’être faite rapidement. L’application du manifeste agile est donc une solution, une réponse à ce besoin de rapidité de livraison, toujours basée sur la priorisation en continu de la valeur d’affaires.

J’ai eu la chance d’être impliqué sur des projets où la direction de l’innovation avait une très bonne écoute auprès de la haute direction. C’est un classique, lorsque que l’équipe de livraison a le support de la haute direction, combiné avec des idées novatrices et un time to market réduit au maximum, les solutions créent de la valeur!

Pour conclure

Lorsque les projets sont terminés, il faut communiquer les succès! Utilisons les Scrum Masters pour faire la promotion de ce mode de livraison. Jumelons-les avec les sponsors et les Product Owners des projets ayant eu du succès! Communiquons nos apprentissages, servons-nous de nos rétrospectives pour diffuser l’information à toute l’entreprise!

Ce n’est qu’à ce moment que nous parlerons d’agilité organisationnelle!



Alors, prêt à prendre le chemin de l’agilité ?