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.
4 rรฉponses
Hello Olivier,
Merci beaucoup pour ce partage. Je souhaiterais mโen inspirer pour une sensibilisation ร lโAgilitรฉ, si tu en es dโaccord?
Hello Sylvia, avec plaisir ! Nโhรฉsite pas ร me faire un feedback aprรจs coup ! ๐
Coucou Olivier,
รงa marche, merci!
Je lโanime cet aprรจs midi.
Je lui ai trouvรฉ un petit nom ยป Agile Wor(l)d ยป ๐
Trรจs bons retours ๐
Propice ร la discussion, sans mรชme chercher ร forcรฉment donner ยซ la ยป correction. Lโimportant cโest lโargumentaire associรฉ.
Jโavais 2 groupes, jโai donnรฉ un ensemble de couples de mots sur un groupe, diffรฉrent de lโensemble de lโautre groupe (6 couples chacun) et un 7ieme couple dont jโai mis un membre dans un groupe et un membre dans lโautre. :-p
A renouveler, merci pour lโinspiration ! ๐