Il y a 9 ans -
Temps de lecture 5 minutes
Le Beer Game, ou petit retour sur l’impact systémique des approches agiles (Episode 3)
Dans le premier article de cette série, Le Beer Game, ou petit retour sur l’impact systémique des approches agiles (Episode 1), nous avons fait quelques rappels sur les origines du Beer Game, sur l’approche systémique, puis nous avons décrit le jeu.
Dans le deuxième article, Le Beer Game, ou petit retour sur l’impact systémique des approches agiles (Episode 2) nous avons décrypté ce qui se passe durant le jeu et expliqué les dynamiques limitantes que celui-ci rend visible.
Ce dernier article explique en quoi les approches agiles enlèvent les composantes bloquantes des systèmes organisationnels, améliorant ainsi leur efficacité et leur performance.
Comment les approches agiles résolvent-elles les problèmes systémiques révélés par le jeu ?
Les approches agiles travaillent par essence sur le système lui-même en s’attaquant directement aux origines des dysfonctionnements, et donc ici, à son organisation. Pour cela, elles mettent en place :
- des cycles courts
- une communication simplifiée et efficace
- la réduction du nombre d’étapes (et donc d’équipes)
- une vue du système dans sa globalité
Des cycles courts
Utiliser des user stories
En privilégiant la construction juste-à-temps de user stories plutôt que de créer de grosses documentations, le circuit de feedback est plus rapide. Les questions trouvent une réponse plus rapidement car l’information est encore fraiche dans les têtes. Les défauts dans la description des fonctionnalités sont identifiés plus tôt, et peut être corrigé et pris en compte dans l’écriture des user stories suivantes.
Prioriser par valeur business et risques
En priorisant les user stories par valeur business et risques (techniques et autres), les hypothèses les plus importantes du projet sont mises à l’épreuve dès les premières livraisons. Elles peuvent ainsi être validées ou remises en question beaucoup plus en amont, ce qui permet de corriger à ses débuts une trajectoire potentiellement hasardeuse.
Un produit fonctionnel à chaque cycle, sur des cycles rapprochés
En faisant la démonstration d’un produit fonctionnel à la fin de chaque itération de développement, longue de deux à quatre semaines maximum, le client peut faire des retours plus rapidement sur du concret. Il peut revoir ses décisions et ses priorisations.
Une communication simplifiée et efficace
Proximité géographique et équipes co-localisées
Rien de plus efficace qu’une communication face à face, sans outil intermédiaire qui pollue la communication. La co-localisation permet d’avoir des discussions impromptues, l’obtention souvent immédiate de l’information.
Les user stories comme véhicule de la communication
Plus qu’une documentation, le format et la taille des user stories permettent d’en faire un outil d’échange et de conversation. Celles-ci contiendront les informations vitales permettant leur développement.
Une communication visuelle
La mise en place de tableaux visuels, dont un simple « Backlog » | « A faire » | « En cours » | « Fait », permet à toute l’équipe, ainsi qu’aux contributeurs externes, de voir en un clin d’oeil l’état d’avancement du projet.
Des réunions journalières efficaces
Les « daily meeting », lorsqu’ils sont bien tenus, permettent d’échanger le minimum vital d’informations sur l’état du projet et de déceler les problèmes au plus tôt.
La réduction du nombre d’étapes (et donc d’équipes)
Une équipe polyvalente, avec le plus de compétences possibles
Les approches agiles comme scrum (pour ne citer qu’elle) privilégient la polyvalence dans les équipes, réduisant le nombre de passages de bâton d’une équipe à l’autre pour produire un résultat. Ainsi, il y a moins d’étapes nécessaires pour obtenir quelque chose et donc moins de complexité à gérer.
Il s’agit également d’éviter les silos créés par les centres de compétences.
A noter que la réduction du nombre d’étapes et de la taille des équipes permettent de simplifier la communication (deuxième point), et de la rendre plus rapide, permettant de raccourcir les cycles (premier point).
Une vue du système dans sa globalité
Un management visuel
Avoir un tableau visuel regroupant les informations principales permet d’avoir une vue globale du projet et de son état. En prenant de la hauteur, on peut ainsi voir le comportement du système dans son ensemble et ainsi déceler les parties qui vont l’empêcher de fonctionner de manière optimale. La simplification engagée par les points précédents permet de réduire le nombre d’information à suivre et donc de faciliter sa représentation.
Conclusion
Le jeu permet à ses participants d’observer, par l’expérience directe, les effets pervers d’un système mal organisé.
Il montre que, bien que le comportement des individus ait un impact négatif sur les résultats du système, c’est le système même qui induit ces comportements peu serviables. C’est lui qui est donc la cause principale des échecs, quelles que soient les compétences et la bonne volonté des parties prenantes.
Se concentrer sur la correction des effets induits par le système en tentant de s’adapter ses contraintes n’a qu’un impact superficiel pour un fort investissement. C’est cependant, et malheureusement, la réponse le plus souvent faite face aux problèmes dans le context d’environnements complexes. La cinématique se résume ainsi : face à la complexité, plus de contrôle => plus de lourdeur => moins de flexibilité => moins de capacité d’adaptation => plus de fragilité face aux aléas => des projets qui peinent à aboutir ou qui n’aboutissent pas.
Changer le système devient plus efficace que d’essayer de s’y adapter. C’est souvent la seule solution viable.
C’est ce que font les approches agiles en s’attaquant aux origines profondes des dysfonctionnements du système. Elles augmentent ainsi les chances de succès des projets.
Commentaire
17 réponses pour " Le Beer Game, ou petit retour sur l’impact systémique des approches agiles (Episode 3) "
Published by Anas , Il y a 9 ans
Papier très instructif qui explique bien comment l’approche agile résout le problème systémique mis en évidence par le jeux.
Si l’approche et pertinente pour les applications front-office, aux frontières du SI, où les besoins ne cessent d’évoluer, elle ne l’est pas au niveau applications back-office, au cœur du SI, là où le besoin évolue peu.
Pour les gros SI, on constate deux cycles: un cycle court cotés applications front-office, et un cycle long coté cœur SI (back-office et référentiels).
La problématique qui se pose pour les gros SI et qui se posera pour les SI en voix de développement est celle de mettre en cohérence les deux cycles.
Published by Laurent Valdes , Il y a 9 ans
Bonjour Anas, tout le dilemne est là.
Une application front office peux évoluer trés vite, parfois même trop vite, avec le risque que le code devienne rapidement non-maintenable.
Toutefois, de mon expérience professionnelle, et pour avoir développé plusieurs années sur des briques faisant partie intégrante du SI de mon entreprise, l’approche agile était indispensable afin de pouvoir délivrer de la valeur d’une manière régulière.
D’ailleurs, les briques frontend bien architecturées doivent s’appuyer sur un SI de qualité. Je te prie par exemple de t’intéresser aux approches microservices, et aux styles d’intégration de type messaging, qui permettent d’apporter l’agilité jusqu’au frontières de ton système d’information, de la spécification à la livraison.
Voci un style d’intégration d’applications SI qui te permettra de le faire:
http://www.informit.com/articles/article.aspx?p=169483&seqNum=5
Au plaisir de te relire.
Published by Nicolas , Il y a 9 ans
@Anas
Je comprends la réflexion qui oppose les cycles traditionnellement longs d’évolution du back office à ceux réputés plus courts du front.
Au-delà du fait qu’il faudrait questionner la raison de ces cycles long côté back, qui me semblent plus relever d’un héritage et d’une complexité à faire évoluer les systèmes, que d’un besoin qui change peu; je pense qu’il faut faire attention à ne pas réduire l’agilité à un moyen de réduire les cycles de mise en production.
L’agilité sert bien d’autres causes, comme notamment la bonne adéquation du développement au besoin exprimé ou la qualité du développement (à travers des boucles de feedback courtes aussi bien sur le développement que les tests). De ce point de vue, il ne me semble pas y avoir de différence entre Front et Back Office.
Enfin il ne faut pas perdre de vue que le Front et le Back Office sont amenés à se répondre l’un à l’autre. De ce fait on observe souvent un besoin des équipes Front (ayant mis en place une approche Agile) à plus de réactivité des équipes Back sur lesquelles elles s’appuient.
Ces équipes Back bénéficieraient ainsi à disposer de méthodes leur permettant de réduire leurs cycles de mise en production.
Pour l’anecdote, j’accompagne d’ailleurs actuellement une équipe de développement Back Office dans la mise en place d’une approche Agile et cela se passe très bien!
Published by yannick grenzinger , Il y a 9 ans
J’aimerais comprendre comment on peut avoir des applications côté utilisateurs dont les besoins ne cessent d’évoluer et un « back » qui n’évoluent que peu.
Pour moi, c’est le signe que le SI côté « back » ne répond pas au besoin des utilisateurs.
Published by Anas , Il y a 9 ans
@Laurent
Effectivement le style d’intégration orienté événement permet plus d’agilité, mais malheureusement ne résout pas le problème de cohérence des cycles (rex de plusieurs années et projets d’intégration/médiation et d’analyses d’architecture d’entreprise). Ce problème relève de la gouvernance du SI. L’approche agile est plutôt adaptée à la construction de cibles déjà pré-définies au niveau gouvernance du SI (coté DSI et architecture d’entreprise).
@Nicolas
J’ai déjà vécu des cas coté back-office où l’on a mis en place avec succès un services dans un contexte agile (tous les intégrateurs ont une offre agilité aujourd’hui), mais celui-ci s’est révélé finalement inadapté au besoins. La méthode la plus agile qui soit ne résout pas le problème de la pertinence de la cible. En revanche elle permet d’avancer à petit pas ce qui limité les pertes en cas de retour en arrière.
Published by Anas , Il y a 9 ans
@yannick
Tout est dans ce que l’on entend par « besoins utilisateur » qui ne veut pas dire la même chose selon le point de vue.
Les métier ont tendance à confondre solutions et besoins. Comme ils on pris l’habitude d’exprimer leur besoins à travers des écrans et des cinématiques d’écran (alias « story borad » ou « user story »), ils empiètent dans la solution, qui elle, ne peut pas faire plus que ce que le back-office lui permet de faire. Cela aboutit à cette situation où les métier « rêvent » ou « fument de la moquette » (… des termes d’usage coté AMOA et AMOE pour exprimer l’infaisabilité de certains besoins par rapport au limites imposées par le back-office).
A ce titre les méthode agiles devraient s’organiser pour définir des « user story » sous forme d’objectifs plutôt que sous forme de cinématique d’écrans qui sont en réalité déjà des solutions. Le meilleur exemple est celui d’un SI implémenté par un ERP où les « user story » ne peuvent pas être définies selon le bon vouloir du métier qui doit uniquement définir les objectif de sa « story » … autrement dit une « story end » plutôt qu’une « user story ». Bien qu’il soit à moindre mesure, le problème reste le même pour des SI qui ne sont pas aussi rigides qu’un ERP.
Published by Emmanuel Sciara , Il y a 9 ans
@Anas
« ils empiètent dans la solution, qui elle, ne peut pas faire plus que ce que le back-office lui permet de faire. » [..] « (des termes d’usage coté AMOA et AMOE pour exprimer l’infaisabilité de certains besoins par rapport au limites imposées par le back-office) »
Le problème n’est-il alors pas que le back-office ne répond simplement pas au besoin du client, plutôt que ce soit le client qui « rêve » ou « fûme de la moquette » ? Tel que tu l’expliques ici, c’est la solution qui décrit le besoin… Et là, c’est le monde à l’envers.
Une solution est censée répondre à un besoin. Si elle ne le fait pas (ici backoffice fini par dicté ce qui est faisable ou pas), alors, c’est la solution qui n’est pas bonne. Parce que c’est alors l’homme qui est au service de la machine et non la machine au service de l’homme. (d’où monde à l’envers)
Le système qui impose des limites qu’il n’est pas censé imposé. L’agilité s’attaque justement au système pour qu’il soit adaptable et qu’il finisse par répondre au besoin du client… Et pas l’inverse.
Published by Anas , Il y a 9 ans
@Emmanuel
ça c’est la théorie … qui marche quand on n’hérite pas d’un SI patrimonial, quand on démarre à zéro ou qu’on soit dans un contexte de refonte complète avec les ressources qui vont avec.
Mais la réalité est souvent différente et similaire à celle d’une ville comme Paris dont beaucoup de cartiers mériteraient d’être réaménagés pour répondre aux besoins des parisiens et des millions de visiteurs quotidiens. Mais bien que les nouveau besoins existent et soient pressants, l’architecture vieillotte de certains quartier impose ses contraintes. A moins d’un plan Marshall de refonte de ces quartiers, tous le monde est bien obligé de s’y faire malgré tout.
« […] c’est la solution qui décrit le besoin… Et là, c’est le monde à l’envers[…] »
Je serais moins binaire que ça et dirait plutôt la chose suivante:
Le besoin doit tenir compte du champ des solutions possibles, lequel est limité par l’accumulation des solutions passées et de la capacité de l’organisation à les mettre en œuvre et les régénérer.
Published by yannick grenzinger , Il y a 9 ans
@Anas: vous évoquez un des réels problèmes du SI: la dette fonctionnelle. La dette fonctionnelle et technique fait que de (trop) nombreux « quartiers » des SI sont vétustes et difficiles à faire évoluer et maintenir.
Comme pour la dette technique, la dette fonctionnelle demanderait un « refactoring » permanent qui éviterait l’accumulation inutile de solutions passés et permettrait de rendre le SI plus agile (= capable de s’adapter aux évolutions du marché et de ses clients).
J’aimerais aussi revenir sur la théorie vs la vrai vie. La théorie dont nous parlons avec passion dans le monde « Agile » (ou lean startup ou design thinking) est la réalité des entreprises dont le logiciel est un des éléments centraux de l’entreprise.
Si vous pensez que le SI n’est qu’un département annexe et de support de l’entreprise, que le logiciel n’est pas votre coeur de métier, je conseille fortement d’aller lire:
http://www.forbes.com/sites/stevedenning/2014/04/11/why-software-is-eating-the-world/
La théorie est souvent la réalité de demain mais la théorie Agile est le besoin du SI d’aujourd’hui.
Published by Anas Taud , Il y a 9 ans
@yannick
Le SI n’est pas le cœur de métier de la majorité des entreprises. En revanche leur Système d’Information est devenu une ressource stratégique pour leur cœur métier … nuance importante que la passion a tendance à occulter :-).
L’agilité est un outil méthodologique, et comme tout autre outil, s’il est bien utilisé par son usager, il permet d’atteindre les objectifs escomptés, il n’y a aucun doute là dessus. Une méthode agile bien montée, implémentera avec succès un besoin, que celui ci soit un besoin bien défini … ou un besoin mal défini.
Mon questionnement va au delà de la capacité des méthodes agiles à répondre au besoin. Je me permets de remettre en question le concept même de « besoin » qui a tendance à embarquer de la solution. Ainsi, un besoin qui inclus de la solution est déjà un besoin mal défini car élaboré par des métiers qui ne sont pas compétents en termes de solutions (que ces solutions soient nouvelles ou héritées de la dette technique).
Les méthodes agiles ne résolvent pas le problème de la confusion entre besoins et solutions. Elles ne résolvent pas non plus le problème de l’incohérence des cycles des différentes couches SI (… pour revenir au premier commentaire). De manière générale, bien que les méthodes agiles soient un bon outils méthodologique de CONSTRUCTION, elles ne résolvent la question de la pertinence de ce qui est construit, ce n’est pas leur prétention.
Published by Anas Taud , Il y a 9 ans
[Correction de la dernière phrase]
De manière générale, bien que les méthodes agiles soient un bon outils méthodologique de CONSTRUCTION, elles ne résolvent pas la question de la pertinence de ce qui est construit, ce n’est pas leur prétention.
Published by Emmanuel Sciara , Il y a 9 ans
@anas
Tout à fait d’accord sur ta remarque sur le besoin : celui-ci ne doit pas contenir la solution technique utilisée derrière.
La question est : à quel point la solution technique utilisée derrière influe sur la possibilité de répondre ou non au besoin exprimé par le client. C’est pour cela que je réagissais à ton commentaire « ne peut pas faire plus que ce que le back-office lui permet de faire ».
Une des hypothèses de départ, sur laquelle se base la philosophie agile, est que ce qui prime avant tout est la valeur business de ce qui est développé (il est vrai que parfois le métier a du mal à bien définir cette valeur business, mais ceci est un autre sujet). Si on se base sur cette hypothèse, alors là où il y a valeur business, il faut trouver le moyen le plus efficace de livrer cette valeur… Et s’il le faut, travailler sur le technique pour qu’il puisse livrer cette valeur.
Il est certain qu’une des réalités rencontrées dans beaucoup d’entreprises est l’existence d’un SI patrimonial. Et malheureusement, dans beaucoup de cas – souvent sans que l’entreprise n’ose se l’avouer – ce n’est plus la valeur business qui pilote les décisions, mais la capacité technique des solutions SI en place à répondre aux besoins.
Et si c’est le cas et qu’il n’y a pas de volonté de renverser la vapeur, alors oui, une approche agile n’est pas adéquat, car celle-ci s’attachera à rendre possible le replacement de la valeur business au centre des préoccupations du développement, et, comme montré dans l’article, à changer le système pour qu’il puisse livrer cette valeur.
Cela n’est pas facile… mais c’est bien du concret, pas que de la théorie :). On peut même faire du DevOps sur du mainframe : http://www.thoughtworks.com/insights/blog/doing-continuous-delivery-with-legacy-systems … C’est pour dire !
Le challenge est autant culturel que technique, et en effet, il faut beaucoup de passion, mais aussi les pieds bien sur terre, pour y arriver. C’est pour ça qu’on est là après tout :)
Published by Anas Taud , Il y a 9 ans
@Emmanuel
« Une des hypothèses de départ, sur laquelle se base la philosophie agile, est que ce qui prime avant tout est la valeur business de ce qui est développé (il est vrai que parfois le métier a du mal à bien définir cette valeur business, mais ceci est un autre sujet). Si on se base sur cette hypothèse, alors là où il y a valeur business, il faut trouver le moyen le plus efficace de livrer cette valeur… Et s’il le faut, travailler sur le technique pour qu’il puisse livrer cette valeur. »
L’hypothèse « valeur business du livrable » de la philosophie agile n’est souvent pas vérifiée pour la simple raison que la valeur business n’est pas clairement définie et souvent polluée par de la solution mal conçue. Si le métier ne sait pas définir sa valeur business, ce n’est pas la technique qui pourra le faire à sa place. En revanche, si le métier défini un besoin business dépollué de mauvaises solutions en se focalisant sur les objectifs métiers, la technique pourra lui offrir la meilleur solution avec la méthode agile.
Ce n’est pas un autre sujet, je dirais plutôt que C’EST le sujet. Si l’hypothèse de la méthodes agile n’est pas vérifiée, celles-ci ne peut pas garantir sont résultat.
« Il est certain qu’une des réalités rencontrées dans beaucoup d’entreprises est l’existence d’un SI patrimonial. Et malheureusement, dans beaucoup de cas – souvent sans que l’entreprise n’ose se l’avouer – ce n’est plus la valeur business qui pilote les décisions, mais la capacité technique des solutions SI en place à répondre aux besoins.
Et si c’est le cas et qu’il n’y a pas de volonté de renverser la vapeur, alors oui, une approche agile n’est pas adéquat, car celle-ci s’attachera à rendre possible le replacement de la valeur business au centre des préoccupations du développement, et, comme montré dans l’article, à changer le système pour qu’il puisse livrer cette valeur. »
Ce n’es pas qu’une question de volonté, c’est aussi une question de moyens financiers.
« Cela n’est pas facile… mais c’est bien du concret, pas que de la théorie :) […] »
Une théorie est valide quand toutes ses hypothèses son vérifiées ;-)
Published by Etienne clercy , Il y a 9 ans
Bonjour
Article fort intéressant. Vos conclusions sont intéressantes, mais parfois légères et enclines à laisser le point le plus important hors de la solution. Un système complexe repose sur trois éléments majeurs
– le degré élevé d’organisation
– l’incertitude de l’environnement
– la difficulté, sinon l’impossibilité d’identifier tous les éléments et toutes les relations en jeu. qui conduit à un comportement global caractérisé par une prédictivité
réduite.
Dans votre article vous faites l’impasse sur l’organisation, qui est le premier point clef d’un système complexe.
Cette organisation est l’agencement d’une totalité en fonction de la répartition de ses éléments en niveaux hiérarchiques. Selon son degré d’organisation, une totalité n’aura pas les mêmes propriétés. On arrive ainsi à cette idée que les propriétés d’une totalité dépendent moins de la nature et du nombre d’éléments qu’ils contiennent que
des relations qui s’instaurent entre eux.
Ce qui induit une nécessité de réduire les niveaux hiérarchiques pour favoriser une communication en réseau. En quoi les méthodes Agile apportent une solution ?
Published by Emmanuel Sciara , Il y a 9 ans
Bonjour Etienne,
L’article ne préconise volontairement pas d’organisation particulière. Il insiste plutôt sur les caractéristiques, portées par les approches agiles, qui doivent émerger d’une organisation pour éviter les dysfonctionnements mis en avant dans le Beer Game, c’est-à-dire :
– des cycles courts
– une communication simplifiée et efficace
– la réduction du nombre d’étapes (et donc d’équipes)
– une vue du système dans sa globalité (ça, c’est moins dans le système organisationnel même que dans les outils et pratiques à mettre en place)
Cet absence de préconisation a pour but d’éviter tout dogmatisme sur telle ou telle solution, et d’être tenté d’en plaquer une sur tout systèmes complexes. Si on reste guidé par les caractéristiques décrites ci-dessus, alors on trouvera un système organisationnel approprié vers lequel converger dans son propre cas particulier.
Il y a bien sûr des patterns que l’on retrouve dans bien des systèmes. Leur étude n’est pas le propos de cet article. D’un autre peut-être !
Em
Published by Emmanuel Sciara , Il y a 9 ans
@Anas
Peut-être aurais-je dû écrire « prérequis » plutôt que « hypothèse ». C’est dans ce sens que je disais que s’il n’y a pas de volonté de mettre la valuer business au centre de tous les efforts, alors pas la peine de faire de l’agile… Et bien d’autres choses d’ailleurs.
Oui, la bonne définition du besoin par le métier est un sujet important ! Et ce n’est tout simplement pas le sujet de cet article.
Pour ce qui est des moyens financiers, en effet ils entrent en compte. Et parfois – souvent même – la question à se poser n’est plus « A-t-on les moyen de le faire ? », mais plutôt, « Peut-on se permettre de ne pas le faire ? »… Par exemple, l’apparition d’un nouvel entrant peut avoir des conséquences encore plus désastreuse pour la compétition si celle-ci ne peut pas s’adapter à cause d’un SI patrimonial limitant. C’est ce qui s’est passé dans le monde des télécoms récemment, et pour avoir travaillé et eu des retours de chez quelques-uns des opérateurs historiques, j’ai pu voir à quel point leur SI les ont empêchés de réagir effectivement à la nouvelle concurrence.
Em
Published by Anas Taud , Il y a 9 ans
@Emmanuel
C’est sûr, l’approche des opérateurs historiques est l’exemple même de ce qu’il ne faut pas faire, d’ailleurs d’autres mastodontes dans d’autres secteurs subiront le même sort s’ils ne se posent pas la question de « Peut-on se permettre de ne pas le faire ? »