Description du Pi Planning pre requis deroulé sur 2 pistes

1. Meetup – Rendre Agile une Organisation
Présentation de SAFe
Meetup ividata.com #2 – Zoom sur le PI Planning
Levallois – 25/04/2018
Hébergé chez:

2.  Mentor, Coach Agile, Scrum Master ou RTE
 Auditeur Technique / Process
 Directeur de projet
 Professeur en Ecole d’Ingénieur
 Responsable de l’Ingénierie technique
 Développement, Architecture logicielle, Team Lead
Qui suis-je ?
2
Pierre MEDINA
Certif SAFe RTE
Certif SAFe SPC en
cours
SM certifié
Twitter @pmedina

3.  Twitter: @pmedina - 14k followers
 LinkedIn: linkedin.com/in/pierremedina (2k followers)
 Malt: malt.fr/profile/pierremedina
 Classements: (en avril 2018)
• CTO: http://ranking.influencer.world/fr/set/ctos (1er)
• Développeurs francophones les plus suivis: ranking.humancoders.com/rankings/developpeurs (22e/200)
• Top des CP et Coach Agile Malters les plus suivis:
https://www.malt.fr/ranking/twitter/projectmanagers_agilecoaches (2e)
• Classement français des influenceurs Social O'métre: http://www.publi-
online.com/aressy/socialedi/classement_people.php (30e/725)
 Score Klout (indicateur mesurant l’influence global sur les differents réseaux sociaux):
https://klout.com/#/user/pmedina (61-62) (supérieur à 95% des utilisateurs des reseaux
sociaux)
Présence sur les Réseaux Sociaux / Influenceur
Comment me contacter?
3

4.  Lors du meetup mars nous avons vu les éléments
suivants:
• Les 4 niveaux de SAFe
• La notion de train agile
• Les Rôles
• Les différents backlogs
• Le Cadencement
• La Qualité
• L’amélioration continue
• La palette des fondamentaux sur lesquels reposent SAFe
• La palette des outils
 Ce soir nous aborderons le déroulé d’un rituel important:
Le PI Planning.
4
Sujet présenté ce soir

5. Agilité à l’Échelle
5

6. Exemples de Frameworks d’Agilité à l’Echelle
Large Scale Scrum
DAD (Disciplined Agile Delivery)
Nexus
Scaling Agile at Spotify
6
SAFe (Scaled Agile Framework)

7. Parmi ces Framework,
SAFe tend progressivement à s'imposer
7
Courbe obtenue en compilant les chiffres des Etudes
VersionOne 2015 à 2018 : State Of Agile Survey
*
Source: Etude mondiale annuelle de VersionOne (State of Agile Survey)

8. SAFe s’impose progressivement
Source: Etude mondiale annuelle de VersionOne 2015 à 2018 (State of Agile Survey)
8
étude n° Année SAFe Less
Scrum of
Scrums
Internally méthod
exemple: Spotify
Lean
Management
Agile
Portfolio
Manageme
nt (APM)
DAD RAGE NEXUS
Enterprise
Scrum
9 2015 19% 3% 69% 25% 18% 9% 4% 1% 9%
10 2016 27% 6% 72% 23% 17% 9% 4% 1% 1% 9%
11 2017 28% 3% 27% 13% 4% 4% 1% 1% 1% 6%
12 2018 29% 5% 19% 10% 3% 3% 5% 0% 1% 3%

9. Présentation de SAFe
9

10. SAFe porte un ensemble de valeurs
et offre les moyens de les appliquer
10
AGILITÉ
délais courts, itérations, valeurs
humaines de l'agilité : confiance…
CADENCEMENT
un même rythme pour
l'ensemble des équipes
ALIGNEMENT
sur la stratégie métier
PRIORISATION
sur la valeur métier
DevOps
Mise en œuvre de
L'ARCHITECTURE
SYNCHRONISATION /
COORDINATION
XP
Clean code, intégration
continue, …

11. 11
11
Big Picture SAFe

12. 12
12
Le PI Planning

13. Rituels
13

14. Rituels
14

15. PI Planning
15

16. 16
Preparation avant PI Planning
En préparation du PI Planning les leaders
préparent des contenus/livrables avec le RTE.
• Vision et Roadmap Métier - Etat des lieux et
objectifs à venir
• vision du produit - Vision et top 10 des
fonctionnalités
• Vision architecturale - Vision pour
l'architecture, nouvelles Epic architecturales
(Enablers), Pratiques d’ingenierie, etc.
• Contexte de développement - Changements
aux pratiques standard, aux nouveaux outils
et techniques, etc.

17. 17
The PI Planning process
INPUT: VISION AND TOP 10 FEATURES
OUTPUT: TEAM AND PROGRAM PI OBJECTIVES AND PROGRAM BOARD
Top 10
Features
Vision Team A PI
Objectives
Team B PI
Objectives
Team C PI
Objectives
Team J PI
Objectives
Program
PI Objectives
...
Program board
Program
Backlog
PI Planning
Iteration
1.1
Iteration
1.1
Iteration
1.1
Iteration
1.1
Iteration 1.5
(HIP)
PI 2 >>>

18. PI Planning – 1er Jour
18

19. Day 1 agenda
8:00-
9:00
9:00-
10:30
1:00-
4:00
5:00-
6:00
10:30-
11:30
4:00-
5:00
11:30-
1:00
State of the business and upcoming objectives
Vision and prioritized features
 Architecture, common frameworks, etc.
 Agile tooling, engineering practices, etc.
Facilitator explains planning process
Teams present draft plans, risks, and
impediments
 Teams develop draft plans and identify
risks and impediments
 Architects and Product Managers circulate
Adjustments made based on challenges,
risks, and impediments
1 2
3 4

20. 20
Business context
Pour lancer le PI Planning, le Business Owner /
Manager Executif partage la vision business (Aspects
métiers, financiers, opportunités à saisir, etc…)
• Les principales priorités du portefeuille
sont communiquées
• Les forces, faiblesses, opportunités, et
menaces (SWOT) de l'organisation sont
analysées

21. 21
Vision Produit
L’equipe du Management Produit présente la vision et les features les
plus importantes.

22. 22
Architecture, Experience Utilisateur et pratiques de developpement
L'architecture, l'expérience utilisateur et les pratiques de développement
sont presentés et discutés avec les équipes!
• Un architecte système présente la vision de l'architecture, de nouvelles
architectures épiques et des cadres communs
• La gestion du développement peut fournir des mises à jour sur l'outillage
Agile et des améliorations dans les pratiques d'ingénierie
• Les professionnels de l'expérience utilisateur fournissent des conseils
sur les problèmes de convivialité

23. 23
Planning context: partage des objectifs des 2 jours de travail
Le RTE établit une compréhension commune du processus de
planification et des livrables pour le processus de planification.
Procédure pas à pas de:
• Processus de planification d'équipe
• Planification des critères d'acceptation
• Programme Board
Chaque équipe avait les mêmes livrables:
• Une feuille d'objectifs
• Une feuille par itération pour les US et TS
• Une fiche de risques pour les risques et les
irritants

24. Team Breakout #1: Livrables attendus
Iteration 1.1 Iteration 1.2 Iteration 1.3 Iteration 1.4 Iteration 1.5
PI OBJECTIVES RISKS
Velocity:
34
Load: 30
Velocity:
34
Load: 30
Velocity:
34
Load: 30
Velocity:
34
Load: 30
Velocity:
34
Load: 0
- ….
- ….
- ….
--Stretch
Objectives--
- ….
- ….
IP Iteration
X
Yellow
Purple
Red/
Pink
Green
Orange
= Risks and
dependencies
= Infrastructure/
Enablers
= User stories
= Maintenance
= Exploration
Enablers
Pour la vélocité, utilisez des
informations historiques ou 8 x?
(Nombre de développeurs +
testeurs).
Attention de prendre en compte
les vacances et féries.
Red/
Pink
= Addressed risks
and dependencies
Color coding gives visibility into investments
Velocity (Capacity): ____
Load: ____

25. Team breakout #1
Pendant le Team Breakout, chaque
equipe decoupe ses Stories qui
sont estimés et placés dans les
Sprints
Il doit y avoir beaucoup de t entre les
équipes, principalement sur la
synchronisation, la compréhension et
la minimisation des dépendances.

26. Program board — Features, dependances et Milestones
Iteration 1.1 Iteration 1.2 Iteration 1.3 Iteration 1.4
Iteration
1.5 (IP)
Milestones/
Events
Unicorns
Dolphins
Bears
Iguanas
Blue = Features
Red String = A dependency requiring Stories or other
dependencies to be completed before the
Feature can be completed
= Significant
dependency
Antelope
Tarantulas
Eagles
Needs UX
Help
Needs Sys
Arch Help
Orange = Milestone/
event
PI 2 >>>
Red/
Pink
A program Milestone or event is
happening in iteration 1.3 (e.g., a
trade show, market release, etc.)
A Feature placed in a team’s
swim lane with no strings means
that it can be completed
independently of other teams
This Feature cannot be delivered
until multiple teams complete their
dependencies

27. 27
PI Objectives
Objectives for PI 1 Business Value
› Structured location and
validation of locations
› Build and demonstrate a
proof of concept for context
images
› Implement negative triangulation by tags,
companies, and people
› Speed up indexing by 50%
› Index 1.2 B more web pages
› Extract and build URL abstracts
Stretch Objectives for PI 1
› Fuzzy search by full name
› Improve tag quality to 80% relevance
Les objectifs sont des résumés en terme métier de ce que
chaque équipe a l'intention de livrer dans le PI à venir.
Ils sont souvent mappés directement aux
fonctionnalités du backlog, mais pas toujours.
Par exemple:
• Agrégation d'un ensemble de
caractéristiques, énoncées en termes plus
concis
• Un jalon, tel qu'un salon
• Une fonctionnalité Enabler nécessaire pour
prendre en charge la mise en œuvre
• Un refactoring majeur

28. 28
Scrum of Scrums
Simple planning radiators
Iteration?
drives your Iteration
backlog?
Le point de contrôle horaire Scrum of Scrums permet de garder les
équipes sur la bonne voie et permet une identification précoce des
risques.
Le point de contrôle horaire Scrum of
Scrums permet :
• de garder les équipes sur la bonne voie
• et permet une identification précoce des
risques.

29. 29
Draft plan review
Agenda du Draft plan review :
1.Velocité (capacité) et charges
2.Draft Objectifs de PI
3.Analyse des risques et
irritants programme
4.Questions/Réponses
Les planifications issus des Team Breakout sont revus par toutes les
equipes.

30. 30
Revue du Management et resolution des problemes
À la fin du premier jour, le management se réunit pour apporter des
ajustements au périmetre et aux objectifs en fonction de la planification
de la journée des équipes
Questions fréquentes lors de la revue des managers:
• Qu'avons-nous appris/decouvert de nouveau?
• Où avons-nous besoin d'ajuster Vision? Périmetre?
Ressources?
• Où sont les goulots d'étranglement?
• Quelles Features doivent être dé scopés?
• Quelles décisions devons-nous prendre d'ici à demain
pour régler ces problèmes?

31. PI Planning –2e Jour
31

32. Day 2
8:00-
9:00
9:00-
11:00
11:00-
1:00
Planning adjustments made based on previous
day’s management meeting
Teams present final plans, risks, and impediments
 Teams develop final plans and refine risks
and impediments
 Business Owners circulate and assign
business value to team objectives
2:00-
2:15
1:00-
2:00
Remaining program-level risks are discussed and
ROAMed
Team and program confidence vote
After
commitment
2:15-
3:00
If necessary, planning continues until
commitment is achieved
 Retrospective
 Moving Forward
 Final Instructions
1 2
3 4
!
1 2
3 4

33. 33
Ajustement du planning
Sur la base de l’examen des retours des équipes de la veille et de la
réunion de résolution des problèmes, les ajustements sont proposés
et discutés.
Les changements possibles sont:
• Modification des priorités business
• Ajustement de la planification
• Changements du scope
• Mouvement de ressources d’une équipe
vers une autre
• Etc…

34. 34
Team breakout #2
En partant des nouvelles connaissances, arbitrages et après une
longue nuit de sommeil, les equipes Travaillent à stabiliser leur plan.
• Lors de ce deuxième TeamBreakout, les
Business Owners circulent et attribuent une
valeur business aux objectifs PI de faible (1) à
élevé (10)
• Les équipes finalisent le plan du prochain
Program Increment
• Les équipes consolident également les risques,
les irritants et les dépendances du programme
• « Stretch Objectives » permettent aux équipes
de se fixer des objectifs secondaires qui
peuvent être abordés si l’avancement le permet.

35. 35
Agenda de la revue du plan Final:
1.Changement de velocité
(Capacité) et charge
2.Final PI Objectives Finaux
pour le PI avec la
business value
3.Risques Programme et
irritants residuels
4.Questions/Reponses
Revue du plan final
L’equipe, le management IT et les business Owners
passent en revue le plan final et le challengent.

36. Acceptation du plan final par le client
• Les plans finaux sont revus par toutes les
équipes
• Les BO sont interrogés sur leur acceptation
du plan
• Si oui le plan est considéré comme validé
• Sinon l’equipe continue la planification après
l’examen du refus du BO

37. 37
Roaming des risques programme
Après que les plans aient été présentés et validés, les
risques et irritants programmes sont discutés et catégorisés.
Categorisation des risques:
RESOLVED : Le risque a été adressé. Il est
considéré comme resolu
Owned : Quelqu’un en a pris la responsabilité
Accepted : Risque connu et accepté, s’il
survient les engagements pourraient etre
compromis.
Mitigated : Risque connu et accepté, l’equipe
saaur reagir si ce risque survient

38. 38
Vote de confiance : Toutes les parties prenantes à l’ART y
prennent part
Une fois le plan validé, les dependances adressées, les risques
categorisés, un vote de confiance est fait par l’ensemble des acteurs
Vote à main levée et utilisant les doigts pour voter
• entre 1 et 5
• 1 : « je ne suis pas confiant »
• 5 : « Je suis très confiant »

39. 39
Retravailler le Plan si ncessaire
WHAT HAPPENS IF THERE IS LOW CONFIDENCE? REWORK!
Si des gens ne sont pas confiant:
• Finir le PI Planning par un vote inferieur à 3 n’est pas une
option.
• Ceux qui votent moins de 3 sont invités à exprimer leur
réserves.
• Et des actions ou décisions peuvent être prises en direct.
• Si nécessaire, les équipes peuvent repartir en
planification
Un vote sera refait après les discussions, actions, décisions
ou replanifications. On itèrera jusqu’à trouver le bon
compromis qui convient à tous.

40. 40
Et la suite
• Quand Faire une retrospective du PI
Planning? ( dans le but de s’ameliorer
continuellement)
• Quand lancer les actions prises lors du PI
Planning?
• Comment les traquer? (KPI)
• Quelles indicateurs utilisés par les Scrum
Masters pour traquer l’activité de l’ART?
• Etc…
40

41. Questions
41
???