Prenons un train SAFe en marche

Le Program Increment (PI)

Un PI est une période regroupant toujours le même nombre de sprints. Tout comme dans Scrum, où le travail à effectuer sur un sprint est préparé grâce à un Sprint Planning, dans SAFe, on prépare le travail à faire sur un PI, en réalisant un PI Planning.

Autrement dit, chaque PI Planning est suivi d’un PI avec sa série de sprints, comme l’illustre la capture suivante :

Toutes les équipes visibles ci-dessus sont en pleine séance de PI Planning.

Le cœur de SAFe se trouve dans le PI, c’est ce dernier qui donne la cadence à l’ensemble des équipes de l’entreprise impliquées dans SAFe ! Le PI est comme un énorme sprint encapsulant d’autres sprints. Il débute par un PI Planning pendant lequel on planifie tout le travail qui devra être fait sur les 8 à 12 prochaines semaines. Le PI Planning dure 2 jours et le PI, lui, dure donc entre 8 à 12 semaines ! Une fois fini, le cycle recommence. On refait un PI Planning pour le PI suivant et ainsi de suite. On peut dire qu’un PI contient 4 ou 5 itérations de développement et 1 itération spéciale. Dans l’illustration précédente, on constate que le PI 4 va durer 10 semaines ; cette longue période du PI est découpée en itérations de 2 semaines chacune. Ces itérations sont tout simplement des sprints, et tout ce que nous avons vu sur les sprints Scrum reste valable dans les itérations SAFe. La dernière itération (Stretch ou IP pour Innovation and Planning) du PI est un sprint particulier, c’est l’itération spéciale. Durant cette dernière...

Les trains

Quel est ce train nommé Agile Release Train (ART) ? Il s’agit tout simplement de plusieurs équipes travaillant sur le même sous-système du SI. On trouve donc entre ces équipes une plus ou moins forte dépendance sur les fonctionnalités constituant le sous-système qui les unit. Chaque ART est composé de 5 à 12 équipes agiles entourées par différents rôles métier, ce qui peut donner entre 50 à 150 personnes dans un même train. Quand une entreprise décide de basculer sous SAFe, au début, on s’attarde sur la constitution de ses trains (ART) en se basant sur les processus fonctionnels de l’entreprise (les Value Streams) et, en général, on a une équipe par Value Stream. Mais selon la complexité du système, d’autres configurations sont possibles.

On va donc découper les fonctionnalités et services de l’entreprise en tentant de les regrouper de façon logique. Ce découpage aboutit à la constitution de nos ART. Chaque ART contient donc des personnes amenées à travailler ensemble sur telle ou telle Value Stream et chaque ART est en mesure de livrer, selon la cadence des PI, un incrément de la solution. En fait, dans son organisation, l’ART dispose de toutes les ressources nécessaires pour définir de nouvelles fonctionnalités, implémenter ces dernières (écrire le code informatique) et déployer les applications contenant ces fonctionnalités. On peut dire qu’un ART (ou train) est une grosse équipe ne contenant que des équipes agiles. Dans un train SAFe, tous les passagers sont donc agiles ! Cette organisation est bien plus efficace, puisqu’on n’est pas retardé par la lenteur administrative imposée par les frontières hiérarchiques des organisations classiques. Tout le monde est dans le même train, ce qui permet d’avancer vite et de concert dans un bel esprit !

Revenons sur le terme de Value Stream. Il s’agit d’un ensemble de personnes, de matériels, de processus et d’informations permettant de livrer de la valeur aux utilisateurs. Une fois livrée, cette valeur apporte une certaine prospérité financière...

Les niveaux SAFe

Dans SAFe, il existe quatre niveaux d’organisation. Ils permettent de configurer l’entreprise suivant sa taille et sa stratégie. Deux niveaux sont obligatoires, le Team Level et le Program Level. Ensuite, quand on commence à jongler avec plusieurs trains ou des trains pouvant porter d’autres trains, on passe au Large Solution Level. Le dernier niveau, le Portfolio Level, permet de basculer le financement des projets de l’entreprise dans les pratiques agiles. Ainsi, de la gestion des budgets jusqu’à la livraison des solutions, toute l’entreprise est soumise à la cadence des sprints SAFe !

Observons le schéma ci-dessous, qui résume les outils et rôles qu’on peut rencontrer dans les différents niveaux de SAFe. Il peut paraître complexe à première vue, mais bientôt il n’aura plus de secret pour nous. Tout d’abord, citons deux outils que l’on retrouve à tous les niveaux : un Backlog et un tableau Kanban. Ces derniers vont permettre d’avoir respectivement une visibilité sur les besoins et suivre l’avancement des travaux.

Au fur et à mesure que nous descendons dans les niveaux, le contenu des Backlogs s’affine pour finir sous forme d’User Stories dans les sprints Backlogs des équipes Dev se trouvant au niveau 1, c’est-à-dire au niveau Team.

Site : https://www.agilest.org/scaled-agile/safe-framework/

Revenons aux 12 équipes rencontrées lors du PI Planning. Comme évoqué précédemment, dans chacune d’elles se trouvent un PO, un Scrum Master, des développeurs et des testeurs. On peut aussi y trouver des leaders techniques et une personne responsable de la qualité (un QA). Testeurs, Lead Tech ou QA font partie de l’équipe Dev comme dans Scrum. Les architectes peuvent être référents sur tout le train, ils ne font donc pas partie d’une équipe précise. Bien sûr, cette organisation n’est pas figée, concevez votre gouvernance suivant votre contexte.

Le Team Level est donc constitué d’un PO, d’un Scrum Master et des développeurs ! Tout ce qu’on a vu concernant Scrum dans la première partie de cet ouvrage constitue la vie des équipes du Team Level. En revanche...