Quelques point d'attention pour la mise en oeuvre de SAFe

1. Quelques points d’attention à propos de l’Agile à l’échelle

2. Jérôme BataillerMichel Lejeune

3. Contexte & SAFe (10 mn)
Nos points d’attention (25 mn)
QuestionsRéponses (15 mn)

8.  Il n’y a rien de plus efficace qu’une équipe agile, sauf 15 équipes agiles qui collaborent.

9.  Il n’y a rien de plus efficace qu’une équipe agile, sauf 15 équipes agiles qui collaborent.
 A l’échelle, la non qualité ne s’additionne pas, elle se multiple.

10.  Il n’y a rien de plus efficace qu’une équipe agile, sauf 15 équipes agiles qui collaborent.
 A l’échelle, la non qualité ne s’additionne pas, elle se multiple.
 SAFe est aux Frameworks agiles, ce que le nucléaire est aux sources énergies.

12.  Ne pas se laisser entrainer pas l’aspect process de SAFe qui séduit le top management.

13. Démo/Release
EPI
C
Feature
Feature
Feature FeatureFeature
Feature
Story
Story
Story
Story
Story
Story
EPI
C
EPI
C
EPI
C
EPI
C
PortfolioProgramTeam
 Ne pas se laisser entrainer pas l’aspect process de SAFe qui séduit le top management.
 Veiller à l’émergence d’une véritable culture de l’Agile à l’échelle.

15.  Le niveau Program (ART ou Train) de SAFe est aussi couvert par d’autres Frameworks.
 On peut aussi synchroniser des équipes Scrum avec un simple Scrum de Scrum.

16.  Large Solution permet de synchroniser plusieurs Programs (Trains) à peu de frais.

17.  Large Solution permet de synchroniser plusieurs Programs (Trains) à peu de frais.
 Portfolio amène un dispositif agile de priorisation des Produits et de gestion budgétaire.

18.  Les trains de la DSI du Courrier (slide REX)

20. Si « La guerre est une chose trop grave pour être confiée à des militaires »
Georges CLEMENCEAU.
1er PIP (Program Incrément Planning),
le vote de confiance (nov 2017)

21. SAFe est sûrement une transformation trop périlleuse pour
être confiée à des consultants en organisation « non agilistes ».
2éme PIP, les risques, janvier 2018

22.  La hiérarchie des niveaux de SAFe est une pyramide de synchronisation down-top.
 Ce n’est pas une hiérarchie de management de type Command & Control.
 L’outillage doit donner le maximum de visibilité du bas vers le haut, pas le contraire.

23.  La hiérarchie des niveaux de SAFe est une pyramide de synchronisation down-top.
 Ce n’est pas une hiérarchie de management de type Command & Control.
 L’outillage doit donner le maximum de visibilité du bas vers le haut, pas le contraire.

24.  La hiérarchie des niveaux de SAFe est une pyramide de synchronisation down-top.
 Ce n’est pas une hiérarchie de management de type Command & Control.
 L’outillage doit donner le maximum de visibilité du bas vers le haut, pas le contraire.

25.  Avant le lancement du premier train, former chacun.e en fonction de son rôle.
 Penser à former les Métiers, prévoir une formation adaptée, SAFe n’en propose pas.
 Former très tôt, 2 ou 3 SPC (SAFe Program Consultant) au Centre Agile et au Codir.

26. 

27. 

28. 

29. 

32. 

33. Les Servant Leaders
du niveau Program
PM : Program Management
RTE : Release Train Engineer

 Le casting des PM et des RTE, leur formation, un accompagnement conséquent.

34.  Durant l’itération IP, ce n’est pas parce que l’on ne produit pas qu’on ne travaille pas.
 L’agilité à l’échelle avec SAFe a un prix = 2 semaines d’intégration et de
synchronisation.

35.  Durant l’itération IP, ce n’est pas parce que l’on ne produit pas qu’on ne travaille pas.
 L’agilité à l’échelle avec SAFe a un prix = 2 semaines d’intégration et de
synchronisation.

37.  Les Features ne sont pas des conteneurs d’User Stories, mais plutôt
un langage d’articulation avec les Métiers et les Utilisateurs.
 Faire en sorte que PM et PO soient capables de rédiger de vraies Features (PM Dojo)

38. Estimations et Story points - Blog Xebia – Expertise - blog.xebia.fr
 Veiller à garder l’estimation des US bien distincte de celle des Features.
 L’estimation d’une Feature ne se fait pas par addition des story points de ses US
filles !

39.  Pousser les équipes à déduire des Features proposées, les Objectifs du PI
 Les aider à rédiger des Objectifs compréhensibles par le PM
 Faire en sorte que le PM priorise réellement les Objectifs du IP (Increment Program)

40.  A l’échelle, l’excellence technique et l’automatisation ne sont plus des options :
 Intégration continue entre Team pour les System Démos
 Tests automatisés
 DevOps et Déploiement continu automatisé

41.  Chaque choix d’implémentation doit être conforme à tous les principes.
 Utiliser le principe 9 pour combattre le retour du Command and Control

42.  La gestion agile du portefeuille des Produits ou des Offres à travers un Backlog
d’Epics.

43. Garder à l’esprit que la « grosseur » des projets est un handicap.
Bien réfléchir à ce qu’il est possible de faire pour éviter de faire de l’agile à l’échelle.