À quoi sert SAFe® 5.0 ?

Vous travaillez avec Scrum et/ou vous travaillez dans différentes équipes de projet ? Vous vous demandez comment vous pouvez mettre à l’échelle les avantages agiles ? Sebastian Friedsam vous présente l’actuelle version 5.0 du « Scaled Agile Framework » (SAFe®).

Auteur / Autrice Sebastian Friedsam
Date 30.06.2020
Temps de lecture 7 Minutes

La capacité de réaction aux changements du marché est de plus en plus cruciale pour la survie des entreprises. La fugacité et la complexité croissante des exigences sur les produits occupent le monde des entreprises depuis des dizaines d’années. Ces dernières années, on a de surcroît assisté à l’augmentation du besoin de concevoir non seulement des produits, mais également des modèles de business complets beaucoup plus adaptables. L’interconnexion judicieuse des divisions au sein d’organisations mais en dehors du développement pur de produits, poursuit par ailleurs ce but.

Cet élément a d’ailleurs d’ores et déjà été pris en compte dans l’actuelle version 5.0 du « Scaled Agile Framework » (SAFe®). Il constitue ainsi l’un des changements que l’on remarque le plus au premier abord dans la vision d’ensemble. Ces changements peuvent être observés très clairement dans les différentes configurations du Framework.

Operational Value Stream

Avec la nouvelle version, SAFe® 5.0 met un accent particulier sur la zone de tension que sont l’organisation des processus (donc comment les tâches sont effectuées dans l’organisation) et l’organisation structurelle (la hiérarchie). Il est possible de s’imaginer l’organisation des processus comme un réseau entre les personnes ayant différentes compétences et capacités et qui apportent toutes leur contribution à la chaîne de valorisation ou à la création de valeur (ce que SAFe® appelle « operational Value Stream »).

L’organisation des processus vise à séduire la clientèle finale avec des produits de grande valeur et de qualité supérieure. Concernant l’organisation structurelle, SAFe® 5.0 recommande plutôt de ne pas s’occuper des changements. Tout changement dans l’organisation structurelle peut mener à des incertitudes du côté des collaborateurs, ce qui peut avoir des conséquences négatives sur la cohésion de tous les intervenants. L’optimisation du réseau professionnel, donc la combinaison des compétences nécessaires, qui devrait s’aligner sur les changements du marché par la réorganisation de la création de valeur, doit être concentré sur les processus de travail afin de pouvoir proposer à la clientèle finale une plus-value plus importante en un minimum de temps.

Measure and Grow

Le développement du framework autour de la « Business Agility » a conduit à l’incorporation d’une compétence supplémentaire : l’ « Organizational Agility ». Celle-ci épaule les changements de stratégie et de l’alignement continu sur l’élimination des délais dans les processus opérationnels afin d’atteindre une orientation commerciale continue. À cette occasion, une « Organization Assessment » est introduite pour la première fois afin d’évaluer l’agilité de la globalité de l’organisation et d’en déduire des mesures précises.

Good Practice : Design Thinking

Un des éléments centraux qui découlent du thème de la « Business Agility » est l’orientation client et la pratique du « Design Thinking » accompagnant cet état d’esprit. Ce spectre très large, qui a fait son entrée dans le framework avec SAFe® 5.0, n’a cependant pas été intégré à toutes les méthodes et tous les outils, mais a été intégré dans le framework en tant que « good practice », comme de nombreux autres framework l’ont fait avant lui (OKRs, Lean Business Cases, DevOps, Loosey Couples Architecture, Business Model Canvas, Agile HR, etc.). Les outils de « Design Thinking » permettant de soutenir méthodiquement l’orientation client sont par conséquent décrits dans le framework SAFe® au travers de quelques exemples. Une approche exhaustive n’a donc pas été poursuivie, de manière à ce que s’informer d’avantage dans le domaine du « Design Thinking » soit tout à fait avantageux lorsqu’on désir se pencher sur les processus créatifs et les outils de design de produits de manière orientée client.

Ce qui n’a été que très peu représenté jusqu’à maintenant dans les versions précédentes est le portfolio et ses outils, qui trouvent de nos jours une application accrue, comme par exemple les « Objectives & Key Results » en tant qu’instrument cohérent d’alignement des objectifs, de la stratégie jusqu’aux objectifs d’équipes, comme il a été imaginé chez Intel par Andrew Grove puis perfectionné par John Doerr et Google. Mais cela ne représente qu’un des nombreux changements du « Lean Portfolio Management », à consulter ici.

Business-focused Teams

SAFe® 5.0 différencie les capacités de livraison et les différents types d’équipes qui sont utilisés dans le framework. Et ceci aussi bien concernant DevOps (dans SAFe®, l’approche CALMR) que concernant les équipes : SAFe® 5.0 clarifie que toutes les équipes ne sont pas forcément des équipes de développement. En effet, SAFe® a, dans le cadre de la « Business Agility », changé le nom de « Development Teams », encore utilisé dans Scrum pour les développeurs et les experts techniques d’une équipe, au profit d’une distinction entre les équipes spécialisées dans le business (« Business-focused Teams ») ou dans la technique (« Technology-focused Teams »). Outre les développeurs et les équipes de développement, les collaborateurs en marketing, ventes, RH, etc. peuvent faire partie d’une « Business-focused Team » dans le cadre des processus (ou « Agile Release Trains »). C’était évidemment également possible avant cette révision mais celle-ci permet maintenant d’éviter les confusions dues à la polysémie de la dénomination.

Afin de se faire une idée des changements apportés à la vision d’ensemble, il convient de s’y confronter directement. Cela signifie donc qu’il ne pas se montrer timide et oser naviguer entre les différents thèmes représentés dans la « Full Configuration ».

Découvrez notre formation Leading SAFe® 5.0 !


Auteur / Autrice

Sebastian Friedsam

Sebastian possède une expérience de plusieurs années dans l’introduction de modèles de mise à l’échelle dans le contexte de l’agilité ainsi que dans la mise en place d’ « Agile Release Trains » (processus) comme la MSP. Il a déjà coaché aussi bien des équipes, le management ainsi que la gestion de produits et peut, grâce à son activité passée de gestion de projets de crise en informatique, apporter son expertise dans des projets classiques ou hybrides ainsi qu’en combinaison avec des projets agiles.