L'agilité à l'échelle de l'entreprise avec SAFe - par @Bertrand Boisvert

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

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

3. Agilité à l’échelle

4. Pourquoi l’agilité à l’échelle ?

5. 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

6. 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

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

8. SAFe : présentation

9. SAFe

10. 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

12. SAFe

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

14. Scrum

15. 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

16. 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

17. 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)

18. 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

19. 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

21. PI Planning

22. 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

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

24. 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

25. 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)

26. PI Planning - exemple d’agenda

27. Gestion des dépendances : Program board

28. PI Planning

29. Bilan

30. 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

31. 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

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

33. Framework en évolution

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