SAFe from the inside

SAFE FROM THE INSIDE

Agile tour rennes 2016

4agile me

CouthaIer Farfrawww.agile4me.com

http://www.agile4me.com

www.agile4me.com4agile me

4agile me

www.agile4me.com

Couthaier farfra coach/formateur agile

[email protected]

+33 6 71 02 48 56 / @farfrac

web : www.agile4me.com

blog : www.agilemouse.com

parcours

1994 DEveloppeur

1998 chef de projet

2009 Scrum master /

coach agile 2007

directeur de projet

• SAFe Agilist (2014)

• Management 3.0 (2014)

• Kanban (2013)

• Scrum Master (2012)

La franCAISE DES JEUX

EurOpcar

EURONEXT

J C D E A U X

GENERALI

BAnque DE FRANCE

A X A

G R O U P

S O L U T I O N S

CredIT

agric

ole

SA BI-SAM

L C L

DECATHLON

AXA FRANCE

2015

4agile me

REFERENCESCOMMUNAUTE

Initiation au Kanban - Codeurs en Seine 2014 (Youtube)

Kanban A grandE Echelle - Open XKE XEBIA 2013 (Youtube)

SociEte GENERALE

2016

(aucune cer)fica)on ne remplace l’expérience terrain)

french safe experience

M A I F

publications

REX KANBAN sur 6 mois - Culture Kanban 2016 (InfoQ)

http://www.agilemouse.com


ce rex n’est pas un SAFE bashing n’y une publicitE commerciale pour vendre un framework et/ou du coaching.

CE rex est le sentiment et la vision du rEdacteur sur la mise en oeuvre de SAFE, dans une organisation complexe. Il ne faut en aucun cas en faire un cas gEnEral sur LA PERTINENCE OU NON DE CE FRAMEWORK.


2011 Field experience at enterprise scale

Now…

Agile development | Lean product development | Systems thinking

1.0 2.0 3.0

LSE 4.0

SAFE, une amelioration continue depuis 2011

site safe http://www.scaledagileframework.com/

http://www.scaledagileframework.com/


Il Etait une fois SAFE 2.5 (2014)


Secteur d’activité : Communication extérieure

Vision & Enjeux : Améliorer la gestion des nouveaux produits de communication digitale ;Augmenter la flexibilité et la réactivité des équipes, face à un environnement de plus en plus concurrentiel, afin de mieux répondre aux besoins spécifiques des clients ;Tenir les engagements de Time to Market ;Réduire l’obsolescence technique des applications ;

Team SAFe :Team level : 3 à 6 Team Agile (7 à 8 membres / team) ;Program level : 13 membres ;Portfolio Level : 5 membres.

Choix d’organisation :Ré-internaliser l’ensemble des équipes de développement ;Utiliser le framework SAFe pour atteindre la vision et les enjeux fixés.

Lancement d’une transformation SAFE, en

mode big bang, sans attendre les

enseignements sur les projets pilotes

+60 personnes

le contexte programme (2014)


#1 : la formation


2 jours de formation SAFE avec des participants n’ayant aucune expERIENCE sur les valeurs et les

pratiques agile (Scrum, Kanban, ...)

Un seul cas pratique, le Release Planning (PI Planning)

scrum presentE comme la seule pratique agile a mettre en oeuvre sur la Team level !!! «"Non, on

ne fait pas de kanban, dans SAFE c’est du Scrum"»!!!

DES personnes certifiEES SAFE Agilist sans expErience agile

#1 : la formation


Les Inputs :La roadmap du programme, sur les 3 prochains PI Planning ;La vision du business ;Le top 10 des features, du Program Backlog, à réaliser dans le PI Planning.

#2 : Release planning


#2 : Release plannIng - pI team


#2 : Release planning - pI team


#2 : Release planning - program board


#2 : Release planning - program board


Team building sur 2 jours

L’émergence de communautés de pratiques PO, SM, Développeurs et de Feature Team ;

Le partage d’une compréhension commune de la visio, des objectifs de l’entreprise et du programme ;

L’implication des architectes et des testeurs ;

La visibilité des adhérences entre Team, permettant une meilleur collaboration entre elles.

Décrire les Stories en Release planning = Tension chez les PO ;

Estimation initiale en pseudo story point-j.h

Passage à SAFe en mode big bang, sans expérience/maturité agile des acteurs

Capacité d’autonomie des team dev inexistante (command & control)

Le Directeur de programme qui devient RTE sans changer mode de management command & control

#2 : Release planning - feedback


#3 : Team Level

du scrum, du scrum, du scrum


#3 : Team Level - HIP HIP HIP ...


ScrumBan

Scrum of Scrum

KPI Kanban et Lean (Cycle time, Lead time, Débit, …)

Team bulding

HIP

Vision non partagée

Le ScrumBan et Kanban restent à la porte

La vélocité transformé en j.h et aide à la pression sur les teams

Pas de culture des valeurs agile au niveau du management. Fonctionnement en mode Command & Control !!! ==> Tension entre les teams et le management

RTE absent des Scrum de Scrum et éloigné des Teams dév

#3 : Team Level - feedback


#4 : PRogram Level

Fonctionnement du Product Management en mode Command & Control ;

Aucune vision globale du produit - Pas de Story Mapping ;

La description des besoins s’arrête au niveau de la Feature

Culture agile inexistante et non prioritaire

Pas de réelle priorisation par le Cost Of Delay (difficile à mesurer réellement), mais plutôt par les urgences « politiques »

L’ensemble des rôles propre à une grosse organisation ou à un programme est réunit ;

La notion d’architecture est enfin prise en compte dans la réalisation d’un projet/programme Agile ;

Le rôle de Product Management est mis en avant et peut permettre (en théorie) d’aller vers une culture produit de l’organisation ;


#5 : portfolio Level

Le Portfolio Level permet, en théorie, d ’embarquer l ’ensemble de l’organisation du programme vers les pratiques agile.

Pas de changement du top management et de la gouvernance ;

Le « politique » a pris la main sur la valeur business

Pas de sponsoring du DSI


Un vivier d’options, adapté au contexte de l’organisation et du programme ;

Une montée en maturité agile, à l’échelle de l’organisation ;

la création d’une team building, à tous les niveaux de l’organisation ;

Une amélioration de la qualité logicielle et un passage vers le DevOps ;

Une montée en autonomie forte des acteurs ;

L’implémentation d’une culture agile & produit

Difficile d’implementer SAFe sans partager les agiles ;

Framework lourd / contexte et difficile à mettre en oeuvre ;

Pas d’émergence d’un leadership fort, à tous les niveaux ;

Un management qui ne change pas => command & control et des changements de stratégies sans concertation ;

Une qualité logicielle jamais au rendez-vous ;

Une démotivation des acteurs ;

Une documentation (trop) riche et étouffante, appliquée sans pragmatisme ;

L’absence d’un sponsor fort ;

Des consultant SAFe SPC peu présent sur le terrain

mon feedback sur l’implementation de safe 2.5

le resultatce que safe aurait put

nous apporter


quels changements avec SAFE 4.0 ?


des questions ?

coach/formateur agile

[email protected]

+33 6 71 02 48 56 / @farfrac

web : www.agile4me.com

blog : www.agilemouse.com

http://www.agilemouse.com

Presentations & Public Speaking

SAFe from the inside