Traditionnel vs Agile : pourquoi changer ?

J’anime depuis un certain temps des sessions d’introduction à l’Agilité, dans lesquelles je me focalise tout particulièrement sur le « pourquoi » : pourquoi l’agilité ? pourquoi souhaitons-nous changer ? Pourquoi utilise t-on telle pratique ? Comparer ce que l’on appelle « Approche Traditionnelle » à « l’Approche Agile » est donc devenu un sujet récurrent, qui selon moi est essentiel à la bonne compréhension du changement occasionné.

C’est lorsque j’ai dû accompagner une collègue dans sa montée en compétence que j’ai décidé de revoir ma manière de faire. En effet, même si l’animation était majoritairement participative – grâce au questionnement – il n’en restait pas moins qu’une grande partie était descendante, surtout en début de formation. Je me suis alors demandé comment au travers d’un atelier, je pourrais faire émerger des participants toute l’information que je leur donnais sur un plateau auparavant.

Voici le résultat 🙂

Instructions

Après avoir formé des sous-groupes, j’indique aux participants qu’ils vont avoir une liste de mots, dans laquelle ils vont devoir, former des couples. Ces derniers devront opposer un mot correspondant à l’approche Traditionnelle et l’autre l’approche Agile.

Voici la liste de mots proposée :

• Prédictif
• Nous
• Apprentissage
• Plan
• Déploiement
• Incertitudes
• Compliqué
• Nous <-> Eux
• Valeur
• Empirique
• Certitudes
• Complexe

Note : J’invite la plupart du temps les participants à noter chaque mot sur un Post-it afin de pouvoir collaborer de manière plus efficace.

J’insiste sur le fait que ce qui importe est l’argumentaire justifiant le choix plutôt que la réponse elle-même; nous verrons ensemble pourquoi par la suite. Entre 10 et 15 mn sont généralement suffisantes pour avoir un résultat dans les équipes. L’idée n’est pas de rechercher la perfection, mais de permettre aux participants de réfléchir ensemble afin d’amorcer les discussions.

Débriefing

Le débriefing se déroule de manière informelle en parcourant les réponses des participants. Chaque équipe justifiera ses choix par rapport à sa compréhension des mots proposés.

Note : En effet, selon l’interprétation, un mot peut basculer d’un côté ou d’un autre (tout en restant tout à fait cohérent) ce qui génère des échanges particulièrement intéressants ! 😉

Je vous partage ci-après mes réponses ainsi que mes éléments de justification sous la forme : (T) Approche Traditionnelle vs (A) Approche Agile.

Je vous donnerais également les arguments exposés par les participants (P) lorsque leurs résultats ne concordaient pas avec les miens ! Vous verrez que nous sommes bien d’accord sur le fond, c’est simplement notre positionnement qui est différent : alors que je me place la plupart du temps en entrée, eux peuvent se placer en sortie ! 🙂

Prédictive vs Empirique

(T) Prédictive pour Approche prédictive

L’approche Traditionnelle est basée sur de la prédiction. On fournit d’ailleurs un certain d’effort pour la rendre la plus précise possible : l’exemple le plus flagrant est le fameux diagramme de Gantt que l’on met des semaines voire des mois à construire et qui s’avère être faux dès les premiers jours de mise en oeuvre.

(A) Empirique pour Approche empirique

L’approche Agile est basée sur de l’expérimentation. Comme dans la démarche scientifique, on part d’hypothèses que l’on va vérifier au fur et à mesure afin d’accumuler des informations fiables provenant du terrain.

Déploiement vs Apprentissage

(T) Déploiement pour Déploiement de méthodes

Le principe de déploiement de méthodes part du principe que si cela marche dans une équipe, le fait de faire la même chose dans une autre produira également le même résultat. On parle d’ailleurs très souvent du « déploiement de l’agilité » dans les entreprises, comme si c’était une simple méthode générique à appliquer et à répliquer dans les équipes, ce qui s’avère être bien plus difficile sur le terrain.

En effet, ce qui pourrait être potentiellement applicable partout est l’ensemble de valeurs et principes décrits dans le Manifeste Agile. Maintenant, cela ne suffit pas car chaque contexte est différent, avec des contraintes et des enjeux spécifiques : le travail des coachs agiles est selon moi essentiellement un travail de contextualisation.

L’approche Agile est donc à la fois générique dans l’esprit et spécifique dans la pratique.

(A) Apprentissage pour Stratégie d’apprentissage

La mise en oeuvre d’expérimentations nécessite de définir une stratégie pour valider nos hypothèses. Ainsi, passer d’une hypothèse conditionnée (quelque chose que l’on suppose) à une information vérifiée (quelque chose que l’on sait) est un apprentissage !

Partir sur des hypothèses implique également que l’on accepte de se tromper : le droit à l’erreur est donc fondamental !

(P) Arguments participants

Le terme Déploiement peut être associé à la notion de Déploiement continu chère au DevOps et à l’Agilité en général. Le fait de déployer en continu permet d’avoir un résultat concret, disponible aux utilisateurs, sur lequel vérifier ses hypothèses rapidement ce qui est typiquement ce que l’on souhaite faire en Agile.

Le terme Apprentissage est parfois décrit comme l’ensemble des apprentissages (statiques) que l’on a acquis par le passé et qui nous enferment dans un modèle de pensée prédictif.

Certitudes vs Incertitudes

(T) Certitudes pour Gestion de certitudes

L’approche Traditionnelle étant prédictive suppose qu’elle peut savoir tout ce qu’il va se passer. Elle part donc d’un ensemble de certitudes qu’il n’y a qu’à mettre en oeuvre. Il suffit donc simplement de déployer les actions nécessaires pour aboutir au résultat.

Si l’on prend l’exemple de projets logiciels, il paraît aujourd’hui très difficile de pouvoir penser à tout, surtout lorsqu’un grand nombre d’éléments sont interconnectés et interdépendants les uns avec les autres. Ainsi, malgré cette impression de certitude, on ne fait qu’accumuler de l’incertitude, augmentant dans le même temps le risque, jusqu’à la livraison finale.

(A) Incertitudes pour Gestion d’incertitudes

L’approche Agile part du postulat que l’on ne sait pas tout et que ce que l’on croit savoir n’est qu’hypothèse. En acceptant l’incertitude, on met en place des expérimentations pour apprendre et pour accumuler des informations validées qui deviendront nos certitudes du moment. On réduit alors la probabilité de mauvaises surprises et leurs impacts si néanmoins ils ont lieu.

(P) Arguments participants

En Agile, on met en place des expérimentations afin d’accumuler des certitudes. L’objectif est donc de gérer des certitudes pour limiter les risques et ainsi augmenter nos chances de toucher la bonne cible au bon moment.

En Traditionnel, on croit gérer des certitudes mais qui ne sont en fait que des incertitudes. On gère donc une quantité d’incertitudes qui à un moment ou à un autre risquent de mettre en péril le projet.

Nous <-> Eux vs Nous

Pour comprendre le changement de modèle de pensée amené par l’Agilité, il faut comprendre d’où l’on part. Je décris alors l’approche Traditionnelle au travers du modèle en Cascade puis du Cycle en V, pas toujours connus des participants.

(T) Nous <-> Eux : Responsabilité locale

Le modèle en Cascade est issu du monde du bâtiment où l’on ne construit pas la toiture avant les fondations. Il se caractérise par des étapes longues, effectuées de manière séquentielle et par des équipes le plus souvent spécialisées. Le problème fondamental réside dans le manque de réactivité de l’approche lorsqu’il y a un changement ou un problème car il doit repasser par l’ensemble des étapes à nouveau.

Pour réduire l’impact de ce problème dans le monde de l’informatique – où il est possible de construire la toiture avant les fondations – a été mis en place le cycle en V où les étapes de la phase montante sont mises en regard des étapes de la phase descendantes par des rétro-actions plus rapides.

Cependant, il a bien hérité des mêmes caractéristiques que le modèle en cascade : étapes longues, séquentielles et équipes spécialisées. Le problème qui se pose est que la phase de développement peut démarrer quelques mois après les phases amont de spécification ce qui fait que les personnes sachantes peuvent déjà s’être engagées sur d’autres projets ou peuvent simplement être parties.

Il n’y a donc pas le choix : il faut écrire de manière exhaustive tout ce que l’on sait pour s’assurer que les informations seront bien transmises dans les phases suivantes ! Un peu de compassion pour la documentation donc, c’est un effet induit par le cycle en V ! 😉

Maintenant, que se passe t’il lorsqu’un problème est détecté, en phase de Test par exemple ? Que peuvent dire les testeurs des phases amont ? Et les autres ?

• « C’est la faute aux développeurs, ils ont fourni un code de mauvaise qualité !« 
• « C’est la faute aux spécifieurs, la documentation est imprécise !« 
• « C’est la faute au client, il ne sait pas ce qu’il veut !« 

C’est la recherche du coupable : chacun est ou se sent uniquement responsable d’une phase spécifique du projet plutôt que de ce qui sera produit dans son ensemble. Il y a donc un « Nous », et un « Eux » ! 😛

(A) Nous : Responsabilité globale

En approche Agile, nous appartenons à la même équipe, nous sommes focalisés sur le même objectif commun. Même si l’on peut avoir des spécialités et/ou des compétences spécifiques, notre effort est continu jusqu’à la fin du projet. En effet, s’il y a un problème, c’est celui de l’équipe en son intégralité et chacun est susceptible d’y apporter un élément de solution.

La responsabilité est donc commune et partagée entre tous les membres de l’équipe ce qui peut contribuer à avoir des interactions de meilleures qualités :

• plus de confiance car on sait que l’on peut compter les uns sur les autres,
• plus de collaboration car on sait que l’on va tous dans la même direction,
• plus d’engagement car on sera ensemble du début jusqu’à la fin.

(P) Arguments participants

Dans l’interprétation du Nous <-> Eux, de par la présence des flèches à double sens, on peut considérer que les échanges vont bien à l’extérieur de notre silo. On est alors plus à l’écoute des autres parties afin de pouvoir atteindre notre objectif commun, ce qui est plutôt Agile.

Dans l’interprétation du Nous, on peut croire que le focus reste en local, « chez nous », plutôt que de s’ouvrir vers l’extérieur et partager nos contraintes et problématiques avec les autres. Cela ressemble alors plus à du Traditionnel.

Plan vs Valeur

Pour expliquer cette partie, je passe par la notion du Triangle de Fer, une autre version du triangle (Qualité, Coût, Délai). Il se caractérise par 2 types de critères : fixes et variables (ou estimés).

(T) Plan pour Pilotage par le plan

En approche Traditionnelle, le contenu demandé est fixe (« Je veux tout ça !« ). Les personnes (Charge) et le temps (Calendrier) agiront alors en variables d’ajustement : on rajoute des gens et/ou on déplace la date pour pouvoir délivrer l’ensemble du contenu.

Cependant, il arrive parfois que tous ces paramètres soient fixes : « Je veux tout ce que j’ai demandé, à la date donnée, avec les personnes prévues« . Et comme on sait que les projets ne se passent pas souvent comme prévu, il nous faut malgré tout jouer sur une variable pour être en mesure de répondre à la demande. C’est souvent la qualité qui devient alors variable d’ajustement : « Réduisons les tests pour livrer à la bonne date, au pire ça reviendra« 

L’importance est donc mise sur la date, au détriment de la qualité de ce qui est produit : on parle de pilotage par le plan.

(A) Valeur pour Pilotage par la valeur

Fort du constat précédent, on comprend pourquoi les projets pouvaient avoir tendance à dépasser leur budget et à livrer du contenu qui ne sera pas forcément utilisé (cf. Chaos Report 1995).

Il est alors intéressant d’observer que les critères que l’on laisse varier sont ceux sur lesquels on a le moins le contrôle : les personnes peuvent ne pas être compétentes individuellement ou collectivement, elles peuvent tomber malades… ce qui impactera naturellement le temps de livraison du contenu attendu.

De manière pragmatique, comment rendre prévisible une variable imprévisible ? En la fixant ! On renverse alors le triangle en fixant la charge et le calendrier : « on a ce nombre de personnes et ce délai ». Et sur quel critère avions-nous le contrôle depuis le début ? Le contenu ! On peut alors se permettre de le laisser varier en optimisant la valeur de ce qui sera produit : on parle ici de pilotage par la valeur.

En approche Agile, on part sur un postulat de base : la qualité est non négociable. Ainsi, on préfère livrer moins (en quantité) mais livrer bien (en qualité) !

Compliqué vs Complexe

Cette partie est généralement celle qui clôture l’atelier. En effet, ellemérite quelques explications surtout dans la terminologie utilisée : les termes « compliqué » et « complexe » sont parfois utilisés de manière interchangeable ou ont un sens un petit peu différent selon les personnes. Il est néanmoins intéressant de voir que le terme « compliqué » tend à avoir une connotation négative à la différence du terme « complexe« .

L’objectif de cette partie est principalement de décrire là où l’approche Agile fait le plus de sens, d’ouvrir le champ de perspectives des participants en leur montrant qu’il existe différents domaines, chacun avec leurs caractéristiques propres.

Pour poser une base commune de compréhension, je passe par un modèle appelé le Framework Cynefin – sur lequel j’avais déjà écrit une série d’articles :

Ce modèle est particulièrement puissant car pour chaque domaine, il décrit le modèle de prise de décision recommandé. Je ne rentrerais pas dans l’intégralité de la description (si cela vous intéresse, je vous invite à aller lire cet article) mais expliciterait simplement les messages principaux. Nous verrons que cela reprend de manière cohérente l’ensemble des caractéristiques vues précédemment.

Note : D’autres collègues préfèrent passer par la Matrice de Stacey pour décrire les notions de « complexe » et « compliqué ».

(T) Compliqué

Le domaine Compliqué fait partie de la famille des systèmes ordonnés, c’est-à-dire que l’on sait qu’un lien causal existe entre un déclencheur et son résultat, un besoin et une solution. La grande différence avec le domaine Évident est que ce lien n’est justement pas directement visible, il nous faut donc du temps pour analyser la situation pour le déterminer : d’où le modèle de prise de décision décrit comme Sentir – Analyser – Répondre.

Le postulat qu’un lien causal existe, que l’on peut donc tout contrôler, correspond typiquement à l’approche traditionnelle dans son caractère prédictif, de gestion de certitudes et de déploiement de solutions. En effet, dans ce domaine, on fournit un grand effort pour analyser la situation afin de pouvoir décrire le déroulement idéal de notre projet : cela explique donc les grandes planifications en amont.

Compliqué signifie étymologiquement « lié ensemble », « composé de plusieurs choses ». Un système compliqué est donc un système que l’on peut démonter et remonter dans son état initial.

(A) Complexe

Le domaine Complexe fait partie de la famille des systèmes non-ordonnés, c’est-à-dire qu’il n’y a pas de lien causal entre un déclencheur et son résultat, un besoin et une solution. Si un événement se reproduit, cela peut être considéré comme une coincidence. C’est donc le domaine du Test and Learn et de l’expérimentation d’où le modèle de prise de décision décrit comme Sonder (on met en oeuvre une expérimentation)- Sentir (on observe ce qu’il se passe)- Répondre (on réagit selon la concordance des résultats avec nos hypothèses).

L’approche Agile est donc toute désignée pour des problématiques du domaine complexe de par son caractère empirique, de gestion d’incertitudes et d’apprentissage : cela explique d’ailleurs les composantes itératives et incrémentales de ce type de démarche.

Complexe signifie étymologiquement « entrelacé », « entremêlé ». Un système complexe est donc un système qu’il est « impossible » de reproduire à l’original de par la multiplicité des interactions qui le composent.

Mais alors, Scrum se trouve dans le domaine complexe ?

Eh bien pas tout à fait ! Analysons un petit peu ce qu’il se passe dans un processus Scrum :

• Sprint planning : j’émets une hypothèse sur ce qui a le plus de valeur pour mon prochain Sprint, mon point de départ est donc bien dans le domaine complexe.
• Daily Scrum : chaque jour, je prends une décision sur ce que je vais réaliser dans la journée par rapport à mon apprentissage de la veille, je reste donc dans le domaine complexe.
• Sprint review : je récupère mon incrément de produit potentiellement livrable, je l’analyse avec l’ensemble des parties prenantes afin de déterminer ce qui sera la prochaine priorité, autrement dit la prochaine hypothèse. Je viens donc de basculer dans le compliqué.
• Sprint retrospective : je me base sur les données objectives (résultats) et subjectives (ressentis) issues du Sprint, j’analyse la situation et décide des actions d’amélioration à mettre en oeuvre avec mon équipe. Je suis bien dans le domaine du compliqué.

Scrum est donc un mécanisme de transition Complexe-Compliqué, décrite comme une des cadences Cynefin. C’est pourquoi on dit souvent que ce qui est important dans Scrum n’est pas la synchronisation mais plutôt le rythme !

L’approche Agile apporte donc une notion de dynamisme permanent à la différence de l’approche traditionnelle qui est beaucoup plus statique intrinsèquement. Peut-être un nouveau couple de mots à tester ? 😉

Conclusion

Cet atelier m’a permis de pouvoir donner la main aux participants dans la construction d’un contenu qui venait d’eux, tout en y injectant de la théorie au fur et à mesure des échanges. Une participante me disait que pour cette activité, je partais du postulat qu’ils ne partaient pas de 0 et je pense que c’est fondamentalement vrai. On entend le terme agile un peu partout aujourd’hui et on lui donne également la signification que l’on veut. L’idée est donc plutôt de s’aligner sur ce dont on parle plutôt que d’imposer une vision statique sur le sujet en laissant place à l’échange constructif et argumenté.

Suite à cet atelier, j’espère que les participants comprendront qu’il y a bien une différence fondamentale dans les modèles de pensée entre l’approche Traditionnelle et l’approche Agile, d’où la difficulté du changement dans les organisations.