L’agilité à l’échelle de
l’entreprise avec SAFe
Bertrand Boisvert
21 février 2019

Plan
● Pourquoi l’agilité à l’échelle ?
● Présentation de SAFe
● Bilan

Agilité à l’échelle

Pourquoi l’agilité à l’échelle ?

Historique des méthodes de développement logiciel
● 1956 - Waterfall (cascade)
● Années 70 - Cycle en Vprout
● 1995 - SCRUM
● 1999 - XP
● 2001 - Manifesto for Agile Software Development
● 2003 - Lean software development
● 2009 - Kanban
● 2011 - Safe

Pourquoi l’agilité à l’échelle ?
● Taille des équipes limités
● Equipe agile mais contexte non
● Complexité des projets
● Synchronisation des équipes
● Gestion des dépendances
● Transformation agile des entreprises
● Répondre plus rapidement aux marchés

Agilité à l’échelle : différentes solutions
● SAFe
● Scrum of scrum
● DAD
● LeSS

SAFe : présentation

SAFe

SAFe
● Dean Leffingwell 2011
● Scaled Agile, Inc
● LEAN, Agile, devops
● SAFe est à l’entreprise ce que Scrum est à l’équipe agile
● SAFe traite à l’échelle de l’entreprise :
○ l’architecture
○ l’intégration
○ les financements
○ les rôles
● Quatre niveaux
○ Equipe
○ Programme
○ Large solution
○ Portfolio

SAFe

Team level
● Scrum
● Sprints de 2 semaines
● Jusqu’à 10 personnes

Scrum

Program level
● ART = Agrile Release Train
● 5 à 10 équipes
● 50 à 125 personnes
● Release Management synchronisé
● Program Increment (= une itération de 5 sprints)
● Release on demand

Program Level - Les Rôles
● Product manager
● Release Train Engineer (RTE)
● System Architect
● System team
● Shared resources (UX, DBA, Sécurité …)
● Release Management team
● Séparation entre contenu et design
○ Contenu : équipes agiles
○ Design :system architect, system team, shared resources
Scrum SAFe
Product Owner Product Manager
Scrum Master RTE

Le Release Train Engineer
● ‘Servant leader’, facilitateur
● Onboarding d’équipes
● Escalade lorsque nécessaire
● ‘Chef’ des Scrum masters
● Organise le PI planning
● Gère des meetings de synchronisation pendant le train
● Représente le train (reporting etc)

Le Product Manager
● Identifie les exigences utilisateurs (Understand requirements)
● Responsable du program backlog (Document requirements)
● Vision, roadmap, delivery (Schedule)
● Priorise (le program backlog) (Prioritize)
● Valide l’incrément de programme (Validate)
● ‘Chef’ des product owners

La System Team
● Experte en intégration et outillage, infrastructure
● Développement d’environnements
● Continuous integration / delivery
● Dans l’agilité à l’échelle, les infrastructures sont très importantes
● Collaboration avec les tierces parties (fournisseurs, partenaires etc)
● Tests de perf end to end
● Démo de program increment
● Peut être partagée par plusieurs trains
● Peut être supprimée du train si infra est mature

PI Planning

Les cérémonies SAFe
Scrum SAFe
Planification de sprint PI planning
Sprint Innovation and Planning
Daily meeting Scrum of scrum
Revue & démo de sprint System demo
Rétrospective Inspect and Adapt events

Backlog
● Program Backlog
○ Responsabilité du product manager
○ Haut niveau de granularité
○ Features ~ Epic
● Team backlog

PI Planning
● Les différents backlog doivent être préparés avant le PI Planning
● Objectif collectif
○ Rassemblement en un même lieu
○ Alignement des équipes sur cet objectif
○ Gérer les dépendances
○ Fédérer les gens en les faisant se rencontrer (rôle social)
● Personnes présentes :
○ Business owners, Product management (PM + PO), Agile teams, System teams, architects,
Divers parties prenantes

PI Planning
Déroulement
● Product Management (PM + PO) présente vision métier, contexte, enjeux et
roadmap
● Animé par le RTE et les Scrum masters
● Prioriser les features (PM + PO)
● Définir les dépendances et collaborations entre équipes (Équipiers)

PI Planning - exemple d’agenda

Gestion des dépendances : Program board

PI Planning

Bilan

Quand utiliser SAFe ?
● Au moins 3 équipes
● Au moins 30 personnes
● Plus d’un an
● Gros projet
● Ou plusieurs projets partageant des composants, avec stratégie globale de
développement et release

Avantages
● Répond à un besoin d’agilité à l’échelle
● Synchronisation entre les équipes
● Solution complète
● Regroupe et organise la plupart des méthodes agiles
● Framework
● Beaucoup d’entreprises s’y mettent

Critiques
● Business
● Rien de nouveau
● Ne résout pas tout
● Pas agile ?

Framework en évolution

Bibliographie
● https://www.scaledagileframework.com/
● SAFe 4.5 Distilled,
Dean Leffingwell Richard Knaster, 2018