Il y a quelques temps, nous avons démarré une saga sur deux sujets qui nous semblaient décorrélés : outils d’Architecture d’Entreprise et Agilité. La question sous-jacente est bien de savoir comment l’outil d’Architecture d’Entreprise peut apporter de la valeur aux équipes opérationnelles, sans perdre pour autant sa simplicité d’utilisation et ses cas d’usage principaux.
De nouveaux acteurs dans le secteur des outils d’Architecture d’Entreprise ont axé leurs efforts sur la facilité de prise en main et la qualité des restitutions à la volée. Un outil facilitant ce travail de manière récurrente peut permettre d’embarquer des utilisateurs « non-architectes », dont l’activité quotidienne est déjà consacrée à 100% à des tâches opérationnelles.
Mais ces nouveaux outils signent-ils pour autant la fin des leaders historiques du marché ? Et surtout, cela signifie-t-il qu’ils doivent être utilisés à des fins plus opérationnelles par les équipes ?
La fin des dinosaures ?
Les outils historiques du marché de l’Architecture d’Entreprise ont été conçus par des experts pour des experts. Et qui en est pleinement satisfait aujourd’hui ? Étant donné leur inertie et la lourdeur de leur configuration, ces outils peuvent exclure les projets et les équipes agiles.
On reproche aux EAMS (Enterprise Architecture Modeling System) d’être des logiciels difficiles d’utilisation, obscurs pour les utilisateurs occasionnels et nécessitant une phase de formation non-négligeable avant utilisation. Trop souvent l’architecte d’entreprise est arrivé avec l’artillerie lourde pour imposer outils et process : c’est tout sauf agile !
Par ailleurs, l’intérêt de l’Agilité est d’apporter rapidement de la valeur au métier, grâce à aux interactions au sein d’équipes mixtes métier/IT. Formés à plusieurs domaines, les développeurs polyvalents sont capables de comprendre les besoins et d’interagir avec les experts pour prendre les meilleures décisions possibles. Cette interaction entre plusieurs disciplines favorise la montée en compétence et enrichit les échanges. De la même façon, des outils déployés par les architectes pour les architectes apportera moins de valeur que s’ils sont ouverts à d’autres domaines d’expertise et améliorés en fonction des enjeux de chacun.
Alors, architectes, puisons notre inspiration des opérationnels et de leurs outils !
Jeune outil deviendra grand
Face aux mastodontes historiques, de nouveaux acteurs ont émergé ces dernières années, jusqu’à devenir de sérieux concurrents. Serait-ce la réponse à l’incompatibilité apparente entre besoins de l’Architecture d’Entreprise et des équipes opérationnelles ?
Certains outils sont de simples modelers. Sans prérequis particuliers de prise en main, ils répondent directement aux besoins de modélisation des projets. Encore faut-il trouver le bon compromis entre la gestion centralisée d’un référentiel d’assets IT et de l’architecture mouvante des projets agiles.
D’autres outils, à peine plus complexes en apparence, gèrent même un référentiel : le principe est d’alimenter l’outil via l’import de données pour générer automatiquement des rapports. Interfacer un outil d’Architecture d’Entreprise et un outil de modélisation est même possible nativement chez certains éditeurs. Ou bien, sous réserve d’avoir quelques « techos » disponibles, une interface « maison » entre l’EAMS et l’outil de modélisation projet (tel Archi, ou autre) permet de dissocier la partie référentielle du projet et de ses changements. Tout cela pour un contenu toujours plus riche, mais structuré !
Nous pensons également aux éditeurs qui intègrent de manière « out-of-the-box » des outils utilisés par les projets, comme la suite Atlassian. En quelques clics sur Confluence, par exemple, il devient possible de partager au sein de l’équipe des diagrammes et roadmaps modélisés dans le logiciel d’AE, de manière dynamique et embarquée. La démarche se veut collaborative : cette interconnexion ferait-elle le pont entre les deux mondes pour finalement mettre tout le monde d’accord ?
Grâce à ces logiciels, il devient possible de centraliser toutes les informations importantes pour les projets et l’entreprise dans une vue unique et partagée. Si le but est de communiquer des informations clés, c’est suffisant. Architectes d’entreprise et équipes agiles échangent leurs connaissances (opérationnelles ou stratégiques, détaillées ou macroscopiques, délimitées ou transverses) pour mener les projets de transformation de l’entreprise au mieux.
L’outil d’AE, l’ouvrir aux opérationnels ou pas ?
Pour garantir la mise à jour régulière du référentiel d’architecture, l’implication des équipes opérationnelles (exploitation, projet, développement, intégration) est indispensable. Car ce sont eux, les « sachants » !
Or, si les équipes opérationnelles ont besoin de connaître l’historique des incidents et évolutions de l’application, ses certificats associés et ses contrats de support, les architectes souhaitent principalement visualiser l’existant et bénéficier d’analyse d’impacts exhaustives sur un périmètre précis.
Pour autant, faut-il que l’outil d’AE se plie aux besoins des équipes opérationnelles pour garantir sa mise à jour effective ?
La réponse à cette question réside dans le fait que pour faire fonctionner un logiciel d’architecture, il faut se focaliser d’abord sur un ou deux cas d’usage majeurs, avant d’en élargir l’utilisation au gré des opportunités et des besoins. Que ce soit un outil flexible succinct ou un imposant dino, il faut revoir à la baisse les attentes vis-à-vis d’un outil d’Architecture d’Entreprise.
L’enjeu est donc de bien cadrer le scope. Votre outil d’Architecture d’Entreprise peut très bien se contenter de renseigner les grands jalons et dates d’atterrissage, afin de donner de la visibilité au métier et à la Direction informatique sur les applications et projets qui vont impacter le Système d’Information.
Dans tous les cas, le niveau de granularité des informations à renseigner reste l’élément le plus structurant pour un tel outil. Savoir quoi renseigner, par qui, jusqu’à quelle maille et surtout à quel moment demeure la clé pour garantir un référentiel cohérent et mis à jour régulièrement.
L’Architecture d’Entreprise en libre-service
N’essayons pas de faire monter les projets sur nos vastes outils d’Architecture d’Entreprise. Soyons clairs, ils ne sont pas adaptés à la capacité et à la philosophie des équipes projets.
Avec un EAMS aussi simple qu’une appli de smartphone (à la navigation fluide, sans formation nécessaire et au contenu aisément partageable), les développeurs membres d’une équipe agile bénéficieraient des apports de l’AE et de sa connaissance du métier, de l’IT comme de l’entreprise dans son ensemble, sans alourdir leur charge.
Peut-être le secret réside-t-il dans la conception à deux entrées de l’outil d’AE : un grain précis et spécialisé pour les équipes opérationnelles et un grain macroscopique pour les responsables de pôle, les architectes et les directeurs (opérations, architecture, études, métier…), gérant les roadmaps et permettant l’alignement du SI sur les besoins du métier.
Architectes et équipes projets, qu’en pensez-vous ?
Il faut que je vous avoue que lorsqu’on me demande sur quelle certification agile je peux former les gens, j’ai parfois un peu honte de dire que je peux le faire sur SAFe avec la Scaled Agile Academy.
Aussi, je m’empresse le plus souvent d’ajouter que je suis aussi formateur licencié Management 3.0. Comme pour me dédouaner.
Cette opposition de genres peut surprendre. Encore plus lorsqu’on connaît également mon penchant pour les organisations plates (pour ne pas dire entreprises libérées) et les interventions et articles que j’ai pu faire à ce sujet.
Pour autant, je ne vois pas cela comme une schizophrénie. Et oui, j’ose le dire, j’aime bien SAFe !
Alors pourquoi SAFe est-il un framework qui crée autant de débats ? Pourquoi est-ce que cela peut sembler honteux d’utiliser SAFe ? Autrement dit, SAFe est-il vraiment agile ?
Je vous propose de décrypter tout cela à travers 9 affirmations. 9 arguments massue trop souvent utilisés pour jeter SAFe en pâture dans la fosse aux lions. 9 critiques à la véracité insuffisamment questionnée.
Non, je ne vous ferai pas le coup des “10 affirmations sur SAFe, la 10éme va vous étonner…” mais restez quand même avec moi jusqu’à la fin ;).
Pour commencer, je reviendrais sur l’une des sentences les plus souvent prononcées à son encontre : “SAFe est trop complexe”.
C’est une affirmation que je peux totalement comprendre. Pour qui a un jour regardé le poster SAFe, cela peut même sembler une évidence, tant on peut se trouver perdu à son premier regard.
Pourtant ce défaut de complexité, au-delà du fait qu’il n’est surtout qu’apparent et s’éclaire grandement quand on appréhende pleinement la logique du framework, est l’une des véritables qualités de SAFe.
Si le framework est compliqué, c’est qu’il imbrique beaucoup de sources de connaissances différentes. Il s’attache à faire le lien entre elles ; ce qui n’est jamais chose facile.
En y regardant de plus près, c’est cependant une manière (mais pas la seule) de construire une véritable approche systémique. Réunir autant de savoirs différents, c’est s’attacher à ce que l’ensemble des aspects de l’équation soient pris en compte. Et de ce point de vue, je pense que c’est le framework qui permet la meilleure vision d’ensemble. On y retrouve du lean startup, du design thinking et de l’UX, du Scrum, du Kanban, du DEVOPS (dont le continuous delivery), du Beyond Budgeting et de la gestion de portefeuille, du Management 3.0, du Lean etc.
On a donc une vision qui n’oublie ni les personnes, ni les pratiques, ni la stratégie, ni le client, ni les environnements, ni le management et ni même la culture !
Donc oui, SAFe peut être complexe (au sens des systèmes complexes), mais c’est une complexité nécessaire. Je citerais d’ailleurs à ce sujet Max Boisot qui dit:
La complexité d’un système doit être en adéquation avec la complexité de l’environnement dans lequel il se trouve.
Max Boisot
The Interaction of Complexity and Management
Cela dit, SAFe ne cherche aucunement à être complet sur l’un ou l’autre de ces composants. Il propose des outils dont il nous laisse en partie le soin d’approfondir le contenu.
Il n’y a par exemple pas d’explication détaillée du Gemba, qui fait partie des éléments inhérents à une approche Kanban. Bien que s’appuyant sur Kanban (et plus largement le Lean), SAFe considère que c’est à nous d’en maîtriser les concepts.
Sur ce sujet, SAFe n’impose d’ailleurs aucune méthode. Pour preuve, même si Kanban est devenu aujourd’hui un pilier important, il était autrefois cantonné à la seule gestion de portefeuille. Jusqu’à la V4 du framework en effet, seul Scrum était utilisé comme moyen de piloter une équipe agile.
SAFe est ainsi un framework qui, en son coeur, encourage la sélection des pratiques et outils. Ce qui nous permet alors de nous adapter à l’environnement auquel nous sommes confrontés. Ce faisant, nous pouvons sélectionner le juste niveau de complexité dont nous avons besoin !
2. SAFe n’a rien inventé (sous-entendu “donc c’est pas bien !”)
[br]Autre objection que l’on entend trop souvent, SAFe n’aurait innové en rien ! C’est tout d’abord un faux reproche. Il est parfois plus utile de relier des savoirs que d’en créer de nouveaux. Je rappellerais d’ailleurs cette citation de Bernard de Chartres reprise par Pascal ou même Newton en leur temps :
Nous sommes comme des nains assis sur des épaules de géants. Si nous voyons plus de choses et plus lointaines qu’eux, ce n’est pas à cause de la perspicacité de notre vue, ni de notre grandeur, c’est parce que nous sommes élevés par eux.
Bernard de Chartres
Metalogicon – Livre III
Pour autant, SAFe est un framework qui a lui aussi apporté sa pierre à l’édifice de l’agilité. L’intégration des savoirs agiles et la proposition d’une représentation cohérente à l’échelle de l’entreprise n’est déjà en soi pas un mince exploit. Quand bien même cela aurait été la seule contribution de SAFe, cela aurait eu de la valeur. Mais SAFe va plus loin. Au-delà de cette mise en cohérence, il amène également ses propres nouveautés.
J’en citerai simplement deux: le PI Planning et l’intégration des architectes au coeur de l’agilité.
Le PI Planning est certainement le plus emblématique des apports de SAFe. Qui aurait pu penser que réunir jusqu’à 125 personnes pendant deux jours était une bonne idée ? Pour autant, cet événement est loin d’être la foire à laquelle on pourrait s’attendre. En vivre un est même bien souvent déterminant pour convaincre une entreprise de s’engager dans SAFe. Et ce quand bien même le PI planning peut justement être l’un des éléments qui auraient tendance à faire peur !
Ce sont d’ailleurs généralement ces mêmes détracteurs du PI planning qui viennent ensuite en faire l’apologie. Ils sont enthousiastes face à l’énergie libérée et l’efficacité avec laquelle les problèmes sont gérés. Ils sont surpris de la transparence et de la vision apportées, heureux de l’engagement suscité.
L’intégration des architectes dans SAFe, même si elle est moins souvent mise en avant est également très intéressante. D’abord elle permet de casser un tabou ! Celui d’une agilité qui ne pourrait pas avoir de vision à moyen terme ou de planification.
En effet, les architectes ont longtemps été les laissés pour compte de l’agilité. Le fait de chercher à obtenir des équipes auto-organisées, autonomes et ayant toutes les compétences pour réaliser le produit a pu être vu comme une critique de leur rôle.
Il faut dire qu’ils avaient fini par être perçus comme un élément de rigidité des organisations. En codifiant les méthodes, outils et langages à utiliser ils venaient entraver les besoins d’adaptation des équipes agiles. La guerre était déclarée.
Pourtant l’autonomie sans vision partagée est la meilleure recette du chaos. Sans celle-ci, il est impossible de créer l’alignement et chacun part dans sa propre direction.
SAFe en intégrant le rôle d’architecte aux différents étages du framework, redonne ce rôle de porteur de sens. Les architectes ne sont plus là pour établir une vision figée de l’organisation, mais une vision évolutive.
Ils viennent donc en soutien des équipes en permettant l’alignement de celles-ci avec des approches dont ils garantissent la cohérence. Ils s’assurent également que si les choix sont ouverts en début de réalisation, ils finissent par se stabiliser avec le temps. Ils permettent ainsi d’éviter l’oscillation permanente qui frappe parfois certaines équipes agiles, incapables de converger vers une solution.
3. SAFe est un framework de command and control
L’idée que SAFe serait en fait une approche de command and control, est peut-être la dernière grande critique que l’on entend régulièrement professée à son égard.
Cette notion d’une approche dictatoriale est sans doute accentuée par le célèbre poster de SAFe. Cette représentation détaillée peut en effet donner l’impression d’un framework très orienté processus. Visuellement, la représentation des différents étages de coordination en se rapprochant des structures pyramidales des sociétés, peut laisser penser à une forme de hiérarchie. Une idée bien ancrée dans l’esprit de certains.
Je soupçonne néanmoins la Scaled Agile Academy de maintenir volontairement une certaine ambiguïté sur le sujet. À travers son poster et sa représentation à étages, SAFe laisse penser à une continuité du fonctionnement hiérarchique de l’Ancien Monde. Un choix qui explique le succès commercial de SAFe. Cette représentation de l’agilité, proche des méthodes traditionnelles, et de nos anciennes croyances, est en effet bien plus rassurante aux yeux des dirigeants.
Malheureusement, cette vision d’un SAFe qui ne nécessiterait pas de changer notre compréhension du monde, mais d’adopter simplement de nouveaux processus est également une des raisons principales d’échec de son implémentation.
SAFe, comme tout framework agile, nécessite savoir-faire et savoir-être. Ce dernier étant essentiel ! N’appliquer bêtement que les processus (le savoir-faire), ne peut donc qu’engendrer un échec.
SAFe nous prévient pourtant dès le départ. Il n’est pas une recette prévue pour une application dans sa globalité. Il doit être adapté. Au-delà même des sous-ensembles directement proposés que sont l’Essential SAFe, le Large Solution SAFe, le Portfolio SAFe ou le Full SAFe. C’est une adaptation qui demande une véritable conscience (au sens de savoir-être) des principes et valeurs de l’agilité.
Pour ma part, il m’arrive assez fréquemment de mettre en place chez mes clients une couche de gestion de portefeuille inspirée du Portfolio SAFe. Alors même que les projets/produits ne nécessitent pas de mécanismes d’agilité à l’échelle. Elle apporte en effet un bénéfice réel à l’organisation par les mécanismes de priorisation des projets/produits qu’elle propose.
SAFe est donc un framework qui, peut-être plus que d’autres, peut facilement être dévoyé et implémenté de manière coercitive. On perd ainsi tout bénéfice d’agilité.
Pour autant, il ne m’a jamais empêché de discuter avec certains clients d’organisations plates alors que nous faisions une implémentation de SAFe. Dans le fond, il n’y a rien d’incompatible à ce qu’une entreprise Opale utilise ce framework.
Si l’on peut certes reprocher l’ambiguïté, SAFe n’en reste pas moins un framework agile. Ce n’est pas SAFe qui est anti-agile, mais ce que nous en faisons qui le transforme en outil de command and control.
4. Les métriques dans SAFe sont un retour vers l’utopie de la prédictibilité
Autre critique que l’on entend surtout parmi les agilistes, SAFe propose une approche des métriques qui peut sembler un peu utopique. Dans un monde complexe (et donc volatile du fait des mécanismes d’émergence), SAFe donne l’impression de chercher à tout prédire. C’est une partie que j’ai personnellement mis un certain temps à maîtriser.
En fait, SAFe ne cherche pas à obtenir un chiffre précis, juste et absolu. Son approche des métriques est un moyen d’éclairer la prise de décision. Autrement dit, c’est un moyen de vérifier nos hypothèses, de détecter les changements éventuels et de s’y adapter le mieux possible.
Prenons pour exemple la mesure de prédictibilité du train, qui se base sur le pourcentage de business value atteinte. Cette mesure n’est pas tant effectuée pour suivre l’avancement de nos engagements que pour déterminer à quel point notre environnement est changeant. On ne cherche pas à savoir si l’on va tenir nos objectifs, mais à ajuster notre manière de piloter en fonction du degré d’incertitude de l’environnement dans lequel on se trouve.
Si parfois l’expérience montre une certaine fiabilité dans l’atteinte de nos engagements, tant mieux ! C’est que nous sommes dans un environnement relativement stable. Nous pouvons alors poursuivre une certaine stratégie d’efficience.
Si au contraire la prédictibilité du train est faible, c’est que notre environnement est extrêmement incertain. Dans ce cas, il ne convient pas de rechercher l’efficience. C’est tout l’inverse. Il faut alors s’attacher à développer nos capacités d’adaptation. Cela veut dire se préserver un maximum d’options, le plus tardivement possible (on pourrait aussi travailler à accroître la stabilité de notre environnement. Tout un challenge !).
Le fait que SAFe repose sur un paradigme de changement se retrouve à la fois dans son fort focus sur la création de valeur et dans la manière dont il la définit.
Dans un contexte où nous ne maîtrisons pas l’évolution de nos écosystèmes, il est en effet essentiel de s’assurer d’investir de manière à ne jamais regretter nos choix. Même si nos prévisions étaient déjouées.
C’est pourquoi SAFe, tout comme l’agilité de manière générale, cherche à travailler en permanence sur les éléments dont nous estimons pouvoir dégager le plus de valeur. Le travail est même découpé d’une manière qui nous permette d’en retirer le maximum de bénéfice, quel que soit le moment où nous devrons procéder à des ajustements.
Autrement dit, face au changement, il s’agit d’être dans une situation où force est de constater que nous n’aurions pas pu mieux nous organiser. Nous n’aurions pas pu créer plus de valeur. Nous n’aurions pas pu mieux limiter nos pertes. À moins évidemment d’avoir eu connaissance du changement à l’avance, mais ce serait là un biais de lecture a posteriori…
Comme je le disais, cette incertitude se retrouve jusque dans la façon dont SAFe définit la valeur. C’est en effet le seul framework à parler d’hypothèses de bénéfices et non de bénéfice tout court.
Il met ainsi en lumière le raccourci trop souvent commis entre la valeur escomptée d’un projet/produit et sa valeur réelle après rencontre avec le marché.
En ajoutant cette notion d’hypothèse, SAFe met en exergue la nécessité de piloter le bénéfice escompté. Dès la réalisation de l’epic hypothesis statement, le framework recommande la définition d’indicateurs de pilotage de la valeur (les leading indicators).
Par la suite, ces KPIs permettront de vérifier la justesse de nos suppositions et de mieux détecter les éventuelles adaptations nécessaires (dans nos priorités comme dans notre stratégie). C’est une approche typiquement Lean Startup dans l’esprit (et une belle utilisation de l’innovation accounting) !
De tout cela on retiendra surtout que SAFe ne cherche pas tant la prédictibilité ou la mesure exacte que l’obtention d’informations suffisantes pour prendre des décisions et les piloter.
5. C’est vraiment compliqué d’évaluer la valeur dans SAFe
Au rang des critiques portées à l’encontre de SAFe, on entend encore celui de la manière dont la valeur y est évaluée. Ce n’est pas sans lien avec les reproches faits au regard de l’apparente précision des métriques et leur illusion de prédictibilité.
Sur ce point, il est essentiel de bien comprendre que lorsque SAFe tâche d’évaluer la valeur d’un élément (notamment avec un WSJF), il n’essaie pas de le faire de manière absolue, mais de manière comparative. En ce sens, il est tout aussi facile de mesurer un WSJF dans un contexte logiciel que de production.
Le Cost of Delay effectif de l’élément A reste certes inconnu, mais sa comparaison avec l’élément B reste relativement facile à réaliser et facilite la décision de prioriser l’un par rapport à l’autre.
En cela nous sommes proches de l’esprit de How to measure anything (de Douglas Hubbard) : il ne s’agit pas d’avoir un chiffre précis, mais bien d’avoir un encadrement de celui-ci par un intervalle de confiance suffisant. Toutes choses étant égales par ailleurs et tous nos biais de mesures et erreurs étant d’une magnitude similaire, nous pouvons ainsi prendre des décisions justes sur la base d’évaluations pareillement fausses.
À ce sujet, j’aime bien évaluer la valeur en m’appuyant sur des mécanismes d’intelligence collective (diversité, décentralisation et indépendance/autonomie suivant James Surrowiecki, l’auteur de La Sagesse des foules).
Pour cela il suffit le plus souvent d’avoir un groupe de personnes suffisamment diversifié et d’utiliser des techniques adaptées de la magic estimation (qui permettent de comparer au plus vite un grand nombre de critères entre eux).
C’est parfois étonnamment rapide. J’ai ainsi pu évaluer le WSJF de près de 80 projets et les prioriser en moins d’une journée avec une dizaine de membres d’un COMEX !
Personnellement, j’apprécie également le côté global de la manière dont SAFe aborde l’évaluation de la valeur. Elle prend en compte aussi bien la user business value (incluant la valeur de satisfaction client) que la valeur liée au coût de ne pas faire (la fameuse Time Criticality) ou la valeur indirecte (réduction de risque et développement d’opportunités futures).
En cela, le framework est plus riche qu’un simple Scrum. Il ne se contente pas de la seule valeur business mais rend explicites d’autres types de valeurs. En retour l’attention constante pour la satisfaction client peut cependant paraître moins évidente.
Ainsi, même si SAFe nous incite à évaluer la valeur sur plusieurs axes, le fait de le faire de manière comparative ne rend pas les choses plus compliquées qu’avec une autre méthode.
6. SAFe, contrairement à LeSS ou au modèle Spotify n’est pas adapté à une démarche produit
On a tendance à penser qu’un framework adapté pour des projets à 125 personnes et plus n’est pas pertinent pour l’adoption d’une démarche produit. C’est là encore une critique que j’ai pu entendre surtout en comparaison avec LeSS ou le modèle Spotify.
On précisera d’abord, comme nous le rappelle Séverin, qu’il n’y a pas de modèle Spotify. Il ne s’agit que d’un retour d’expérience. Une expérimentation dont le bénéfice, même chez Spotify, est aujourd’hui remis en question. Il n’y a rien de magique. Spotify n’a finalement rien fait de plus que de créer une organisation spécifique à son contexte. Si le mot feature teams peut sembler sexy, il ne s’agit pour autant pas d’autre chose que d’une équipe pluridisciplinaire.
Ceci étant posé, SAFe est bien lui aussi un framework construit pour fonctionner dans une démarche produit. C’est sans doute moins visible que dans le framework LeSS, car SAFe se veut plus versatile. Il cherche à la fois à pouvoir définir le fonctionnement d’une organisation complète et à permettre la cohabitation de différentes démarches (y compris donc du cycle en V avec de l’agilité).
La vision produit de SAFe est essentiellement portée par la manière de financer les values stream et l’approche capacitaire qui en découle. À travers cela, SAFe promeut la stabilité des équipes dans le temps.
Il facilite également le suivi des produits tout au long de leur cycle de vie en n’externalisant pas la gestion du run. Dans cette logique, SAFe introduit Kanban comme méthode de gestion au niveau équipe lors de la parution de sa V4. Il permet ainsi un meilleur pilotage d’activités de build et de run simultanées, courantes lorsqu’on travaille sur un produit.
Au niveau équipe, SAFe met également en avant la constitution d’équipes organisées en feature teams avec toutes les compétences (quand c’est possible) pour développer et maintenir l’intégralité du produit.
Cela fait d’ailleurs relativement sourire de voir SAFe opposé au retour d’expérience de Spotify dans la mesure où les équipes pluridisciplinaires sont bien présentes dans le framework (de mémoire au moins depuis la V3 et avec les communautés de pratiques et d’intérêt dès la V4).
Il serait donc temps d’arrêter de déifier le modèle Spotify et de le prendre pour le retour d’expérience qu’il est.
L’organisation en feature teams, l’utilisation de Kanban ou la promotion d’équipes pérennes sont autant d’éléments de SAFe adaptés à une approche produit.
7. SAFe n’est que pour les grosses entreprises
Si l’on arrive à faire face à tous ces arguments anti-SAFe, il en reste encore un qui tient à l’idée que SAFe ne serait de toute façon adapté qu’à de grandes organisations.
Ce n’est pas totalement faux. À moins de 50 personnes sur un projet, SAFe a effectivement peu d’intérêt. Dans ce cas, le surcoût de pilotage nécessaire surpasse le plus souvent les bénéfices obtenus.
De manière générale d’ailleurs, la première règle de l’agilité à l’échelle devrait être de ne pas faire d’agilité à l’échelle !
Trop souvent, on cherche en effet à mettre en place des mécanismes d’agilité à l’échelle pour compenser un manque de rigueur dans l’optimisation du système.
Affronter les problèmes en face est difficile. Changer une culture peut sembler un véritable travail d’Hercule. Rechercher les causes racines d’un problème est bien plus délicat que de trouver un coupable. Aussi, pour ne pas remettre en questions nos habitudes, on s’efforce trop souvent de compenser en ajoutant plus de monde sur le projet ou en essayant d’appliquer le dernier framework à la mode.
Plutôt que de prendre le risque d’adopter une véritable démarche d’amélioration continue et de régler les problèmes qui nous font face, nous choisissons de grandir dans une fuite en avant. Nous cherchons à avoir toujours plus de ressources en espérant que cela va miraculeusement tout résoudre!
Si je me souviens bien, Alistair Cockburn rapportait d’ailleurs cette anecdote : sur un projet, il avait déterminé qu’avec les bonnes personnes, il était réalisable avec 6 développeurs. Comme il ne les avait pas, il lui en fallait 50 !
Cela étant, il y a bien sûr des situations où il est indispensable de faire grandir les projets. C’est là une des forces de SAFe qui propose un système facilement scalable.
J’ai déjà dit qu’il m’arrivait de n’avoir recours qu’à la partie Portfolio du framework, mais il est aussi possible de n’utiliser que l’une ou l’autre des couches. Si vous le souhaitez, vous pouvez parfaitement vous contenter de ne mettre en place qu’un seul train. Non seulement rien ne vous force à tout déployer, mais il sera par ailleurs très facile d’ajouter de nouveaux éléments ultérieurement.
La règle devrait être de ne mettre en place que le strict minimum de processus que vous pensez nécessaire et ceci fait d’en retirer encore ! De manière surprenante, vous vous rendrez compte que même ces éléments que vous pensiez indispensables et que vous venez de supprimer n’ont rien d’obligatoire.
Ainsi, nul besoin d’être un grand groupe du CAC 40 pour utiliser SAFe, le plus important c’est d’adapter et de ne pas vouloir systématiquement utiliser tous les étages de la fusée !
8. Pour faire de l’agilité à l’échelle, il vaut mieux construire son propre framework
À en croire certains SAFe ne serait finalement pas un bon framework d’agilité à l’échelle, car chaque entreprise étant unique il n’est pas possible d’avoir une solution pertinente pour tous. Il vaudrait donc mieux concevoir son propre framework.
C’est d’ailleurs la tendance dans tous les grands groupes. J’ai pu participer à la création de quelques-uns et en observer d’autres. Je dois avouer que cela m’a laissé perplexe…
Certes, on peut se féliciter de voir que même les grands groupes, pourtant peu connus pour leur rapidité à s’adapter, ont fait leur ce principe d’adaptation de l’agilité au contexte. Cependant, je ne peux que constater que tous ces frameworks maison, ne sont en fin de compte que de pâles copies de SAFe. J’ai même pu observer l’intervention de grands noms du conseil qui en créant ces modèles, ne faisaient rien d’autre que recopier SAFe. Parfois, et c’est un comble, ils y ajoutaient même des erreurs !
Il en résulte que toutes ces tentatives de développement d’une solution maison aboutissent souvent à des coûts importants, des délais à rallonge et un framework déjà obsolète au jour de son lancement ! Il n’y a rien de surprenant à cela.
En effet, vouloir dès le début se construire une approche spécifique, c’est le faire au plus mauvais moment. Celui où nous ne maîtrisons ni l’agilité, ni ses conséquences sur notre organisation.
Bien sûr, il y a de nombreux frameworks d’agilité à l’échelle. Mon propos n’est pas de dire que SAFe est le meilleur d’entre eux. Je dirais surtout que c’est probablement le moins pire !
Ce qui est essentiel n’est pas d’en faire une implémentation rigide, mais de le prendre comme point de départ.
C’est un moyen de se construire une expérience de l’agilité à l’échelle au sein de notre organisation et de notre contexte.
Cela n’est en aucun cas un objectif ou une destination !
Alors que nos connaissances sur la nature de notre environnement, nos particularités culturelles et les attentes de nos clients progressent, nous pouvons alors commencer à élaborer nos adaptations en connaissance de cause. Il sera alors temps de concevoir une approche dans un esprit de continuous organization. C’est-à-dire, une entreprise capable de se réinventer et de s’améliorer en permanence.
Ainsi utiliser SAFe comme point de départ est un raccourci intéressant. Cela nous évite de devoir directement construire une approche spécifique, à un moment où notre compréhension des mécanismes est largement insuffisante. Créer son propre modèle quand on n’en a pas la maturité est une perte de temps. Tout comme faire de SAFe une vérité absolue à suivre à la lettre serait une erreur grossière
9. SAFe n’est pas de l’agilité à l’échelle
Quant à la dernière objection à faire à SAFe, c’est à moi d’intervenir et de la soumettre à votre réflexion. Si l’on en revient au coeur du problème qui est la manière de faire de l’agilité à l’échelle, je crois que SAFe, LeSS, DAD et autres Nexus sont tous foncièrement biaisés.
Face aux problématiques d’échelle, tous ces frameworks proposent de gérer la complexité liée à l’augmentation du nombre d’échanges (facteur d’émergence) par ajout de processus (ou mécanismes de coordination).
Ceux-ci peuvent être plus ou moins lourds, ils n’en restent pour autant pas autre chose qu’une forme de procédure. C’est à dire quelque chose par essence figée et qui ne peut être adaptée à toutes les situations.
Multiplier ainsi les processus reviendrait donc à réduire notre capacité d’adaptation.
Sur ce sujet d’ailleurs, il est intéressant de voir combien, dans le domaine militaire, les forces spéciales laissent une grande place à l’autonomie.
Certes, elles sont entraînées à réagir de manière quasi automatique à un grand nombre de situations. N’oublions pas qu’elles interviennent à des moments laissant souvent peu de place à la réflexion. Dans ces contextes, l’automatisme peut faire la différence entre la vie et la mort.
Si nous cherchons réellement à être agile à l’échelle, nous devons donc fuir les règles préétablies.
Dès lors, il s’agit bien de diminuer le nombre de processus pour accroître notre capacité d’adaptation. En effet, plus nous serons nombreux, plus nous multiplierons les interfaces avec nos environnements et plus nous serons fréquemment confrontés au changement. Avec la taille, la nécessité de développer notre faculté d’adaptation gagne en criticité.
Si l’on devait proposer une définition de l’agilité à l’échelle, on pourrait l’écrire ainsi : Être agile à l’échelle, c’est savoir accroître les capacités d’adaptation, de résilience ou d’innovation de l’organisation plus rapidement que sa taille n’augmente.
Sur ce sujet SAFe, tout comme l’ensemble des frameworks d’agilité à l’échelle, de par leurs ajouts de processus au fur et à mesure que l’organisation grandit, ne sont donc pas réellement adaptés…
Mais alors… l’agilité à l’échelle est une utopie ?
Bien sûr que non ! Mais le changement pour y parvenir est loin d’être évident !
Si l’on accepte que l’agilité à l’échelle c’est l’adaptabilité à l’extrême, il existe bel et bien une approche en ce sens.
Si l’on regarde les principes de construction des organisations plates, tels que présentés par Frédéric Laloux dans son livre Reinventing Organizations, on s’aperçoit en effet que c’est précisément cette philosophie qui est à l’oeuvre.
L’entreprise libérée n’est à ce titre ni plus ni moins qu’une société dont la capacité d’adaptation a été poussée à l’extrême. Laisser chacun libre d’entreprendre les actions qui lui semblent les plus justes pour l’entreprise c’est permettre d’agir au plus près du changement. C’est comme de mettre le volume de l’agilité à 11 !
Plus l’entreprise est apte à laisser de l’autonomie à ses collaborateurs, plus elle gagne en agilité.
C’est un chemin qui, s’il peut être séduisant, comporte ses propres embûches !
À commencer par la difficulté à proposer une vision transcendantale, véritable lien de l’organisation qui permette à chacun d’avancer indépendamment dans la même direction.
Sur ce sujet, vous pouvez d’ailleurs tout de suite oublier les visions du type: faire un milliard de chiffre d’affaires ou être le premier sur son marché.
Une vision ne vaut que si elle est partagée et bénéficie à tous. Tant que la poursuite de votre vision ne se traduit pas dans les actes de chacun au sein de l’organisation, vous n’avez pas encore trouvé le bon message.
Ce genre de transformation représente une véritable révolution culturelle et une route ardue.
Vous serez confrontés aux difficultés de la transparence, de l’acceptation des erreurs et de la valorisation de l’apprentissage et de l’expérimentation.
Vous affronterez la perte de repères de l’abandon des statuts et le challenge de la redéfinition des plans de carrière.
Vous devrez construire une entreprise apprenante qui permette le développement de chacun et se réinvente en permanence.
Aller dans cette direction, c’est accepter d’avancer sur un chemin peu emprunté où il vous faudra découvrir vos propres leçons.
De fait, même si un tel mode d’organisation serait finalement une réponse plus pertinente aux problématiques d’échelle dans un monde complexe, le challenge est indéniable.
Il est ainsi souvent plus aisé d’apporter une réponse s’appuyant sur un framework d’agilité à l’échelle que de s’engager sur ce chemin. Quand bien même l’agilité à l’échelle porte ses propres limites.
Il n’y a aucune honte à cela et vous pouvez vous réconcilier avec SAFe.
Et si d’aventure votre coeur d’agiliste vous poussait vers davantage, n’ayez aucun regret.
Comme je l’ai dit et le répète : avec le bon accompagnement, l’un n’est pas nécessairement incompatible avec l’autre.
Si SAFe n’est pas la destination, c’est peut-être néanmoins l’un des meilleurs premiers pas…
Un voyage de mille lieues commence toujours par un premier pas.
Rhapsodies Conseil accompagne les Chiefs Data Officer ou toute personne ayant une responsabilité sur les données à tirer parti de cet actif stratégique.
Les dimensions et les activités à traiter pour augmenter la valeur des données sont nombreuses : usages, culture data, maîtrise et gouvernance des données, amélioration des compétences, technologies data… Indispensable pour une organisation qui veut gérer ses données comme des actifs stratégiques, le rôle de CDO est encore récent dans de nombreuses organisations, où il faut trouver la meilleure articulation avec les Métiers, la DSI, mais aussi la Direction Générale.
Nos collaborations avec différents CDO ont motivé la formalisation d’un cadre complet et opérationnel au service de la transformation data : “Le Framework du CDO”. Les fiches pratiques de notre Framework pose le cadre qui structure la mise en œuvre de la transformation data d’une organisation avec l’ambition d’être un guide et un accélérateur de cette transformation au quotidien.
La question de l’organigramme dans nos missions d’organisation surgit toujours, à un moment ou un autre, comme un diablotin hors de sa boite… Comment traiter ce sujet qui est l’objet de tant d’attentes ?
L’organigramme qui cache la forêt (de l’organisation)
Dans certaines entreprises, l’organigramme est mis à jour et diffusé régulièrement, dans d’autres, il est inexistant et implicite. Il peut être éternellement transitoire, ou parfois faux ou approximatif. Sa consultation et son analyse sont, dans tous les cas, essentielles pour comprendre une organisation.
Avant d’être une source d’information factuelle, l’organigramme porte une dimension symbolique, la répartition du pouvoir, réel ou supposé, au sein de l’entreprise. De ce fait, l’organigramme revêt une grande importance pour tous les collaborateurs, particulièrement pour ceux avec un positionnement hiérarchique, comme source d’affirmation de sa position dans l’entreprise : nombre d’échelons hiérarchiques entre soit et la direction, nombre de personnes encadrées, intitulés des postes et des entités, font partie des informations scrutées. Tout le monde essaye d’y lire « entre les ligne » et tout changement alimente frustrations et espoirs.
Lorsque que l’on conduit une mission touchant à l’organisation opérationnelle (optimisation des processus, évolution des modes de management, transformation des équipes, etc.), la question de l’évolution de l’organigramme finit toujours par surgir : va-t-il évoluer ? Qu’est-il prévu pour moi ? A quel moment sera-t-il publié ? Est-ce une version définitive ? Etc.
Même si les organisations ont changé, que les pyramides hiérarchiques ont été aplaties, que les postes de travail sont plus évolutifs, l’organigramme reste emblématique de l’organisation. Il demeure une source intéressante d’informations. Donc, pour tout projet de transformation, c’est une dimension importante à utiliser. Comment aborder le sujet ? Voici une liste de questions à considérer face à un organigramme.
En préambule, il faut rappeler que l’évolution de l’organisation, avec sa traduction dans l’organigramme, doit être soumise au CSE lorsque les changements sont structurels et substantiels. L’avis du CSE n’est que consultatif mais n’en est pas moins obligatoire. Il est bon de garder ce point en tête pour ne pas oublier de le traiter.
Venons-en à l’organigramme lui-même : comment le lire ? comment l’aborder ?
Le taux d’encadrement : il s’obtient en comptant le nombre de collaborateurs par manager et en divisant le tout par le nombre total de managers. Il permet de mesurer la taille moyenne des équipes. Plus le chiffre est bas, plus l’organisation est « pyramidale ». La multiplication de petites équipes, de moins de 3 personnes, doit interroger sur l’atomisation du management et la répartition de l’activité.
La lisibilité de l’organisation : est-ce que les fonctions ou les noms des structures correspondent à une réalité opérationnelle ? S’agit-il de fonctions-types sans rapport avec la réalité des rôles assumés dans l’organisation ? S’agit-il d’un organigramme statutaire et administratif? Il arrive parfois de constater que l’organigramme ne permet tout simplement pas de comprendre l’organisation.
Le degré d’alignement de l’organigramme par rapport aux besoins-cibles de fonctionnement : Il s’agit là de comprendre la répartition de l’activité et la logique d’organisation de l’entreprise. Est-elle construite par rapport aux chaînes de valeur (processus et missions), par rapport aux marchés (clients et produits -ou services-) ou encore par rapport aux compétences (logique de filières et de pool de ressources) ?
La capacité d’exécution : l’organigramme renseigne enfin sur les capacités de l’entreprise en nombre de collaborateurs. L’analyse du dimensionnement et de la répartition des collaborateurs complète l’analyse des compétences et de leur adaptation rapport aux missions à accomplir et aux postes à occuper.
Toutes ces questions à se poser sur l’organigramme aident à comprendre l’organisation, et viennent compléter les autres axes d’analyse : catalogue de service, processus, règles de fonctionnement, fiches de postes, gouvernance (instances et process de reporting et de décision).
L’organigramme est une riche source d’informations (explicites et implicites). C’est un instrument de management et de communication. Dans tous les projets touchant à l’organisation il faut se poser la question de l’organigramme et le cas échéant en faire l’objet de toutes les attentions, en se remémorant qu’au-delà du fonctionnement réel de la structure, il a pour les collaborateurs toute une dimension symbolique.
Lorsque l’on recherche sur Linkedin des experts en micro-services, les résultats sont nombreux… Y a-t-il une explosion des pratiques micro-services au sein des entreprises ou est-ce une surévaluation des expériences professionnelles ? Qu’est-ce qui nous rend pertinents sur le sujet ?
Qui fait réellement des micro-services ?
Ceux qui n’ont en fait pas compris ce que c’est…
Un micro-service est un service qui embarque des composants applicatifs et des données : nous entendons souvent parler de « frontal découpé en micros-services » ou « code applicatif découpé en micro-services » ou « j’ai créé un container Docker, j’ai produit un micro-service ».
Sans vouloir rentrer dans le débat de la pertinence de ces pratiques, nous pouvons affirmer qu’elles ne suffisent pas pour déclarer adhérer à une démarche micro-services.
Ceux qui font des micro-applications…
Il s’agit là de micro-services que nous n’avons pas besoin d’appeler micro-services.
Il s’agit d’une application, créée pour un besoin très spécifique.
Le découpage autour d’une seule API, liée à un domaine bien spécifique, pour un cas d’usage très précis, avec une base de données dédiée, est logiquement associable à un micro-service. Néanmoins, bien que l’appellation soit correcte, avoir contribué à ce type de réalisation ne nous rend pas forcément éligibles à des projets micro-services d’envergure…
Ceux qui font réellement des micro-services…
Seuls ceux qui y ont réellement contribué connaissent les vrais enjeux : sachez les identifier. Nous parlons ici d’une vraie approche micro-services qui suppose une réflexion data, mais également de l’orchestration et de la gestion de la cohérence.
Nous allons donc amorcer une première analyse de ces enjeux majeurs en nous focalisant surtout sur un des points clés de complexité : la gestion des adhérences entre micro-services (nous n’allons pas aborder les sujets de sécurité et gouvernance au sein de cet article, ils seront abordés dans une publication à venir).
Un micro-service, comme décrit dans le précédent article, doit être indépendant et isolé. Ces caractéristiques sont difficiles à obtenir quand le micro-service est créé et utilisé au sein d’un processus complexe demandant des orchestrations complexes.
Quels enjeux pour l’orchestration et la gestion de la cohérence des micro-services ?
L’orchestration des micro-services
Les micro-services, par leur nature, peuvent ne pas entièrement satisfaire à un processus ou à une étape de ce processus.
Pour pallier à ce besoin, une orchestration peut être réalisée en se basant sur des architectures de référence, selon le degré de complexité. Pour les cas les moins complexes, nous pouvons utiliser les backends des frontaux (avec par exemple une application BFF, Back For Front). Cette orchestration restera très spécifique à un cas d’usage. Il s’agit ici de l’enchaînement par exemple des appels vers deux micro-services, en lecture, car un seul ne suffit pas à garantir une expérience utilisateur complète (je retrouve les contrats d’un client et pour chaque contrat je lui montre les commandes associées).
Dans des cas plus complexes, ou hautement réutilisables, nous pouvons baser notre démarche sur d’autres outils. L’orchestration pourra alors être réalisée :
Par un moteur d’orchestration maison, spécialement conçu et dédié
Par des outils de BPM, qui peuvent y voir une seconde jeunesse après les promesses de la période SOA
Ces cas de figure permettent comme dit auparavant, également de mieux gérer le second point, la cohérence des données.
La gestion de la cohérence des micro-services
La cohérence canalise le sujet sur l’aspect données. Nous allons le résumer aux questions suivantes :
Comment assurer la cohérence si on travaille sur plusieurs bases de données ?
Rollback ? On se complique la vie avec les micro-services ?
On oublie l’ACID et on perd donc tous ses avantages ?
Probablement, ce qui va résoudre la moitié de ces cas de figure est le pragmatisme. Voici quelques exemples :
Un axe de simplification est porté par le découpage des micro-services : un découpage trop fin implique forcément une complexité croissante, donc attention à ne pas scinder là où on n’en a pas besoin.
Un autre est de s’assurer de la bonne conception fonctionnelle maximisant les couplages lâches entre les objets, les taches et les processus, pour qu’on ait le moins de rollback à faire si une des opérations orchestrées n’aboutit pas.
Un troisième est une analyse de la rigueur / la sécurisation demandée pour chaque cas d’usage. N’oublions pas que chaque information traitée demande une attention différente. Les données de tracking des utilisateurs sur mon site internet peuvent avoir un niveau de certitude inférieur par rapport à la gestion des transactions bancaires liées aux achats sur le même site.
C’est à partir de ces réflexions qu’on balaie une partie des interrogations et qu’on peut se focaliser sur les sujets complexes d’intégration et gestion des micro-services, demandant la mise en place de pratiques d’orchestration visant à pallier à ces sujets de cohérence.
Les exemples discutés dans cet article n’ont pas vocation à être exhaustifs mais aident dans l’élaboration et la mise en application d’une démarche micro-services.
Les contraintes imposées par une démarche micro-services obligent à une réflexion très structurée dès la conception. D’où l’importance, comme nous avons pu le dire auparavant, de ne pas se focaliser uniquement sur du découpage fin mais de bien mener la réflexion autour des données, des interactions, des orchestrations et de la spécificité de chaque micro-service.
NB : nous n’avons pas distingué l’orchestration et la chorégraphie des micro-services dans cet article, ce sera le sujet d’une publication à venir !
Le Télétravail va devenir la normalité : avec la reprise et les perspectives incertaines, c’est toute la chaîne de support IT et les modes de consommation de sourcing IT qu’il faudra repenser pour construire des solutions pérennes, performantes et adaptées.
En première ligne, les fonctions support IT (les héros directs du confinement) depuis plusieurs semaines, ont vu émerger de nouveaux besoins non identifiés auparavant, bousculant les habitudes des utilisateurs et mettant à mal les garanties de qualité et l’efficacité des services (dispositifs de support, solutions techniques, modèles de delivery) contractualisés avec des partenaires ou réalisés en interne.[br]Avec les perspectives de reprises, incertaines, le télétravail massifié, l’exigence de performance et la nécessité de garantir un niveau de qualité élevé pour les équipes IT, c’est toute la chaîne de support IT et les modes de consommation de sourcing IT qu’il faudra repenser pour construire rapidement des solutions pérennes, performantes et adaptées.
Dès lors, se posent une multitude de questions :
Quel modèle de delivery pour un nouveau support IT opérant encore davantage à distance et parfois chez les utilisateurs ?
Quelle organisation EUS mettre en œuvre pour s’adapter à ce nouveau modèle ?
Comment intervenir rapidement sur une panne de matériel informatique ?
Quels indicateurs de performance, modèle de gouvernance et outillages pour y parvenir ?
Comment accélérer, encore plus, la digitalisation des fonctions support IT ?
Comment modifier ses contrats de sourcing pour tenir compte du mode de travail à distance ?
Quelles adaptations contractuelles et de modèle économique faut-il prévoir ?
Comment optimiser les coûts de support dans un contexte de travail mixte : sur site et à distance ?
Après les défis relevés récemment par vous et vos équipes, il est temps de prendre du recul sur votre organisation et process afin de construire un plan de transformation de vos contrats de services support IT en toute sérénité.
Comment réduire le volume des sollicitations de votre support informatique ?
Comment tenir compte des nouvelles attentes métiers en révisant vos engagements de services ?
Comment assurer une disponibilité de votre support IT quelque soit la situation au travers des nouveaux canaux digitaux (ChatBot, Self-Service, Portail, Web callback …)
Comment transformer la crise sanitaire actuelle en une opportunité sur le long terme pour réorganiser votre Support IT ?
Comment faire de cette transformation nécessaire un levier d’optimisation de vos coûts de support IT?
Nous vous proposons de conduire un audit flash de votre contrat de sourcing IT EUS afin d’établir un livrable de préconisations d’évolution en tenant compte du double enjeu pour vous : assurer la continuité de votre activité post-confinement tout en tirant les enseignements de cette crise pour anticiper votre adaptation aux situations de travail de demain.
Faites évoluer vos contrats de sourcing IT
Une évolution importante du contrat classique de support IT est nécessaire. Les axes d’évolution de transformation des contrats de sourcing IT sont :
L’évolution du périmètre de service
Les nouveaux engagements de services (SLA)
Le modèle de delivery des infogérants intégrant la digitalisation du support
L’accélération de la digitalisation de la chaine de support
La nouvelle gestion du support de proximité
La gestion du parc et la logistique (mise à disposition des équipements)
Les nouveaux outils collaboratifs
L’évolution des modèles économiques
L’accélération de l’automatisation
L’évolution des coûts de prestation (ou coûts du support)
