Comme à son habitude, le framework d’agilité à l’échelle SAFe va proposer une nouvelle version majeure, la cinquième depuis ses débuts.  

Plusieurs évolutions sont au menu, d’importance plus ou moins grandes. Par exemple, un nouvel onglet  Overview  vient résumer les « compétences » sur la page principale, l’étage  portfolio  se complète,  l’orientation client  prend une place centrale dans le framework, la notion  d’agilité business fait son apparition, … 

Mais est-ce tout ? Pas tout à fait… 

Car là où SAFe 5.0 apporte une grande nouveauté, c’est sur sa posture vis-à-vis de la structure des entreprises. En effet, nous avions jusqu’alors un modèle orienté delivery qui ne présumait pas spécialement de la façon dont l’entreprise était organisée.  

SAFe 5.0 semble (enfin) prendre position, notamment à travers deux introductions majeures : 

• Un 10ème  principe « Organize Around Value », qui explique ni plus ni moins comment une entreprise grandissante perd son agilité en se structurant, et propose le framework comme un « Second Operating System » pour un regain d’agilité. 
• Deux nouvelles « compétences » (qui portent le total à 7),  Organizational Agility  et  Continuous Learning Culture, qui mettent l’emphase sur l’agilité au-delà du delivery, comme le faisait déjà la compétence  Lean Portfolio Management.  

On aurait d’ailleurs presque envie de voir cette dualité  agilité du delivery  versus  agilité structurelle  dans l’Overview, toutes deux supportées par le lean agile mindset au service d’une entreprise « orientée client ». 

Si cette tendance se confirme dans la version finale de SAFe 5.0, cela sera une grosse évolution… et sans doute un gros argument de moins pour nombre de ses détracteurs  ! 

Ces éléments nouveaux contribuent à porter l’agilité à l’échelle de l’entreprise en proposant une ébauche pour embarquer les fonctions support (RH, légal, finance, marketing) tout en intégrant la culture d’entreprise comme un facteur clé de succès pendant et après la transformation !

Nous continuerons à vous donner plus détail sur le blog au fur et à mesure que les informations arriverons. 

SAFe 5.0:  https://scaledagileframework.com/# 

Pour aller plus loin :
Nos offres de conseil en entreprise agile.

SAFe 4.5, la nouvelle mouture de SAFe dans la continuité de la 4.0

SAFe 4.5 est sorti le 21 juin 2017 et il nous offre une image revue et enfin simplifiée de la Big Picture et un framework destiné aux Lean Enterprises !

SAFe 4.5 apporte en effet 4 éléments principaux :

1. Une meilleure adaptabilitée à chaque situation au travers des 4 configurations de SAFe ;
2. Une roadmap d’adoption du framework plus développée que la stratégie 1,2,3 ;
3. Un focus très fort sur l’intégration de DevOps comme moteur d’agilité global des trains ;
4. Une intégration de Lean Startup et Lean UX au sein du framework ;

Intro, un nouveau nom qui en dit long

SAFe n’est officiellement plus réservé qu’à l’IT, SAFe for Lean System Engineering devient SAFe for Lean Enterprises. Ce changement de nom n’est pas anodin et démontre s’il le fallait encore que l’on peut appliquer SAFe à n’importe quel type de contexte dans l’entreprise. L’utilisant moi-même depuis des années comme démarche de transformation pour l’implanter lui même comme modèle opérationnel d’entreprise, je ne peux qu’approuver ce changement.

1. Une meilleure adaptabilitée à chaque situation au travers des 4 configurations de SAFe

SAFe se décline maintenant en 4 configurations beaucoup mieux adaptées aux contextes de déploiements que l’on rencontre en entreprise. Dans tous les cas la Big Picture a subit un gros coup de lifting pour faire disparaître les éléments en double et donner plus d’espace à la lecture et la compréhension du schéma.

La version Essential SAFe

Cette version essentielle convient à la majorité des implémentations de SAFe ou à une première version d’un déploiement plus important. Fortement dépouillée, elle est beaucoup plus simple et abordable que la big picture précédente.

La version Portfolio SAFe

Cette version apporte la gestion de portefeuille et correspond au framework par défaut à trois couches que nous avions précédemment. La Big Picture est plus légère qu’auparavant grâce à l’utilisation de la palette sur le côté gauche.

La version Large Solution SAFe

Cette version ajoute à Essential SAFe le niveau Solution anciennement chaine de valeur, sans la gestion de portefeuille. Ce niveau a été fortement revu et son vocabulaire totalement simplifié afin que tout s’aligne sur le terme de Solution.

La version Full SAFe

Cette version intègre les 4 niveaux de SAFe équipe, programme, solution et portefeuille. C’est la plus complète et surement pas celle par laquelle on démarre lorsque l’on déploie SAFe pour la première fois dans une organisation.

2. La roadmap d’adoption de SAFe

La stratégie d’implémentation 1,2,3 qui consistait à passer quelques formations a vécu, elle était en effet beaucoup trop simpliste ! L’adoption de SAfe dans une organisation est une véritable transformation du modèle opérationnel de l’entreprise et pas seulement une affaire de quelques formations.

Même si cette nouvelle roadmap propose une trajectoire plus complète, elle reste encore bien trop simpliste pour adresser la transformation de modèle opérationnel que l’adoption de SAFe impose. Cette nouvelle version est encore une fois très centrée sur la formation aux différents rôles du framework et n’adresse pas réellement la reconception des processus, de l’organisation, de la gouvernance que l’adoption du framework impose. Elle passe sous silence le besoin fort d’outillage ALM / DevOps nécessaire pour supporter ces processus et encore plus l’effort de conduite du changement pour adopter la culture d’entreprise et les comportements des managers et collaborateurs adaptés à ce type de changement.

La meilleure façon d’adopter SAFe étant de l’utiliser lui même pour s’implémenter. Le pilotage d’une transformation organisationnelle en utilisant Essential SAFe est la meilleure stratégie pour l’adopter tout en validant au fur et à mesure que le framework s’adapte bien au contexte de l’entreprise.

3. Une intégration forte de DevOps

Toutes les implémentations de SAFe nécessitent un fort besoin d’outillage ALM et DevOps pour assurer la performance du système. La 4.5 met l’accent sur le DevOps en introduisant une double boucle en 8 entre le développement et les opérations et met en exergue des pratiques qui étaient essentielles sur le terrain pour assurer la performance de fonctionnement.

Le DevOps est ainsi adressé sur ces différentes dimensions culturelle, d’outillage, d’intégration dans le flux de travail, de mesure et de sécurisation des mises en production.

Le flux jusqu’à la production est introduit dans le Kanban de programme gérant les Features. A mon sens ce flux de Release doit même être séparé de celui des Features pour devenir un Kanban à part entière et se connecter à la fois au Kanban de programme pour Releaser des Features, mais aussi à celui d’équipe pour Releaser Stories d’évolution et anomalies.

4. Une intégration de Lean Startup et Lean UX au sein du framework

Qui ne s’est jamais posé la question : Les features doivent être Minimum Marketable Feature, mais que fait-on s’il faut un ensemble minimum de Features pour avoir un premier produit minimum viable (MVP) ?

La nouvelle mouture de SAFe intègre le Lean Startup au niveau du portefeuille d’Epic afin d’institutionnaliser un constat : un Epic est une très grosse exigence sur laquelle nous pouvons faire tout un tas d’hypothèses qui peuvent se révéler fausses : quel est l’élément le plus petit que l’on peut construire pour valider les hypothèses afin d’éviter la casse et s’orienter dans la bonne direction ?

Le Lean Startup étant essentiellement basé sur la roue de Deming et pronant un apprentissage très rapide, il s’intègre effectivement parfaitement avec le portefeuille d’Epics. Le débat qui peut ensuite subsister, porte sur le MVP pour chaque Epic ou un ensemble d’Epics pour constituer un MVP …

Enfin dernier apport de SAFe 4.5, l’intégration de Lean UX. L’intégration de l’UX dans le Kanban de programme et le Kanban d’équipe était l’affaire de spécialiste et d’une bonne dose de contextualisation. Sur ce dernier point l’article proposé n’apporte pas de réponses très importantes, mais des pointeurs intéressants vers l’ouvrage Lean UX.

Notre offre de transformation agile

Evénement CIO DSI Agile

Venez me retrouver le 13 juin 2017 à l’événement DSI Agile organisée par CIO événements.
A l’agenda :

1. Agilité

Qu’il s’agisse du Build comme du Run, la DSI doit pouvoir s’adapter aux évolutions des besoins et de la demande. Du développement agile au cloud hybride, tout est bon pour cela.

2. DevOps

Le développement agile se heurtait jadis au mur de la mise en production. Les méthodes de mises en production continues font sauter ce bouton sans mettre en cause la stabilité du SI.

3. API

Si le concept d’urbanisation ou d’APi n’est pas jeune, organiser tout son système d’information autour d’une notion de services publiés permet d’atteindre le Graal de l’agilité fiable.

4. Management agile

L’agilité n’est pas une affaire d’outils ou de méthodes. Ce sont bien les hommes qu’il faut faire changer. Le management doit s’adapter à l’agilité.

Plus d’information ici : http://www.cio-online.com/conferences/lire-la-dsi-agile-245.html

Pour aller plus loin consultez notre article CIO Office Design & Déploiement. 

Premier Meetup du French SAFe User Group,
15 mars 2016 de 18h00 à 20h00
chez ING France

Déjà dans sa version 4, SAFe est le framework d’agilité à grande échelle le plus utilisé au monde avec des déploiements dans plusieurs grands groupes français.

L’équipe du DSI d’ING France accueillent ce premier rendez-vous Cour St Emilion dans leurs locaux. Cet événement est réservé aux DSI et à leur équipe de management.  Il se présente sous la forme d’échange entre pairs, nous aborderons le thème de l’agilité à grande échelle avec le Framework SAFe. Vous pourrez profiter du retour d’expérience du DSI d’ING et de ses équipes. Vous pourrez ensuite échanger par tables sur vos retours d’expérience respectifs sur le déploiement de l’agilité dans vos organisations et profiter du retour d’expérience des équipes ING et des animateurs de l’événement.

Pour vous inscrire au groupe Meetup FSUG : http://www.meetup.com/fr-FR/French-Scaled-Agile-Framework-SAFe-User-Group/ et vous inscrire à l’événement.

En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.

SAFe 4.0, avec la maturité, l’agilité change une nouvelle fois d’échelle

Avec la sortie de SAFe 4.0, Scaled Agile Inc frappe fort et nous propose une version 4.0 du framework d’agilité à grande échelle qui apporte une réponse aux grandes différences d’échelles auxquels il est utilisé et qui fusionne enfin les versions logicielle et d’ingénierie système du framework.

En synthèse

La version 4.0 apporte ainsi le support d’un niveau permettant de gérer des milliers de personnes et de construire des systèmes complets incluant du logiciel et du matériel. Cette version apporte une plus grande modularité dans son adaptation au contexte spécifique dans lequel il est déployé en faisant figurer clairement les stratégies d’adaptation à partir de principes de base. Très fortement employé au sein des équipes agiles, SAFe 4.0 fait la part belle au système de Kanban à tous les niveaux du framework. Enfin SAFe 4.0 réaffirme très fort l’implication nécessaire des managers leaders comme porteurs du changement et comme support des équipes.

Un quatrième niveau “chaine de valeur” optionnel

SAFe 4.0 ajoute un niveau optionnel intermédiaire qui porte les chaines de valeur de l’entreprise. Il permet aux très grandes organisations de structurer leurs ARTs (grandes équipes agiles au sens de SAFe) sur ces chaines de valeur de l’entreprise et de les aligner sur une vision commune. Ce niveau, qui permet maintenant de gérer plusieurs milliers de personnes, a pour objectif de construire une solution complètement intégrée reposant sur un assemblage de logiciel et de matériel pour un client. Le client est encore mis plus au coeur de la construction itérative de la solution que l’on construit pour lui.
SAFe 4.0 distingue les chaines de valeur opérationnelles (ex. la chaine de valeur de commande ou la facturation), des chaines de valeur de développement des systèmes qui supportent ces chaines de valeur opérationnelles. La coordination entre chaines de valeur dépendantes est maintenant assurée par ce niveau chaine de valeur en introduisant la notion de points d’intégration entre chaines de valeur. Cette coordination est assurée par les trois rôles Value Stream Engineer (VSE), Solution Management et les Solution Architects. La coordination à proprement dite est assurée par deux points : pré-PI Planning et Post-PI Planning pour valider les dépendances et l’alignement sur les capacités à développer dans la backlog de chaine de valeur qui est répartie entre les multiples équipes programme.
Le framework introduit une évolution du framework de pilotage économique permettant de prendre des décisions éclairées à niveau de maille chaine de valeur. Pour préserver les différentes options au cours de la construction de la solution, SAFe 4.0 introduit la notion  de “Solution Intent” qui définit un système de balance entre architecture intentionnelle et exploration d’architecture au fur et à mesure de la construction.
Enfin, ce niveau ajoute le support et l’intégration de fournisseurs dans la construction de cette chaine de valeur.

Un niveau portefeuille ajusté pour gérer les chaines de valeurs multiples et les très grandes équipes

Pour tenir compte du niveau chaine de valeur, le niveau portefeuille accepte maintenant la gestion de portefeuilles multiples avec pour chacun une allocation budgétaire dédiée et un système d’allocation commun à tous.
Les thèmes stratégiques servent maintenant de pivot entre le top management et les responsables du portefeuille. Sur le terrain, j’ai effectivement constaté que la manipulation des Epics par le Top Management est impossible car trop fin. Le Top Management alloue maintenant des budgets sur ces thèmes stratégiques, la déclinaison opérationnelle étant à la charge du portefeuille et de(s) l’ART(s). Le budget du portefeuille n’est plus alloué au ART mais directement au chaines de valeur.

Une simplification des trois niveaux de SAFe

La version standard de SAFe à trois niveaux a été simplifiée pour tenir compte des remarques de la communauté, notamment sur le vocabulaire employé. Par exemple le Release Planning devient le PI Planning ce qui semble plus logique.
La Big Picture peut-être visionnée avec 3 ou 4 niveaux permettant ainsi de se balader entre les deux vues très simplement.
Les fondations de SAFe ont été ajoutée directement sur la “Big Picture” permettant ainsi d’affirmer leur importance avec notamment l’introduction des “SAFe principles” et du “Implementing 1, 2, 3” vous guidant dans le déploiement et l’adaptation de SAFe à votre contexte.
Les pratiques Kanban de niveau équipe ont été intégrées de manière beaucoup plus poussées que dans les versions précédentes permettant ainsi de mixer des équipes Scrum et des équipes fonctionnant en Kanban.

Introduction des communautés de pratiques

Présentes dans le modèle Spotify, les communautés de pratiques faisaient défaut dans SAFe jusque là. Elles permettent de tenir compte de l’organisation en réseau nécessaire aux équipes agiles pour diffuser le savoir entre des équipiers, Scrum Master ou Product Owner répartis dans des équipes agiles différentes. Cette pratique favorise la capitalisation des savoirs faire et participe à l’alignement global des équipes.

Un système de Kanban de bout en bout

Le system de Kanban, initialement au niveau portefeuille, est maintenant étendu aux niveaux chaine de valeur et programme assurant ansi une gestion du flux et des limites de travail en cours de manière homogène de bout en bout. Déjà très souvent utilisé au niveau équipe en ScrumBan ou Kanban direct, le kanban est aussi introduit au niveau programme pour gérer notamment l’état de complétude des features avant de les proposer aux équipes (Definition Of Ready du Feature).

Une gestion des exigences de bout en bout revue

L’introduction du niveau chaine de valeur a imposé d’introduire des éléments de backlogs supplémentaires et de les mettre en cohérence les uns avec les autres. Le triptyque simple de départ Epic, Feature, Story avait déjà été étendu en cas de multiples ART avec les quatre éléments Portfolio Epic, Program Epic, Feature et Story. Maintenant si vous utilisez le version à 4 niveaux de SAFe, vous avez Epics / Capacities / Features / Stories.

Introduction de la “Spanning Palette”

Tous les éléments ou les fonctions qui sont utilisables à plusieurs niveaux de SAFe sont regroupées dans cette nouvelle “Spanning Palette”. Elle regroupe d’une part les artefacts d’alignement tels que la Vision, la Roadmap, les Métriques, les milestones et les releases et d’autre part les équipes transverses telles que les DevOps, la System Team, le Release Management, la User Experience et les services partagés (experts intervenant au besoin). Vous pouvez décider d’utiliser ces éléments aux niveaux portefeuille, chaine de valeur, programme ou équipe selon vos besoins, le framework n’impose rien ici.

Introduction de la notion d’enabler pour regrouper les contributions techniques

Cette notion chapeau d’enabler regroupe les anciennes notions d’epic technique, de feature d’architecture et de spike. Elle a pour objet de montrer que ces éléments n’apportent pas de valeur intrinsèque, mais qu’ils servent bien à construire les éléments à valeur ajoutée métier qui les utilisent. A partir de maintenant la hiérarchie d’exigences techniques s’exprime ainsi : Enabler Epics – Niveau Portefeuille, Enabler Capability – Niveau Chaine de valeur, Enabler Features – niveau Programme, Enabler Stories – Niveau Equipe. Les enablers peuvent être catégorisés en exploratoire, architecture ou infrastructure.

Dores et déjà les grands éditeurs qui supportent le framework proposent de nouvelles version de leurs suites d’outils :

• CA Agile Dev, ex Rally Software, annonce le support de SAFe 4.0 dans sa suite CA Agile Central ici.
• Version One annonce son support de SAFe 4.0 ici.

Pour les SAFe Program Consultant (SPC) comme moi-même, cette version impose un retour par la case certification.

En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.