Retrouver les slides sur : https://speakerdeck.com/denisagile/transformation-agile-arretons-de-suivre-aveuglement-des-frameworks

Exemple d’un objectif clair et mesurable

Exemple de transformation de la direction

Baser les jalons sur une évaluation objective des systèmes de travail.

—Principe Lean-Agile #5

La System Demo est un événement important qui fournit une vue intégrée des nouvelles Features de la dernière itération proposée par toutes les équipes du train Agile Release Train (ART). Chaque démo donne aux parties prenantes de l’ART une mesure objective des progrès accomplis au cours d’un Programme Increment (PI). Une démonstration du système est un événement critique. Il s’agit de la méthode permettant de recueillir immédiatement les réactions des personnes qui effectuent le travail, ainsi que des Business Owners, des sponsors, des parties prenantes et des clients. La mesure réelle de la valeur, de la vitesse et du progrès est la démonstration du travail entièrement intégré de toutes les équipes lors de la précédente itération. Planifier et présenter une System Demo utile nécessite du travail et de la préparation de la part des équipes. Mais c’est le seul moyen d’obtenir rapidement le retour d’information nécessaire pour construire la bonne solution.

Détails

L’objectif de la démonstration du système est de tester et d’évaluer le système complet dans l’environnement de staging sur lequel l’ART travaille et d’obtenir les commentaires des principales parties prenantes. Ces parties prenantes comprennent des Business Owners, des sponsors exécutifs, d’autres équipes agiles, des responsables du développement, des clients (et leurs mandataires) qui fournissent des informations sur l’adéquation de la solution en développement. Le retour d’information est essentiel, car ils sont les seuls à pouvoir guider (voir la figure 1) le train doit rester sur sa trajectoire ou prendre des mesures correctives.

Figure 1. La System demo

La System Demo a lieu à la fin de chaque itération. Il fournit une vue intégrée et complète des nouvelles fonctionnalités fournies par toutes les équipes du train lors de la dernière itération. Il offre à l’ART une mesure factuelle des progrès actuels au niveau du système au sein du PI. C’est la seule mesure réelle de la vitesse de l’ART. Pour ce faire, vous devez mettre en œuvre les pratiques d’ingénierie évolutives nécessaires à la prise en charge de l’intégration et de la synchronisation dans ART. À la fin de chaque PI, l’ART tient une dernière démonstration du système PI. C’est une affaire quelque peu structurée et formelle, dans la mesure où elle présente une augmentation qui inclut toutes les fonctionnalités développées au cours de l’IP. Cette démonstration fait généralement partie de l’événement Inspect and Adapt (I&A), qui alimente les métriques rétrospectives et les progrès de du PI, y compris la «mesure de prévisibilité du programme» et les «métriques de performance du programme».

Remarque : l’environnement de staging est le mieux adapté à la démonstration système, car il reflète généralement autant que possible la production. Dans les grands trains de solutions, la démonstration du système est intégrée à la démonstration de solution.

Le timing de la System demo

La System Demo a lieu le plus près possible de la fin de l’itération, idéalement le lendemain. Il peut y avoir certaines complications, ce qui peut rendre ce moment impraticable. Ceux-ci inclus:

• En règle générale, les résultats de l’intégration complète ne sont disponibles qu’à la fin de l’itération. (Bien entendu, l’objectif est de rechercher l’intégration continue sur toute la pile, mais ce n’est pas toujours faisable.)
• De plus, chaque nouveau incrément peut nécessiter des extensions de l’environnement de démonstration, de nouvelles interfaces, des composants tiers, des outils de simulation, etc. Bien entendu, la System Team et les équipes agiles peuvent planifier cette opération, mais certains éléments de dernière minute sont inévitables.

Cependant, la System Demo doit avoir lieu dans les délais de l’itération suivante. Sinon, le retour d’information aux équipes sera retardé, ce qui mettra potentiellement le PI en danger. L’ART doit faire tous les investissements nécessaires pour permettre à la démonstration du système d’intervenir rapidement.

Équilibrer l’effort d’intégration et les commentaires

La démonstration du système a pour objectif de tirer parti des expériences de développement les plus récentes et d’ajuster le cours des actions. Toutefois, lorsque les préoccupations relatives à un logiciel ART, au matériel, aux systèmes mécaniques et aux composants fournis par le fournisseur s’étendent, l’intégration de tous les actifs toutes les deux semaines risque de surcharger les capacités et de générer un coût de transaction inacceptable. Simplement, l’intégration continue peut ne pas être économique ou pratique dans de tels environnements.

Cependant, l’intégration différée, voire aucune intégration, est bien pire. Il inhibe considérablement l’apprentissage et crée un faux sentiment de sécurité et de rapidité. Par conséquent, si cela n’est pas pratique, il est essentiel de trouver le bon équilibre et d’améliorer continuellement l’intégration et les tests automatisés afin de réduire le coût des intégrations futures. La figure 2 illustre une optimisation des coûts en «courbe en u» pour les efforts d’intégration.

Figure 2. Optimisation des coûts d’intégration de la courbe en u

Lorsque l’intégration complète à chaque itération est trop coûteuse, les équipes doivent prendre en compte:

• Intégration d’un sous-ensemble de capacités, composants ou sous-systèmes
• Intégration pour illustrer une fonctionnalité, une capacité ou une exigence non fonctionnelle (NFR) particulière
• Intégration partielle à l’aide de prototypes et de maquettes
• Intégration moins fréquente (par exemple, toutes les deux itérations) jusqu’à ce qu’il soit possible de le faire plus souvent

Il est également important de rappeler que l’intégration continue représente un défi naturel pour les groupes qui passent encore aux méthodes Lean et Agile. C’est normal et cela ne devrait pas être une excuse pour réduire la portée ou l’ampleur de l’intégration. La plupart des défis devraient disparaître à mesure que le train mûrit, mais seulement si les équipes démarrent immédiatement.

L’intégration continue validée par la démonstration du système contribue à la capacité de l’entreprise Lean à atteindre le délai de commercialisation plus rapidement grâce à un flux de valeur plus continu pour ses clients, comme indiqué dans les compétences DevOps et Release on Demand.

Processus et agenda

Avoir un agenda défini et une heure fixe permet de réduire les coûts de transaction de la démo système. Un exemple d’ordre du jour suit :

• En bref, passez en revue le contexte commercial et les objectifs du PI (environ 5 à 10 minutes)
• Décrivez brièvement chaque nouvelle fonctionnalité avant la démonstration (environ 5 minutes).
• Démonstration de chaque nouvelle fonctionnalité dans un cas d’utilisation de bout en bout (environ 20 à 30 minutes, au total)
• Identifier les risques et les obstacles actuels
• Discussion ouverte de questions et de commentaires
• Terminez en résumant les progrès, les commentaires et les mesures à prendre.

Participants

Les participants incluent généralement :

• Product Managers et Product Owners, généralement responsables de la démonstration
• Un ou plusieurs membres de l’équipe système, souvent chargés de la configuration de la démonstration dans l’environnement de transfert
• Business Owners, sponsors exécutifs, clients et mandataires de clients
• System Architect/Engineering, opérations informatiques et autres participants au développement

Vous trouverez ci-dessous quelques conseils pour une démonstration réussie du système:

• Timebox la démo à une heure. Une courte période est essentielle pour maintenir l’implication continue et bihebdomadaire des principales parties prenantes. Il illustre également le professionnalisme des équipes et la préparation du système.
• Partagez les responsabilités de démonstration entre les teams lead et les Product Owners dotés de nouvelles fonctionnalités
• Démo utilisant l’environnement de staging
• Minimiser l’utilisation des diapositives; à la place, ne démontrez que des solutions fonctionnelles et testées
• Discuter de l’impact de la solution actuelle sur les NFR
• Concentrez-vous sur la manière dont le système a évolué par rapport aux contributions d’équipe par équipe

Apprendre encore plus

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

© Scaled Agile, Inc.

Développer sur la cadence. Libération à la demande.

—Un mantra de SAFe

Release à la demande

La release à la demande est le processus par lequel les nouvelles fonctionnalités sont déployées en production et diffusées immédiatement ou de manière incrémentielle aux clients en fonction de la demande.

La libération sur demande est la dernière dimension du pipeline de distribution continue en quatre parties, précédée de l’exploration continue (CE), de l’intégration continue (CI) et du déploiement continu (CD), comme le montre la figure 1.

Figure 1. La release sur demande est le dernier élément du pipeline de livraison continue.

Les trois dimensions qui précèdent Release on Demand permettent de s’assurer que les nouvelles fonctionnalités sont continuellement préparées et vérifiées dans l’environnement de production. Toutefois, étant donné que la valeur de développement tangible ne se produit que lorsque les utilisateurs finaux exploitent la solution dans leur environnement, il est essentiel de libérer cette valeur au bon moment pour que l’entreprise puisse obtenir les avantages réels de l’agilité.

La décision quant au moment et aux éléments à publier est un facteur économique clé qui nécessite un examen attentif. Pour beaucoup, la livraison continue est l’état final souhaité. Une nouvelle fonctionnalité est publiée dès son développement. Mais pour d’autres, le lancement est le plus souvent une activité à la demande découplée, se produisant pour des utilisateurs spécifiques, programmée au moment où ils en ont besoin, ou qui convient le mieux à l’Entreprise.

Détails

L’article sur les compétences de base DevOps et Release on Demand décrit comment l’entreprise crée la capacité de fournir des solutions de plus en plus utiles aux utilisateurs finaux avec une fréquence optimale. La deuxième partie de cette compétence, la capacité de publication sur demande, soulève trois questions (qui servent également de rappel du principe 3, Assumer la variabilité et préserver les options). Ce sont:

• Quand une release devrait-elle avoir lieu?
• Quels éléments du système doivent être libérés?
• Quels utilisateurs finaux doivent recevoir la version?

Garder ces options ouvertes aussi longtemps que raisonnable permet une flexibilité dans la création de valeur. Mais seule la publication peut «boucler la boucle» lors de l’évaluation de l’hypothèse de bénéfice proposée lors de la phase d’exploration continue du pipeline. La publication fournit les données nécessaires pour décider si une exploration plus approfondie d’une idée est justifiée, ou si de nouvelles fonctionnalités doivent être ajoutées, ou si une approche différente est justifiée.

Les quatre sous-dimensions de la libération sur demande

Conformément aux autres dimensions du pipeline, SAFe décrit quatre sous-dimensions de la release sur demande, comme l’illustre la figure 2:

• Release – couvre les compétences nécessaires pour fournir la solution aux utilisateurs finaux, tout à la fois ou progressivement
• Stabilize and Operate – couvre les compétences nécessaires pour s’assurer que la solution fonctionne correctement du point de vue fonctionnel et non fonctionnel
• Measure – couvre les compétences nécessaires pour quantifier si la fonctionnalité nouvellement publiée fournit la valeur recherchée
• Learn – englobe les compétences nécessaires pour décider de ce qui doit être fait avec les informations collectées et préparer la prochaine boucle du pipeline de distribution continue avec de nouvelles hypothèses

Figure 2. Quatre sous-dimensions de la release à la demande

Libérer la valeur pour le client

Lorsque la solution est en production et que son bon fonctionnement a été vérifié, le moment est venu de le mettre à la disposition des clients. Il s’agit là d’une décision cruciale pour l’entreprise car céder de la valeur trop tôt ou trop tard peut avoir de graves répercussions économiques. Ceci est la porte manuelle. Une fois que les développeurs ont engagé le code dans le contrôle de source, tout peut être automatisé jusqu’à ce point. Des modifications peuvent s’implanter dans le pipeline via CI et CD, voire même être plus petites que les récits, mais à l’approche de la publication, elles doivent être agrégées pour devenir des fonctionnalités minimales négociables (MMF), qui sont les plus petits éléments qui apportent valeur pour les clients. Désormais, en collaboration avec les parties prenantes, la gestion des produits doit prendre la décision de publier quoi, à qui et quand.

Quatre compétences contribuent à la capacité de publication :

• Lancements invisibles – permettent de déployer dans un environnement de production sans libérer la fonctionnalité pour les utilisateurs finaux.
• Feature toggles – Il s’agit d’une technique permettant de faciliter les lancements dans l’obscurité en implémentant des basculements dans le code, ce qui permet de basculer entre les anciennes et les nouvelles fonctionnalités.
• Canary release – ils fournissent un mécanisme permettant de libérer la solution pour un segment de clientèle spécifique et de mesurer les résultats, avant de pouvoir être étendus et diffusés à un plus grand nombre de clients.
• Découpler les éléments de libération – La libération sur demande soulève une question et une opportunité: une «libération» est-elle un processus monolithique, tout ou rien? Si tel était le cas, la stratégie de publication serait limitée. Afin de libérer quoi que ce soit, vous devez tout libérer. Heureusement, ce n’est pas le cas. En fait, même les solutions simples auront plusieurs éléments de version, chacun fonctionnant avec des stratégies de version différentes, comme le montre la figure 3.

Figure 3. Élément de publication dissocié de la solution

Par exemple, le site Web SAFe hébergeant cet article comporte plusieurs cycles de publication quelque peu indépendants.

• Nous pouvons corriger une version déployée ou résoudre un problème de sécurité à tout moment (ad hoc, mais en mode accéléré).
• Nous pouvons mettre à jour n’importe quel article à tout moment et en informer simplement les lecteurs via un message de blog (haute fréquence).
• Nous pouvons ajouter de nouveaux articles à la section Sujets avancés chaque fois que du nouveau contenu important est disponible (moyenne fréquence).
• Toutefois, les révisions majeures du cadre ne sont effectuées que périodiquement, sur la base de nouveaux contenus, de nouvelles façons de donner une image globale et, surtout, lorsque le marché est prêt pour une nouvelle version du cadre complet (basse fréquence).

Nous appelons ces flux distincts «flux de valeur», car ils représentent un flux complet de valeur de bout en bout dans un flux de valeur. Chaque ruisseau peut et doit être géré pour générer de la valeur en fonction de ses propres besoins et de son rythme. L’identification des flux de données est essentielle pour permettre la diffusion à la demande, car elle permet de diffuser indépendamment les différents éléments de la solution dans une cadence distincte. Ils fournissent également des indications sur la manière d’organiser les équipes et les ART afin qu’ils puissent indépendamment faire des release à la demande.

Stabiliser et exploiter

Les modifications apportées à la solution ont été vérifiées après leur déploiement, mais une fois que les clients y ont accès, de nouveaux problèmes peuvent survenir. Ces nouveaux problèmes peuvent non seulement être dus à l’augmentation de l’utilisation, mais également à des modèles d’utilisation inattendus. Lorsque des incidents et des menaces pour la sécurité sont découverts, ils doivent être résolus rapidement et dans le respect des accords sur les niveaux de service (SLA) convenus. La solution repose sur quatre compétences principales:

• Collaboration inter-équipes – Un état d’esprit de coopération dans le flux de valeur pour identifier et résoudre les problèmes à mesure qu’ils surviennent est crucial. Cela implique la création de trains de version Agile capables d’exploiter la solution et de la développer.
• Reprise en ligne / reprise sur sinistre – Des échecs surviendront. Il est important de développer un mécanisme de basculement pour permettre au service de reprendre rapidement, voire d’éviter une interruption du service. La reprise après sinistre doit être planifiée, intégrée au service et mise en pratique.
• Surveillance continue de la sécurité – Les tests de sécurité et de code de sécurité visent avant tout à empêcher les vulnérabilités connues d’entrer en production. Mais il est également important de tester en permanence les services pour détecter les vulnérabilités récemment découvertes et signalées et de détecter les intrusions et les attaques contre les services et les infrastructures.
• Architecte des opérations – Les besoins opérationnels doivent être pris en compte. Intégrez des fonctionnalités de télémétrie et de journalisation dans chaque application et dans la solution dans son ensemble. Permettre aux services d’être déclassés ou même supprimés en période de forte charge ou en réponse à des incidents. Construisez des capacités pour une récupération rapide et pour la réparation de correctifs.
• Surveiller les besoins non fonctionnels (NFR) – Les attributs système tels que la fiabilité, les performances, la maintenabilité, l’évolutivité et la convivialité doivent être surveillés en permanence pour éviter les interruptions de service.

Mesurer la valeur commerciale

La première sous-dimension du pipeline est une hypothèse. Dès que la valeur est transmise aux clients, il est temps d’utiliser la télémétrie de l’application pour mesurer l’hypothèse et la valeur commerciale fournie. Deux compétences soutiennent cet effort:

• Comptabilité de l’innovation – L’hypothèse d’évaluation nécessite des métriques différentes de celles utilisées pour mesurer les solutions fonctionnelles à l’état final. La comptabilité des innovations met l’accent sur la manière de mesurer les résultats commerciaux intermédiaires et prévisionnels de l’hypothèse, à la fois lors du développement initial de la solution et lors de l’évaluation du produit minimal viable.
• Télémétrie d’application – La télémétrie d’application est le principal mécanisme permettant de suivre les données d’utilisation et de les mesurer par rapport à l’hypothèse.

Apprendre et réagir

Les informations recueillies au cours de la sous-dimension de mesure doivent être analysées, puis une décision doit être prise sur ce qu’il faut faire ensuite, pivoter ou persévérer – supprimer ou continuer à développer. C’est également là que l’apprentissage du processus entre en vigueur et que l’information sur la manière dont la valeur a été générée doit être utilisée pour améliorer le pipeline de distribution continue. Pour ce faire, trois compétences sont nécessaires:

• Lean stratup thinking – Si les hypothèses et les MVP sont évalués, et si la décision est de savoir si les hypothèses ont été prouvées ou réfutées, si les efforts se poursuivent dans la direction actuelle, si les travaux doivent cesser, ou si de nouvelles hypothèses être formé pour évaluer différentes approches d’une même stratégie.
• Cartographie du flux de valeur – Un outil clé pour améliorer le flux de valeur dans le pipeline est la cartographie du flux de valeur. Cet outil (expliqué dans l’article sur le pipeline de distribution continue) fournit la visibilité nécessaire pour identifier les goulots d’étranglement et les zones à traiter, ainsi que pour concevoir un état futur et créer des facilitateurs permettant d’améliorer le pipeline.
• Amélioration continue – Le flux de travail peut toujours être amélioré. Cet état d’esprit fait partie de la SAFe House of Lean et est essentiel pour obtenir des résultats.

Lorsque les fonctionnalités sont dans les clients pratiques, la valeur est finalement réalisée. Lorsque cette valeur est mesurée, les connaissances informent des efforts d’exploration continus en cours, qui relancent le cycle. C’est la fin du pipeline pour une fonctionnalité et, en même temps, le début pour une autre, le pipeline de distribution continue génère une nouvelle valeur pour les utilisateurs et un nouvel apprentissage pour l’organisation tout le temps.

Gouvernance des publications

La gouvernance des versions est le processus de planification, de gestion et de gouvernance des versions des solutions, qui aide à orienter le flux de valeur vers les objectifs de l’entreprise. Dans certaines entreprises, en particulier celles dont les critères de réglementation et de conformité sont importants, il s’agit d’une équipe ou d’une fonction centralisée au niveau du portefeuille (la gestion des mises à jour est un terme commun) qui assure que les mises à jour répondent à tous les critères commerciaux pertinents.

Dans d’autres circonstances, ART et Solution Train leadership et les parties prenantes des opérations de développement, de la qualité, des ventes et d’autres parties prenantes prennent part aux responsabilités de gestion des versions et de gouvernance.

Dans les deux cas, la gouvernance des versions facilite les activités nécessaires pour aider les parties prenantes internes et externes à recevoir et à déployer la nouvelle solution. Cela garantit également que les éléments les plus critiques de la qualité de la gouvernance sont correctement pris en compte avant le déploiement, en particulier les consignes de sécurité internes et externes, réglementaires et autres.

La planification des versions fait partie du processus de PI Planning. Mais c’est la partie facile; Le plus difficile est de coordonner l’implémentation de toutes les fonctionnalités et fonctionnalités sur plusieurs itérations d’une même version. Cela est particulièrement vrai lorsque de nouveaux problèmes, de nouveaux obstacles, des dépendances et des lacunes dans Vision et les backlogs sont découverts. En raison de ces défis, la portée de chaque publication doit être continuellement gérée, revalidée et communiquée. Les considérations principales incluent:

• Veiller à ce que la gouvernance de la publication de l’organisation soit comprise et respectée
• Communiquer le statut de la publication aux parties prenantes externes
• Veiller à ce qu’un plan de déploiement approprié soit en place
• Coordination avec le marketing et la gestion des produits et des solutions pour les communications internes et externes
• Vérification de la conformité de la solution aux critères de qualité et de conformité pertinents
• Participer à Inspect and Adapt (I&A) pour améliorer le processus de publication, la productivité et la qualité de la solution, ainsi que la qualité de la solution.
• Fournir l’autorisation finale pour la publication.
• Assurer la liaison avec Lean Portfolio Management (LPM), selon le cas.
• Participer et superviser les activités de publication finales.

De nombreuses entreprises organisent des réunions hebdomadaires sur la gouvernance des communiqués afin de répondre aux questions suivantes:

• La vision est-elle toujours comprise et les trains et les équipes sont-ils alignés à cette fin?
• Est-ce que tout le monde comprend ce qu’ils construisent et est-ce que cela concorde avec la compréhension de l’objectif du flux de valeur et des thèmes stratégiques actuels?
• Les trains suivent-ils les dates de sortie prévues?
• La qualité appropriée est-elle intégrée à la solution?
• Quels sont les obstacles à surmonter pour faciliter les progrès?

Cette réunion hebdomadaire offre aux membres de la haute direction une visibilité régulière sur les progrès de la publication. C’est également l’endroit pour approuver toute modification de portée, de calendrier, de personnel ou de ressources nécessaire pour assurer la publication. Dans un environnement de diffusion plus continu, les participants surveillent de près la section de publication du programme Kanban, s’assurant que les éléments sont diffusés lorsque cela est nécessaire pour le public cible approprié, gèrent les diffusions sombres et canaris, vérifient que les hypothèses sont évaluées et que les fonctionnalités sont supprimées après la vérification de la production.

Apprendre encore plus

[1] Ries, Eric. Lean Startup: comment les entrepreneurs d’aujourd’hui utilisent l’innovation continue pour créer des entreprises radicalement performantes. Random House, Inc.

[2] Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc.

[3] Leffingwell, doyen. Configuration logicielle requise pour les logiciels agiles: pratiques de configuration simplifiée pour les équipes, les programmes et l’entreprise (série de développement logiciel agile). Pearson Education.

[4] http://www.innovationgames.com [5] Gothelf, Jeff et Josh Seiden. Lean UX: Concevoir des produits de qualité avec des équipes agiles. O’Reilly Media.

© Scaled Agile, Inc.

Connaissez-vous la différence entre un flux de valeur et un Agile Release Train (ART) ? Savez-vous comment DevOps s’intègre dans le concept de flux de valeur Scaled Agile Framework® (SAFe®) ? Nous avons récemment organisé un webinaire avec Dean Leffingwell pour répondre à ces sept questions principales et plus encore. Vous pouvez voir le webinaire complet ici, mais pour votre commodité, nous avons fourni un résumé ci-dessous :

1- Qu’est-ce qu’un flux de valeur ?

Un flux de valeur est la construction organisationnelle fondamentale de SAFe. C’est là où nous commençons. Chaque flux de valeur est une séquence d’étapes permettant de fournir de la valeur au client. Il y a un déclencheur, quelque chose qui le cause, et il y a une forme de monétisation ou de valeur livrée à la fin. Les étapes au milieu sont les étapes de développement.

Les flux de valeur sont généralement interfonctionnels, inter-organisationnels et inter-géographiques. Lorsque nous développons des systèmes pour prendre en charge des flux de valeur ou générer directement de la valeur, nous le faisons avec un train de développement agile (ART). L’ART contient toutes les personnes appropriées et toutes les compétences nécessaires pour fournir tout ou partie d’un flux de valeur.

2- Pourquoi s’organiser autour de flux de valeur ?

La raison pour laquelle nous organisons des flux de valeur est très simple. Nous voulons accélérer les délais de commercialisation. Nous le faisons en optimisant le flux dans le système dans son ensemble.

Si nous sommes organisés de la sorte, nous aurons moins de transferts et nous pourrons travailler avec des lots plus petits, qui passent plus rapidement dans le système. Il est beaucoup plus facile d’intégrer la qualité car tout le monde travaille ensemble. Vous obtenez un alignement intégré entre les activités et le développement. Les entreprises font partie de la chaîne de valeur, le développement fait partie de la chaîne de valeur, DevOps fait partie de la chaîne de valeur. C’est juste un flux.

3- Qu’est-ce que la cartographie du flux de valeur?

Une fois que nous comprenons les flux de valeur, nous pouvons appliquer un outil d’analyse appelé mapping de flux de valeur. La cartographie des flux de valeur est un processus analytique qui demande: Quelles sont les étapes ? Quel est le temps entre les marches ? Que pouvons-nous faire pour minimiser les délais entre les étapes ?

Lorsque nous réalisons une cartographie des flux de valeur, nous découvrons des choses intéressantes. Nous découvrons que le temps nécessaire pour implémenter une fonctionnalité représente un très petit pourcentage du temps total de livraison. Par petit, j’entends typiquement entre trois et sept pour cent. Donc, quelque chose qui prend un mois à construire, peut prendre un an à déployer. Mais alors vous pouvez commencer à voir ce que vous pouvez faire à ce sujet.

4- Qu’est-ce qu’un Agile Release Train (ART) ?

Un ART est une organisation virtuelle qui inclut toutes les personnes, avec toutes les compétences requises, pour créer de la valeur. Après tout, les gens font tout le travail et nous nous rendons compte de la valeur avec les gens dans les ART.

Il existe également des ART qui sont des organisations physiques. Ce que je veux dire par là, c’est que ce sont de véritables structures de rapport. Même dans ce cas, tout le monde dans le train ne se rapporte pas nécessairement à un seul individu. Plus généralement, vous commencez à voir se dessiner un modèle organisationnel plus amorphe, ce que nous appelons le mode «achetez un t-shirt».

Une personne peut se rapporter à l’exploitation et à la maintenance ou à l’entreprise, mais nous aimons «lui acheter un t-shirt» pour l’accueillir à l’ART. Tout le monde sous ART porte le même t-shirt, pour ainsi dire; c’est la métaphore pour faire partie d’une plus grande équipe d’équipes. Ils viendront à la planification du PI et participeront aux grands événements tels que la démonstration du système. Ils feront donc logiquement partie de la multithérapie, peu importe à qui ils rapportent.

En règle générale, nous ne suggérons pas de modifier la structure organisationnelle d’une entreprise, car c’est un gros problème et que les ART auront tendance à évoluer avec le temps. Avec la structure virtuelle de l’ART, tout ce dont nous avons besoin est la permission de planifier ensemble, de s’engager ensemble, d’exécuter ensemble, de faire une démonstration ensemble, d’inspecter et de s’adapter ensemble. C’est assez difficile de dire non à cela. Pour y parvenir, les ART gèrent une séquence d’événements que nous appelons itérations et incréments de programme (PI), dans lesquels tout le monde travaille ensemble pour créer de la valeur.

5- Qu’est-ce que le client a à voir avec le flux de valeur ?

Le client a pratiquement tout à voir avec un flux de valeur. Nous n’avons pas de modèles Agile, Lean ou SAFe dans lesquels le client n’est pas intégré au processus de développement. Ce ne sont pas des développeurs, mais ils jouent un rôle critique. Ils sont essentiels pour commenter les idées et les idées de développement. Et bien sûr, ils sont impliqués dans la livraison de valeur ultime. Il n’existe aucun modèle permettant de dire: «Oh, mon client est distant et ne fait pas partie du développement. Nous espérons donc que tout ira pour le mieux lorsque nous livrerons». Il est peut-être vrai qu’ils sont distants et qu’ils font partie d’une organisation différente, mais si nous nous dirigeons vers une voie simple et agile, le client fait absolument partie intégrante de la chaîne de valeur. Ils reçoivent le même t-shirt et ont des responsabilités spécifiques, comme tout le monde.

6- Comment organisez-vous les ART dans le flux de valeur ?

C’est l’art et la science de la compréhension des flux de valeur, à l’échelle agile et à SAFe. Les ART sont conçus de manière à ce que chaque ART puisse offrir un ensemble de fonctionnalités et, dans certains cas, être libéré indépendamment des autres ART. Par exemple, pensons à un satellite de collecte de données géophysiques. Ce système ne comprend pas seulement le satellite évident avec des caméras, il existe également une station au sol et de l’hébergement qui transmet des données géophysiques à l’utilisateur final. Techniquement, ce sont des systèmes très différents, mais ils doivent travailler ensemble pour fournir les données. Et leurs cycles de publication ne sont pas les mêmes. Vous pouvez facilement considérer le satellite comme son propre flux de valeur, la station sol comme un flux de valeur et l’hébergement comme un flux de valeur. Dans ceux-ci, il pourrait facilement y avoir plusieurs ART. Vous pouvez penser à cette activité comme trois grandes sources de valeur et un certain nombre d’ART dans chacune. Mais cela dépend beaucoup de la portée.

7- Qu’est-ce que DevOps a à voir avec le flux de valeur ?

La valeur n’apparaît que lorsque l’utilisateur final utilise la solution. La chaîne de valeur ne peut pas avoir un modèle qui implique des idées et du développement, mais exclut le déploiement. Le pipeline DevOps fait simplement partie du flux de valeur.

Prenons notre exemple du satellite. La société dispose de téraoctets et de téraoctets de données qu’elle transmet de la batterie de serveurs Web à l’utilisateur final. Toutes ces données sont évidemment alimentées via des systèmes déployés.

DevOps est simplement une capacité d’un ART. C’est juste une partie de ce que font les ART. Si vous déconnectez le client ou DevOps, ce n’est pas un flux de valeur. Ce n’est qu’un processus de développement logiciel. Cela ne prend pas une vue des systèmes.

Conclusion

J’espère que ces sept questions et réponses de Dean Leffingwell vous aideront à mieux comprendre les flux de valeur de SAFe. Ces sept questions ne sont que quelques-unes des questions auxquelles Dean a répondu à propos de SAFe lors de notre webinaire. Découvrez le webinaire complet à la demande, Comment utiliser SAFe pour apporter de la valeur à l’échelle de l’entreprise.

© Scaled Agile, Inc.

Appliquer la cadence, synchroniser avec la planification interdomaine.

—SAFe Lean-Agile Principe # 7

Planification pré et post-PI

Les événements de planification avant et après le programme (PI) servent à préparer et à suivre un PI Planning pour les Agiles Release Trains (ARTs) et des fournisseurs dans la Solution Train.

La planification d’incrément de programme (PI) est le point de synchronisation critique basé sur la cadence pour chaque ART. Pour la Solution Trains, cependant, il existe deux activités supplémentaires: la planification avant et après l’IP. Ils soutiennent et coordonnent les différents ART impliqués dans le train de solutions. La planification à ce niveau supérieur permet d’aligner le développement de la solution dans son ensemble et offre une direction et une visibilité quant à l’orientation des trains vers le prochain PI.

Détails

Les événements de planification pré et post-PI permettent aux Agile Release Train (ARTs) et aux fournisseurs de grands flux de valeur de créer un plan unifié pour le prochain PI. Les événements de planification pré et post-IP servent de wrapper pour la planification des PI Planning au niveau du programme, où la planification détaillée réelle a lieu et est intégrée au calendrier de itérations Innovation et planification (IP).

L’événement de planification pré-PI est utilisé pour coordonner les objectifs d’entrée, les jalons et le contexte métier et de solution pour les sessions de planification ART PI.

L’événement de planification post-PI est utilisé pour intégrer les résultats de la planification d’ART dans la vision et la feuille de route pour le flux de valeur. À la fin de l’événement de planification post-PI, il devrait y avoir un accord sur un ensemble des PI Objectifs de solution à mettre en œuvre d’ici la fin de l’IP et à présenter lors de la prochaine démonstration de Solution. Comme pour la planification des PI, les événements de planification avant et après les PI offrent plusieurs avantages métier:

• Fournir une communication ouverte et productive grâce à un alignement face à face
• Synchronisez les ART avec la solution Entraînez la vision via les objectifs ART et PI de la solution
• Identifier les dépendances et favoriser la coordination entre ART
• Fournissez la possibilité de disposer de la bonne quantité d’architecture au niveau solution et de conseils sur l’expérience utilisateur (voir l’article Lean UX).
• Adapter la demande de solution aux capacités de traitement

Un autre avantage est la constitution d’équipes au sein du Solution Train, qui contribue à créer le tissu social nécessaire pour atteindre des performances élevées. De plus, la planification étant basée sur des vitesses connues, l’événement de planification post-PI est une étape cruciale de l’évaluation et de la suppression en continu des travaux en cours (WIP).

Entrées et sorties

Les entrées dans la planification avant et après PI incluent la feuille de route de la solution, la vision, l’objectif de la solution et le top des Capabalities du backlog des solutions. Les participants incluent:

• Parties prenantes de la solution, y compris le Solution Train Engineer (STE), Solution Management, architecte / ingénierie de solution, solution System Team et Release Management
• Représentants de tous les ARTs et fournisseurs, généralement des Release Train Engineers (RTE), Product Management, System Architect / Engeneering, Customers et autres parties prenantes principales

Les sorties incluent trois artefacts principaux:

1. Un ensemble d’objectifs PI spécifiques, mesurables, réalisables, réalistes et limités dans le temps (SMART) agrégés pour la solution
2. Un tableau de planification de solution, qui met en évidence les capacités, les dates de livraison prévues et toute autre étape pertinente pour la solution
3. Un vote de confiance (engagement) à la solution objectifs PI

Ce processus de planification basé sur la cadence, guide la livraison à travers les inévitables obstacles techniques et les méandres de l’environnement commercial et technologique.

Gain de contexte dans la démonstration de solution

La démonstration de solution concerne le train de solutions, ce que la démonstration système représente pour ART. Dans ce cas, c’est une occasion régulière d’évaluer la solution entièrement intégrée. Habituellement hébergés par Solution Management, les parties prenantes à la solution y assistent généralement. (Cela inclut également la gestion de la solution et l’ingénieur de la solution.) Les informations tirées de la démonstration informeront ces parties prenantes de l’évaluation objective actuelle des progrès, des performances et de l’aptitude potentielle à l’utilisation de la solution. Bien que le calendrier de la démonstration de solution varie en fonction du contexte de la solution, il fournit des entrées objectives essentielles pour les événements de planification pré et post-PI.

Préparer la planification avant et après l’IP

Les événements de planification pré et post-IP rassemblent les parties prenantes de toutes les parties du train de solutions. Ils nécessitent une préparation, une coordination et une communication avancées du contenu. Les ordres du jour et les calendriers indiqués ci-dessous sont une méthode suggérée pour organiser ces événements, mais divers flux de valeur peuvent les adapter à leurs capacités et à leurs emplacements.

Quelle que soit la manière dont le calendrier et la logistique physique sont organisés, tous les éléments de ces événements doivent être réunis pour parvenir au bon alignement des trains et des fournisseurs. Il est essentiel de définir clairement le contexte et la participation des bonnes parties prenantes, ainsi que la réalisation des principales activités, notamment:

• Le briefing exécutif – Définit le contexte actuel de l’entreprise, de la solution et du client
• Briefing (s) de vision de solution – Briefings préparés par Solution Management, y compris les principales fonctionnalités de l’arriéré des solutions.
• Définitions des jalons – Expliquez clairement les événements et métriques à venir

Définir le contexte de planification dans la planification Pre-PI

L’événement de planification pré-PI est utilisé pour développer le contexte dans lequel les ART et les fournisseurs créent leurs propres plans. La figure 1 montre un ordre du jour suggéré et chaque point est décrit ci-après.

Figure 1. Exemple d’agenda de planification pré-PI

• Rapports de synthèse des PI– Chaque ART et chaque fournisseur présente un bref rapport sur les réalisations de l’PI précédent. Cela ne remplace pas la démonstration de la solution, mais fournit le contexte de ce qui a été réalisé pour le processus de planification.
• Contexte commercial et vision de la solution – Un haut dirigeant présente un exposé sur l’état actuel de la solution et du portefeuille. Solution Management présente la vision actuelle de la solution et met en évidence les modifications par rapport à l’IP précédent. Ils peuvent également présenter la feuille de route pour les trois prochains IP, ainsi que les jalons qui surviennent au cours de cette période pour s’assurer qu’ils sont connus et traités.
• Carnet de commandes de solutions – Solution Management examinera les principales fonctionnalités du prochain PI. L’architecte / ingénieur de solution discutera des capacités à venir d’Enabler et d’Epics.
• Features des prochains PI – Chaque responsable produit d’ART présentera le backlog du programme qu’ils ont préparé pour le prochain PI et discutera des dépendances potentielles avec d’autres trains.

Les parties prenantes à la solution participent à la planification des ARTs

La logistique pratique de la planification de grandes solutions peut limiter la participation de tous les acteurs de la solution. Cependant, il est essentiel que les principales parties prenantes, notamment la Solution Management, Solution Train Engineer et Solution Architect / Engineering, participent au plus grand nombre possible de séances de planification ART PI. Dans de nombreux cas, les sessions de planification des ARTs sont simultanées et ces parties prenantes de la solution peuvent y participer en les faisant circuler parmi les sessions de planification des traitements antirétroviraux. Les fournisseurs et les clients jouent également un rôle essentiel et ils devraient être représentés dans la planification d’ART PI.

Résumer les résultats dans la planification post-PI

L’événement de planification post-PI se produit après que les ART ont exécuté leurs sessions de planification respectives et est utilisé pour synchroniser les ART et créer le plan de solution global et la feuille de route. Les participants incluent les parties prenantes clés de la solution et de l’ART. Un exemple d’ordre du jour est présenté à la figure 2.

Figure 2. Exemple d’agenda de planification post-PI

• Rapport de planification des PI – La gestion des produits de chaque ART présente ses plans de planification des PI, expliquant les objectifs de ces derniers et indiquant quand ils devraient être disponibles. Les RTE placent leurs informations sur la rangée du tableau de planification des solutions de leur ART et discutent des dépendances avec d’autres ART ou fournisseurs.
• Examen du plan, analyse des risques et vote de confiance – Tous les participants examinent le plan complet. Au cours de la planification des IP, les ARV ont identifié des risques critiques et des obstacles susceptibles d’atteindre leurs objectifs. Les risques pertinents sont traités dans un contexte de solution plus large, devant l’ensemble du groupe. Un par un, les risques sont classés et traités de manière claire, honnête et visible:
  • Résolu – le problème n’est plus une préoccupation
  • Propriétaire – une personne en prend possession, car le problème ne peut pas être résolu immédiatement
  • Accepté – certains risques sont des faits ou des problèmes qui doivent être compris et acceptés
  • Atténué – l’impact du risque peut être réduit en mettant en œuvre un plan d’urgence

Une fois que tous les risques ont été traités, le train de solutions évalue sa confiance dans la réalisation des objectifs de la solution en matière de PI. Un premier vote sur cinq est tenu pour évaluer la confiance. Si la moyenne est de trois doigts ou plus, la direction devrait accepter l’engagement. Si la moyenne est inférieure à trois doigts, des ajustements sont effectués et les plans sont retravaillés. Toute personne votant deux doigts ou moins devrait avoir le temps de faire part de ses préoccupations, ce qui pourrait ajouter à la liste des risques.

• Retravailler le plan si nécessaire – Si nécessaire, le groupe révise ses plans aussi longtemps qu’il le faudra avant qu’un engagement soit atteint. Cela pourrait déboucher sur des réunions de suivi avec les ART, car les équipes devront être impliquées dans tout changement des plans.
• Planification et rétrospective de la planification – Enfin, le STE organise une brève rétrospective des sessions de planification avant et après l’PI afin de déterminer ce qui a bien fonctionné, ce qui n’a pas fonctionné et ce qui pourrait être amélioré la prochaine fois. Ensuite, les étapes suivantes sont discutées, y compris la définition d’objectifs, l’utilisation d’outils de gestion de projet agile et la finalisation du calendrier des activités et événements à venir du train Solution.

Créer les bons résultats

Un événement réussi fournit trois artefacts principaux:

1. Ensemble d’objectifs PI de la solution « SMART » pour le train de solutions, avec la valeur métier définie par la Solution Management, les architectes / ingénieurs de solutions et les clients. Cela peut inclure des objectifs ambitieux, qui sont des objectifs intégrés dans le plan mais non résolus par la solution. Les objectifs Stretch fournissent la capacité flexible et les options de gestion de la portée nécessaires pour accroître la fiabilité et la qualité de l’exécution des PI.
2. Un tableau de planification de solutions, qui met en évidence les objectifs, les dates de livraison prévues et toute autre étape pertinente, regroupés à partir des tableaux de programme, comme l’illustre la figure 3.
3. Un engagement basé sur le vote de confiance pour atteindre les objectifs de la solution.

Figure 3. Exemple de tableau de planification de solution

Ensuite, la feuille de route de la solution est mise à jour en fonction des objectifs pour le PI planifié. Cela est généralement effectué par STE et Solution Management après la session de planification post-PI.

Coordination du train de solutions et des événements de planification ART dans l’itération IP

La réalisation de tous les ateliers de perfectionnement, de planification préalable et postérieure, de planification PI et d’inspections et d’adaptation (I&A) pour un train de solutions et ses ART peut représenter un défi logistique. Le séquencement des événements dans l’ordre optimal requiert une planification précise de la part du STE et de tous les RTE afin de garantir la présence des acteurs appropriés lors de la planification. La figure 4 montre un exemple de planification d’une itération IP de deux semaines avec tous les événements de solution et d’ART séquencés pour le flux idéal d’entrées et de sorties pour chacun. En fonction de la portée et de la complexité de la solution, certaines organisations trouveront que cette configuration est trop simpliste et peut nécessiter plusieurs sessions de planification préalable à l’IP 4 à 6 semaines à l’avance. N’oubliez pas que SAFe est un cadre et utilisez ses principes comme guide pour adapter votre planification en fonction des besoins.

Figure 4. Exemple de calendrier IP pour Solution Train et ARTs

Pour les trains distribués géographiquement, la planification de l’I&A la veille de la planification de l’IP est un schéma courant, car de nombreuses personnes peuvent être amenées à se rendre dans un lieu central pour participer. Pour une planification des déplacements et des sites rentable, cela nécessite généralement un bloc de temps adjacent pour effectuer l’I&A et le PI Planning.

Lorsque la logistique n’est pas la considération primordiale, l’alternative consiste à organiser des ateliers I&A de niveau ART avant le Solution Train I&A. Cela permet aux résultats d’ART I&As – y compris les démonstrations, les métriques et les ateliers de résolution de problèmes – d’être intégrés au processus I&A de Solution Train. L’avantage est que les parties prenantes à la solution auront une image la plus récente de l’état de la solution lors de leurs événements de planification. Considérez la conception de la logistique comme une hypothèse. Évaluez-le et inspectez-le et adaptez-vous au besoin.

© Scaled Agile, Inc.

Même s’ils ne le savent pas encore, les clients veulent quelque chose de mieux et votre désir de ravir les clients vous incitera à inventer pour eux. Aucun client n’a jamais demandé à Amazon de créer le programme d’adhésion Prime, mais il s’est avéré qu’il le souhaitait et je pourrais vous en donner de nombreux exemples.

—Jeff Bezos

Client

Les clients sont l’acheteur final de chaque solution. Ils font partie intégrante du processus de développement Lean-Agile et de la chaîne de valeur et ont des responsabilités spécifiques dans SAFe.

Que ce soit interne ou externe, les clients sont de plus en plus exigeants. Ils ont des choix. Ils s’attendent à ce que les solutions fonctionnent bien et résolvent leurs besoins actuels. Ils attendent également de leurs fournisseurs de solutions qu’ils améliorent continuellement la qualité de leurs produits et services.

Détails

Les clients apportent leur soutien aux principes SAFe. Leur engagement actif et leur participation continue au développement de solutions sont essentiels au succès de votre entreprise.

Responsabilités du client

En personne ou par procuration, les clients assument les responsabilités suivantes:

• Participer en tant que Business Owner à PI Planning
• Assistez à la démonstration de la solution et éventuellement aux démonstrations du système; aider à évaluer l’incrément de solution
• Participer aux ateliers d’inspection et d’adaptation; aider à éliminer certains obstacles systémiques
• Interagissez avec des analystes et des experts en la matière lors d’ateliers de spécification
• Gestion collaborative de la portée, du temps et d’autres contraintes avec la gestion des produits et des solutions
• Aider à définir la feuille de route, les jalons et les releases
• Communiquer la logique économique à la base de la solution et aider à valider les hypothèses du cadre économique
• Examiner le statut technique et financier de la solution
• Participer aux tests bêta, aux tests d’acceptation des utilisateurs (UAT) et à d’autres formes de validation de solutions

Le client fait partie de la chaîne de valeur

La mentalité Lean-Agile va au-delà de l’organisation de développement pour englober l’ensemble du flux de valeur, qui inclut le client.

L’engagement des clients dans le processus de développement dépend du type de solution et de son impact. Par exemple:

• Un client interne demandant à son service informatique de créer une application pour lui
• Client externe achetant une offre personnalisée (par exemple, un gouvernement achetant un système de défense) ou faisant partie d’une catégorie d’acheteurs plus large (par exemple, un fournisseur de logiciels indépendant vendant une suite de produits).

Client interne

Pour ceux qui construisent des solutions pour un utilisateur final interne (par exemple, un service informatique interne), le client fait partie du flux de valeur opérationnel, comme l’illustre la figure 1.

Un exemple serait un directeur marketing responsable du flux de valeur des inscriptions de partenaires. Le partenaire est l’utilisateur final du flux de production et est le client. Toutefois, pour l’équipe de développement, le client est le directeur marketing et les opérateurs de la chaîne de valeur.

Figure 1. Le client interne fait partie du flux de valeur opérationnelle

Client externe

Pour ceux qui construisent des solutions pour un utilisateur final externe, le client est l’acheteur direct de la solution, comme l’illustre la figure 2. Dans ce cas, le flux de valeur de développement et le flux de valeur opérationnel sont identiques. La solution peut être un produit final vendu ou déployé directement. Dans d’autres cas, il peut être nécessaire d’intégrer la solution à un contexte de solution plus large, tel qu’un système de systèmes.

Figure 2. Les clients externes sont des acheteurs directs.

L’engagement client conduit au succès agile

Le développement Lean-Agile dépend d’un degré élevé d’engagement du client, qui dépasse de loin nos modèles de développement traditionnels.

Cependant, les méthodes d’engagement sont différentes et sont déterminées par le fait que la solution soit:

• Solution générale – une solution conçue pour être utilisée par un nombre important de clients
• Solution sur mesure – une solution conçue et conçue pour un client individuel

La figure 3 illustre le niveau relatif d’engagement client indirect ou direct dans chaque cas.

Figure 3. Modèles d’engagement du client en général et solutions personnalisées

Solutions générales

Les solutions générales doivent répondre aux besoins d’un public plus large. Aucun client unique n’est un proxy adéquat pour l’ensemble du marché. Dans ce cas, la gestion des produits et des solutions devient le proxy indirect du client. ils ont autorité sur le contenu de la solution. C’est leur responsabilité de faciliter les interactions externes et de s’assurer que la voix du client sera entendue et que l’organisation validera en permanence de nouvelles idées. L’étendue, le calendrier et le budget de développement sont généralement laissés à la discrétion des Business Owners.

Dans la mesure où il est peu probable qu’un client particulier participe à des sessions régulières de planification du système et de démonstration du système, les interactions client sont généralement basées sur des ateliers sur les exigences, des groupes de discussion, des tests de convivialité et des versions bêta limitées. La solution évolue à travers les commentaires de l’analyse du comportement des utilisateurs, des métriques et de la veille stratégique pour valider les différentes hypothèses. Au cours de la planification des PI, un groupe de parties prenantes internes et externes agit en tant que Business Owners – le proxy client interne ultime au sein d’un flux de valeur spécifique.

Solutions sur mesure

Pour les solutions personnalisées, le client externe définit généralement la solution avec le support de la gestion des produits et des solutions. Cependant, même si le client dirige l’effort, il est essentiel d’établir une approche collaborative de la portée et de la priorisation. Cela favorise l’apprentissage incrémental et démontre une volonté d’ajuster le plan d’action au besoin.

Une participation active à la planification des PI, à la démonstration de la solution et à des ateliers de spécification sélectionnés est requise. Cela révélera souvent des incohérences dans les exigences et les hypothèses de conception, avec des problèmes contractuels potentiels. Ce processus devrait conduire le client et les ART vers une approche plus collaborative et incrémentale.

La démonstration des résultats de l’augmentation du programme au client, sous la forme d’une incrémentation de solution entièrement intégrée, crée un degré de confiance élevé (par exemple, «ces équipes peuvent vraiment donner les résultats escomptés».). Elle permet également de valider de manière empirique le cours de l’action. Sur la base de la prévisibilité mesurée et de la vitesse des trains, les prévisions sont considérablement améliorées.

La transition vers un modèle de contrat Agile contribuera également à accroître la confiance et à réduire les aspects gagnant-perdant des contrats traditionnels. L’un de ces modèles est le «modèle d’investissement géré SAFe», dans lequel le client engage le financement d’un ou de deux investisseurs, puis s’ajuste en fonction de preuves objectives et de livraisons incrémentielles. Cela nécessite un peu de confiance, mais la confiance est construite progressivement, sur la base d’un flux continu de valeur reçue.

Apprendre encore plus

[1] Ward, Allen and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.

© Scaled Agile, Inc.

Chaque entreprise est maintenant une entreprise de logiciel.

L’agilité n’est pas une option ni une chose pour les équipes, c’est un impératif commercial.

—Dean Leffingwell, créateur de SAFe

SAFe pour les entreprises Lean

Lean Enterprise est une entreprise florissante de l’ère numérique qui fournit des solutions et des systèmes concurrentiels à ses clients dans les délais les plus courts et les plus durables.

SAFe® for Lean Enterprises est une base de connaissances de principes, pratiques et compétences intégrés et éprouvés pour Lean, Agile et DevOps.

Scaled Agile Framework utilise la puissance de Agile, ainsi que les connaissances contemporaines issues de la pensée système et du développement de produits Lean, pour aider les entreprises à relever les défis importants liés au développement et à la fourniture de logiciels et de systèmes de classe entreprise dans les délais les plus courts et les plus durables. Il s’agit d’une base de connaissances en ligne librement révélée sur les modèles de réussite éprouvés pour la mise en œuvre de logiciels et de systèmes Lean-Agile à l’échelle de l’entreprise.

Les avantages commerciaux de SAFe

«Avec un cadre éprouvé, nous pouvons fournir des solutions beaucoup plus rapidement et avec moins d’effort. SAFe définit les rôles, les équipes, les activités et les artefacts permettant d’appliquer les principes Lean et Agile à l’échelle de l’entreprise et fournit un matériel de formation et de coaching exceptionnel pour augmenter nos chances de réussite. ”

—Peter Vollmer, Hewlett Packard Enterprise, Technologue distingué

Les entreprises doivent apprendre à s’adapter rapidement à l’évolution de la technologie et à la conjoncture économique, sans quoi elles disparaîtront, peu importe leur taille, leur puissance ou leur intelligence. Même les entreprises qui ne se considèrent pas comme des éditeurs de technologies de l’information (TI) ou de logiciels (services professionnels, services financiers, fabricants, établissements de santé, agences gouvernementales, etc.) dépendent désormais beaucoup de leur capacité à produire de nouveaux produits et services numériques. Scaled Agile Inc (SAI) a pour mission d’aider ces entreprises à développer leur activité numérique par le développement et la publication de la base de connaissances SAFe, ainsi que par la certification, la formation, les didacticiels et un réseau mondial de plus de 150 partenaires outillage et service.

Améliore les résultats de développement du système

Fondé sur plus d’une décennie d’expérience sur le terrain, SAFe s’appuie sur quatre corps de connaissances principaux: le développement agile, la pensée systémique, le développement de produits lean et le développement de DevOps. Il aide les entreprises à répondre aux types de questions suivantes:

• Comment aligner les objectifs commerciaux et techniques?
• Comment pouvons-nous offrir une nouvelle valeur selon un calendrier prévisible afin que le reste de l’entreprise puisse planifier?
• Comment pouvons-nous améliorer la qualité de nos solutions et ravir nos clients?
• Comment pouvons-nous adapter les pratiques agiles de l’équipe au programme et à l’unité opérationnelle, ainsi qu’à l’ensemble de l’entreprise, pour obtenir de meilleurs résultats?
• Comment organisons-nous les gens autour de la valeur de sorte que nos programmes le délivrent efficacement et évitent les retards inhérents à une structure fonctionnelle traditionnelle?
• Comment pouvons-nous créer un environnement qui favorise la collaboration, l’innovation et l’amélioration continue pour nos employés?
• Comment pouvons-nous changer notre culture pour qu’elle tolère l’échec et récompense la prise de risque et l’apprentissage continu? Comment pouvons-nous aider nos équipes à s’améliorer sans se gêner?

En adoptant SAFe – et en appliquant son ensemble bien décrit de valeurs, de principes et de pratiques -, l’entreprise peut répondre à ces questions et générer des avantages commerciaux et individuels plus importants.

Maintenant dans sa cinquième révision majeure, SAFe 4.6 améliore les résultats commerciaux des entreprises de toutes tailles à travers le monde. SAFe a considérablement amélioré les délais de mise sur le marché, l’engagement des employés, la qualité, la satisfaction de la clientèle et l’amélioration des résultats économiques. Cela aide également à créer des cultures plus productives, plus enrichissantes et plus amusantes.

La Figure 1. met en évidence ces avantages tels qu’ils découlent directement d’études de cas rédigées par des clients de SAFe.

Figure 1. Avantages commerciaux SAFe directement issus d’études de cas rédigées par des clients SAFe

«Nous avons eu de nombreux efforts en waterfall, une intégration avec une tierce partie et un mandat réglementaire strict qui a rendu la coordination et l’exécution extrêmement difficiles. SAFe a fourni l’agilité, la visibilité et la transparence nécessaires pour nous permettre de nous intégrer aux nombreux autres efforts, d’obtenir des résultats prévisibles et d’assurer le respect des délais.  »

– David McMunn, directeur du centre d’excellence agile de Fannie Mae (COE)

Vue d’ensemble

Bien que les avantages soient clairs, avant qu’une entreprise puisse obtenir ces avantages commerciaux substantiels, elle doit se transformer en une entreprise allégée. Cette transformation nécessite de développer des «compétences d’entreprise» qui permettent un nouveau style de leadership, de nouvelles façons de penser et de travailler, ainsi qu’une culture axée sur la création de valeur et l’amélioration continue.

SAFe est un ensemble de connaissances exhaustif qui décrit les rôles, les responsabilités, les artefacts et les activités nécessaires à la mise en œuvre d’un développement Lean-Agile à l’échelle de l’entreprise. SAFe synchronise l’alignement, la collaboration et la livraison pour un grand nombre d’équipes agiles. Evolutif et configurable, SAFe prend en charge des solutions à plus petite échelle employant de 50 à 125 praticiens, ainsi que des systèmes complexes nécessitant des milliers de personnes.

La page d’accueil du site Web SAFe Framework contient un graphique interactif «Big picture» qui donne un aperçu visuel du Framework et constitue la principale interface utilisateur de la base de données. Chaque icône de l’image est cliquable et fournit une entrée dans la vaste base de connaissances SAFe qui comprend: les cinq compétences principales de l’entreprise allégée, les quatre configurations prenant en charge une gamme complète d’environnements de développement et d’entreprise, ainsi que les principes, valeurs, état d’esprit, rôles, artefacts et éléments d’implémentation constituant le cadre SAFe. Les composants du cadre SAFe sont décrits plus en détail dans les paragraphes suivants.

Cinq compétences de base de l’entreprise Lean

La version 4.6 de SAFe ajoute les cinq compétences clés de l’entreprise allégée, qui constituent désormais le principal objectif de la compréhension et de la mise en œuvre de SAFe. Chaque compétence Lean Enterprise est un ensemble de connaissances, de compétences et de comportements associés permettant aux entreprises d’obtenir la meilleure qualité et la meilleure valeur possible dans les délais les plus courts et les plus durables. Chaque compétence est brièvement décrite ci-après.

• La compétence Leadership Lean-Agile décrit comment les leaders Lean-Agile conduisent et soutiennent le changement organisationnel en permettant aux individus et aux équipes d’atteindre leur plus haut potentiel. Pour ce faire, ils apprennent, exposent, enseignent et encadrent la mentalité, les valeurs, les principes et les pratiques Lean-Agile de SAFe. Le résultat est des employés plus heureux, plus engagés et une productivité et une innovation accrues.
• La compétence Team and Technical Agility décrit les compétences critiques ainsi que les principes et les pratiques Lean-Agile nécessaires pour créer des équipes agiles hautes performances produisant des solutions techniques de haute qualité et bien conçues. Il en résulte une productivité accrue, une mise sur le marché plus rapide et une livraison de valeur prévisible.
• Les domaines de compétence DevOps et Release on Demand décrivent comment implémenter DevOps et un pipeline de distribution continue permet à l’entreprise de générer de la valeur, en tout ou en partie, à tout moment pour répondre aux besoins du marché et des clients. Cela permet à l’organisation de réduire les coûts de développement, de réduire les risques et de déjouer la concurrence.
• Le domaine de compétence Business Solutions et Lean Systems Engineering explique comment appliquer les principes et les pratiques Lean-Agile à la spécification, le développement, le déploiement et l’évolution de grandes applications logicielles complexes et de systèmes cyber-physiques.
• La compétence Gestion de portefeuille Lean aligne la stratégie et l’exécution en appliquant des approches Lean et de pensée systémique au financement de la stratégie et des investissements, aux opérations de portefeuille Agile et à la gouvernance. Ces collaborations permettent à l’entreprise d’exécuter les engagements existants de manière fiable et de mieux permettre l’innovation.

En outre, SAFe 4.6 constitue un nouveau domaine d’orientation pour le gouvernement. Basées sur les fondements et les principes de SAFe, les instructions mettent l’accent sur:

• Adapter les pratiques de gouvernance pour soutenir l’agilité et le flux de valeur Lean
• Modification des pratiques d’acquisition pour permettre le développement et les opérations Lean-Agile
• Application d’estimations et de prévisions Lean sur la cadence
• Adopter une budgétisation allégée alignée sur les flux de valeur
• Passer des projets à un flux épique d’épisodes maigres
• Aligner les investissements technologiques avec la stratégie de l’agence
• Création d’équipes performantes composées d’équipes gouvernementales et de sous-traitants
• Bâtir une base de valeurs, de principes et de pratiques Lean-Agile.

Configurations SAFe

SAFe prend en charge la gamme complète d’environnements de développement avec quatre configurations prêtes à l’emploi. Le sélecteur de configuration a été simplifié et repensé dans la version 4.6 et est illustré à la figure 2. Les configurations sont décrites ci-dessous.

• Essential SAFe
• Portfolio SAFe
• Large Solution SAFe
• Full SAFe

SAFe Essentiel

La configuration Essential SAFe est le bloc de construction de base pour toutes les configurations SAFe et constitue le point de départ le plus simple pour la mise en œuvre. Il fournit la compétence Leadership Lean-Agile, les compétences Team et Agility technique, ainsi que les compétences DevOps et Release on Demand.

SAFe est ancré dans une structure organisationnelle appelée ART (Agile Release Train), dans laquelle les équipes Agile, les principales parties prenantes et d’autres ressources sont dédiées à une mission de solution importante et permanente.

La figure 3. illustre cette organisation interfonctionnelle, optimisée pour faciliter le flux de valeur de l’idéation au déploiement et à la publication, et aux opérations.

Figure 3. Les trains de version Agile sont entièrement interfonctionnels

Essential SAFe inclut les constructions d’équipe et de programme, comme illustré à la figure 4.

Figure 4. Configuration essentielle de SAFe

Large Solution SAFe

La configuration SAFe des solutions étendues présente les domaines de compétence Business Solutions et Lean Systems Engineering, destinés à ceux qui développent les solutions les plus vastes et les plus complexes nécessitant plusieurs trains de version et fournisseurs Agile, mais ne nécessitant aucune considération au niveau du portefeuille.

Ce développement de solutions est courant dans des secteurs tels que l’aérospatiale et la défense, l’automobile et le gouvernement, où la grande solution – et non la gouvernance de portefeuille – constitue la principale préoccupation.

La structure organisationnelle Solution Train aide les entreprises confrontées aux plus grands défis, à savoir la construction de logiciels, matériels, cyber-physiques et systèmes informatiques complexes et de grande envergure. Le développement de ces solutions nécessite des rôles, des artefacts, des événements et une coordination supplémentaires, comme illustré dans la figure 5.

Portefeuille SAFe

La configuration de Portfolio SAFe fournit la compétence Lean Portfolio Management qui aligne l’exécution du portefeuille sur la stratégie de l’entreprise. Il organise le développement autour du flux de valeur via un ou plusieurs flux de valeur.

Portfolio SAFe offre aux entreprises de l’agilité par le biais de principes et de pratiques concernant la stratégie de portefeuille et le financement des investissements, les opérations de portefeuille Agile et la gouvernance Lean.

Dans la grande entreprise, il peut y avoir plusieurs portefeuilles SAFe. Apprendre encore plus.

Figure 6. Configuration de Portfolio SAFe

Full SAFe

La configuration Full SAFe inclut les cinq compétences principales de l’entreprise Lean. Il s’agit de la version la plus complète du Framework et soutient les entreprises qui construisent et maintiennent un portefeuille de solutions vastes et complexes.

Dans les plus grandes entreprises, plusieurs instances de diverses configurations SAFe peuvent être nécessaires.

Figure 7. Configuration SAFe complète

La Palette Spanning

La palette de répartition contient divers rôles et artefacts pouvant s’appliquer à une équipe, un programme, une solution volumineuse ou un contexte de portefeuille spécifique.

Élément essentiel de la flexibilité et de la configurabilité de SAFe, la palette englobante permet aux organisations d’appliquer uniquement les éléments nécessaires à leur configuration. La figure 8 illustre deux versions de la palette de recouvrement.

Figure 8. Palette Spanning

La figure la plus à gauche est utilisée par la configuration Essential SAFe, tandis que la plus à droite sert à toutes les autres configurations. Toutefois, SAFe étant un cadre, les entreprises peuvent appliquer l’essentiel des éléments de la palette la plus étendue à Essential SAFe.

Vous trouverez ci-dessous une brève description de chaque élément de la palette recouvrante:

• Métriques – La mesure principale dans SAFe est la mesure objective des solutions de travail. En outre, SAFe définit certaines mesures supplémentaires à moyen et à long terme, ainsi que des mesures que les équipes, programmes et portefeuilles peuvent utiliser pour mesurer les progrès.
• Services partagés – Représentent les rôles spécialisés nécessaires au succès d’un train ART ou Solution, mais ne pouvant être affectés à plein temps à un train spécifique.
• Communauté de pratique (CoP) – Une communauté de pratique est un groupe informel de membres de l’équipe et d’autres experts, agissant dans le contexte d’un programme ou d’une entreprise, qui a pour mission de partager des connaissances pratiques dans un ou plusieurs domaines pertinents.
• Jalons – Un jalon est utilisé pour suivre les progrès accomplis vers un objectif ou un événement spécifique. SAFe décrit les jalons d’apprentissage à date fixe, d’incrément de programme (PI) et d’apprentissage.
• Feuille de route – La feuille de route communique les produits livrables et les jalons planifiés du ART et de la chaîne de valeur sur une chronologie.
• Vision – La vision décrit une vision future de la solution à développer, reflétant les besoins du client et des parties prenantes, ainsi que les fonctionnalités et les capacités proposées pour répondre à ces besoins.
• Équipe système – L’équipe système est une équipe Agile spéciale qui fournit une assistance pour la création et l’utilisation du pipeline de distribution continue et, le cas échéant, pour la validation des performances système de bout en bout.
• Expérience utilisateur allégée (UX) – Lean UX est l’application des principes Lean à la conception d’expérience utilisateur. Il utilise une approche itérative, basée sur des hypothèses, pour le développement de produits, par le biais de mesures et de boucles d’apprentissage constantes (construction-mesure-apprentissage).

La Fondation

La Fondation contient les principes, les valeurs, l’état d’esprit, les consignes de mise en œuvre et les rôles de leadership nécessaires pour offrir une valeur à grande échelle.

Comme le montre la figure 9, chaque élément de fondation est décrit brièvement ci-dessous.

Figure 9. Fondation SAFe

• Leaders Lean-Agile – La direction assume la responsabilité ultime des résultats opérationnels. Les dirigeants sont formés à SAFe et deviennent, à leur tour, des formateurs de ces modes de pensée et de fonctionnement plus simples et plus agiles. À cette fin, SAFe décrit un nouveau style de leadership présenté par le nouveau «gestionnaire-enseignant-lean-pensant» de l’entreprise.
• Valeurs fondamentales – Quatre valeurs fondamentales: alignement, qualité intégrée, transparence et exécution du programme définissent le système de croyances et de valeurs de SAFe.
• Lean-Agile Mindset – Les leaders Lean-Agile sont des apprenants permanents et des enseignants qui comprennent, adoptent et promeuvent les principes et pratiques Lean et Agile dans l’ensemble de l’entreprise.
• Principes SAFe – Les pratiques SAFe reposent sur neuf principes qui synthétisent les méthodes Agile, le développement de produits Lean, DevOps, la réflexion sur les systèmes et des décennies d’expérience sur le terrain.
• Feuille de route de la mise en œuvre – La mise en œuvre des changements nécessaires pour devenir une entreprise à technologie Lean-Agile constitue un changement substantiel pour la plupart des entreprises. SAFe fournit une feuille de route de mise en œuvre pour aider les organisations à suivre ce chemin.
• Consultants de programme SAFe (SPC) – Les SPC sont des agents de changement qui associent leurs connaissances techniques de SAFe à une motivation intrinsèque pour améliorer les processus de développement de logiciels et de systèmes de leur entreprise.

Apprendre encore plus

[1] Knaster, Richard and Dean Leffingwell. SAFe 4.0 Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, Kindle Edition.

© Scaled Agile, Inc.

Le succès de tout type d’épidémie sociale dépend fortement de la participation de personnes possédant un ensemble de compétences sociales particulier et rare.

—Malcolm Gladwell, le point de basculement

Atteindre le point de basculement

Changer la façon de travailler – les habitudes et la culture d’une grande organisation de développement – est difficile. De nombreuses entreprises ont déclaré que la mise en œuvre de SAFe était l’une des initiatives de changement les plus difficiles et les plus enrichissantes jamais réalisées dans les entreprises.

Les gens résistent naturellement au changement, et vous entendez souvent des phrases telles que «c’est comme ça que nous avons toujours fait les choses ici» ou «ça ne marche pas ici. La meilleure façon, ou pire encore, peut remettre en question les croyances ou les valeurs de longue date d’une personne.

C’est facile pour les gens de conserver leur ancien comportement – à moins qu’il n’y ait une bonne raison de procéder à un tel changement. Une raison si convaincante que le statu quo devient tout simplement inacceptable. Une raison si forte que le changement devient le seul moyen raisonnable de réussir.

En d’autres termes, l’entreprise doit atteindre son «point de basculement» – le point où l’impératif organisationnel primordial est de réaliser le changement plutôt que de lui résister [1].

Détails

Le besoin de changement

Les organisations en viennent au besoin de changement à partir d’un large éventail de points de départ. Vous pouvez vous retrouver dans un environnement de chutes d’eau hautement réglementé, caractérisé par des examens stricts des portes de phase et des contrôles de qualité, une séparation des préoccupations et des procédures sophistiquées de gestion des ressources. Ou peut-être avez-vous développé une approche ad hoc associant des méthodes agiles au niveau de l’équipe et des techniques plus traditionnelles de gestion de projet et de portefeuille. Quoi qu’il en soit, avant qu’un effort de changement réussi puisse commencer, il doit exister un élan clair et convaincant en faveur du changement. Reconnaissance générale du fait que les méthodes de travail actuelles ne permettent pas d’obtenir la performance requise, maintenant ou à l’avenir. Nous avons constaté que les organisations capables d’établir une telle prise de conscience partagée rencontrent généralement l’une des deux conditions suivantes:

• Une plate-forme en feu – Parfois, le besoin de changer un produit ou un service est évident. La société ne parvient pas à faire face à la concurrence et les méthodes de travail existantes sont évidemment insuffisantes pour parvenir à une nouvelle solution dans un délai raisonnable. Des emplois sont en jeu. C’est le cas le plus facile pour le changement. Même s’il y aura toujours des résistants, ils seront probablement submergés par la vague d’énergie qui entraîne le changement obligatoire dans toute l’organisation.
• Leadership proactif – en l’absence d’une plate-forme enflammée, le leadership doit conduire le changement de manière proactive en prenant position pour un meilleur état de l’avenir. Les dirigeants Lean-Agile doivent montrer ce que Toyota [2] appellerait «un sentiment constant de danger», à savoir un sentiment sans fin de crise potentielle qui alimente une amélioration continue. C’est souvent la raison la moins évidente d’inciter au changement, car les personnes dans les tranchées peuvent ne pas voir ou ne pas ressentir l’urgence de faire le dur labeur qui accompagne le changement. Après tout, ils réussissent maintenant, pourquoi supposeraient-ils qu’ils ne continueront pas à réussir dans l’avenir? Le changement n’est-il pas risqué? Dans ce cas, la haute direction doit constamment insister sur la nécessité d’un changement pour tous, en précisant que le maintien du statu quo est tout simplement inacceptable.

Établir la vision du changement

Bien que nécessaire, une raison de changement convaincante et bien comprise est insuffisante pour qu’une organisation atteigne le point de basculement. Une vision claire pour l’avenir est également essentielle. Kotter note qu’établir une «vision du changement» est l’une des principales responsabilités du leadership [3]. La vision du changement offre trois avantages clés:

• But – Il clarifie le but et la direction du changement et définit la mission à suivre par tous. Cela évite les détails potentiels déroutants et concentre tout le monde sur le pourquoi, pas le comment du changement.
• Motivation – Cela commence à faire avancer les gens dans la bonne direction. Après tout, le changement est difficile et la douleur inévitable, surtout au début. Les emplois des gens vont changer. La vision aide à motiver les gens en leur donnant une raison impérieuse de faire le changement. Plus important peut-être, cela souligne le fait qu’il n’y a vraiment aucune sécurité d’emploi dans le statu quo.
• Alignement – Il est utile de lancer l’action coordonnée nécessaire pour garantir que des centaines, voire des milliers de personnes travaillent ensemble dans le but d’atteindre un nouvel objectif plus gratifiant personnellement. Avec une vision claire, les personnes sont habilitées à prendre les mesures nécessaires pour réaliser cette vision, sans besoin constant de supervision ou d’enregistrement de la part de la direction.

Dans notre cas, la vision du changement doit être ancrée dans une compréhension des principes Lean-Agile Mindset et SAFe.

D’un point de vue économique

Que ce soit réactif ou proactif, la principale raison de conduire le changement dans une organisation est de réaliser les avantages commerciaux et personnels que le changement est censé apporter. Le principe n°1 de SAFe nous rappelle de toujours «faire preuve de vision économique». Dans ce contexte, les dirigeants doivent exprimer l’objectif du changement dans des termes que tout le monde peut comprendre. Des dizaines d’études de cas montrent que les entreprises peuvent s’attendre à des avantages dans quatre domaines principaux, comme le montre la figure 1.

Figure 1. Avantages de SAFe pour l’entreprise: amélioration du délai de mise sur le marché, de la qualité, de la productivité et de l’engagement des employés

Les leaders du changement devraient communiquer ces avantages attendus dans le cadre de la vision du changement. En outre, les dirigeants doivent décrire tout autre objectif spécifique et concret qu’ils souhaitent atteindre. Des améliorations mesurables de ces indicateurs de performance clés fourniront le carburant nécessaire pour sortir de l’inertie du statu quo.

S’y rendre – Leading SAFe

Trop d’initiatives de changement meurent avant de commencer par prendre de l’avance. Tandis que former des personnes et former des ART (agiles release trains) peut sembler être un progrès, nous avons constaté que ces efforts s’arrêtent inévitablement face à l’inertie de le point de bascule.

Le moyen le plus efficace que nous ayons trouvé pour les organisations d’atteindre le point critique est l’expérience commune de participer à Leading SAFe.

Nous reconnaissons à quel point il peut être difficile pour les hauts responsables de s’engager pendant deux jours, mais nous savons par expérience qu’il est essentiel d’établir une raison et une vision du changement véritablement partagées. Les dirigeants doivent prendre le temps, en groupe, d’explorer, de raisonner et de valider en collaboration les défis auxquels l’organisation est confrontée. Ils doivent évaluer dans quelle mesure le système actuel contribue à relever ces défis et apprendre l’état d’esprit, les principes et les pratiques qu’ils devront adopter pour obtenir les résultats transformateurs qu’ils envisagent.

Aborder la mise en œuvre de SAFe au gouvernement

L’expérience pratique nous a montré que les principes et les pratiques de SAFe fonctionnent aussi bien dans un contexte gouvernemental que dans un contexte commercial. Cependant, les défis du contexte organisationnel, de la culture et de la gouvernance dans les programmes du secteur public sont vraiment uniques. Les processus et les lois d’acquisition des pouvoirs publics visent à créer des conditions de concurrence équitables entre les fournisseurs potentiels, mais ils peuvent également créer une bureaucratie et des retards. En outre, les agences gouvernementales ne disposent pas de la dynamique du marché concurrentiel et de la motivation du profit qui induisent un changement rapide et l’innovation dans un environnement commercial. Au lieu de cela, le financement est généralement fourni par les organes législatifs dans le cadre de processus de crédits annuels politiquement chargés qui avancent lentement. Même le concept de «valeur» dans un programme technologique gouvernemental est souvent difficile à conceptualiser et à mesurer.

Pour aider les agences gouvernementales à dépasser le seuil critique et à prendre la décision d’adopter SAFe, nous avons ajouté des directives qui traitent directement des obstacles les plus fréquents à l’intégration de Lean-Agile au gouvernement et nous avons proposé des solutions pratiques pour surmonter ces défis. Vous pouvez en savoir plus sur ces recommandations dans notre article sur SAFe for Government. En outre, nous avons créé un cours intitulé SAFe pour le gouvernement, qui oriente les apprenants vers les meilleures pratiques pour la mise en œuvre de SAFe dans un contexte gouvernemental. Comme Leading SAFe, ce cours peut être utilisé pour aider les décideurs à «passer au SAFE» et orienter les autres dirigeants d’agences et de partenaires industriels sur les modèles recommandés pour aligner la budgétisation, les prévisions, les contrats, la gouvernance, la gouvernance, etc. sur les principes et les pratiques. de Lean-Agile.

Avancer

Une vision claire et une raison impérieuse de changement sont gaspillées si elles ne sont pas accompagnées par une puissante coalition directrice pour faire avancer la vision [3]. Le point de basculement n’est que le début de la formation de cette coalition directrice. SAFe est un cadre éprouvé qui a permis d’obtenir des résultats transformateurs pour des centaines d’organisations. Étant donné que le changement est une raison impérieuse, l’étape suivante consiste à engager les dirigeants à constituer une équipe de transformation capable d’acquérir des connaissances et d’explorer les voies possibles pour lancer la mise en œuvre de SAFe.

Par conséquent, le prochain mouvement critique consiste à former des agents de changement Lean-Agile.

© Scaled Agile, Inc.

Les méthodes Agiles ont été définies et formalisées en 2001 par l’Agile Manifesto. Elles prônent une démarche plus pragmatique et itérative que les méthodes traditionnelles. L’implication de tous les acteurs du projet, dont le client final, est au cœur de cette logique, afin de permettre une plus grande réactivité au changement de la demande.

En résumé, nous pouvons dire que n’importe quelle équipe, dont les actions se reposent sur les 12 principes agiles, suit cette méthodologie.

En fin de compte, la méthode agile vise, de manière collaborative, à développer une remise finale étape par étape, par le biais de petits livrables individuels, permettant de modifier ces derniers à tout moment (à cause des changements d’objectifs ou du feedback des clients), sans en affecter l’ensemble, ce qui permet d’apporter dans le marché uniquement les produits qui sont pertinents.

Les avancements sont incrémentaux et permettent une gestion agile et rapide, capable de s’adapter aux changements sans accrocs majeurs.

Les méthodes Agiles sont des pratiques de gestion pouvant s’appliquer à tous les types de projets. Elles sont particulièrement développées dans le domaine de la conception logiciel.

Le mouvement plus large du management Lean couple les valeurs Agiles aux techniques d’amélioration continue de la qualité. L’Agilité s’inscrit alors dans l’ensemble des projets de l’entreprise.

Pour résumer, l’agile est un système de production, une façon d’organiser une équipe pour qu’elle réussisse à livrer dans une situation complexe et incertaine. Et cela fonctionne très bien ! L’agile permet de faire des miracles.

Lean

Le Lean, issu du Toyotisme, a pour but l’amélioration de la productivité, de la qualité, des délais et une meilleure gestion des coûts. Cela passe par l’amélioration continue et l’élimination des gaspillages.

Cette agilité appliquée à l’entreprise se matérialise par une organisation en services ayant pour objectif :

• la motivation des ressources humaines
• l’usage des nouvelles technologies
• l’amélioration continue des processus

À la fin du dernier millénaire, il a commencé à être utilisé dans le développement de logiciels et, en 2008, a évolué vers les célèbres 5 principes du Lean (au départ il y en avait 7), créés par Eric Reis, avec l’objectif principal d’aider les startups à :

« Élaborer des produits et des services dans un contexte d’extrême incertitude ».

Les 5 principes du lean sont les suivants :

• Les entrepreneurs sont partout
• Entrepreneuriat signifie gestion
• Validation de l’apprentissage
• Comptabilité pour l’innovation
• Construire – Mesurer – Apprendre

Le but de tout cela est de suivre un cycle dans lequel on fait passer de nombreux tests, de préférence liés à l’avis des consommateurs et usagers, dans le but de réduire les risques de développer un produit qui n’intéresse pas le marché.

Si on prend les préceptes de la culture Lean :

• Lean est une culture d’amélioration continue pratiquée à tous les niveaux de l’organisation et par chaque équipe
• Lean est l’application de la méthode scientifique d’expérimentation et d’étude des processus de travail et des systèmes pour trouver des améliorations.
• Lean est le respect pour les gens. C’est le respect de la voix du client et c’est le respect pour ceux qui font le travail, qui sont «sur le terrain» et sont, par conséquent, les «plus grands experts du monde» dans leur travail.
• Lean est l’élimination des déchets sous toutes ses formes. Lean est la capacité de distinguer entre le travail qui ajoute de la valeur à vos clients et le travail qui ne fait pas. En éliminant les déchets, vous libérez des ressources pour vous consacrer à une activité à valeur ajoutée qui sert vos clients.
• Lean est un environnement de travail qui assure la qualité et la sécurité de tous les travaux pour les clients et le personnel.
• Lean met l’accent sur l’amélioration du processus de travail et non sur le blâme ou la peur.
• Lean est une culture de travail d’équipe, de responsabilité partagée et de propriété qui abat les murs d’organisation ou les silos.
• Lean est une culture qui retourne la joie au travail. Honda parle des trois joies de l’achat, la vente et la fabrication du produit. Nous faisons notre meilleur travail lorsque nous avons de la joie dans notre travail.
• Lean est flux. Lean est un processus sans interruption qui coule du début à la fin sans interruption.

Lean ou agile ? Le point sur les différences

La méthode agile (pour développer le produit) et le Lean startup (pour le business model) sont les deux méthodologies qui permettent de procéder de façon itérative et incrémentale pour augmenter les chances de succès des projets. En réalité, il s’agit davantage de “philosophies” qui guident tout un tas d’autres méthodologies aux noms barbares (Scrum, Kanban, XP, TPS, etc.) mais qui reposent sur leurs principes.

Voir les différences via cet article https://hackerchick.com/agile-vs-lean-yeah-yeah-whats-the-difference/

Autres informations :

• Agile++ : ce que la pensée Lean apporte aux méthodes Agiles

Éliminez les barrières entre les départements.

—W. Edwards Deming

Identifier les Value Streams et les ARTs

Les quatre premiers «mouvements critiques» de la feuille de route pour la mise en œuvre établissent l’urgence du changement et la masse critique de personnes informées et dévouées nécessaires à la mise en œuvre efficace de SAFe:

• Atteindre le point de bascule
• Former des agents de changement Lean-Agile
• Former les dirigeants, les gestionnaires et les dirigeants
• Créer un centre d’excellence Lean-Agile (LACE)

Avec un sentiment d’urgence et une puissante coalition en place, il est maintenant temps de mettre en œuvre SAFe. Dans cet article, nous décrivons le prochain mouvement critique: identifier les flux de valeur et les Agile Release Train (ART). Si vous considérez les flux de valeur et les ART comme l’épine dorsale d’une initiative SAFe, vous comprendrez leur importance pour ce parcours. Vouloir raccourcir ou accélérer cette étape équivaudrait à appuyer sur le frein en même temps que vous essayez d’accélérer. Mais si vous l’avez bien choisi, vous serez sur la bonne voie pour réussir votre transformation.

Détails

L’identification des Value Streams et des Agile Release Train (ART) nécessite la compréhension d’un nouveau modèle organisationnel, optimisé pour faciliter le flux de valeur entre les silos fonctionnels, les activités et les limites, et comprend les étapes suivantes:

• Identifier les flux de valeur opérationnels
• Identifier les systèmes prenant en charge le flux de valeur opérationnel
• Identifier les personnes qui développent et entretiennent ces systèmes
• Définition des flux de valeur de développement contenant les systèmes et les personnes
• Identifier les ART qui réalisent les flux de valeur de développement

Les sections ci-dessous décrivent chacune de ces activités.

Mise à jour de la Value Stream

Avant de commencer, un bref rappel est nécessaire. Une Value Stream est un élément fondamental pour comprendre, organiser et générer de la valeur dans SAFe. Comme l’illustre la figure 1, chaque flux de valeur est une longue série d’étapes utilisées pour créer de la valeur, du concept à la fourniture d’un résultat tangible pour le client. Comme tout récit bien construit, le flux de valeur identifie un flux d’activités chronologique:

Figure 1. L’anatomie d’un flux de valeur

• Trigger – Un événement important déclenche le flux de valeur, par exemple une commande client ou une demande de nouvelle fonctionnalité. Elle se termine lorsqu’une valeur (livraison, achat client ou déploiement de solution) a été livrée.
• Steps – Les chevrons situés au centre sont les étapes que l’entreprise utilise pour accomplir cet exploit [1]. Par exemple, la figure 2 décrit les étapes nécessaires à la publication de l’article que vous lisez actuellement sur ce site Web.

Figure 2. Étapes de la chaîne de valeur qui ont créé cet article

• Value – Le client reçoit une valeur lorsque le flux de valeurs exécute toutes ses étapes. Dans la Figure 2, l’utilisateur tire profit de la valeur de son article pour améliorer sa connaissance de SAFe.
• People and systems – Un flux de valeur comprend également les personnes qui effectuent le travail, les systèmes qu’elles exploitent et le flux d’informations et de matériel. Par exemple, dans la Figure 2, les personnes qui rédigent les articles, celles qui gèrent le site Web, l’application WordPress qui le rend fonctionnel et les systèmes d’hébergement du service Web d’Amazon font tous partie du flux de valeur.
• Lead time – Le délai entre le déclenchement et la livraison de la valeur est le délai d’exécution. Le raccourcissement du délai réduit le délai de mise sur le marché. Le moyen le plus simple de réduire les délais consiste à identifier et à réduire (ou supprimer) les activités sans valeur ajoutée et les retards inutiles. C’est l’objectif principal de la pensée Lean.

Types de flux de valeur

Avant de risquer de simplifier à l’excès, notons qu’il existe deux types de value steams [1], comme l’illustre la figure 3.

Figure 3. Flux de valeur opérationnels et de développement

• Operational Value Streams – Ce sont les personnes et les étapes utilisées pour fournir des biens ou des services à un client. Les exemples peuvent inclure la fabrication d’un instrument médical, ou la commande et la réception d’une pièce d’un fournisseur.
• Development value streams – Il s’agit des personnes et des étapes utilisées pour développer de nouveaux produits, systèmes, solutions et services vendus par l’entreprise ou prenant en charge des flux de valeur opérationnels internes. Ce sont les flux de valeur qui constituent un portefeuille SAFe.

SAFe s’intéresse principalement aux flux de valeur de développement. Après tout, SAFe se concentre sur la fourniture de nouvelles solutions dans les délais les plus courts et les plus durables, et les flux de valeur nous aident à comprendre comment y parvenir. Cependant, les flux de valeur opérationnels de l’entreprise doivent être identifiés pour déterminer les flux de valeur de développement qui les prennent en charge.

Identifier les flux de valeur opérationnels

Pour certaines organisations, l’identification des flux de valeur opérationnels est simple. Beaucoup ne sont que des produits, des services ou des solutions que la société développe et vend.

Cependant, dans la grande entreprise, la tâche est plus compliquée. La valeur transite par divers applications, systèmes et services – dans de nombreux secteurs de l’organisation distribuée – aux clients internes et externes.

Dans ces cas, l’identification des flux de valeur opérationnels est une activité analytique essentielle. La figure 4 fournit un ensemble de questions qui aident les parties prenantes à travers ce processus d’identification.

Figure 4. Questions permettant d’identifier les flux de valeur opérationnels

Identifier les flux de valeur opérationnels dans la grande entreprise n’est pas une mince affaire. Cela nécessite une prise de conscience du but plus général de l’organisation et une compréhension explicite de la manière dont des éléments spécifiques de la valeur sont transmis au client. Pour vous aider, nous avons illustré deux exemples dans les sections ci-dessous: un du secteur des soins de santé et un des services financiers.

Modèle de définition de Value Stream

Le modèle de définition de flux de valeur peut être utilisé pour élaborer et comprendre davantage les caractéristiques du flux de valeur identifié. La figure 5 en fournit un exemple.

Figure 5. Modèle de définition de flux de valeurs avec un exemple de flux de valeurs opérationnelles

Exemple de flux de valeur opérationnelle pour le fournisseur de soins de santé

Notre premier exemple de flux de valeur opérationnelle est un fournisseur de réseau de soins de santé, comme illustré à la figure 6 [2]:

Figure 6. Flux de valeur opérationnels d’un fournisseur de réseau de soins de santé

À titre d’illustration, cet exemple concerne l’hôpital, en particulier le flux de valeur qui représente les processus et les systèmes d’information prenant en charge le traitement des patients, de l’admission au traitement en passant par la facturation.

Le déclencheur de ce flux de valeur est l’arrivée d’un patient à l’hôpital. L’hôpital reçoit la valeur totale une fois que le patient est traité et que les services fournis sont payés, comme le montre la figure 7.

Figure 7. Étapes du flux de valeur de facturation patient

Les personnes indiquées au-dessus des chevrons (activités principales de création de valeur) sont les personnes qui exécutent les différentes étapes de la chaîne de valeur.

Exemple de flux de valeur des services financiers

Le deuxième exemple de flux de valeur opérationnel, que nous développerons plus loin, est un établissement bancaire. La figure 8 illustre la diversité des flux de valeur pouvant exister dans une grande institution financière.

Figure 8. Une banque et ses flux de valeur opérationnels

Le rectangle rouge met en évidence le flux de valeur «prêts bancaires aux consommateurs» utilisé pour une illustration plus détaillée ci-dessous. Le flux de valeur est déclenché lorsque le client recherche et trouve les offres et les taux de prêt de la banque et est rempli lorsque le client rembourse le prêt avec intérêt. Les étapes et les personnes qui les exécutent sont mises en évidence à la figure 9.

Figure 9. Flux de valeur des prêts à la consommation

(Remarque: le client participe également directement à ce flux de valeur.)

Identifier les systèmes qui supportent le flux de valeur opérationnelle

Une fois que les étapes de la chaîne de valeur opérationnelle sont identifiées, l’activité suivante consiste à identifier les systèmes développés pour la prendre en charge. Pour les flux de valeur plus importants, il est important de mapper les connexions des systèmes aux différentes étapes du flux de valeur. Cela crée une compréhension plus profonde de la façon dont tout cela fonctionne, comme le montre notre exemple de prêt à la consommation à la figure 10.

Figure 10. Identification des systèmes prenant en charge les étapes

Identifier les personnes qui développent les systèmes

Une fois que les systèmes qui supportent le flux de valeur opérationnelle ont été identifiés, la prochaine activité consiste à estimer le nombre et l’emplacement des personnes qui construisent et entretiennent ces systèmes, comme l’illustre la figure 11.

Figure 11. Identifier les personnes qui développent les systèmes

Définir les flux de valeur de développement

Ensuite, nous identifions les flux de valeur de développement, qui représentent les étapes nécessaires pour développer ces systèmes, ainsi que les personnes qui les développent. Étant donné qu’il s’agit de flux de valeur différents des flux opérationnels, nous devons examiner quels sont le déclencheur et la valeur. Les systèmes prennent en charge et permettent un meilleur fonctionnement à travers les flux de valeur opérationnels et, à ce titre, représentent des fonctionnalités nouvelles ou modifiées dans les systèmes. Les éléments déclencheurs sont donc les exigences et les idées qui animent ces fonctionnalités.

Figure 12. Définition des flux de valeur de développement

Nous pouvons utiliser ces déclencheurs pour identifier le nombre de flux de valeur de développement que nous avons. Si la plupart des exigences nécessitent de toucher tous les systèmes pour activer la nouvelle fonctionnalité, nous disposons probablement d’un flux de valeur de développement. Si, toutefois, les systèmes sont découplés, nous pourrions en avoir quelques-uns. Dans tous les cas, les flux de valeur de développement doivent être essentiellement ou totalement indépendants, et capables de se développer et de se libérer par eux-mêmes, sans trop de dépendances intra-flux de valeur. Dans l’exemple de la figure 12, la plupart des exigences concernent les trois premiers systèmes ou les deux derniers, mais rarement tous. Nous avons donc deux flux de valeur de développement, chacun capable de se développer, de s’intégrer, de se déployer et de se libérer indépendamment l’un de l’autre.

Flux de valeur de développement transfrontaliers

Une fois que les flux de valeur de développement sont identifiés, l’étape suivante consiste à comprendre comment former des Agile Release Train pour les réaliser. Les ART contiennent toutes les personnes et autres actifs nécessaires pour améliorer le flux de valeur. La première étape consiste à comprendre où cette valeur est créée dans l’entreprise, car c’est là que se trouvent les personnes, les processus et les systèmes. Ce faisant, il devient évident que les flux de valeur de développement traversent de nombreuses frontières. Les entreprises sont organisées comme elles le sont pour de nombreuses raisons: histoire, commodité fonctionnelle, efficacité de la centralisation, acquisitions, géographie, etc. En conséquence, il est tout à fait possible que personne ne comprenne la série complète d’événements nécessaires au développement et à l’amélioration continus des systèmes contribuant à la création de valeur. En outre, les tentatives d’amélioration tendent à se concentrer sur des améliorations fonctionnelles et locales, ce qui peut permettre d’optimiser une fonction ou une étape, mais de sous-optimiser le flux de bout en bout.

C’est la nature de longue durée des flux de valeur qui déclenche une réflexion différente au sein de l’organisation Lean. Pour résoudre ce problème, les entreprises appliquent la pensée systémique (principe 2, Appliquer la pensée systémique) et comprennent enfin comment diverses parties du système doivent travailler ensemble pour améliorer le flux. En règle générale, les grandes entreprises sont organisées de manière fonctionnelle. En outre, les personnes sont réparties dans plusieurs régions géographiques et plusieurs pays. Mais la valeur dépasse ces limites, comme l’illustre la figure 13.

Figure 13. Flux de valeur à travers les limites fonctionnelles, organisationnelles et géographiques

Identifier les ART

La dernière activité consiste à définir les ART qui réalisent la valeur. L’expérience a montré que les ART les plus efficaces présentent les attributs suivants:

• 50 – 125 personnes
• Axé sur un système holistique ou un ensemble de produits ou de services associés
• Des équipes stables et durables qui apportent de la valeur de manière constante
• Minimiser les dépendances avec d’autres ART
• Peut releaser indépendamment des autres ART

Comme le montre la figure 14, il existe trois scénarios possibles pour la conception d’un ART.

Figure 14. Trois scénarios possibles pour la conception d’un ART

• Plusieurs flux de valeur de développement peuvent s’intégrer à un même ART – Lorsque plusieurs produits ou solutions connexes peuvent être produits avec un nombre de personnes relativement réduit, un seul ART peut générer plusieurs flux de valeur. Dans ce cas, l’ART est à peu près identique à la chaîne de valeur. Tout le monde est dans cet art!
• Un seul flux de valeur de développement peut s’inscrire dans un ART – Souvent, un flux de valeur peut être réalisé avec 100 praticiens ou moins. De nombreux groupes de développement sont déjà organisés en unités d’environ cette taille, il s’agit donc d’un cas courant. Encore une fois, tout le monde est sur l’ART.
• Plusieurs ART sont nécessaires pour les flux de valeur de développement importants – Lorsque de nombreuses personnes sont impliquées, la valeur de développement doit être divisée en plusieurs ART, comme décrit dans la section suivante, pour former un train de solutions.

Séparation de flux de grande valeur en plusieurs ART

Les grandes chaînes de valeur de développement sont très courantes dans les grandes entreprises et nécessitent souvent une analyse supplémentaire. Dans la mesure du possible, les trains devraient se concentrer sur un seul système primaire ou sur un ensemble de produits ou services étroitement liés dans cette chaîne de valeur. Il s’agit d’une conception assez simple: un ART fournissant un ensemble bien défini d’objets de valeur.

Cependant, dans le cas où plusieurs personnes sont nécessaires pour mettre en place un système unique, cela fonctionne mieux lorsque les équipes travaillent ensemble tout en développant des fonctionnalités et des composants présentant un degré élevé d’interdépendance. Cela nous amène au schéma relativement commun d’organisation des ART autour de «zones de fonctionnalités» ou de sous-systèmes.

• Les ARTs de Feature sont optimisés pour le flow et la vitesse. Dans ce cas, les équipes individuelles dans le train et l’ensemble du train lui-même peuvent offrir des fonctionnalités de bout en bout. L’avantage est évident et c’est pourquoi ils sont préférés. Mais faites attention à la gouvernance des sous-systèmes, sinon l’architecture du système se détériorera, ce qui réduira finalement la vitesse. Souvent, un architecte de système (une ou plusieurs personnes, voire une petite équipe) est dédié au maintien de l’intégrité de la plate-forme.
• Les ARTs de sous-systèmes les applications, composants, plates-formes, etc., sont optimisés pour la robustesse architecturale et la réutilisation des sous-systèmes et des services. Là encore, l’avantage est évident, car cela peut augmenter l’efficacité du développement et de la réutilisation. (Les architectures orientées service exploitent cela.) Toutefois, en fonction de la séparation des préoccupations dans l’architecture système, le flux de valeur dans ce scénario peut créer davantage de dépendances et nécessiter une coordination entre les ART.

Il n’existe pas de solution unique et les grands systèmes nécessitent généralement les deux types d’ART. Un exemple typique est lorsque plusieurs ART fournissent des services ou des solutions basés sur une plate-forme commune. Dans ce cas, il peut y avoir un ou plusieurs ART de plate-forme prenant en charge les ART de fonction, comme l’illustre la figure 15.

Il existe un autre schéma courant, dans lequel les ART réalisent des segments spécifiques dans un flux de valeur plus important. Cela peut ne pas sembler tout à fait complet, mais en réalité, le «début et la fin» d’un flux de valeur sont des notions relatives. Les types d’entrée, la valeur et les systèmes peuvent être très différents dans ces segments, créant une ligne de division logique.

Et bien entendu, les combinaisons de ces modèles apparaissent souvent dans les flux de valeur les plus importants, comme le montre notre dernier exemple à la figure 16.

Figure 16. Combinaisons de modèles d’ART sous l’exemple de prêt bancaire à la consommation

Enfin, il existe d’autres facteurs de conception et d’optimisation de l’ART basés sur des préoccupations telles que la géographie, le langage parlé et les centres de coûts, facteurs qui peuvent tous influer sur la conception de l’ART. Mais ceux-ci sont beaucoup moins souhaitables.

Le flux de valeurs SAFe et l’atelier de mise en œuvre

Comme démontré, la réflexion critique et l’analyse impliquées dans ce processus. Pour vous aider à identifier les flux de valeur, Scaled Agile, Inc. fournit une boîte à outils de flux de valeur, composée d’un atelier et d’autres artefacts que les consultants en programmes de SAFe (SPC) peuvent utiliser pour guider les parties prenantes. L’atelier propose une approche structurée permettant d’identifier les flux de valeur et de définir les ARTs, susceptibles de générer un flux de valeur dans l’entreprise. Cette boîte à outils offre une approche systématique éprouvée pour optimiser la conception en prenant en compte les dépendances, la coordination et les contraintes.

L’atelier Value Stream est souvent organisé directement après une Leading SAFe avec les principaux intervenants. L’objectif est de les guider tout au long du processus d’identification des flux de valeur, de la conception des traitements ART et peut-être même de choisir la date du premier lancement des ART après avoir acquis une compréhension fondamentale du développement Lean-Agile permis par SAFe.

Comme aucune conception n’est parfaite, les entreprises répètent parfois cet atelier après en avoir appris davantage, dans le cadre de l’étape de la feuille de route «Soutenir et améliorer». Cela permet aux entreprises d’affiner leur compréhension des flux de valeur et des ART et d’intégrer de nouveaux apprentissages dans la conception organisationnelle.

Avancer

Dans cet article, nous avons décrit la manière dont les équipes identifient les flux de valeur et conçoivent les ART qui constituent la structure organisationnelle de base de la transformation.

Nous sommes maintenant prêts pour la prochaine étape, Créer le plan de mise en œuvre, qui est le prochain article de la feuille de route de la mise en œuvre SAFe.

Apprendre encore plus

[1] Allen Ward, Lean Product and Process Development. (video) Lean Enterprise Institute, 2004

[2] Contributed by SPCT candidates Jane Tudor, Justine Johnston, Matt Aaron, Steve Mayner, and Thorsten Janning.

[3] Contributed by SPCT candidates Darren Wilmshurst, Murray Ford, Per-Magnus Skoogh, Phillip Manketo, Sam Bunting, and Virpi Rowe.

[4] Knaster, Richard and Leffingwell, Dean. SAFe Distilled, Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.

© Scaled Agile, Inc.