SAFe 4.0, l’âge de raison ?

SAFe 4.0 a vu le jour le 3 Janvier 2016. Deux ans se sont écoulés depuis la dernière version majeure.

À l’heure où SAFe devient une solution sérieuse aux transformations digitales des grandes entreprises françaises, cette nouvelle version se veut plus scalable et plus modulaire. Mais qu’en est-il vraiment ? Version marketing ou réelle évolution tirée par les enseignements des précédentes releases ?

Chez Xebia, nous pensons que SAFe entre dans l’âge de raison et voilà pourquoi :

SAFe devient flexible

Depuis ses débuts, SAFe et son poster exhaustif dégagent une image de rigidité « anti-agile ». Pourtant, ce framework se veut être un point de départ pour une transformation agile à l’échelle. Il constitue une boite à outils laissant une place prépondérante à l’autonomie.

Cette dernière version accentue son positionnement en proposant plus clairement des choix d’implémentation suivant le contexte.

Tout d’abord, il change de nom et devient « SAFe 4.0 for Lean Software and Systems Engineering ». La partie « Systems Engineering » est nouvelle, elle n’était pas adressée auparavant.

Plus spécifiquement, SAFe 4.0 laisse le choix d’être implémenté sur 3 ou 4 niveaux.

Sur 3 niveaux, le framework s’adresse aux organisations de quelques centaines de personnes ou moins. Les différences sont minimes avec la version précédente. La rétro-compatibilité en est facilitée.

Sur 4 niveaux, la nouvelle version gère les flux de valeurs complexes composés de plusieurs trains et de fournisseurs non-agiles. La version 3 présentait déjà le cas d’implémentation d’un flux de valeur composé de plusieurs trains. Une documentation légère et discrète présentait alors des rôles supplémentaires comme le « Solution Architecte » pour synchroniser les trains.

Avec sa version 4.0, SAFe adresse plus précisément le sujet. Le poster se voit ainsi doté d’une nouvelle couche « Value Stream » ajoutée entre le portfolio et le programme. De nouveaux rôles, processus et artefacts font leurs apparitions.

Pour ce qui est de ces nouveaux rôles, ils sont au nombre de trois :

• Value Stream Engineer (VSE) : un rôle de servant leader qui s’assure du bon fonctionnement du « Value Stream » à l’image du RTE pour les trains. C’est finalement un rôle assez proche de celui d’un Scrum Master.
• Solution Management – Primary Content Authority: le Product Manager de l’ensemble de la « Value Stream », responsable du « Value Stream Backlog » et de sa priorisation, mais aussi de la création d’un framework d’analyse financière (« Economic Framework ») pour aider à la prise de décision des « Agile Release Trains » (ART) et « Agile Teams ».
• Solution Architect/Engineer: une équipe participant à la volonté d’excellence technique que l’on retrouve dans SAFe. Elle a en charge le design de l’architecture nécessaire à la coordination de la solution à travers les différents ARTs.

Parmi les artefacts, nous retenons plus particulièrement l’émergence d’un nouveau backlog avec un niveau de granularité appelé « Capability » situé entre l’Epic et la Feature. Au global la hiérarchie de définition du besoin d’une implémentation de SAFe 4.0 sur l’ensemble des 4 niveaux devient donc la suivante: Epics > Capabilities > Features > Stories.

« Features » et « Capabilities » sont largement similaires, ils participent tous deux à l’amélioration de la solution. La « Capability » est simplement l’expression d’une Feature à un plus haut niveau. Quand une « Feature » est généralement développée au sein d’un seul ART, les « Capabilities » sont le plus souvent réalisées au sein de plusieurs ARTs. Dans les deux cas, on garde l’objectif de livraison au sein d’un « Product Increment » (PI).

Enfin, SAFe 4.0 introduit la notion de « Solution Intent », c’est-à-dire un répertoire dynamique de partage de connaissances sur la solution. Il vise à réconcilier les besoins de documentation des systèmes à haut niveau de criticité et de souplesse d’une approche Agile. Si le « Solution Intent » regroupe des spécifications, du design et du test, il le fait à la fois pour le comportement actuel et le comportement futur du système. C’est un répertoire qui préserve donc le 3e principe de SAFe « assume variability; preserve options ». Par ailleurs cette base documentaire est bien conçue dans une approche Lean visant à limiter les déchets. Elle n’est normée ni dans sa forme, ni dans son contenu qui doit représenter le juste niveau pour le système.

À noter également la prise en compte de la gestion des adhérences et des aspects contractuels avec des fournisseurs non agiles.

Toujours dans le registre de la flexibilité, SAFe V4.0 adresse désormais les développements de firmwares et de hardwares, la mise en place de plusieurs portfolios dans le cadre de très grandes entreprises et laisse le choix de la méthode de travail des équipes en ajoutant non seulement Kanban à Scrum et XP, mais aussi en permettant des approches hybrides (on pense à Scrumban). On note donc que Kanban ne se retrouve plus cantonné au seul pilotage au niveau portefeuille, mais devient une approche valide pour l’organisation opérationnelle des équipes.

SAFe se simplifie

Saviez-vous que SAFe est basé sur le Lean Thinking, le manifeste Agile, 4 « core values », 9 principes et s’appuie sur la démarche de conduite du changement de Kotter ? Sans avoir suivi la formation certifiante Leading SAFe (SA), bon courage pour reconstituer une vision d’ensemble à partir de la documentation en ligne dans sa version 3.

Avec la version 4, tout est désormais sur le poster. Un cadre « Foundation » voit ainsi son apparition présentant les fondamentaux de SAFe et son pattern de déploiement. Ses principes fondamentaux, dont la maîtrise est une des clés d’une implémentation réussie, sont désormais accessibles dès le poster.

À noter également une rationalisation des rôles, activités et artefacts avec l’apparition de la « Spanning Palette ». Dans la V3, ces items étaient répartis sur le poster avec, dans certains cas, des redondances ou des absences (par exemple, pas de vision au niveau du portfolio). La « Spanning Palette » est donc un ensemble d’items pouvant être appliqués ou non à tous les niveaux. Cette simplification accentue encore le côté flexible de cette nouvelle version.

Kanban se voit également généralisé. Dans la V3, seul le « Portfolio Backlog » utilisait Kanban pour suivre la maturation et l’avancement des Epics. Les Features et les Stories semblaient oubliées. Avec la V4, c’est rectifié. Kanban est utilisable à tous les niveaux de granularité (Epic, Capability, Feature et Story).

De plus, le vocabulaire du poster se voit rationalisé.

Les « Architectural Epic », « Architectural Feature » et « Architectural Story » disparaissent au profit des « Enabler ». Un « Enabler » est un item de backlog couvrant un sujet d’exploration (notion de Spike en Scrum), d’architecture ou d’infrastructure. Le terme « Enabler » est maintenant généralisé et utilisé dans chaque niveau de backlog (Portfolio, Value Stream, Program et Team).

Les « Portfolio Backlog », « Program Backlog » et « Team Backlog » ont été simplifiés par « Backlog ». Le poster affiche maintenant 4 backlogs à des niveaux de granularité différents (Portfolio, Value Stream, Program et Team).

Les « Program PI Objectives » et « Team PI Objectives » ont été simplifiés par « PI Objectives ». Le poster affiche maintenant 3 niveaux de « PI Objectives » (Value Stream, Program et Team).

Enfin, avec la généralisation de kanban, les rares termes «  Sprint » ont été remplacés par « Iteration ».

SAFe se raffine

Avec SAFe 3.0, certaines questions restaient en suspens. Comment identifier un flux de valeurs ? Comment gérer les activités de RUN ? Comment gérer des équipes en Cycle en V ? Comment gérer plusieurs portfolios ? Comment capitaliser les bonnes pratiques entre les équipes ? La documentation semblait parfois très théorique et un peu légère.

Avec une documentation mise à jour en profondeur, cette quatrième version respire le retour d’expérience. Beaucoup de concepts ont été complétés, d’autres ajoutés.

Tout d’abord, la gestion stratégique et la gouvernance dans le cadre de très grandes entreprises ont été précisées. La gestion budgétaire a été améliorée avec un financement au niveau des flux de valeur (au lieu des trains) et la prise en compte des activités de RUN (différence entre CapEx et OpEx) dans la gestion des backlogs.

Une aide à l’identification et à la synchronisation des flux de valeur a été ajoutée. Les communautés de pratiques, un concept très important pour la capitalisation entre Feature Teams, sont développées. La gestion des workflows de travail entre les niveaux est clarifiée. Enfin, les bonnes pratiques de développement prennent désormais en compte les développements de firmwares et de hardwares.

Pour terminer, le vocabulaire du poster a lui aussi été raffiné.

Le « Release Planning » est remplacé par « PI Planning ». Ce changement de vocabulaire est assez logique puisque cet évènement est la réunion de planification d’un PI à l’image du Sprint Planning en Scrum. De plus, le terme « release » pouvait porter à confusion étant donné que les PI et les releases peuvent être découplés.

Le slogan « Develop on Cadence, Release on Demand » devient « Develop on Cadence, Release Any Time ». Un changement de vocabulaire qui peut paraître anodin, mais beaucoup plus proche des principes Devops. Enfin, le terme « Code Quality » est remplacé par « Built in Quality » sans doute pour coller davantage aux principes XP.

À la question « SAFe 4.0 est-il vraiment plus scalable et plus modulaire ? » nous répondons donc un grand OUI.

Nous retenons de cette version une réelle volonté de s’adapter aux contextes en proposant des choix d’implémentation beaucoup plus marqués. La volonté d’adresser une plus grande échelle est également très nette. En simplifiant et raffinant davantage les concepts, nous sentons que SAFe a été soumis à rude épreuve et a bénéficié de vrais retours d’expérience. Le framework est plus pertinent et répond davantage aux problématiques rencontrées sur le terrain des transformations à grande échelle.

Le résultat est que SAFe 4.0 dégage une réelle image de maturité.

N’hésitez pas à plonger dans cette nouvelle version : http://www.scaledagileframework.com/