Tous les points de départ se valent car seul le chemin compte
26 oct. 2013 Olivier Azeau En français 8
Je viens de lire quelques échanges assez critiques sur twitter concernant le Scaled Agile Framework, plus connu sous le petit nom de "SAFe".
Du coup, je me sens obligé d'apporter mon point de vue et, une fois n'est pas coutume, d'avoir une vision bien plus modérée que ce que j'ai pu lire.
Lu sur twitter ici ou là : "SAFe : à qui profite le crime ?", "outil + certification le duo maléfique", "ce truc est un poison", "c'est du flan. de la nouille. un danger même"...
Les qualificatifs ne manquent pas pour décrire SAFe qui, semble-t-il, n'a pas que des adeptes.
La critique de ce modèle semble majoritaire dans la communauté agile. Lors de l'open space du Scrum Gathering Paris, quelqu'un avait proposé une discussion (à laquelle je n'ai pas participé) sur le sujet. Je crois qu'elle était intitulée "SAFe not safe".
Je suis disposé à entendre toutes les critiques. Je suis le premier à en faire sur de nombreux sujet et je n'ai absolument aucun intérêt personnel dans SAFe. Mais en l'occurrence, je trouve que tous les reproches sonnent faux. Il est évident qu'un outil qui propose un modèle prêt à l'emploi avec plein de boites et de flèches pour structurer une organisation ne semble pas très agile. Mais si on y réfléchit 2 secondes, Scrum ne vaut pas mieux car il découle d'une même logique.
Bah oui, Scrum propose un modèle prêt à l'emploi avec des rôles, des rituels, et j'en passe. Et pour ce qui est de la certification, je ne connais personnellement aucun "certifié SAFe" (du moins pas encore). Alors que des personnes certifiées par la scrum alliance...
Bref, proposer Scrum ou proposer SAFe, c'est bonnet blanc et blanc bonnet.
Que celui ou celle qui n'a pas son CSM me jette la première pierre !
Le problème n'est pas là. Quand on prend un outil, Scrum, SAFe ou autre, on ne fait que choisir un point de départ car il faut bien commencer par quelque chose - quelque chose qui peut être "l'organisation existante" si on penche du côté Kanban.
Mais aucun modèle ne survit à une implémentation réellement agile : il évolue à travers son appropriation. Si on reste scotché au point de départ, on a, de toutes façons, perdu. On fait de l'agile mais on n'est pas agile.
En ce qui concerne SAFe, il faut savoir mettre de côté les aspects les plus repoussants et peut être regarder ce qu'il y a derrière.
Quand je lis des trucs comme "Optimize the whole, not the parts, of the organizational and software system." "Fully support the values and principles of the Agile manifesto. Know how and when to apply XP, Scrum, Kanban, SAFe and other, evolving Agile software development practices." je me dis que tout n'est peut être pas aussi noir que ce que pourrait laisser penser le diagramme...
SAFe apparait comme une sorte de mélange Agile-Scrum-Lean avec un aspect extérieur très carré qui peut être rassurant pour une organisation Waterfall.
Et si on pousse jusqu'aux études de cas, pas de quoi fouetter un lolcat non plus. J'en ai pioché une au hasard et, franchement, je suis plutôt agréablement surpris de la transformation agile qui est présentée.
Reste l'aspect "business" de la chose. Quel que soit le besoin, SAFe a une solution : formations, certifications, conseils, customisation...
Mais on ne va peut être pas reprocher aux gens de faire de l'argent grâce à l'existence de l'agilité en aidant les organisations à évoluer, non ?
Le problème n'est pas le point de départ que l'on choisit. SAFe me parait être un très bon choix dans certains cas. Je pense à la création de produits où l'expression des besoins utilisateurs ne représente pas plus de 10% de la description du produit et la conception est essentiellement pilotée par les besoins technologiques. C'est le cas de la plupart des "gros" produits industriels.
L'exemple est simpliste mais imaginons une voiture. Les besoins de l'utilisateur final, celui qui conduit ou celui qui est simple passager peuvent facilement être assimilés à des "features" d'un "programme". Ces features peuvent difficilement être implémentées sans introduire un 2ème niveau plus technique où chaque élément (un moteur, un chassis, une carosserie...) aura un product backlog qui ne parlera pas vraiment à l'utilisateur final.
Cela n'est peut être pas l'organisation idéale mais le canevas proposé par SAFe peut permettre de démarrer un cheminement agile en calquant sur la nouvelle organisation des fonctions existantes. Peut être qu'un jour on sortira un nouveau modèle de voiture toutes les semaines en fonction des attentes des utilisateurs mais, avant ça, on va se mettre en position d'évolution et on va commencer par conserver notre release semestrielle ou annuelle.
Ce n'est qu'après la sélection du point de départ que le vrai boulot commence, celui du cheminement éternel. Que l'on commence par SAFe, Scrum, Kanban ou Puma ne change rien à l'affaire : ce sont tous des mauvais choix incontournables.
Olivier
Merci pour ce billet, je partage ce point de vue. Sur le terrain (et pas dans les conf) je constate que SAFe est *audible* et est une "accroche" possible pour l'agilité à l'échelle, comme mgt3.0 pour le management agile par ailleurs. à mon sens, ce qui est non négociable ce n'est pas le framework lui-même c'est le principe agile d'adaptation locale. Sur le fond, dire que le pilotage du portfolio est basé sur kanban et les projets sur scrum me semble un cadre utile pour démarrer une adaptation de l'agilité à l'échelle de l'organisation.
Hello,
Je peux me permettre de jeter la première pierre alors ? :)
Je ne suis en effet plus CSM depuis 2 ans :)
En fait, je suis juste complètement d'accord avec ta dernière phrase ! Et c'est justement ce que je trouve pénible avec ces approches : elles ne vont pas dans la bonne direction, elles ne mettent en avant que la partie process.
Toutes les initiatives visant à "unifier" les approches agiles vont pour moi totalement à l'encontre de ce qu'est l'agile.
Comment peut-on penser être agile juste en appliquant un modèle pareil ? Ou est l'apprentissage par l'erreur la dedans ? Ou est la simplicité ? Ou est la liberté permettant à l'organisation de faire émerger sa culture agile, et tout ce qui sous-tend cette culture ?
Et c'est pas la première fois que ce genre de choses est proposé. Je me rappelle y'a 3 ou 4 ans une soirée du SUG avec Scott Ambler qui présentait déjà un famework pour scaler en agile (dont le nom est, si les souvenirs sont bons, lui aussi sous trademark soit dit en passant). Et ce que toutes ces approches ont en commun, et c'est la ou je te rejoins pas, c'est qu'elles sont bien plus structurantes que Scrum par exemple (qui lui aussi est d'une certaine façon plus structurant que d'autres approches).
Ça reste à confirmer par les faits, mais intuitivement, ce truc n'a aucune chance de marcher (ie être durablement utile) dans une organisation si on le dépolît tel quel. En revanche, que le modèle décrit puisse fonctionner, j'en doute pas. Mais il faut qu'il émerge de l'organisation elle-même (aidée sans doute par des coachs). Et c'est la qu'une approche comme l'open agile adoption de Dan Mezick me paraît beaucoup plus pertinente : cela reste léger, et surtout cela laisse la place à l'émergence, à une forme de changement de culture, pas de manière forcée, mais par l'organisation elle-même, en douceur. Qui plus est : pas de trademark, pas de certification, juste un bouquin... Un signe ?
J'ai oublié d'ajouter qu'il serait intéressant de demander aux signataires du manifeste ce qu'ils en pensent, et si ça reste dans l'esprit de ce qu'ils ont défini un jour :)
@Thierry, Bien ! On est au moins deux !
@Jérôme,
Pour les signataires du manifeste, tu sais que DSDM était également représenté ? Tu as déjà vu une description de DSDM ? Tout particulièrement l'aspect process tant décrié sur SAFe ?
Mais je crois que tu as presque pointé le noeud du problème, ou, du moins, du désaccord.
Je pense que personne, même aidé par un coach, ne peut intégralement construire son propre savoir à travers une approche exclusivement basée sur l'expérience (apprendre de ses erreurs, de ses succès...)
Et cela va bien au delà des méthodes agiles si on parle d'enseignement au sens large.
Il faut des points d'ancrage que l'on pourra -plus tard- critiquer pour mieux s'en libérer.
La phrase la plus importante du manifeste, c'est la première. Elle entérine le cheminement ("we are uncovering") et le fait qu'il y a désormais un existant ("we have come") que l'on ne va pas renier pour tout recommencer à chaque fois.
Si on pouvait faire l'expérience de transitions agiles complètement isolées du monde extérieur, c'est à dire sans rien connaître du manifeste ni de ce qui y est relié en amont ou en aval, combien d'organisation "redécouvriraient" Scrum, XP ou quelque chose d'approchant ? Combien d'organisations ne feraient qu'optimiser une cascade ?
Je serais d'accord avec l'article si, la plupart des équipes qui se mettent à l'agilité avaient compris que l'agilité c'est du constructivisme et que pendant le chemin, les éléments de départs seront déconstruits pour être reconstruits différemment, et qu'ils n'ont donc que peu d'importance. Mais dans les équipes que j'ai pu voir on en est loin, parce que cette compréhension n'existe pas, notamment parce que le constructivisme, le progrès par essais/erreur, n'est pas dans la culture de l'entreprise, qui carbure généralement au management analytique, aux objectifs chiffrés, et à la peur de la sanction.
Scrum notamment, (mon CSM a expiré je ne sais plus quand :), mais XP ou kaban aussi (sans même parler du lean) a été largement récupéré par la culture historique (scrummasters/chefs de projets, stories/spécifications/, apparition d'un engagement sur la vélocité, etc), et son adoption a été plutôt contre-productive pour l'adoption de l'agilité en brouillant la rupture qu'amène l'agilité. Je pense que SAFe est du même acabit, avec un côté "agilité pour managers" bien plus marqué et assumé que les autres. Ça va peut-être donner confiance aux décideurs et favoriser l'adoption de l’agilité, mais si c'est pour généraliser une agilité diluée (encore plus diluée que ce qu'elle est actuellement, je veux dire), bof.
@Antoine,
Tout à fait d'accord sur la possible dilution. Mais, là encore, Scrum pose exactement le même problème.
N'est-il pas évident que Scrum a, à ce jour, fait plus de dégats que SAFe ne pourrait en faire ?
On en revient donc à "Faut-il déconseiller Scrum car il engendre trop souvent des conséquences néfastes sur l'agilité implémentée ?"
Je sais qu'il y a un consensus pour dire que Scrum est la racine de tout le mal, mais je ne sais pas bien d'où tout ça sort :
1) Scrum d'après le Scrum guide est plutôt radical, en remettant en cause la notion d'estimations, la hiérarchie au sein des équipes, les objectifs chiffrés, en parlant de PO, d'équipes pluridisciplinaires, et en permettant aux développeurs d'établir leurs pratiques sans entraves, ce qui est quand même assez en accord avec les principes de l'agilité. Donc discréditer Scrum en tant que méthode agile me semble injuste.
2) Pour l'avoir vu dans pas mal de contextes, Scrum a été extrêmement mal utilisé, voire sciemment saboté par les couches managériales des SSII comme celles des grands comptes. Ils se sont immiscés dans le fonctionnement des équipes et les ont contraintes à dénaturer la méthode pour la faire rentrer dans les référentiels qualité et les pratiques commerciales pré-existantes, au lieu de saisir l'occasion d'utilier cette mutation pour améliorer l'entreprise.
3) La ScrumAlliance a "commercialisé" Scrum de la façon que l'on sait, et en donnant l'impression qu'un ex-CP repeint en ScrumMaster au bout de 2 jours de formation permettait de dire qu'on fait de l'agililté, et a accentué la dénaturation. Mais les agissements de la ScrumAlliance ne permettent pas de discréditer Scrum en tant que méthode. Si un jour des gens se mettent à vendre des certifications TDD bidon, ça ne voudra pas dire que le TDD est une mauvaise pratique.
Tout ça pour dire que je pense que les dégâts dont on parle ont été faits par une industrie qui a pris pour cible une méthode agile, l'a dénaturée pour pouvoir dire qu'elle fait de l'agilité à ses développeurs et ses clients sans en faire vraiment. (Et la communauté s'est laissée embarquer là dedans, jusqu'a se fragmenter en pro-Scrum et anti-Scrum, comme si l'agilité était une question de méthodes.)
Ce qui est pire avec SAFe c'est que la dénaturation est déjà faite à la sortie de la boîte. Certes ça n'est qu'une méthode, mais elle promeut et rend légitime une agilité dénaturée prête à l'emploi pour des raisons lucratives. Tu sembles penser que Scrum avait déjà pris ce rôle et je ne suis pas d'accord, mais le coup, c'est ce qui est en train de se passer avec SAFe. Je ne pense pas que la communauté devrait rester passive sous prétexte que le mal est déjà fait, mais ne pas perdre une occasion de marquer les limites entre ce qui concourt aux valeurs de l'agilité et le reste.