Scaled Agile a lancé un effort de recherche sur les retours des clients et utilisateurs SAFe et c’est le plus important de son histoire : State of SAFe Report
Téléchargez ce rapport en langue anglaise.
Ce rapport 2025 donne un bon aperçu et analyse les informations partagées dans les réponses à l’enquête.
Sur de nombreux sujets, les commentaires reçus soutiennent la nécessité de simplifier les directives, de les rendre plus pratiques et adaptables, et de se concentrer davantage sur les résultats opérationnels plutôt que sur les processus.
La nécessité pour Scaled Agile de rendre SAFe encore plus facile à adapter en sort encore renforcée.
Et vous, quels sont vos retours pratiques sur SAFe ?
Même si je ne suis pas personnellement un grand fan de SAFe, une nouvelle version recèle toujours son lot de nouveautés dont nous pouvons toutes et tous apprendre : Voici donc SAFe 6.0 !
Cette version représente une avancée significative dans la façon dont les entreprises intègrent les pratiques SAFe dans le travail quotidien, font perdurer le changement et obtiennent les avantages d’une véritable agilité business.
Suite à la pandémie et au télétravail généralisé dans certaines professions et secteurs, de nombreuses personnes n’en sont encore qu’à envisager de retourner au bureau, ou pas…
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
Visitez le site SAFe
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
Guide téléchargeable gratuitement
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.
Lisez cet article en anglais.
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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Même si je ne suis pas personnellement un grand fan de SAFe, une nouvelle version recèle toujours son lot de nouveautés dont nous pouvons toutes et tous apprendre : Voici donc SAFe 6.0 !
Cette version représente une avancée significative dans la façon dont les entreprises intègrent les pratiques SAFe dans le travail quotidien, font perdurer le changement et obtiennent les avantages d’une véritable agilité business. SAFe 6.0 comprend de nombreuses nouvelles pratiques pour supporter les dernières tendances technologiques et business, y compris comment accélérer le flux de valeur et étendre SAFe à travers toute l’organisation à d’autres fonctions business.
Et, bien sûr, ces nouvelles directions se reflètent dans les mises à jour du didacticiel, de l’apprentissage en ligne et des ressources SAFe. Leading SAFe®, l’un des cours les plus populaires de Scaled Agile, est désormais disponible en français.
Pour tous les détails, lisez l’article What’s new in SAFe 6.0. Et n’oubliez pas de regarder les vidéos d’annonce de lancement de SAFe 6.0 pour en savoir plus sur SAFe Studio, SAFe 6.0 et d’autres nouveaux produits pour vous aider dans votre parcours SAFe.
Beaucoup de critiques concernant SAFe sont dirigées vers la prescription détaillée qu’il donne du « comment faire ».
Comment exécuter les rencontres, comment chaque rôle doit fonctionner, comment faire ceci ou comment faire cela.
SAFe peut être perçu comme un livre de cuisine détaillé qui répond à toutes les questions, et superficiellement, c’est vrai.
Oui, la documentation fournie par Scaled Agile, Inc est le livre de recettes officiel de SAFe.
Et oui, elle compose ce que nous connaissons officiellement sous le nom de SAFe.
Suivez cette recette, disent-ils, et vous cuisinerez SAFe correctement.
Mais.
Tout comme vous pouvez cuisiner un plat exactement comme le dit la recette, il n’y a aucune garantie que vous en aimerez le résultat. Et en ne suivant que des recettes, vous ne deviendrez jamais un bon cuisinier.
Si vous ne pouvez rien faire sans vous baser sur des recettes écrites par d’autres, vous pouvez avoir l’illusion que vous pouvez cuisiner, mais en réalité, vous ne le pouvez pas. Si vous le pouviez, vous n’auriez pas besoin de quelqu’un pour réfléchir à votre place.
Est-ce mal d’avoir des recettes ? Non.
Est-ce mal d’utiliser des recettes ? Non.
Est-il possible d’obtenir un bon résultat en suivant des recettes ? Oui.
Pouvez-vous construire votre avenir sur des recettes créées par d’autres ? Non.
#SAFe est excellent pour les personnes qui ne savent pas par où commencer et qui préfèrent ne pas partir de rien. Il vous donne de nombreuses instructions sur la façon de commencer.
À partir de là, vous devez (pour ainsi dire) apprendre à cuisiner par vous-même, sinon tout ne sera que gaspillage.
Surtout, si la seule chose que vos consultants SAFe peuvent faire pour vous est de vous relire ce que dit la recette, ils ne vous aident pas.
Si vous savez lire, vous pouvez lire la recette par vous-même. Ils ou elles doivent vous apprendre à créer vos propres recettes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Un risque asymétrique est un risque où la récompense potentielle l’emporte largement sur la perte potentielle. Identifiez et prenez davantage de ces risques.
La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. Ceci est un dysfonctionnement courant dans de nombreuses équipes Scrum, et en particulier dans les Agile Release Trains de SAFe où les équipes opèrent sur un horizon de planification de 3 à 5 sprints. Il en résulte un antipattern souvent appelé « Planification Tetris. » C’est extrêmement nocif, et voici pourquoi.
En tant que manager de projet et leader d’équipe, la sécurité psychologique est un élément essentiel de la création et du support d’équipes très performantes.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’Agilité est souvent fantasmée, parfois usurpée et trop fréquemment mal comprise.
Voici 12 mythes à garder à l’esprit pour éviter de se tromper quand on envisage d’adopter une approche Agile.
1. L’agilité est une mode
Fauxcar Scrum a été conçu en 1995, le manifeste agile a été écrit en 2001… Donc on ne peut pas dire que « c’est une mode ».
L’agilité est ancrée, durablement. Le 15ème état de l’Art sur l’agilité rappelle que 94% des entreprises ayant une composante de développement logiciel pratiquent l’agilité, et 65% de ces entreprises ont plus de 3 ans de pratique (source 15th State of Agile Report, Digital.ai)
2. L’Agilité, ce n’est que pour l’IT.
Faux: Même si les outils et méthodes utilisent souvent le vocabulaire de l’IT, j’ai personnellement eu l’occasion de voir que c’était aussi parfaitement adapté à d’autres projets de l’entreprise (Marketing, R&D, Juridique, Sécurité, Mécanique, Électronique…).
3. L’Agilité, c’est la meilleure façon de faire pour tout le monde, tout le temps.
Faux : L’agilité n’est pas la réponse à tout. Si vous êtes certain de votre périmètre, de votre techno, que les attentes des parties prenantes ne changeront jamais… alors ne le faites pas en agile.
Par contre, si l’un de ces domaines pourrait être amené à évoluer (combien de fois vos parties prenantes ont-elles changé d’avis sur les 2 dernières années ?), alors faites-le en Agile.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
4. L’Agilité, c’est moins cher.
Faux : L’agilité, entrainant un certain nombre de réunions supplémentaires, décomptées du temps de réalisation, va coûter plus cher que le même projet en cycle en V.
Rapport téléchargeable gratuitement en ligne
Cependant, un projet en cycle en V a beaucoup plus de chance de se « planter ». 29% des projets utilisant le cycle en V se sont plantés, contre 9% des projets agiles. (Source le Chaos report de 2015).
Si on prend en compte les rallonges, avenants… qui sont traditionnellement le lot des projets en cycle en V, il devient évident qu’un portefeuille de projets, menés en Agile coûtera moins cher que ce même portefeuille de projet menés en cycle en V.
C’est comme les trous dans le fromage : Plus il y a de trous, moins il y a de fromage et plus il y a de fromage, plus il y a de trous…
5. L’agilité peut être appliquée de la même façon dans toute l’entreprise
« One size fits all » est un gros mensonge. Portons-nous tous la même paire de chaussures ?
Les pratiques agiles doivent s’adapter aux équipes, aux métiers, aux projets…
Si vous changez l’un de ces composants, il vous faudra revoir le dispositif.
Une partie de Disciplined Agile a été construit dans ce but : Vous fournir le meilleur outil en fonction de votre problématique, de la complexité de votre domaine, de la complexité de votre solution, de la taille de vos équipes, de leur maturité… (cf. Disciplined Agile Browser).
6. L’Agilité, c’est facile
L’Agilité, c’est simple à comprendre… ça ressemble tellement à du « bon sens ».
Mais il faut comprendre ce qui est écrit en creux
Si on demande aux équipes d’être autonomes, auto organisées, cela implique que l’on supprime les « petits chefs » qui regardent leur montre quand quelqu’un part avant 18h…
Si on demande aux équipes de construire de la valeur, cela implique qu’elles aient accès aux utilisateurs (et non plus l’homme qui a vu l’homme qui a vu l’homme… qui a vu l’ours), qu’elles puissent re-prioriser le Backlog sans redemander la validation d’un comité de pilotage « Copil N+x »…
Si on demande aux équipes d’être efficaces, cela implique que ce qui a été produit va être mis dans les mains des utilisateurs pour recueillir leur feedback, à chaque itération (et non pas tous les 3 mois…)
Si on se permet des changements dans la méthodologie (« On fait du Scrum, mais… » ), on se retrouve trop souvent à avoir supprimé tout ce qui était compliqué, mais essentiel.
Cette liste n’est pas exhaustive. J’ai repris le schéma du ministère de la défense américain à propos de « Agile bullshit« .
L’Agilité demande de vrais changements « autour » de l’équipe. S’ils n’ont pas été entrepris, les équipes vont se décourager. Je suis convaincu que l’Agilité doit être conduite de façon sérieuse, voire disciplinée (cf. Disciplined Agile).
8. Passer à l’échelle, c’est rajouter des équipes agiles partout
téléchargez gratuitement le guide complet de 19 pages
Passer à l’échelle requiert une analyse de l’organisation actuelle et de comprendre ses faiblesses.
L’organisation à l’échelle devra avoir mis en place des solutions pour éviter de reproduire les problèmes de l’ancienne organisation.
Il est important de garder le lien avec les parties prenantes, ainsi qu’avec la vision du produit (et pour qui on travaille).
9. Passer à l’échelle, c’est mettre en place SAFe.
Seulement 37% des entreprises ayant mis en place une organisation agile à l’échelle utilisent SAFe (cf. 15th State of Agile Report).
Visitez le site SAFe
10. L’Agilité, c’est le Chaos. On a sacrifié la prédictibilité pour la réactivité.
Trop souvent, en acceptant un changementdemandé par le client, on oublie de lui rappeler les conséquences. On lui fait plaisir sur le moment, mais quand il faudra faire le bilan de 15 changements d’avis sur les 3 derniers mois, celui qui va payer la note ne sera pas content…
L’Agilité requiert une plus grande rigueur et discipline que sur un cycle en V car les conséquences sont visibles immédiatement (cf. PM2 de la commission européenne) d’où le nom de « Disciplined Agile ».
11. L’Agilité, c’est faire 2 fois plus vite pour 2 fois moins de temps
Jeff Sutherland, Creator of SCRUM
Même si Jeff Sutherland le promet dans son livre (“Scrum, The art of doing twice the work in half the time”), il est important de se rappeler que le père Noël ne vient qu’une fois par an…(et vous pouvez lui demander ce livre).
« 95% des performances d’un système viennent de la conception du système, et non des capacités des personnes qui travaillent dans le système » W.E. Deming.
J’ai un petit Serious Game pour le mettre en pratique, créé par Henrik Kniberg et mis à jour par Alfred Almendra.
Donc oui, on peut toujours améliorer les choses, tout en étant réaliste.
12. On peut faire une transformation Agile en 6 mois
Non. Celles auxquelles j’ai participé ont toutes demandé bien plus de 6 mois. Tout le monde ne travaille pas dans la Silicon Valley… Même Mc Kinsey le dit et parle de 1 à 3 ans.
Jean-Yves KLEIN, Certifié PMP, DASSM, PMS1, SAFe
Jean-Yves Klein
Ancien développeur, passé directeur de projet puis responsable d’agence, Jean Yves a basculé en 2008 sur la mise en place d’équipes agiles.
Coach Agile, il a accompagné plusieurs entreprises dans la mise en place d’organisations guidées par l’efficacité.
Il est intervenu en électronique, mécanique, marketing, et bien sûr en IT.
Il est membre du PMI Rhône Alpes, et formateur Disciplined Agile.
Il est aussi président d’OpenSeriousGame car c’est l’une des meilleures méthodes pour faire passer un message, que de le faire vivre. Il a créé Lego4DevOps, Lego4SAFe, DevSecOps.
partagez ce billet avec vos amis, collègues et relations professionnelles
La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard.
Ceci est un dysfonctionnement courant dans de nombreuses équipes Scrum, et en particulier dans les Agile Release Trains de SAFe où les équipes opèrent sur un horizon de planification de 3 à 5 sprints. Il en résulte un antipattern souvent appelé « Planification Tetris. » C’est extrêmement nocif, et voici pourquoi.
Bien que le plan de fonctionnalités ci-dessus semble être parfaitement optimisé, la réalité semble souvent différente : tous les articles génèrent de la valeur plus tard qu’ils le pourraient potentiellement; à un coût plus élevé, en demandant plus de temps et avec une efficacité moindre !
Accumulation des travaux en cours
La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. C’est efficace sur le plan des ressources (c-à-d. maximiser l’utilisation du temps disponible), mais pas du débit (c-à-d. maximiser le rythme auquel la valeur est générée).
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Cela mène à une augmentation du travail en cours, ce qui est un problème pour de multiples raisons
Déni de valeur
Tout comme dans l’exemple de diagramme ci-dessus, « Fonctionnalité 1 » et « Fonctionnalité 2 » pourraient chacun être finis en un seul Sprint. Et encore, Fonctionnalité 1 ne fournit aucune valeur dans Sprint 1, et Fonctionnalité 2 n’a aucune valeur dans Sprint 2. Donc, nous perdons 1 Sprint de mise sur le marché sur Fonctionnalité 1 (notre plus haute priorité) – et sur Fonctionnalité 2 aussi :
Un exemple parfait de la façon dont l’utilisation optimale de l’équipe fait arriver la valeur plus tard !
Perte d’argent
Imaginez maintenant que chaque fonctionnalité coûte moins cher qu’elle ne le vaut (ce qu’elle devrait, sinon elle ne vaudrait pas la peine d’être développée) et vous voyez que l’efficacité « économisée » d’avoir travaillé sur les caractéristiques 3 et 4 avant de terminer la caractéristique 1 coûte à l’entreprise plus d’argent que les bénéfices cumulés.
Perte d’efficacité
Vous pouvez argumenter que « différentes personnes travaillent sur les fonctionnalités, donc il n’y a pas de multitâche. »
Oui, et Non. Que se passe-t-il vraiment ?
Le Sprint Planning du Sprint 1 doit discuter de 3 caractéristiques : 1, 3 et 4. Cela signifie que toute l’équipe discute de trois sujets différents (dont aucun ne sera livré dans ce Sprint). La même chose se produit dans les réunions journalières et les revues. Et peut-être aussi au niveau du code source. Les interférences des fonctionnalités peuvent également alourdir la complexité de la configuration technique, des processus de déploiement et autres.
L’équipe devient plus lente, donc moins efficace.
Ajout de risques inutiles
Livre sur Amazon
Dans les statistiques, il y a un phénomène appelé « la probabilité élevée d’événements à faible probabilité ». Permettez-moi d’expliquer brièvement : Il y a une quantité infinie d’événements presque totalement improbables, mais malheureusement, l’infini élevé divisé par l’infini faible est encore un nombre proche de : Quelque chose va arriver. Vous ne savez tout simplement pas quoi, ni quand, alors vous ne pouvez pas vous préparer ni en atténuer les effets. Comme vous ne savez pas quel aspect de votre plan sera touché lorsqu’un risque frappe, vous serez toujours pris par surprise.
En quoi est-ce un plus gros problème dans la planification de Tetris que dans la livraison séquentielle ?
Effet massif de répercussions en chaine
Certains effets « dominos » sont quasiment impossibles à arrêter.
Lorsque vous travaillez sur un sujet et qu’un événement touche toute votre équipe, vous avez à communiquer sur un problème. Lorsque la même chose se produit alors que vous travaillez sur de multiples sujets, tous sont touchés, et vous générez un effet de répercussion en chaine beaucoup plus fort.
Mesures d’atténuation complexes
Comme plusieurs sujets sont en cours de traitement, vous vous retrouvez soudainement à limiter l’impact sur plusieurs sujets. Et cela signifie des efforts d’atténuation multiples : moins de temps pour travailler, et en même temps un risque plus élevé que toutes les mesures d’atténuation ne réussissent pas. Vous vous retrouvez avec une probabilité plus élevée de ne pas être en mesure de revenir sur les rails !
Conséquences chaotiques
L’effet des répercussions en chaine dans l’organisation et des mesures d’atténuation pourraient entraîner des conséquences imprévues qui sont encore plus difficiles à prévoir que l’événement déclencheur. Dans de nombreux cas, la seule solution possible est de dire stop et de marquer tous les sujets commencés comme retardés, puis d’essayer de réparer la casse à partir de là.
Préparez vous à l’échec
Relisez ce billet sur la Loi de Parkinson
Il y a la Loi de Parkinson – « Le travail s’étend toujours pour remplir la quantité de temps disponible« . C’est souvent utilisé comme argument pour commencer un autre sujet, parce qu’il arrête le sur-investissement et garde les gens concentrés.
Mais il y a aussi la Loi des moyennes : « Les plans basés sur les moyennes échouent la moitié du temps. »
Cette dernière fait de la planification Tetris une approche suicidaire d’un point de vue business : Elle enclenche un cercle vicieux.
Échec prévisible
Parce qu’il n’y a pas de marge de temps intégrée dans la planification Tetris, le plan à mi-parcours échouera automatiquement dès qu’une seule fonctionnalité s’avère plus complexe que prévue. Plus les fonctionnalités font partie de notre pile Tetris, plus il est probable qu’au moins l’une d’entre elles échouera. Et l’équipe sera généralement blâmée pour cela. Pour cette raison, nous nous retrouvons avec…
Des estimations prudentes
Les équipes doivent insérer des zones tampons dans leurs estimations de fonctionnalités afin de réduire la probabilité de défaillance. Lorsqu’un plan Tetris s’étend sur plusieurs sprints, il se peut que certaines fonctionnalités ne soient pas « prêtes » à être implémentées pendant le sprint lorsque la marge de manœuvre serait disponible – donc nous nous retrouvons avec la Loi de Parkinson, les estimations gonflées ne réduisent pas les probabilités d’échec.
Un débit en baisse
À ce stade, La loi de Parkinson se combine avec le défaut des moyennes pour mettre l’équipe KO. Indépendamment de la manière conservatrice dont les estimations ont été construites, l’équipe finira toujours par échouer la moitié du temps. La conséquence est que le débit business continue de diminuer (Jusqu’à un fond intéressant : quand un Sprint ne contient qu’une seule caractéristique !)
Étranglement de l’équipe
Examinons maintenant l’impact psychologique de la Planification Tetris.
Pas d’espace pour la créativité
Je n’ai jamais vu une organisation où le marketing produits était heureux que les développeurs ajoutent des « espaces créatifs » dans un plan Tetris. Il s’agit de lancer fonctionnalité, après fonctionnalité, après fonctionnalité, sans pause, sans pause. Lorsqu’une fonctionnalité est terminée, une autre est déjà en cours. Il n’y a pas de place pour la créativité.
Pas d’espace pour la croissance des personnes
Le seul résultat opérationnel pertinent dans les plans Tetris est généralement la valeur opérationnelle fournie.
Il ne tient pas compte du fait que les développeurs sont le capital humain de l’organisation, et leur croissance accroît la capacité de l’organisation à offrir de la valeur.
Surtout dans notre industrie technologique en rapide évolution, ne pas croître équivaut à reculer jusqu’à ce que finalement, l’équipe ne soit plus compétitive.
Pas de place pour l’amélioration
Je conseille souvent que les développeurs devraient prendre un certain temps pour regarder le travail « fait » pour réfléchir à comment il aurait pu être mieux fait, et de transformer cette meilleure façon en action. Avec Planning Tetris, cette opportunité n’existe pas car il y a toujours une autre fonctionnalité en attente et améliorer quelque chose qui existe est toujours moins important que de livrer la prochaine grande chose. Cela finit souvent dans des produits ratés qui ne sont pas un plaisir ni pour les développeurs ni pour les clients !
Maintenant… et alors ?
Le fait que la planification Tetris soit une mauvaise idée devrait être évident.
Mais alors, quelle est la meilleure façon ? pouvez-vous vous demander.
Cela semble incroyablement simpliste, parce que c’est aussi simple que cela.
Livre sur Amazon
Réduisez la quantité de fonctionnalités sur lesquelles l’équipe travaille en parallèle au minimum absolu. Cela minimise le rayon de l’explosion.
Au lieu d’avoir des gens en parallèle de multiples sujets, laissez les gens « inefficaces », « peu qualifiés » prendre des parties plus faciles du travail pour améliorer leur capacité. Cela réduit l’impact des événements à faible probabilité et donne à chacun de l’air pour respirer.
Donnez du mou dans les sprints. La résilience acquise peut absorber l’impact. Elle réduit également le besoin d’estimations gonflées, contre la loi de Parkinson et le défaut des moyennes. Elle donne également aux gens de l’air pour respirer.
Tirez : Soyez d’accord sur l’approche Pull-Forward. Lorsque l’équipe se sent sous chargée, elle peut toujours ramener les sujets futurs dans ces temps d’inactivité. Personne ne se plaint quand un sujet est fini à l’avance, tout le monde se plaint quand quelque chose arrive en retard. Le Pull-Forward n’a pas d’effets de répercussions en chaine ou de conséquences chaotiques.
Ok, trop de mots, alors pour faire court
Séquencez.
Donnez du mou.
Tirez.
Tous les problèmes mentionnés dans cet article sont alors résolus.
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a une citation présentant le contenu du PI Planning sur Scaled Agile Framework : “Il n’y a aucune magie dans SAFE® sauf peut-être pour le PI Planning”.
Regardons de plus près de la cérémonie du PI Planning et, se faisant, éclairons peut-être pourquoi il est considéré avec un tel respect.
La plupart des organisations qui mettent en œuvre SAFE® ne le mettent pas entièrement en œuvre. Mais s’il y a un dénominateur commun entre toutes ces mises en œuvre de SAFE®, c’est le PI Planning. Ainsi qu’est-ce que le PI Planning ? Et que signifie ‘PI’ dans PI Planning ?
Eh bien, PI signifie Programme Increment, un Incrément de Programme. Un Incrément de Programme entre dans une fenêtre de temps (timebox) de 8 à 12 semaines (le défaut étant 10 semaines comme recommandé par Scaled Agile Inc.). Cette timebox de 10 semaines encapsule 5 Sprints Agiles ou Itérations de 2 semaines. La 10ème semaine du PI se termine avec la Démonstration de PI où le travail construit pendant le PI est présenté aux parties prenantes. (Il est utile de noter ici, qu’un PI est un incrément d’un Programme entier. Un Programme est là où les équipes et autres ressources sont investies d’une mission de développement importante. Un Programme consiste donc en de multiples Incréments de Programme.
Comme le PI a 5 itérations avec des équipes multiples travaillant en cadence pour réaliser une vision commune, il est important pour ces équipes de se rassembler et planifier le cours des actions pour la durée entière du PI. La réunion aide aussi les équipes à comprendre quelles sont les dépendances entre elles et les risques à adresser. Cette réunion est appelée PI Planning. C’est une réunion complexe et détaillée d’une durée de 2 jours pendant la semaine 10 du PI.
Alors, qu’est-ce qui entre dans un PI Planning ?
La Vision du Programme et le Programme Backlog sont deux entrées principales et essentielles pour conduire une réunion de PI Planning. La Vision fournit le contexte à l’équipe entière sur pourquoi et comment le travail fait dans le PI aidera dans la construction de la Solution complète. Le Programme Backlog comprend des 10 premières fonctionnalités classées par priorité et accompagnées de descriptions courtes des bénéfices business que la fonctionnalité génèrerait.
Le Programme Backlog appartient au Product Manager qui est aussi responsable de s’assurer qu’on l’ordonne selon la priorité business en fonction de la réalité du marché et d’autres facteurs exogène. Les 10 premières fonctionnalités sont aussi accompagnées de Starter Stories (beaucoup d’histoires peuvent manquer, beaucoup ont besoin d’être décomposées ou sont des duplications dans les backlogs d’autres équipes). Ces Starter Stories permettent aux équipes de démarrer rapidement leur planification pour le PI.
Visitez le site SAFe
PI Planning
La réunion de PI Planning s’applique à l’équipe entière allouée au Agile Release Train et on s’attend à ce que chacun y participe. Si certains des membres d’équipe sont à d’autres emplacements géographiques, ils doivent participer à distance. La réunion de PI Planning est divisée en différentes sessions sur un créneau de 2 jours.
La réunion de PI Planning est organisé par le Release Train Engineer (RTE, aussi appelé le Scrum Master du Agile Release Train). Le RTE présente la Vision et les 10 premières fonctionnalités à la session inaugurale du PI Planning. Après cela, toutes les équipes entrent dans leurs sessions respectives où elles évaluent leur propre vélocité pour au moins les 2 premières itérations sur les 5. Les équipes mûrissent les fonctionnalités et les Starter Stories et évaluent leur taille. À la fin du premier jour, les équipes se réunissent avec les Business Owners, des architectes système et d’autres parties prenantes pour obtenir des clarifications et mettre en avant leur compréhension.
Le deuxième jour, les équipes entrent de nouveau dans des sessions spécifiques et détaillent encore davantage leurs backlogs respectifs. Chaque équipe formule une liste d’objectifs appelés des Objectifs d’Équipe et les Business Owners donnent chacun des objectifs un score de Valeur Business. Le score de Valeur Business est un chiffre entre 1 à 10 (10 pour la Valeur la plus élevée côté business, 1 pour la plus basse). Plusieurs objectifs peuvent avoir le même score de Valeur Business.
Après cela, chaque équipe présente son plan au groupe assemblé en entier. Le plan met en évidence les risques identifiés, les dépendances prévues et les objectifs agréés avec leur Valeur Business. Une fois que chacune des équipes a achevé sa présentation, une liste agrégée d’objectifs d’équipe est présentée et une liste agrégée de risques de Programme est aussi compilée.
L’équipe discute chacun des risques et les adresse avec l’approche ROAM (Resolved, Owned, Accepted, Mitigated). Finalement, il y a un vote de confiance où chaque équipe donne son score (entre 1 et 5) de confiance d’atteindre les divers objectifs. Si une équipe donne un score de moins de 3, ses membres doivent exprimer leurs réserves qui sont discutées avec le groupe entier. Le problème pourrait ajouter à la liste de risques ou exiger un peu de re-planification ou être simplement informatif. Si nécessaire les équipes retravaillent leurs plans jusqu’à ce qu’un fort niveau de confiance puisse être atteint.
La magie de SAFe tient en grande partie à ce qui va sortir du PI Planning.
Productions du PI Planning
Les productions de la réunion PI Planning sont les suivantes
Une liste d’Objectifs d’Équipe avec la Valeur Business, où les objectifs sont les résumés business de ce que chaque équipe a l’intention de livrer dans le prochain PI.
Il y a aussi des Objectifs additionnels que chaque équipe peut avoir choisi au cas où elle serait capable d’achever son travail et qu’une certaine bande passante resterait.
Les objectifs d’équipe sont agrégés et raffinés pour former les Objectifs complet du PI avec sa Valeur Business. C’est réalisé par le RTE après que la réunion de PI Planning soit finie et pas pendant la réunion.
Nous gagnons une compréhension de la vitesse de chaque équipe au minimum pour l’Itération 1 et 2, avec des histoires d’utilisateur de taille identifiée pour ces itérations sur lesquelles les équipes travailleront.
Une production importante du PI Planning est le tableau de Dépendance de Programme qui dépeint les Fonctionnalités / Histoires, les Dépendances et les jalons marquants. Les architectes et des membres d’équipe UX jouent un rôle clef pour aider à identifier ces dépendances.
Le PI Planning donne aussi une liste de Risques identifiés et comment ils ont été adressés à travers le mécanisme ROAM.
Rôles Principaux dans le PI Planning
Les rôles clefs et leur fonction pendant le PI Planning sont mis en évidence ci-dessous.
Business Owner – fournit la Valeur Business et l’approbation des Objectifs de l’Équipe PI
Product Manager – fournit les 10 premières fonctionnalités priorisées du backlog
RTE – présente le processus de planification et les résultats attendus
Product Manager et ScrumMasters– supportent les sessions d’Équipe et la décomposition des histoires
Équipes Agiles – mûrissent les fonctionnalités des Histoires d’Utilisateur pendant les sessions d’Équipe, identifient les risques et donnent le crucial vote de confiance
Architecte Système / – aide à établir des dépendances inter-équipe et les risques
QRP est partenaire de DantotsuPM
Épilogue
Le PI Planning sert la fonction importante de rassembler l’équipe entière et d’aider ses membres à gagner une perspective unifiée sur le travail qu’ils vont accomplir.
Les équipes entendent directement des Business Owners, les leaders organisationnels, comment le PI en cours de planification aidera l’organisation à s’approcher des ses objectifs finaux et quel est l’avenir attendu de la solution en construction.
Sur une note plus banale, les équipes sont capables de mettre en évidence les interdépendances et comment elles prévoient de les adresser avec succès. Ayant formulé les objectifs du PI, les équipes développent un sentiment d’appropriation pour les livrer.
La réunion de PI Planning est organisée dans la 5ème itération du PI qui est l’Itération de l’Innovation et de la Planification et n’a ainsi pas à être planifiée sur un créneau de temps complémentaire. Elle répond au besoin de perspective que les équipes désirent souvent mais obtiennent rarement. Elle distribue la planification et le contrôle du travail aux équipes qui sont en fin de compte responsables de sa livraison.
Avant que vous ne répondiez à cette saga surchauffée de courriels, voici comment éviter certaines bévues dans l’étiquette entourant l’usage de la messagerie électronique qui seraient potentiellement embarrassantes ou dommageables.
Un des principes du Manifeste Agile est “la Simplicité — l’art de maximiser le travail non fait — est essentielle”. Les études du Standish Group présentées dans l’un de leurs Chaos Report montrent que 60 % des fonctionnalités développées ne sont pas ou rarement utilisés. Si vous livrez seulement les bonnes, votre client obtiendra le produit beaucoup plus rapidement et à bien meilleur marché.
Considérer de manière critique les fonctionnalités du produit que vous développez est une façon de prendre en compte ce principe. Vous pourriez appliquer ce même principe au processus que vous utilisez pour développer votre produit. Combien de règles devez-vous suivre ?
Avez-vous jamais joué au jeu de Go ?
Le Go est un jeu de société de stratégie vieux de 2500 ans pour deux joueurs, dans lequel le but est d’entourer plus de territoire que l’adversaire. Malgré ses règles relativement simples, Go est déjà très complexe. Ou pensez au « jeu de la vie » de Conway sur l’automatisation cellulaire. Juste quelques règles très simples et des résultats stupéfiants. Ajouter davantage de règles aboutira au chaos.
CSP est partenaire de DantotsuPM
J’ai lu une histoire à propos des garderies d’enfants en Israël.
Ils faisaient face au problème e que certains parents venaient chercher leur enfant trop tard. Comme solution, ils ont mis en œuvre une nouvelle règle : Si vous venez chercher votre enfant en retard, vous devez payer une amende. Suite à cette règle même encore plus de parents sont venus récupérer leur enfant en retard. Ce qui était un compromis moral (je ne peux pas y aller trop tard) est maintenant devenu une transaction financière : je paie ma dette. Les règles ne sont pas nécessairement sacrées, les principes le sont.
Si vous regardez certaines structures agiles ou façons de travailler, vous pouvez vous demander si les concepteurs vous forcent à adopter une règle ou à la transgresser. Beaucoup sont pensées pour vous aider à construire des équipes d’équipes qui développent un produit ou un service, mais ici aussi, si vous pouvez réussir à ‘simplifier’ votre architecture vers des micro services vous n’aurez pas besoin de ces structures pour « monter en échelle/volume ».
Si vous comparez le nombre de règles de Scrum avec celles de SAFe, vous pourriez vous demander si vous réussissez sortir des agile release trainsgrâce aux règles SAFe ou malgré elles ?
Si vous voulez fonder un laboratoire d’innovation ou de croissance, assurez-vous de rester à distance de la bureaucratie. Pour réduire des obstacles, exemptez le laboratoire des règles d’entreprise, des procédures, des manuels, des directives, des principes et des formats. Les approches innovantes peuvent faire sans !
Jim Johnson, rêveur et président du Standish Groupe a partagé dans un interview pour un magazine de Managers de Projet des Pays-Bas : “L’analyse des données de projet a apporté des standards, des approches et des structures, bien que j’hésite en réalité sur les standards, parce qu’ils limitent la croissance. Toutes choses bien considérées, le réflexe de construire des structures accroit les chances d’échec d’un projet technologique. Des structures sous forme d’outils de gestion compliqués, trop de règles de gouvernance, des exigences professionnelles trop étroitement définies… Des structures construites avec les meilleures intentions rendent les projets plus lents, plus chers et plus consommateurs de temps. Des structures dans lesquelles personne n’ose prendre la moindre décision.”
Si vous recherchez l’agilité, pensez à une citation de Pablo Picasso “Apprend les règles comme un professionnel afin de pouvoir les briser comme un artiste”.
Ou avec mes propres mots : Utilisez le bon sens en appliquant des approches agiles ou façons de travailler et démontrez une mentalité agile en comprenant juste la logique plutôt qu’en suivant des règles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Cette vidéo explique les principes principaux de SAFe 5.0 en cinq minutes.
Elle comprend une explication des cadences, des cérémonies et des processus de Scrum et de SAFe applicables aux équipes, aux programmes, aux grandes solutions et aux portefeuilles de projets.
Aujourd’hui, la communauté des producteurs de matériel est dans la même position que la communauté du logiciel l’était il y a deux décennies quand ils ont connu une demande business en augmentation pour des livraisons plus rapides et de qualité très élevée.
What’s new in SAFe 5? SAFe for Hardware Development!
Beaucoup d’entre nous travaillent dans les organisations qui essayent d’améliorer la livraison de produit dans des solutions qui comprennent du matériel. Pendant que SAFe offre aux développeurs de logiciels une myriade de bonnes pratiques pour accélérer l’exécution, nous n’avons eu que peu à dire aux développeurs de matériels. Jusqu’à présent.
Aujourd’hui, la communauté des producteurs de matériel est dans la même position que la communauté du logiciel l’était il y a deux décennies quand ils ont connu une demande business en augmentation pour des livraisons plus rapides et de qualité très élevée. La communauté du logiciel a inventé de nouvelles pratiques comme les méthodes Agiles et l’intégration continue, qui a mené à des innovations technologiques comme des micro-services, les plateformes et l’infrastructure « as-a-service » et le management d’interfaces pour les soutenir.
Aujourd’hui, le business exige la livraison toujours plus rapide de matériel de haute qualité et de systèmes et sous-systèmes mécaniques. La pression est maintenant sur le développement de matériel pour découvrir que de nouvelles pratiques LEAN et Agile favorisent une livraison plus rapide de solutions.
Nous voyons maintenant que des pratiques Agiles commencent à émerger dans l’industrie du matériel. Les organisations utilisent avec succès des jumeaux numériques, l’impression 3D, le Circuit Imprimé (PCB) en un jour, les Développements Pilotés par les Tests dans la conception CAO, l’intégration continue et d’autres pratiques et technologies qui accélèrent la livraison de produit et en améliorent la qualité.
La dernière mise à jour de SAFe 5 inclut de nouveaux conseils pour ceux qui font face à ces défis particuliers.
L’article Applying SAFe to Hardware Development décrit 6 principes critiques pour aider les ingénieurs de matériels à mieux comprendre comment le développement LEAN-Agile s’applique à leur contexte.
Ces principes seront immédiatement reconnaissables pour ceux qui sont familiers de SAFe
Organisez autour de la valeur pour le développement de matériel
Embrassez la variabilité et préservez des options
Construisez de manière incrémentale, intégrez fréquemment
Concevez pour le changement
Exécutez le travail par petits lots
Intégrez la qualité dans la construction de matériel
Il est grand temps que LEAN et Agile traverse le fossé pour aider le matériel et les constructeurs de systèmes cyber-physiques à répondre aux demandes de l’ère digitale. Vous pouvez lire l’article complet en anglais ici.
Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).
Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets
Le manque de transparence cause des malentendus et des conflits.
Cependant, générer de la transparence a un coût.
Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.
Plusieurs des techniques les plus communes pour générer de la transparence
#1 – Le Contrat
Spécifiez ce qui peut et doit être partagé dans le contrat. Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre. Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu). Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.
#2 – Un Plan construit conjointement
Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres. La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur des risques et communiquer les dépendances en temps réel.
Matchware est partenaire de DantotsuPM
#3 – Des Cérémonies communes
Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies). Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives. Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.
#4 – Des Ateliers de mûrissement des exigences et de design
Collecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.
#5 – Des Modèles de design
L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.
Facile ET difficile à la fois
une plus grande transparence comme base de relations et de travail
Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.
partagez ce billet avec vos amis, collègues et relations professionnelles
Au début 2020, une nouvelle version de SAFe sera disponible. Elle est, comme d’habitude, entièrement compatible avec la version précédente SAFe 4.6, permettant une migration en douceur.
Il y a maintenant 7 compétences fondamentales qui permettent l’agilité dans le business. Certaines sont repositionnées et restructurées et 2 nouvelles compétences étendent SAFe afin qu’il englobe l’entreprise toute entière et permettent l’agilité d’affaires. Voir la nouvelle grande image de SAFe.
Les deux nouvelles compétences sont : Culture d’Apprentissage Continu (Continuous Learning Culture / CLC) et Agilité Organisationnelle (OA).
La Cultured’Apprentissage Continu est basée sur trois dimensions : L’Organisation Apprenante (vision partagée, systems thinking, modèles mentaux, apprentissage dans l’équipe, maîtrise personnelle), l’Amélioration Inexorable (un sentiment constant de danger, optimisation de l’ensemble, culture de résolution de problème, Prise de recul aux événements marquants principaux, l’amélioration basée sur les faits) et la Culture d’Innovation (les gens innovateurs, le temps et l’espace, aller voir, expérimentation et réactions, pivoter sans pitié ni culpabilité, innovations à contre-courant).
Les trois dimensions d’Agilité Organisationnelle sont : des gens pensant LEAN et des équipes agiles (house of lean, principes SAFe, Manifeste Agile), des Opérations LEAN (temps de traitement –temps d’attente – temps de traitement) et Agilité de Stratégie.
L’ancienne compétence DevOps et release on demand est maintenant appelée Livraison de Produit Agile (Agile Product Delivery). Ici nous voyons des développements sur la Cadence, la livraison sur demande, DevOps et le Pipeline de Livraison en Continu. Une nouveauté est la Position Centrée sur le ClientCustomer Centricity qui comprend : étude de marché, design avec l’utilisateur) et Design Thinking dans la Livraison Agile de Produit.
Livre sur mazon
Les équipes business de l’entreprise montent maintenant ‘sur le train’ et participent à la livraison et au support de solutions business innovantes. Ces équipes adoptent les valeurs, principes et pratiques Lean et Agiles.
Si je prends une vue d’ensemble de la forêt agile, je replace SAFe pour souligner que SAFe couvre maintenant, au niveau produit, cible produit ainsi que le choix de culture.
La boite à outils DA est un ensemble complet de connaissances agiles (un Body of Knowledge – BOK) qui fournit des conseils simples et pratiques pour aider les personnes, équipes et entreprises à décider de leur « façon de travailler » en fonction du contexte.
Parmi les principes clés
Être centré sur le client
Être pragmatique plutôt que puriste
Proposer une large gamme d’options agiles et LEAN
Adapter ses pratiques en fonction du contexte
Optimiser les flux dans l’ensemble de l’entreprise
CertYou est partenaire de DantotsuPM
Il s’agit pour les organisations d’adapter « leur façon de travailler » à leur contexte.
Disciplined Agile a compris la nécessité de personnaliser toute méthode ou toute approche, traditionnelle et prédictive, Scrum ou SAFe, afin d’obtenir des résultats qui les différencient de leurs concurrents.
La combinaison de PMI et DA offre donc une proposition de valeur nouvelle et attractive. Voici, je pense, pourquoi le PMI a fait cette acquisition. Elle lui permet de rester à la pointe dans le management de projet en utilisant de manière pragmatique des approches Agiles quand cela fait sens pour le projet.
PMI is a registered mark of Project Management Institute, Inc.
Si vous connaissez ou utilisez déjà Disciplined Agile, n’hésitez pas à me contacter pour partager votre expérience sur ce blog.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pas de surprise côté méthodes, SCRUMreste fortement majoritaire à plus de 50%, même si l’on commence à voir une percée des approches hybrides.
En ce qui concerne l’agilité à l’échelle, rien de très nouveau. SAFe continue de dominer. Même s’il n’est utilisé que dans moins du tiers des cas, SAFe distance cette année plus largement ses compétiteurs comme Scrum of Scrums.
Le point le plus positif selon moi du rapport est que les bénéfices attendus des projets Agiles sont au rendez-vous et dépassent même souvent les attentes des organisations.
Comme plusieurs sujets sont en cours de traitement, vous vous retrouvez soudainement à limiter l’impact sur plusieurs sujets. Et cela signifie des efforts d’atténuation multiples : moins de temps pour travailler, et en même temps un risque plus élevé que toutes les mesures d’atténuation ne réussissent pas. Vous vous retrouvez avec une probabilité plus élevée de ne pas être en mesure de revenir sur les rails !
L’effet des répercussions en chaine dans l’organisation et des mesures d’atténuation pourraient entraîner des conséquences imprévues qui sont encore plus difficiles à prévoir que l’événement déclencheur. Dans de nombreux cas, la seule solution possible est de dire stop et de marquer tous les sujets commencés comme retardés, puis d’essayer de réparer la casse à partir de là.
Parce qu’il n’y a pas de marge de temps intégrée dans la planification Tetris, le plan à mi-parcours échouera automatiquement dès qu’une seule fonctionnalité s’avère plus complexe que prévue. Plus les fonctionnalités font partie de notre pile Tetris, plus il est probable qu’au moins l’une d’entre elles échouera. Et l’équipe sera généralement blâmée pour cela. Pour cette raison, nous nous retrouvons avec…
Avec Planning Tetris, cette opportunité n’existe pas car il y a toujours une autre fonctionnalité en attente et améliorer quelque chose qui existe est toujours moins important que de livrer la prochaine grande chose. Cela finit souvent dans des produits ratés qui ne sont pas un plaisir ni pour les développeurs ni pour les clients !
DantotsuPM.com 