| Formation | Tarif | Session 1 | Session 2 | Session 3 | Session 4 |
|---|---|---|---|---|---|
| SAFe Lean Portfolio Management 3j | 2600€ HT | 28/01/2020 | 21/04/2020 | 07/07/2020 | 17/11/2020 |
| SAFe For Architect 3j | 2600€ HT | 24/03/2020 | 16/06/2020 | 08/09/2020 | 08/12/2020 |
| Leading SAFe 2j | 1450€ HT | 09/03/2020 | 01/06/2020 | 28/09/2020 | 14/12/2020 |
| SAFe Agile Product and Solution Management 3j | 2600€ HT | A venir | |||
| Agile RH 2j | A venir | 02/03/2020 | 08/06/2020 | 21/09/2020 | 30/11/2020 |
Comme à son habitude, le framework d’agilité à l’échelle SAFe va proposer une nouvelle version majeure, la cinquième depuis ses débuts.
Plusieurs évolutions sont au menu, d’importance plus ou moins grandes. Par exemple, un nouvel onglet Overview vient résumer les « compétences » sur la page principale, l’étage portfolio se complète, l’orientation client prend une place centrale dans le framework, la notion d’agilité business fait son apparition, …
Mais est-ce tout ? Pas tout à fait…
Car là où SAFe 5.0 apporte une grande nouveauté, c’est sur sa posture vis-à-vis de la structure des entreprises. En effet, nous avions jusqu’alors un modèle orienté delivery qui ne présumait pas spécialement de la façon dont l’entreprise était organisée.
SAFe 5.0 semble (enfin) prendre position, notamment à travers deux introductions majeures :
On aurait d’ailleurs presque envie de voir cette dualité agilité du delivery versus agilité structurelle dans l’Overview, toutes deux supportées par le lean agile mindset au service d’une entreprise « orientée client ».
Si cette tendance se confirme dans la version finale de SAFe 5.0, cela sera une grosse évolution… et sans doute un gros argument de moins pour nombre de ses détracteurs !
Ces éléments nouveaux contribuent à porter l’agilité à l’échelle de l’entreprise en proposant une ébauche pour embarquer les fonctions support (RH, légal, finance, marketing) tout en intégrant la culture d’entreprise comme un facteur clé de succès pendant et après la transformation !
Nous continuerons à vous donner plus détail sur le blog au fur et à mesure que les informations arriverons.
SAFe 5.0: https://scaledagileframework.com/#
Pour aller plus loin :
Nos offres de conseil en entreprise agile.
Le PI Planning de SAFe concentre toutes les attentions tant cet événement est marquant dans la vie d’un incrément de programme. L’Inspect & Adapt, la cérémonie d’amélioration continue de niveau programme, est pourtant toute aussi importante et difficile à préparer que le PI Planning.
Comme dans toutes les cérémonies de niveau programme, c’est le RTE qui est aux manettes de l’Inspect & Adapt. Les participants sont les mêmes que ceux du PI Planning et de par sa nature hétérogène, elle nécessite aussi beaucoup de préparation.
L’inspect & Adapt se déroule en trois parties et dure en général 3 à 4 heures :
La démonstration système de l’Inspect & Adapt se déroule devant toutes les équipes du programme, les demandeurs et le management. Comme pour les autres démonstrations système, elle nécessite la collaboration du RTE, des Product Managers et de la System Team pour respectivement s’assurer de la logistique, des scénarios de démonstration et des environnements. A la différence des autres démonstrations système qui se déroulent en petits comités, celle-ci se déroule devant un large public et nécessite une logistique beaucoup plus importante. En effet, il faut que tout le monde puisse visualiser et comprendre la démonstration.
La revue des engagements de programme (PI objectives) ou d’équipe montre l’atteinte partielle ou totale des objectifs de PI fixés par le Business Owner lors du PI Planning. On y indique les causes d’atteinte partielle et le lien avec les fiches A34 qui vont être traitées dans la partie suivante si le problème doit être adressé.
Cette revue est préparée en amont entre le RTE, le Business Owner, les Product Managers et les Scrum Masters et Product Owner des équipes. Cette préparation permet de déterminer les taux d’atteinte des objectifs de PI et de formaliser les causes d’atteinte partielle des objectifs.
Cette partie fait le lien direct avec la résolution des problèmes qui suit. En effet, la cause d’atteinte partielle d’un objectif peut être due à un problème systémique identifié. L’impact de ces problèmes est d’autant plus criant qu’il concerne plusieurs équipes.
Les problèmes systémiques (ceux qui concernent plusieurs équipes du programme) sont identifiés lors des 4 rétrospectives des différentes équipes du programme. Lorsqu’un tel problème est découvert, le Scrum Master doit le formaliser sous la forme d’une fiche A3 et la donner immédiatement au RTE. Le RTE se charge alors de voir avec les autres Scrum Masters si le problème les concerne aussi, de valider le degré d’urgence de son traitement (immédiat ou durant l’Inspect & Adapt) et de consolider des métriques pour comprendre son impact.
Le RTE consolidant toutes les fiches A3 au fur et à mesure doit les challenger, les dédoublonner, les rapprocher si elles sont similaires, suivre leur résolution si elles doivent être traitées immédiatement.
Afin d’être efficace, ce travail de constitution des fiches A3 se fait donc tout au long de l’incrément de programme. Il est extrêmement difficile de constituer ces fiches au dernier moment en fin de Sprint 4, les équipes ont en général oublié une bonne partie de ce qui s’est passé en début de PI et sont trop occupées à terminer leur dernier Sprint pour réellement avoir le temps de s’occuper de formaliser ces fiches.
L’animation de cette troisième partie de l’Inspect & Adapt se déroule en sous-groupes. Dès la fin de la présentation des problèmes, formalisés sous forme de fiches A3, le RTE passe la main aux Scrum Masters pour animer des ateliers de résolution de problème en sous-groupes. Les sous-groupes sont constitués en temps réel autour des problèmes. Les participants d’un sous-groupe doivent avoir la capacité à résoudre le problème par eux-mêmes.
Les 6 étapes du Problem solving de l’Inspect & Adapt
Le RTE garde la main sur le cadencement des étapes 2 à 6, mais ce sont réellement les Scrum Masters qui en assurent l’animation, ils doivent être prêts à animer toutes ces étapes.
Chaque groupe doit ressortir de cet atelier avec une fiche A3 complète, une liste d’actions faisables dans le prochain incrément de programme et des porteurs identifiés au sein du groupe.
Les outils proposés par SAFe comme l’analyse causale grâce au diagramme d’Ishikawa1 (l’arête de poisson) ou les 5 pourquois2 ne sont pas simples à appréhender pour tout le monde. Avant même l’analyse causale, la formalisation des problèmes sous forme de fiche A34 est en elle-même une vraie difficulté si on n’y est pas formé. Le RTE doit impérativement former les Scrum Masters du train à l’utilisation des différents outils de l’Inspect & Adapt avant que le train ne démarre.
SAFe recommande l’analyse de problèmes pour la troisième partie, c’est effectivement efficace mais pas très positif. Certaines équipes peuvent mettre en place des outils ou des pratiques qui leur donnent une performance et un engagement meilleurs que les autres. Ce qui fonctionne bien peut être renforcé ou diffusé à d’autres.
Je vous recommande d’identifier plusieurs sujets de ce type avant l’Inspect & Adapt et faire travailler des groupes dessus au même titre que les problèmes, c’est bien plus positif !
L’Inspect & Adapt terminé, l’amélioration continue ne s’arrête pas là, il faut impérativement suivre l’avancement des actions que les groupes ont pris.
Les actions doivent avoir été planifiées dans des Sprints durant le PI Planning et celles-ci doivent être suivies par le RTE et les Scrum Masters durant l’ART Sync.
L’inspect & Adapt nécessite un véritable travail de préparation et d’anticipation tout au long de l’incrément de programme. Son efficacité a un véritable impact sur le moral des équipes tant lors de l’animation que lors du suivi des actions qui en découlent ; rien n’est plus frustrant que d’identifier des actions qui ne mènent à rien par la suite !
Aller plus loin : Notre offre de conseil en entreprise agile, Vous former à SAFe par la formation Leading SAFe.
Articles connexes :
1Diagramme d’Ishikawa : https://fr.wikipedia.org/wiki/Diagramme_de_causes_et_effets
25 pourquois : http://www.wikilean.com/Articles/Kaizen/1-La-resolution-de-problemes-20-articles/2-Le-5-pourquoi
3RTE (Release Train Engineer) : Scrum Master du programme SAFe.
4Fiche A3 : formalisme pour décrire un problème dans sous la forme d’une fiche qui tient au format A3. Exemple.
SAFe 4.5 est sorti le 21 juin 2017 et il nous offre une image revue et enfin simplifiée de la Big Picture et un framework destiné aux Lean Enterprises !
SAFe 4.5 apporte en effet 4 éléments principaux :
SAFe n’est officiellement plus réservé qu’à l’IT, SAFe for Lean System Engineering devient SAFe for Lean Enterprises. Ce changement de nom n’est pas anodin et démontre s’il le fallait encore que l’on peut appliquer SAFe à n’importe quel type de contexte dans l’entreprise. L’utilisant moi-même depuis des années comme démarche de transformation pour l’implanter lui même comme modèle opérationnel d’entreprise, je ne peux qu’approuver ce changement.
SAFe se décline maintenant en 4 configurations beaucoup mieux adaptées aux contextes de déploiements que l’on rencontre en entreprise. Dans tous les cas la Big Picture a subit un gros coup de lifting pour faire disparaître les éléments en double et donner plus d’espace à la lecture et la compréhension du schéma.
La version Essential SAFe
Cette version essentielle convient à la majorité des implémentations de SAFe ou à une première version d’un déploiement plus important. Fortement dépouillée, elle est beaucoup plus simple et abordable que la big picture précédente.
La version Portfolio SAFe
Cette version apporte la gestion de portefeuille et correspond au framework par défaut à trois couches que nous avions précédemment. La Big Picture est plus légère qu’auparavant grâce à l’utilisation de la palette sur le côté gauche.
La version Large Solution SAFe
Cette version ajoute à Essential SAFe le niveau Solution anciennement chaine de valeur, sans la gestion de portefeuille. Ce niveau a été fortement revu et son vocabulaire totalement simplifié afin que tout s’aligne sur le terme de Solution.
La version Full SAFe
Cette version intègre les 4 niveaux de SAFe équipe, programme, solution et portefeuille. C’est la plus complète et surement pas celle par laquelle on démarre lorsque l’on déploie SAFe pour la première fois dans une organisation.
La stratégie d’implémentation 1,2,3 qui consistait à passer quelques formations a vécu, elle était en effet beaucoup trop simpliste ! L’adoption de SAfe dans une organisation est une véritable transformation du modèle opérationnel de l’entreprise et pas seulement une affaire de quelques formations.
Même si cette nouvelle roadmap propose une trajectoire plus complète, elle reste encore bien trop simpliste pour adresser la transformation de modèle opérationnel que l’adoption de SAFe impose. Cette nouvelle version est encore une fois très centrée sur la formation aux différents rôles du framework et n’adresse pas réellement la reconception des processus, de l’organisation, de la gouvernance que l’adoption du framework impose. Elle passe sous silence le besoin fort d’outillage ALM / DevOps nécessaire pour supporter ces processus et encore plus l’effort de conduite du changement pour adopter la culture d’entreprise et les comportements des managers et collaborateurs adaptés à ce type de changement.
La meilleure façon d’adopter SAFe étant de l’utiliser lui même pour s’implémenter. Le pilotage d’une transformation organisationnelle en utilisant Essential SAFe est la meilleure stratégie pour l’adopter tout en validant au fur et à mesure que le framework s’adapte bien au contexte de l’entreprise.
Toutes les implémentations de SAFe nécessitent un fort besoin d’outillage ALM et DevOps pour assurer la performance du système. La 4.5 met l’accent sur le DevOps en introduisant une double boucle en 8 entre le développement et les opérations et met en exergue des pratiques qui étaient essentielles sur le terrain pour assurer la performance de fonctionnement.
Le DevOps est ainsi adressé sur ces différentes dimensions culturelle, d’outillage, d’intégration dans le flux de travail, de mesure et de sécurisation des mises en production.
Le flux jusqu’à la production est introduit dans le Kanban de programme gérant les Features. A mon sens ce flux de Release doit même être séparé de celui des Features pour devenir un Kanban à part entière et se connecter à la fois au Kanban de programme pour Releaser des Features, mais aussi à celui d’équipe pour Releaser Stories d’évolution et anomalies.
Qui ne s’est jamais posé la question : Les features doivent être Minimum Marketable Feature, mais que fait-on s’il faut un ensemble minimum de Features pour avoir un premier produit minimum viable (MVP) ?
La nouvelle mouture de SAFe intègre le Lean Startup au niveau du portefeuille d’Epic afin d’institutionnaliser un constat : un Epic est une très grosse exigence sur laquelle nous pouvons faire tout un tas d’hypothèses qui peuvent se révéler fausses : quel est l’élément le plus petit que l’on peut construire pour valider les hypothèses afin d’éviter la casse et s’orienter dans la bonne direction ?
Le Lean Startup étant essentiellement basé sur la roue de Deming et pronant un apprentissage très rapide, il s’intègre effectivement parfaitement avec le portefeuille d’Epics. Le débat qui peut ensuite subsister, porte sur le MVP pour chaque Epic ou un ensemble d’Epics pour constituer un MVP …
Enfin dernier apport de SAFe 4.5, l’intégration de Lean UX. L’intégration de l’UX dans le Kanban de programme et le Kanban d’équipe était l’affaire de spécialiste et d’une bonne dose de contextualisation. Sur ce dernier point l’article proposé n’apporte pas de réponses très importantes, mais des pointeurs intéressants vers l’ouvrage Lean UX.
L’agilité est régulièrement évoquée comme levier de performance globale dans le discours des grands dirigeants du CAC 40. Elle s’inscrit dans les stratégies des grandes entreprises telles qu’Orange, AXA ou le Crédit Mutuel. Mais passer d’une volonté stratégique à une réalité opérationnelle dans toute l’entreprise n’est pas simple. Le management intermédiaire se retrouve souvent perdu face à la transformation à mener et ne sait pas comment décliner opérationnellement cette intention. Vous découvrirez dans cet article comment opérer cet alignement de bout en bout.
Découvrez le nouvel article sur l’agilité d’entreprise publié dans IT Expert.
Issu du Framework SAFe, le rôle de RTE (Release Train Engineer) est le plus critique d’un bon déploiement de l’agilité à grande échelle. Le RTE pose le cadre méthodologique et veille à sa bonne application tout en améliorant le système au fur et à mesure. Maitriser le Framework ne suffit pas, le RTE doit aussi disposer de qualités humaines certaines pour pouvoir mener à bien ses missions.
La gouvernance du niveau programme de SAFe s’appuie sur le trio Release Train Engineer (RTE), Product Manager et System Architect. Là où le Product Manager est garant du contenu fonctionnel du train et le System Architect, garant de l’architecture, le RTE est garant du cadre méthodologique.
Le RTE met tout en œuvre pour que le train parte toujours à l’heure, qu’il puisse avancer en toute circonstances avec un contenu de qualité fourni par ses deux rôles partenaires.
Pour les adeptes de Scrum, le premier rôle visible et simple à appréhender du RTE est celui de Scrum master des Scrum Masters. Le RTE organise deux fois par semaines des ART Sync (voir l’article sur les ART Sync). Equivalents de Scrum Of Scrum avec les Scrum Masters et les Product Owners, cet événement a pour objectif d’identifier tous éléments pouvant bloquer tout ou partie du train agile et si nécessaire de définir les actions de contournement.
Le RTE veille à la montée en compétence des Scrum Masters des différentes équipes et à leur bonne appropriation des différents événements qu’ils doivent faciliter en commun.
Le RTE s’appuie en effet sur les Scrums Master pour faciliter l’événement principal de SAFe, à savoir le PI planning. Véritable grand-messe qui réunit l’intégralité des équipes agiles et des donneurs d’ordre du programme, cet événement réuni des dizaines de personnes qui doivent collaborer de manière efficace durant les deux jours pour débroussailler le travail sur plusieurs Sprints. Le RTE et les Scrums Master s’assurent de leur alignement durant les deux sessions de team breakout. Pour cela ils doivent se coordonner de manière étroite et rapide durant les deux jours. Faciliter un PI Planning revient à surveiller une douzaine de casseroles de lait sur le feu proches de l’ébullition… cela demande une vraie capacité à jongler et un calme olympien.
Pour préparer cet événement le RTE doit s’assurer de la qualité des Features qui lui sont fournis par les Product Managers et System Architects, de la logistique de la salle, des fournitures, de la présence des parties prenantes, de l’agenda des différentes interventions… une telle mobilisation de moyens humains ne peut être freinée par un détail de logistique.
Préparer un PI Planning nécessite une vraie anticipation !
Hormis cet événement majeur, le RTE facilite l’ART Sync, l’Inspect and Adapt, les Systems Demos et potentiellement aussi le Release Management.
Vous l’aurez compris, RTE est un job full time les différents événements de niveau programme nécessitent de la préparation, de la coordination et de l’anticipation, son rôle de développeur des Scrums Masters est tout aussi crucial.
Le RTE doit avoir une vrai qualité d’écoute et de pédagogie relationnelle, une grande capacité d’organisation, de synchronisation et d’anticipation et une vraie intelligence de situation pour animer le PI Planning.
Le RTE doit adopter une posture haute pour fixer le cadre dans les différents événements qu’il facilite et une adopter une posture basse quant au contenu de ce qui est produit. Son style de leadership doit être à la délégation, notamment dans le PI planning qu’il ne peut animer seul sans l’aide des Scrum Masters.
Indispensable au bon fonctionnement du train, le RTE ne doit pas se transformer en sauveur et porter sur ses épaules tout le poids du train !
Si vous souhaitez déployer SAFe dans votre organisation, consultez nos offres de conseil en transformation.
Vous souhaitez former votre futur RTE et les autres rôles de management d’un train SAFe, participez à une formation Leading SAFe.
Vous êtes RTE et vous souhaitez continuer à transformer votre posture, le coaching de manager est fait pour vous.
Que deviennent les vieux COPILs lorsque l’on passe à l’agilité à grande échelle avec SAFe ?
Dans une approche classique, les comités de pilotage servent à coordonner piloter les risques, les jalons principaux et les dépendances avec d’autres projets. Ils débordent souvent sur des aspects opérationnels et viennent souvent constater des dérives difficiles à redresser.
Pourquoi sont-ils si peu efficaces ?
La lourdeur de leur préparation et la présence d’acteurs peu disponibles imposent une fréquence assez faible (en général un par mois) qui autorise les projets à dériver sur une durée trop importante. En effet, sur un mois une équipe a largement de dériver du plan établi et se retrouver dans une situation difficile par manque d’arbitrage et d’alignement intermédiaire.
SAFe, le framework d’agilité à grande échelle propose un mécanisme très simple à mettre en place qui permet de créer un alignement quasi permanent entre les équipes et une gestion des risques au plus près : l’ART Sync. Cet événement bi-hebdomadaire de 15 minutes sous l’égide du RTE (Release Train Engineer) regroupe les Scrums Master et les Product Owners des équipes agiles du train1. L’événement se tient devant le Program Board et le Tableau des risques tous deux construits lors du PI Planning.
Deux questions simples se posent à chacune des équipes : y-a-t-il un Feature en risque dans l’équipe ? existe-t-il un risque systémique actif dans l’équipe ?
Si une équipe a un Feature en risque, le RTE propose alors de traiter en rechercher en séance une solution pour sécuriser sa production. Pour cela il s’appuie sur les autres équipes qui peuvent proposer leur aide ou en cas d’impossibilité, le RTE peut chercher à éliminer un Feature moins prioritaire (WSJF plus faible) et dégager la capacité pour sécuriser celui en risque. Si une solution est trouvée en séance, le train reprend son cours, les Scrum Masters et Product Owner pouvant immédiatement communiquer aux équipes les retours de l’ART Sync.
Si la recherche de solution ne peut-être résolue en séance, elle est traitée en aparté et peut nécessiter de mobiliser les parties prenantes du train pour arbitrer sur l’élimination ou la dégradation d’un Feature important du PI. Dans tous les cas, les risques portant sur le contenu de l’incrément de programme sont immédiatement rendus visibles aux parties prenantes qui peuvent arbitrer au plus tôt.
Se tenant à une fréquence bi-hebdomadaire, les ART Sync, ne laissent jamais dériver le train qui reste en permanence sur ses rails. Cet événement renforce la collaboration entre les équipes et le pilotage par la valeur central au fonctionnement de SAFe.
Pour aller plus loin, consultez nos offres de conseil sur SAFe et nos formations Leading SAFe.
1Train : ensemble des équipes agiles qui participent à la construction d’un incrément de programme dans le framework SAFe.
Déjà dans sa version 4, SAFe est le framework d’agilité à grande échelle le plus utilisé au monde avec des déploiements dans plusieurs grands groupes français.
L’équipe du DSI d’ING France accueillent ce premier rendez-vous Cour St Emilion dans leurs locaux. Cet événement est réservé aux DSI et à leur équipe de management. Il se présente sous la forme d’échange entre pairs, nous aborderons le thème de l’agilité à grande échelle avec le Framework SAFe. Vous pourrez profiter du retour d’expérience du DSI d’ING et de ses équipes. Vous pourrez ensuite échanger par tables sur vos retours d’expérience respectifs sur le déploiement de l’agilité dans vos organisations et profiter du retour d’expérience des équipes ING et des animateurs de l’événement.
Pour vous inscrire au groupe Meetup FSUG : http://www.meetup.com/fr-FR/French-Scaled-Agile-Framework-SAFe-User-Group/ et vous inscrire à l’événement.
En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.
Le PI Planning est l’événement le plus symbolique du framework d’agilité à grande échelle SAFe. Il regroupe l’intégralité des équipes agiles, le management et les parties prenantes du programme. C’est souvent une centaine voire des centaines de personnes qui collaborent intensivement pour organiser les travaux de l’incrément de programme sur lequel ils doivent travailler pendant plusieurs semaines.
Pour un manager n’ayant jamais vécu un tel événement, il est souvent perçu comme une dépense énorme alors que son ROI est tout juste incroyable !
Les clés pour réussir cet événement sont pourtant simples :
Le PI Planning a pour objectif d’aligner toutes les équipes du programme ou des programmes entre elles, de les engager sur des objectifs construits et partagés durant le planning, de les faire travailler sur leurs Backlogs de Sprints respectives et d’identifier leurs dépendances structurantes.
Ce PI planning repose sur le principe du manifeste agile qui pousse à privilégier la communication directe entre tous les membres du programme en un temps très réduit pour obtenir un consensus sur l’incrément à venir.
Les équipes sortent de l’événement avec une première version de leurs backlogs de sprints pour les itérations de l’incrément de programme et des objectifs pour chacun de leurs sprints.
Le management du programme sort avec un Program Board traduisant l’engagement des équipes à livrer leurs features lors des sprints de l’incrément de programme, des objectifs synthétisant cet engagement des équipes et une liste de risques à piloter durant l’incrément.
Les porteurs métier sortent eux en ayant l’assurance de l’engagement et de la compréhension des équipes par rapport à leurs enjeux.
L’important est donc de focaliser les équipes sur l’analyse de leurs features et leur découpage en stories, l’analyse de ces stories à un premier niveau de maille permettant d’en estimer la complexité. Ce travail doit leur permettre rapidement de construire leur Sprint Boards, d ‘identifier les dépendances avec les autres équipes et d’identifier les risques à adresser.
Il faut faut veiller à ce que les équipes ne fasse pas un travail trop en profondeur pour une partie de leurs travaux et ne soient pas en capacité d’avoir une vision large de leurs travaux.
L’événement dure 2 jours complets, mais les bénéfices sont énormes : à la sortie du premier PI Planning auquel j’ai assisté, un des directeurs informatique nous a dit :
« Nous n’avons jamais pris autant de décisions en si peu de temps, si nous avions dû programmer des réunions pour nous caler, nous aurions mis des semaines pour nous accorder et cela aurait couté extrêmement cher ! »
En effet, du fait de la présence de tous les acteurs en un même endroit, les décisions sont prises extrêmement rapidement et en ayant toutes informations pour être prises de manière éclairées.
Le PI planning regroupant l’intégralité des équipes agiles et le management, on ne peut se permettre de le rater, sa préparation doit être impeccable et les équipes ne doivent pas être freinées durant leurs travaux par des problèmes de logistique ou de disponibilité d’acteurs clé pour décider.
Concernant la logistique, la salle doit être suffisamment grande pour accueillir tout le monde et doit disposer de surfaces murales permettant de travailler directement dessus avec les Postits géants. Les fournitures à prévoir et à pré organiser sont elles aussi assez nombreuses, l’idéal étant de se référer à l’ART Launch Pack fourni par Scaled Agile pour calculer au plus juste les éléments à préparer si vous ne l’avez jamais fait.
La disponibilité des personnes clé permettant d’arbitrer, de découvrir, de comprendre les features que les équipes doivent s’approprier est fondamentale. L’événement étant à une fréquence connue à l’avance, il faut bien veiller à la présence des Epic Owners, des Product Managers, des Business Owners et de toute personne étant utile aux équipes, la qualité du travail des équipes et leur capacité à s’engager dépend grandement de la présence de ces personnes durant les travaux en équipes.
Pour faciliter la présentation et rappeler à tout le monde le fonctionnement du PI Planning au fur et à mesure, nous vous recommandons de créer un jeu de slides tout préparé que vous pouvez utiliser d’un PI à un autre et qui préciser pour chaque partie de l’agenda le fonctionnement et les règles d’acceptation du travail produit.
Selon mon expérience, Scaled Agile dispose de suffisamment de recul pour proposer un fonctionnement qui doit marcher du premier coup dans tous les contextes. Il est très tentant d’essayer d’optimiser le PI Planning en cherchant notamment à en réduire le cout en réduisant la durée, les équipes présentes, mais le résultat est très rapidement décevant et l’on se retrouve face à un gâchis.
Commencez donc par suivre à la lettre ce qui est proposé et profitez de la rétrospective en fin de chaque PI Planning pour l’améliorer et le contextualiser à votre organisation.
Le PI Planning est un exercice de transparence et d’explication à grande échelle. Le management vient expliquer les enjeux de l’entreprise qui sont adressés par l’incrément de programme, les Thèmes Stratégiques qui couvrent ces enjeux, les Epics sélectionnés qui réalisent les Thèmes Stratégiques et enfin les Features de l’incrément de programme sur lesquels les équipes vont travailler et qui contribuent aux Epics sélectionnés.
Cette compréhension de bout en bout de la valeur des travaux de chacune des équipes et chacun des équipiers est fondamentale pour leur motivation. L’émulation créée par le travail collaboratif durant ces deux jours à la fois au sein de chaque équipe et entre les équipes crée un réel esprit de corps qui s’aligne à réaliser les objectifs de l’incrément.
Pour atteindre cette motivation, le management doit travailler son leadership, sa pédagogie relationnelle et laisser les équipes autonomes pour travailler selon la vision proposée. Attention à l’interventionnisme, ou au reflexes de commande / contrôle issus des méthodes traditionnelles. La réunion de management en foin de première journée doit être expliquée le lendemain avec pédagogie et les solutions trouvées ou proposées de manière collaborative avec les équipes.
L’idéal pour réussir cet événement est de s’appuyer sur un SAFe Program Consultant expérimenté apte à vous guider dans sa préparation et son déroulé, vu l’enjeu de l’événement vous ne pouvez vous permettre de le rater.
En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.
Avec la sortie de SAFe 4.0, Scaled Agile Inc frappe fort et nous propose une version 4.0 du framework d’agilité à grande échelle qui apporte une réponse aux grandes différences d’échelles auxquels il est utilisé et qui fusionne enfin les versions logicielle et d’ingénierie système du framework.
La version 4.0 apporte ainsi le support d’un niveau permettant de gérer des milliers de personnes et de construire des systèmes complets incluant du logiciel et du matériel. Cette version apporte une plus grande modularité dans son adaptation au contexte spécifique dans lequel il est déployé en faisant figurer clairement les stratégies d’adaptation à partir de principes de base. Très fortement employé au sein des équipes agiles, SAFe 4.0 fait la part belle au système de Kanban à tous les niveaux du framework. Enfin SAFe 4.0 réaffirme très fort l’implication nécessaire des managers leaders comme porteurs du changement et comme support des équipes.
SAFe 4.0 ajoute un niveau optionnel intermédiaire qui porte les chaines de valeur de l’entreprise. Il permet aux très grandes organisations de structurer leurs ARTs (grandes équipes agiles au sens de SAFe) sur ces chaines de valeur de l’entreprise et de les aligner sur une vision commune. Ce niveau, qui permet maintenant de gérer plusieurs milliers de personnes, a pour objectif de construire une solution complètement intégrée reposant sur un assemblage de logiciel et de matériel pour un client. Le client est encore mis plus au coeur de la construction itérative de la solution que l’on construit pour lui.
SAFe 4.0 distingue les chaines de valeur opérationnelles (ex. la chaine de valeur de commande ou la facturation), des chaines de valeur de développement des systèmes qui supportent ces chaines de valeur opérationnelles. La coordination entre chaines de valeur dépendantes est maintenant assurée par ce niveau chaine de valeur en introduisant la notion de points d’intégration entre chaines de valeur. Cette coordination est assurée par les trois rôles Value Stream Engineer (VSE), Solution Management et les Solution Architects. La coordination à proprement dite est assurée par deux points : pré-PI Planning et Post-PI Planning pour valider les dépendances et l’alignement sur les capacités à développer dans la backlog de chaine de valeur qui est répartie entre les multiples équipes programme.
Le framework introduit une évolution du framework de pilotage économique permettant de prendre des décisions éclairées à niveau de maille chaine de valeur. Pour préserver les différentes options au cours de la construction de la solution, SAFe 4.0 introduit la notion de “Solution Intent” qui définit un système de balance entre architecture intentionnelle et exploration d’architecture au fur et à mesure de la construction.
Enfin, ce niveau ajoute le support et l’intégration de fournisseurs dans la construction de cette chaine de valeur.
Pour tenir compte du niveau chaine de valeur, le niveau portefeuille accepte maintenant la gestion de portefeuilles multiples avec pour chacun une allocation budgétaire dédiée et un système d’allocation commun à tous.
Les thèmes stratégiques servent maintenant de pivot entre le top management et les responsables du portefeuille. Sur le terrain, j’ai effectivement constaté que la manipulation des Epics par le Top Management est impossible car trop fin. Le Top Management alloue maintenant des budgets sur ces thèmes stratégiques, la déclinaison opérationnelle étant à la charge du portefeuille et de(s) l’ART(s). Le budget du portefeuille n’est plus alloué au ART mais directement au chaines de valeur.
La version standard de SAFe à trois niveaux a été simplifiée pour tenir compte des remarques de la communauté, notamment sur le vocabulaire employé. Par exemple le Release Planning devient le PI Planning ce qui semble plus logique.
La Big Picture peut-être visionnée avec 3 ou 4 niveaux permettant ainsi de se balader entre les deux vues très simplement.
Les fondations de SAFe ont été ajoutée directement sur la “Big Picture” permettant ainsi d’affirmer leur importance avec notamment l’introduction des “SAFe principles” et du “Implementing 1, 2, 3” vous guidant dans le déploiement et l’adaptation de SAFe à votre contexte.
Les pratiques Kanban de niveau équipe ont été intégrées de manière beaucoup plus poussées que dans les versions précédentes permettant ainsi de mixer des équipes Scrum et des équipes fonctionnant en Kanban.
Présentes dans le modèle Spotify, les communautés de pratiques faisaient défaut dans SAFe jusque là. Elles permettent de tenir compte de l’organisation en réseau nécessaire aux équipes agiles pour diffuser le savoir entre des équipiers, Scrum Master ou Product Owner répartis dans des équipes agiles différentes. Cette pratique favorise la capitalisation des savoirs faire et participe à l’alignement global des équipes.
Le system de Kanban, initialement au niveau portefeuille, est maintenant étendu aux niveaux chaine de valeur et programme assurant ansi une gestion du flux et des limites de travail en cours de manière homogène de bout en bout. Déjà très souvent utilisé au niveau équipe en ScrumBan ou Kanban direct, le kanban est aussi introduit au niveau programme pour gérer notamment l’état de complétude des features avant de les proposer aux équipes (Definition Of Ready du Feature).
L’introduction du niveau chaine de valeur a imposé d’introduire des éléments de backlogs supplémentaires et de les mettre en cohérence les uns avec les autres. Le triptyque simple de départ Epic, Feature, Story avait déjà été étendu en cas de multiples ART avec les quatre éléments Portfolio Epic, Program Epic, Feature et Story. Maintenant si vous utilisez le version à 4 niveaux de SAFe, vous avez Epics / Capacities / Features / Stories.
Tous les éléments ou les fonctions qui sont utilisables à plusieurs niveaux de SAFe sont regroupées dans cette nouvelle “Spanning Palette”. Elle regroupe d’une part les artefacts d’alignement tels que la Vision, la Roadmap, les Métriques, les milestones et les releases et d’autre part les équipes transverses telles que les DevOps, la System Team, le Release Management, la User Experience et les services partagés (experts intervenant au besoin). Vous pouvez décider d’utiliser ces éléments aux niveaux portefeuille, chaine de valeur, programme ou équipe selon vos besoins, le framework n’impose rien ici.
Cette notion chapeau d’enabler regroupe les anciennes notions d’epic technique, de feature d’architecture et de spike. Elle a pour objet de montrer que ces éléments n’apportent pas de valeur intrinsèque, mais qu’ils servent bien à construire les éléments à valeur ajoutée métier qui les utilisent. A partir de maintenant la hiérarchie d’exigences techniques s’exprime ainsi : Enabler Epics – Niveau Portefeuille, Enabler Capability – Niveau Chaine de valeur, Enabler Features – niveau Programme, Enabler Stories – Niveau Equipe. Les enablers peuvent être catégorisés en exploratoire, architecture ou infrastructure.
Dores et déjà les grands éditeurs qui supportent le framework proposent de nouvelles version de leurs suites d’outils :
Pour les SAFe Program Consultant (SPC) comme moi-même, cette version impose un retour par la case certification.
En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.