by Ahmed Abd AlRhman
by Александр Светличный
Passer à Scrum avec 45 personnes - ...
by Guillaume Magnier
Un retour d'expérience concret et vécu sur plusieurs années passées au sein d'une ample transformation agile d'une très grande entreprise.
INFILTRÉ DANS UNE AMPLE
 Venez découvrir de l’intérieur à quoi
ressemble une transformation agile de
 Il s’agit d’un retour d’expérience personnel et
partial, contrasté.
 Auditoire : n’importe qui qui est partie
prenante d’une transformation agile ou qui va
l’être, au delà des premiers pilotes. Une
expérience d’un projet agile est préférable.
Vision un peu Naïve
DEPLOYER SCRUM ET XP
AGILE : SCRUM ET XP NE SUFFISENT PAS
Dévt
FIXER L’AGILITÉ AU NIVEAU MÉTHODO ?
 Référentiel méthodologique : utilisé uniquement par les
ingénieurs qualité mais déterminant car qualité présente
 Templates documentaires : finalement très peu, valeur
ajoutée importante des exemples spécialisés (ex: BI)
 Wiki de la transformation : abandonné remplaçé par le
RSE pour l’exterieur, un SVN en interne
 Grilles : finalement trois pour des usages distincts
 Evaluation des risques à y aller en agile et actions de
 Revue par les ingénieurs qualité (produit et process)
 Evaluation de la maturité en agile
 Formations : ce qui fait foi finalement c’est les supports
de formation parce que eux sont à jour.
LA VARIETE DES PROJETS
CAS DE FIGURE ½ :
 Progiciels : étonnament, ca se fait bien si dans l’équipe on a une
bonne maîtrise du progiciel
 BI : assez adapté, pour peu qu’on adapte le template de User
Stories pour inclure d’autres éléments comme le mapping des
 Grand système : un echec cuisant. Difficultés techniques
(notamment gestion de version et branches), choc culturel
 Fixed Price : difficile, discussions sans fin. Pour l’instant Time &
Material, sécurisés par des partenariats très forts par entité
 Développents réalisés par les éditeurs : difficile de les faire ,
discussion sans fin. Mieux vaut passer par des intégrateurs.
Approche “Agile Black Box” : demander certaines propriétés de
l’agile, sans imposer un process.
CAS DE FIGURE 2/2 : PAS N’IMPORTE COMMENT
 Micro-équipes : mutualiser les projets, équipes multi projet. Plus
ScrumBan que Scrum.
 Programmes : galère s’il s’agit d’un SI et pas d’un produit.
Envisager des éléments de Agile@Scale Larman ou Leffingwell :
backlog global, synchro des releases, …
 Distribué : pas simple mais pas impossible. Se rencontrer en
personne au début. Visio, conf call. Formaliser plus (tant pis pour
le “un logiciel qui fonctionne plutôt qu’une documentation
exhaustive”)
 Internationaux : représenter dans la “core team” les différentes
 Multi-domaines : représenter dans la “core team” les différents
 Gros déploiements : se faire aider pour la conduite du
changement, quitte à ce qu’elle soit un peu conventionnelle.
“PRESCRIPTIF…
 … et contextualisable”
 Ce qu’il faut retenir :
 Les projets “agiles” doivent avoir un certain nombre
de caractéristiques “visibles” qui les rattachent avec
l’agilité telle qu’on l’imagine.
 Toute la stratégie projet doit être adéquate, tout
échec d’un projet agile risquant d’être imputé à
l’agilité. Lever tous les risques, liés ou non à l’agile.
 Si tout va bien, personne ne viendra poser de
questions embarassantes sur l’agilité ou non d’un
projet. S’il y a le feu, la lisibilité de l’agilité permet de
ANALOGIES TOXIQUES SUR LES PROJETS
UN SI N’EST PAS UN PRODUIT
 L’agilité repose sur la capacité à définir un
 Un SI est un SI, pas un produit.
 Les idées valables pour les produit (backlog au
niveau programme) ne s’appliquent pas telles
quelles à un SI :
 Les commanditaires sont multiples, nécessité
d’arbitrage entre les sources d’exigences
 S’il est parfois possible de relier un projet à des
réductions d’effectifs ou de stocks ou à une
meilleure performance, La notion de valeur pour un
SI n’est pas évidente : combien rapporte la fin d’une
obsolescence ? Une obligation règlementaire ?
JALONS : CECI N’EST PAS UN PRODUIT MANUFACTURÉ
Faisabilité Conception Devt
Un projet informatique (build) n’est pas un produit manufacturé (make)
: pas la même variabilité, pas la même stabilité des besoins, etc…
Appliquer le même jalonnement aux deux est un raccourci qui
engendre d’inutiles rigidités, notamment en terme de documents à
fournir et d’approche systématique mal adaptée aux différents cas de
Néanmoins passer un jalon d’engagement budget + délai + nombre de
points a des vertus. En effet c’est au moins à ce moment là que la
confrontation entre désirs et réalité se met en marche, et que l’effort
permanent de simplification débute s’il n’a pas débuté avant.
EVANGELISTE OU REPRESENTANT DE
TRANSFORMER : FORMER NE SUFFIT PAS
2010 Jeux dans les
2011 Scrum Lego
City Game x 80
2012 Green Belt
“Agile par défaut”
2012 Vidéo en
présence du PDG à
“Value Driven
Agile4Managers
DSI + n-1
ACCOMPAGNEMENT DES PROJETS : DOUBLE JEU
 Pré-assessment : faut-il y aller en agile (lire : vendre l’agile)
 Assessment : faut-il y aller en agile (lire : vendre l’agile au business et pousser
des éléments d’agile dans l’organisation du projet à venir)
 Formation : théorie agile et scrum (lire: jeux pour conduire le changement et
souder l’équipe)
 Workshop Impact Mapping : produire le backlog (lire : créer un consensus,
souder l’équipe élargie, annoncer au business qu’il n’aura pas tous les jouets
sur sa liste au pere noel, prioriser : I oui, II peut-être, III probablement pas)
 Coaching : aider sur la théorie agile, les pratiques, les usages dans l’entreprise
(lire: coacher l’équipe pour qu’elle ose prendre la parole, coacher le scrum
master pour qu’il résiste, coacher le métier pour qu’il découvre la gestion de
 Engagement après 3 sprints : vérifier l’application de la méthode (lire: faire
comprendre au scrum master / chef de projet qu’il faut annoncer au métier qu’il
n’aura pas tout, et qu’il ne sert à rien de spéculer sur une augmentation de la
vélocité, et que la seule solution est de revoir le périmètre).
EMBARQUER LA QUALITÉ
relaxation des
garantie qualité,
extrémisme des
ENCERCLER LE MIDDLE MANAGEMENT
Engagement for t
Fixer les objetifs
Notoriété de la méthode hors
APRÈS LE CHASM ?
Résistance passive et
Adhesion passive et molle
Contextes projet moins
adaptés à l’agile,
Agilité tordue et moins
On adresse ces populations
8 QUESTIONS, 2^8 POSSIBILITIES
 Prescriptive versus Contextualized
 Therapist versus Lean senseï
 Serious versus Playfull
 Proven versus Innovative
 Persuading versus Leading
 Intensive vs Lasting
 Planned vs Reactive
 Visible vs Invisible
COURBE D’AGILISATION D’UN PROJET
Premiers sprints
Projets longs :
Idéalement 15jh/projet,
en moyenne 8jh en 2013
Conditions de sortie du coaching :
3 à 6 sprints
maturité suffisante et en hausse
Passage de relai du contrôle à la qualité
TAUX D’AGILISATION DE L’ENTREPRISE
(1) Annoncé en copil
80% en deux ans, (3) Annoncé en
copil 55% en 2015
sans aucune base
(4) Quand on gratte
un peu, la cible
finale est 100%
(5) A mon avis, 40%
serait une meilleure
cible, à consolider et
(2) Une évaluation
réaliste donne 40%
RÉPARTITION DE L’ACTIVITÉ DES COACH
Activité idéale des coach Activité réelle des
coacher tous
KPI ENVISAGÉS
 Indicateurs de moyen :
 Taux d’agilisation
 Maturité moyenne des projets (cf grille)
 Variance du taux d’agilisation entre entités
 Effort de coaching / budget total
 Synchronisation au sein des programmes
 Indicateurs de résultat
 Temps de mise à disposition des solutions (intègre le %
de valeur des MVPs)
 Throughput : valeur par unité de temps
 Taux d’usage des solutions par les utilisateurs (par
ANALOGIES TOXIQUES SUR LA
UN COACH AGILE N’EST PAS UN COACH
 Un coach agile n’est pas (qu’) un coach.
 Formateur
 Mentor
 Consultant
 Change agent, politicien, showman
 Contrôleur de conformité à un idéal agile
 Parfois Project Officer
 Coach : 10% du temps grand maximum
UNE TRANSFORMATION AGILE N’EST PAS UN
 Les actions reposent beaucoup sur les
opportunités (notamment d’évènements à
hacker pour faire passer des messages)
 L’expérience montre un fossé énorme entre ce
qu’on avait imaginé au début de l’année, ou
même il y a six mois et ce que l’on a fait. Et
 Définit un critère d’acceptance est parfois ardu.
Quand-est ce qu’une grille est finie ? Quand elle
est validée ? Comment savoir qu’elle est
partagée, généralisée ? Par interview ?
UN PRODUCT OWNER D’UNE TRANSFORMATION
AGILE N’EST PAS UN PRODUCT OWNER
 Le “product owner”
 N’a pas d’expérience du sujet principal (l’agilité)
 Attend du conseil sur le sujet de la part des
 Ne peut pas prioriser
 Est incapable de définir une vision à long terme
(si ce n’est un impact sur des indicateurs
subjectifs)
 Est capable de réagir à une proposition, à une
idée, mais a besoin d’une base de proposition.
UN SCRUM MASTER D’UNE TRANSFORMATION
AGILE N’EST PAS UN SCRUM MASTER
 Le “scrum master”
 Est bien en peine d’avoir un périmètre pour des
sprints puisque tout change beaucoup, notamment
du à la charge consacrée par les coach aux projets
par rapport aux chantiers
 Essaie de discipliner un groupe d’experts agiles
habitués à monter sur scène et férus de débats
d’experts, ce qui est un réel challenge.
 Peut toutefois utiliser des bonnes pratiques de
facilitation d’équipes, ex: sociocratie ou process com
 Considérer qu’il s’agit d’une équipe Kanban serait
moins impropre.
UNE EQUIPE DE TRANSFORMATION AGILE N’EST
PAS UNE EQUIPE
 L’équipe
 Passent 80% de sont temps à
 travailler seuls
 sans interaction
 à coacher des projets qu’eux seuls connaissent
 et sur place.
ÊTRE COACH DANS UNE GRANDE TRANSFORMATION
 Environnement riche et
 Top Down qui dynamise
 Emulation des autres coach
 Temps plein
 Top Down subi
 Dilution de la responsabilité
 Besoin de sortir prendre de
 Pas de vision d’ensemble
 Spécialisation
ULTIME MANTRA