SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe peut paraître inacceptable pour les agilistes confirmés.

Addressing some SAFe concerns par Michael Küsters

https://failfastmoveon.blogspot.com/2023/05/addressing-some-safe-concerns.html

Très souvent, je rencontre des préoccupations avec SAFe (Scaled Agile Framework). Lorsque l’on regarde la situation dans son ensemble, et ce que de nombreuses entreprises font de SAFe, ces préoccupations sont recevables et devraient être prises au sérieux. Pourtant, aucune de ces préoccupations ne pourrait être résolue par un consultant SAFe compétent (SAFe® Practice Consultant-T – SPCT) et une direction soucieuse de réaliser une différence significative dans ses méthodes de travail. Dans cet article, je considère certaines de ces préoccupations. Michael Küsters.

Préoccupations typiques avec SAFe

Avant de creuser, je crois que les compétences et l’expérience de vos consultants SAFe sont essentielles au succès de SAFe. Si vous comptez sur des gens qui ne comprennent pas les conséquences des conseils qu’ils donnent, vous êtes dans une situation difficile. Un de mes amis SPCT (SAFe® Practice Consultant-T – SPCT) a récemment déclaré :

Avoir les mauvais SPC (SAFe® Practice Consultant) – ou ignorer complètement les conseils d’un SPC – vous coûtera facilement dix fois plus cher que ce qu’un bon SPC vous coûterait.

Je suis d’accord. Les bons SPC valent leur pesant d’or. Malheureusement, ils ne poussent pas sur les arbres… Mais c’est une autre histoire. Maintenant, jetons un coup d’œil à certaines des préoccupations que je rencontre habituellement, et ce que vous devez considérer.

SAFe répond à l’état d’esprit traditionnel

SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe est écrit d’une manière qui pourrait être plus acceptable pour les personnes qui ont une faible compréhension de l’agilité. C’est l’idée de « rencontrer les gens là où ils sont ». Oui, c’est controversé, mais c’est de loin mieux que d’affronter les personnes mêmes dont vous avez besoin pour réussir un changement. Ce qui se passe après les avoir rencontrés dépend beaucoup de leur motivation à changer et de la capacité du SPC à mener le changement.

Complexité excessive

Tout d’abord, si vous n’avez pas les problèmes que SAFe adresse, ne l’utilisez pas. Ceci étant dit, SAFe ne peut pas et ne devrait généralement pas être appliqué dans son intégralité. Au contraire, lorsque vous repérez un problème pour lequel SAFe propose une solution, vous pouvez regarder ce que dit SAFe, avoir une discussion pour savoir si cela vaut la peine d’essayer. Et, si c’est le cas, alors allez-y.

Cela ne signifie pas non plus que vous devez faire des choses qui adressent des problèmes que vous n’avez pas, ni que vous devez faire les choses comme SAFe dit de le faire si cela ne fonctionne pas pour vous. Pour ma part, quand quelqu’un vient me voir et me dit : « Nous utilisons SAFe et avons tel ou tel problème », je me réfère généralement à un article SAFe, et les pointeurs originaux auxquels SAFe fait référence, et je prends la discussion à partir de là. Pour moi, SAFe est un déclencheur de discussion, pas la panacée à tous les maux.

Des dépendances partout !

SAFe reconnaît que les dépendances peuvent être un défi dans les organisations complexes. Il fournit des conseils et des pratiques clairs qui rendent les dépendances visibles, puis offre un moyen de traiter ces dépendances de manière systématique. Dans de nombreuses organisations, les dépendances sont inévitables mais au moins vous savez quels problèmes vous avez à cause d’elles, et vous pouvez commencer la discussion sur ce qu’il faut faire à leur sujet. J’ai vu plus d’une fois que les équipes trouvaient leurs dépendances irréalisables et décidaient de se réorganiser. Une excellente discussion à avoir.

Durée des intervalles de planification

SAFe utilise une approche de planification basée sur un cadencement avec des intervalles de planification (Planning Intervals – PIs) de longueur fixe s’étendant généralement sur 8 à 12 semaines. Des intervalles de planification plus longs offrent stabilité et prévisibilité aux équipes au détriment de la flexibilité. Cependant, vous pouvez ajuster la durée des PIs en fonction de votre propre contexte. J’ai vu des trains de livraison agiles exécuter 3 sprints de 1 semaine plus un sprint PI de 1 semaine. Cela correspond même au vieux slogan de Scrum, « Working Software in 30 days or less » – à grande échelle ! Essayez ce qui fonctionne pour vous et discutez.

Processus de planification descendants

Peut-être avons-nous une mauvaise image dans notre tête, mais qui peut nous en blâmer quand nous avons été conditionnés à penser en hiérarchies ? Dans un contexte SAFe, vous aimeriez décentraliser ce qui a du sens mais tout n’a pas de sens à être décentralisé. Par exemple, la fonction de Product Management dans SAFe pourrait être composée de Product Owners par équipe, s’ils ont les compétences et la capacité de réussir dans ce rôle, de sorte que cela n’a pas besoin d’être hiérarchique.

Ce dont vous avez besoin, c’est de vous concentrer clairement sur les plus gros morceaux de valeur et d’aligner toutes les équipes autour d’eux.

La façon dont cela se produit peut varier d’une organisation à l’autre, mais le fait que chaque équipe décide par elle-même n’augure rien de bon. Veuillez noter que SAFe encourage la participation active et l’autonomisation des équipes et des individus dans la prise de décisions.

Pas de vrai Scrum

SAFe n’est pas une implémentation stricte de Scrum, mais plutôt un cadre qui intègre des principes et des pratiques agiles provenant de diverses sources, y compris Scrum. Étant donné que de nombreuses équipes utilisent déjà Scrum et sont familières avec les concepts de base de Scrum, SAFe en a tiré parti et conserve les principes fondamentaux de transparence, d’inspection et d’adaptation.

Lorsque je coache des équipes SAFe, je me réfère souvent au Guide Scrum et suggère que comprendre et pratiquer Scrum aide beaucoup à bien mettre à l’échelle. Malheureusement, ce que je vois assez souvent, c’est que les organisations ont déjà utilisé un Scrum hautement dysfonctionnel depuis des années, et veulent maintenant changer cela. En fait, la transformation SAFe pourrait être l’occasion de réparer les trucs Scrum qui ont toujours été cassés et n’ont jamais été résolus.

Les équipes deviennent des usines à fonctionnalités (Feature Factories)

C’est déjà un dysfonctionnement parce que les fonctionnalités produites avec SAFe devraient se concentrer sur la valeur, pas sur la maximisation de la quantité de travail livré. Vous ne devriez avoir qu’un seul ART Kanban hiérarchisé par valeur et les équipes devraient collaborer sur des objectifs partagés, en utilisant des backlogs communs et des événements inter-équipes pour assurer une solution système cohérente qui maximise la valeur.

Alors que parfois, je constate que les équipes individuelles peuvent se concentrer sur la fourniture de leurs propres fonctionnalités indépendamment de la valeur.

SAFe fournit des mécanismes tels que les démonstrations système et les événements d’inspection et d’adaptation pour s’assurer que les équipes ne partent pas sur une tangente et effectuent une grande quantité de travail de faible valeur.

Processus d’estimation fallacieux

Il y a beaucoup à dire sur le processus d’estimation de SAFe, et j’ai ma propre opinion sur les conseils donnés. Pour faire simple: Ces conseils sont réservés aux personnes qui ne savent pas par où commencer. Le coaching et l’empirisme devraient conduire à une approche qui répond aux besoins de ceux qui ont besoin des estimations.

Vous devez réaliser que dans les grandes organisations, très souvent, plusieurs parties prenantes, d’autres équipes et potentiellement de grosses sommes d’argent dépendent de l’établissement de prévisions assez précises de l’achèvement. L’estimation peut avoir des implications qui n’existent pas dans des contextes plus petits.

Mon propre exemple est que nous devons absolument savoir si la fonctionnalité sera prête pour un salon précis ou si nous devons mitiger. Mais « Eh bien, nous pourrions ou être prêts à temps ou pas pour le salon » pourrait conduire à un désastre majeur en matière de relations publiques, et est probablement inacceptable.

Un événement d’amélioration continue tous les 3 mois, c’est trop peu, trop tard

Alors que l’événement Inspect and Adapt (I+A) se produit à la fin de chaque intervalle de planification (PI), SAFe encourage l’amélioration continue tout au long du PI, les Scrum-of-Scrums (SoS) et les rétrospectives étant des opportunités pour faire apparaître et résoudre les problèmes transversaux.

J’ai moi-même donné des conseils sur le fait que les équipes sont censées apporter leurs propres changements et améliorations indépendamment de l’événement I+A, et même partager leurs apprentissages avec d’autres équipes pendant cet événement. Je m’attends à ce que les équipes apportent des problèmes à court terme au SoS, et n’apportent à l’I+A que des problèmes qui nécessitent des périodes de préparation et d’observation plus longues, et ont un impact bien au-delà des limites de l’équipe. Surtout, vous devez considérer que le I+A est un point de réflexion, où vous vous détachez de la routine quotidienne et vous réunissez en tant qu’équipe d’équipes pour discuter des choses dont vous devez discuter et dont vous n’avez jamais eu l’occasion de discuter auparavant. Il y a toujours quelque chose. Oui, vous pourriez avoir de tels événements plus souvent si vous pensez que cela pourrait aider, il n’y a rien dans SAFe qui vous arrête. Essayez.

Conclusion

Je conviens que le Scaled Agile Framework (SAFe) a des domaines d’interprétation et suscite des préoccupations. S’attendre à ce que ce soit une solution miracle est complètement irréaliste. SAFe fournit une approche structurée pour les grandes organisations qui essaient de donner un sens à toute cette chose « Agile », mais cela ne fonctionne que si elles ont quelqu’un qui comprend plus que ce que dit le matériel. Lorsque vous pouvez faire face aux complexités du développement à grande échelle, de la collaboration entre les équipes et de l’alignement global tout en vous améliorant continuellement, vous avez réussi avec SAFe.

Pour y arriver, vous devez absolument personnaliser SAFe et l’utiliser à bon escient sinon cela deviendra un gâchis, et c’est pourquoi vous avez besoin de personnes qui savent de quoi elles parlent.

Et j’ai vu ce gâchis : La pagaille prend des années à nettoyer. Les personnes qui soutiennent votre initiative de changement doivent être en mesure de répondre aux préoccupations critiques en fonction de leur propre expérience et de leurs apprentissages. Et les personnes de votre organisation qui ont des préoccupations ont besoin d’un temps et d’un endroit où exprimer ces préoccupations car ce n’est qu’alors que vous pourrez vraiment vous améliorer.