Accueil > Méthodes Agiles > La stratégie Agile : comment en tirer réellement parti ?

La stratégie Agile : comment en tirer réellement parti ?

De nos jours, l’agilité est devenue très à la mode dans les services informatiques. Ce succès est porté notamment par les bénéfices tangibles qu’elle apporte aux entreprises :

  • plus de pertinence et des livraisons plus rapides côté produit ;
  • moins de lourdeurs et des équipes motivées et épanouies du côté organisation.

Son adoption se déroule souvent de la même manière, que ça soit via l’impulsion d’un sponsor, d’un manager ou d’une équipe. On commence par choisir une méthode et on essaie de la mettre en pratique, plus ou moins bien et plus ou moins complètement. La méthode Scrum est souvent choisie du fait de sa popularité, mais aussi du fait de son apparente simplicité : quelques rôles, quelques cérémonies, un tableau de management visuel… et Hop !

Malheureusement derrière cette apparente simplicité se cache en fait des valeurs et des principes (ceux du manifeste Agile, mais aussi d’autres provenant du Lean) plus complexes à comprendre (ou en tout cas nécessitant une certaine rigueur) et souvent ignorés. Pire encore, cette incompréhension (ou ce manque de rigueur) peut aller jusqu’à faire échouer la démarche.

Voici donc quelques clés pour tirer réellement parti d’une démarche Agile, sans tomber dans les pièges d’une mise en pratique trop simpliste.

Comprendre l’Agilité en tant que stratégie

Si Scrum est bien cerné en tant que méthode (bien que ses créateurs en parlent plutôt comme d’un « framework » méthodologique) qu’en est-il de l’agilité ? Elle ne se place certainement pas sur le plan de la méthode (il n’y a d’ailleurs aucun guide d’application de l’agilité au sens large). On en parle souvent comme d’une « démarche », voir même une « philosophie ». Ça reste très abstrait. Nous pouvons en fait la voir comme une « stratégie », ce qui permet de structurer la façon dont on va appréhender ses composantes.

Stratégie Agile = processus de conduite de la décision

D’après Wikipedia, dans la théorie des jeux, une stratégie correspond à un mode de prise de décision. L’agilité peut s’apparenter à cela. C’est d’ailleurs assez proche de la façon dont est tourné le manifeste : « si on a le choix entre privilégier A ou B, alors c’est A qui doit l’emporter ».

L’agilité dans son ensemble peut être vue comme une articulation de valeurs, de principes, de méthodes, de pratiques et d’outils qui conduit à faciliter les prises de décisions. C’est bien là le nerf de la guerre (le mot stratégie a d’ailleurs une étymologie militaire) : arriver à prendre les meilleures décisions, le plus vite possible.

Les décisions stratégiques dont on parle ici concernent à la fois le produit et l’organisation. En effet, l’agilité tire parti des démarches itératives pour construire la connaissance sur le produit (en misant surtout sur le recueil et la prise en compte du feedback utilisateur), mais aussi sur l’organisation en elle-même (en misant cette fois sur l’amélioration continue).

La stratégie Agile vue à travers différents niveaux d’abstractions

Avant tout, il faut comprendre que tout part des valeurs, et que ce sont elles qui induisent au final les pratiques, pas l’inverse. Ainsi la stratégie Agile peut se représenter sous la forme d’une pyramide ayant à son sommet les valeurs :

Stratégie Agile

La stratégie Agile représentée via une pyramide allant des valeurs à son sommet jusqu’aux outils et pratiques à sa base

On peut analyser les relations entre chaque niveau de la pyramide de la façon suivante (attention, les termes sont décrits dans le contexte d’une stratégie Agile et peuvent avoir un sens différents dans d’autres contextes) :

Une valeur est un idéal, un critère assez abstrait, mais communément considéré comme nécessaire au succès de la stratégie. Par exemple : « Les personnes et leurs interactions prévalent sur les processus et les outils » (source : Manifeste Agile)

Un principe est une règle fondamentale considérée comme nécessaire pour atteindre une ou plusieurs valeurs, et donc réussir la stratégie. Par exemple : « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet » (source : Manifeste Agile)

Une méthode est un guide décrivant la façon d’utiliser un ensemble de pratiques et d’outils dans le but d’appliquer concrètement et efficacement certains principes. Par exemple : la méthode « Extreme Programming » (ou XP) explicite comment combiner différentes pratiques pour permettre d’appliquer efficacement entre autre le principe de collaboration entre les développeurs et le représentant des utilisateurs.

Les pratiques et les outils correspondent aux actions et aux moyens que l’on se donne concrètement pour organiser les opérations nécessaires pour réussir la stratégie. Ils sont souvent prescrits par des méthodes, mais peuvent aussi venir en complément pour renforcer des principes ou des valeurs. Par exemple : « Client sur site » et « Planning Poker » sont certaines des pratiques que l’Extreme Programming suggère de combiner, alors que « INVEST » est un outil mnémotechnique qui a été popularisé en dehors de toute méthode.

Les exemples décrits dans notre analyse, peuvent être illustrés via une instanciation de la pyramide vue précédemment :

Stratégie Agile : exemple

Exemple d’instanciation de la stratégie Agile

La stratégie Agile en action

Dans notre pyramide, les éléments les plus bas ont le mérite d’être très concrets et donc très facilement applicables. Il est logiquement tentant, quand on démarre une transformation Agile d’essayer de mettre directement en place certaines pratiques et certains outils.

Ce n’est pas un mauvaise chose en soit, mais il va arriver un moment ou les « bonnes » pratiques trouvées sur le Web ou prescrite par des méthodes ou des livres ne seront pas applicables directement. Il est parfois impossible par exemple de réunir sur le même site les développeurs et un représentant des utilisateurs. Comment faire alors ? C’est là que le système d’aide à la décision rentre en scène.

Escalader pour décider

Quand on n’arrive pas à mettre en place une pratique ou un outil, l’option répandue à tort consiste à l’abandonner purement et simplement. On considère qu’on peut s’en passer sans prendre plus de précautions. A force de faire cela on finit par prôner suivre telle méthode ou clamer « nous sommes agiles » alors qu’en réalité on a dénaturé totalement la stratégie Agile en perdant certains principes ou certaines valeurs essentielles. Il va sans dire que le succès de la démarche au final n’est pas garanti.

La bonne façon de faire consiste en fait à s’interroger sur le ou les principes de la stratégie Agile que la pratique ou l’outil qu’on abandonne est censé servir. Ainsi on « escalade » de la pratique au principe en quelque sorte. Un peu comme quand on appelle une assistance téléphonique et qu’on a un problème suffisamment grave pour « escalader » au niveau de support plus élevé. Quand le ou les principes correspondant sont identifiés, on est alors capable de chercher ou d’inventer d’autres pratiques ou d’autres outils pour arriver à le conserver quand même.

Si on reprend l’exemple du « client sur site », l’important n’est en fait pas vraiment que le client ou le commanditaire d’un produit soit physiquement présent auprès de l’équipe. L’important c’est que « Les utilisateurs ou leurs représentants et les développeurs travaille[ent] ensemble[s] quotidiennement tout au long du projet ». Pour répondre à ce principe on peut expérimenter tout un tas d’outils de communication et de collaboration, mettre en place des réunions quotidiennes en télé-présence, travailler la façon dont remonte le feedback des utilisateurs… Tout est valable, à partir du moment où le principe recherché (en l’occurrence une collaboration quotidienne entre les bonnes personnes) est atteint. Bien-sûr quand on sort des pratiques prescrites, trouver le bon remplaçant ne se fait pas du premier coup…

Pas de stratégie Agile sans amélioration continue

Au-delà de l’abandon pur et simple de certaines pratiques (ou outils), leur substitution hâtive par des dispositifs qui ne répondent pas aux principes sous-jacents est tout aussi dangereuse.

L’amélioration continue est l’un des principes fondamentaux de l’agilité. Il s’accompagne de sa méthode de prédilection, PDCA (aussi appelée la roue de Demming), qu’il est chaudement recommandé d’appliquer ; typiquement dans le cas où l’on cherche à remplacer des pratiques inapplicables ou inefficientes. Sans réexpliquer complétement la méthode, l’essentiel est de ne pas perdre de vue l’objectif à atteindre. Car même si l’on pense que tel super outil de collaboration en ligne va permettre de compenser l’absence de client sur site, encore faut-il poser clairement l’hypothèse, expérimenter et évaluer si cette fameuse collaboration quotidienne existe ou pas. Si c’est le cas on entérine, sinon il faudra itérer.

Cette démarche est résumée dans le schéma suivant :

Stratégie Agile : Exemple d'amélioration continue

Exemple d’amélioration continue dans le cadre de la stratégie Agile

On observe que dans une logique d’amélioration continue, on peut s’autoriser à « contourner » une méthode pour inventer ses propres pratiques et outils. C’est une mise en œuvre assez avancée de la stratégie Agile, mais qui peut s’avérer nécessaire étant donné la complexité de certaines organisations. L’idéal serait de les simplifier, par exemple en localisant les personnes qui doivent collaborer au même endroit, mais si ça n’est pas faisable rapidement et facilement ce genre de tactique peut permettre de compenser certaines lacunes et avancer quand même dans la bonne direction.

Une stratégie difficile à maîtriser

Une transformation Agile n’est jamais évidente tant elle s’éloigne des réflexes culturels de ceux qui sont soumis à ce changement. Les théories autour de la conduite du changement nous apprennent que les personnes qui doivent s’approprier de nouvelles façons de faire ont tendance à résister, même inconsciemment, par exemple en appliquant le jargon lié à la nouvelle façon de faire sur les pratiques auxquelles ils sont déjà habitués. Ainsi ils ne changent pas vraiment, ils ne font que se donner l’illusion de le faire. Cela ne veut pas dire que la transformation ne s’opère pas, mais elle prend simplement beaucoup de temps et devient difficile à évaluer.

L’approche orientale : Shu Ha Ri

Une approche pour accompagner les transformations telles que le passage à l’Agile consiste à s’inspirer d’une techniques appelée « Shu Ha Ri » utilisées dans le domaine des arts martiaux japonais.

Sans re-décrire cette approche, ni l’a façon de l’appliquer à l’agilité (il existe
déjà de nombreux articles sur le sujet), il faut noter qu’elle mise au départ sur la mise en œuvre des aspects concrets de la stratégie (méthodes, pratiques et outils) sans chercher à ce que les personnes impliquées dans la transformation comprennent la théorie sous-jacentes (les valeurs et les principes en haut de la pyramide). Le but est de leur permettre d’acquérir des réflexes et de constater des premiers succès. Cela leur conférera l’aisance et la confiance nécessaire pour aller plus loin. Elles finiront ainsi par comprendre d’elle mêmes les principes et valeurs, mais plus tard, au fur et à mesure de leur pratique.

Shu Ha Ri

Les trois stades du Shu Ha Ri

Bien-sûr cette approche nécessite l’accompagnement d’une personne expérimentée, qu’on appelle en général un « Coach Agile ».  Maîtrisant la stratégie, il va pouvoir enseigner les bonnes pratiques, mais aussi servir de « garde-fou ». En effet, il évitera aux personnes de faire des erreurs trop importantes, du fait de leur manque d’expérience ou de connaissance théorique. Le Shu Ha Ri a le mérite de donner des résultats très rapidement (du moins en apparence), mais nécessite aussi un accompagnement sur la durée. S’il est interrompu trop tôt on risque de livrer à elles-mêmes des équipes et des personnes qui ne sont pas encore autonomes. Elle ne sauront pas encore s’adapter à de futurs changements, avec toutes les conséquences néfastes imaginables.

L’approche occidentale : l’Agile académy

Autant Shu Ha Ri est une approche tout à fait naturelle dans la culture orientale, autant elle peut sembler exotique dans les pays occidentaux. En fonction des besoins, du contexte et des personnes soumis à la transformation, on peut vouloir adopter une approche plus académique.

Cette seconde approche, appelons-la l’Agile « academy » (aucun rapport avec une organisation existante), consiste à mettre en place un cursus de formation et d’accompagnement visant à inculquer la théorie avant la pratique. Contrairement au Shu Ha Ri qui n’aborde les principes et les valeurs qu’une fois les pratiques maitrisées, on navigue ici sur l’ensemble de la pyramide évoquée au début de cet article. Ainsi, chaque pratique mise en place est mûrement étudiée au regard des principes à mettre en œuvre.

Approche académique

L’approche académique

L’Agile academy est plus rassurant dans une culture où l’on souhaite conserver un sentiment de maîtrise. Il peut d’ailleurs plus facilement séduire les managers soucieux (et ils ont raison !) de comprendre la stratégie dans son ensemble pour en apprécier l’intérêt avant de l’appliquer. Mais même dans ce cas de figure, les managers qui s’approprient les principes agiles pêchent souvent par excès de confiance en soi et finissent par jouer aux apprentis sorciers, par exemple en prescrivant des pratiques qu’ils maîtrisent mal ou qui ne se prêtent pas au contexte. L’intervention d’un coach agile peut s’avérer là encore salutaire pour pousser à la réflexion et permettre à tous les acteurs de remettre en question les soi-disant bonnes pratiques.

Mélanger les approches

Finalement, les deux modes d’adoption de l’agilité ne sont pas nécessairement incompatibles au sein d’une organisation. Shu Ha Ri est plutôt une approche bottom-up : la hiérarchie déduit les principes qui fonctionnent au travers de l’observation des pratiques des opérationnels, alors que l’Agile Academy est plutôt une approche top-down : les pratiques opérationnelles sont déduites des principes que l’on décide de mettre en place. De ce fait, l’adoption peut se faire en mode Shu Ha Ri avec l’équipe de réalisation qui expérimente tout de suite la mise en œuvre d’une méthode comme Scrum ou Extreme Programming pendant que le management travail sur la compréhension des principes et la mise en place d’indicateurs. Les deux modes vont évidemment interagir, car ils se complètent.

Maillage des approches de transformation Agile

Les différentes approches de transformation Agile s’entremêlent et se complètent

A l’inverse, on sait bien aujourd’hui qu’une équipe ne peut pas mettre en place l’agilité sans avoir le soutien de sa hiérarchie et que l’adoption des méthodes agiles ne prend réellement que lorsque les opérationnels commencent à en observer les bénéfices concrets.

Trouver la bonne recette… avec un bon cuisinier…

Une transformation Agile est donc une cuisine assez complexe dans laquelle il faut savoir mettre les bons ingrédients, au bon moment. C’est-à-dire agir sur les différents niveaux de l’organisation, avec le bon timing et de la bonne manière. Même si on connaît quelques exceptions, ce type de changement nécessite l’accompagnement d’un coach agile qui aura l’expérience, le recul et la liberté suffisante pour créer les conditions d’une adoption réussie. Les coachs eux-mêmes ayant une multitude de façons de faire issues de leurs propres sensibilités, de leur vécu, etc.

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


× trois = 21