Un résumé rapide des ateliers et présentations auxquels j'ai pu prendre part et un feedback pour partager le contenu de certains ateliers que j'ai trouvé intéressant mais qui pourraient ne pas être retranscrit en vidéo

1. FEEDBACK
09/04/2015

2. SCRUMday 2015 – mon retour d’expérience
2
19/05/2015
 Jour 1
o KEYNOTE « Simple, but not simplistic »
o Le plus petit pas, comment accélérer votre transformation agile en
passant de 1000 à 1
o Mangement et agilité
o DevOps Mindstorm
o Rallye Test Game
 Jour 2
o KEYNOTE « The scaling Dilemma »
o OPEN SPACE
o Remonter des indicateurs / donner de la visibilité à mon
manager
o Transformation agile d’une entreprise en une semaine
o Piloter une équipe agile transverse

3. SCRUMday 2015 – mon retour d’expérience
3
19/05/2015

4. FEEDBACK – SCRUMDAY 2015
Orateur : Dave SNOWDEN, est un universitaire Gallois, chercheur et
consultant dont les travaux s’articulent autour de la théorie de la
complexité, des modèles cognitifs permettant d’organiser et construire un
savoir à partir d’expériences réalisées et vécues.
SCRUMday 2015 – mon retour d’expérience
4
19/05/2015
Travaux : Ses travaux autour du SENSEMAKING, procédé par lequel, nous donnons
du sens à l’expérience, est implémenté à travers le modèle Cynefin pour lequel, il a
effectué un exposé lors de cette Keynote d’ouverture du SCRUMDAY 2015
Propos : Le modèle Cynefin est la seule approche qui valide pour découvrir nos
environnements et orienter les choix car il repose sur une base scientifique. Nos
choix sont « logiques », « rationnels » et « intentionnés »; De plus, ce modèle décrit
les différents types d’environnements « simple », « complexe », « compliqué »,
« chaotique », « désordonné ». Suivant le type d’environnements, il y a une
corrélation entre causes et effets plus ou moins forte et qui seront ou non
reproductibles pour amener soit une prise de conscience, une réorientation des
objectifs fixés, une évolution vers un type d’environnement (plus ou moins
complexe) en fonction de « nouveaux objectifs » à atteindre.
Feedback : Il n'y a pas de modèle parfait applicable à tout type
d'environnement et l'Agilité à grande échelle n'est pas possible parce que cela
nécessite une approche globale quand des systèmes ayant fait leur preuve existent.
Il est donc relativement « simple » de naviguer d’un modèle à l’autre pour s’adapter,
amener du changement ou répondre à des demandes ou besoins particuliers, mais
cela n’est pas « simpliste » dans le sens où ces choix restent quand même orientés
et régis par l’environnement dans lequel nous sommes et donc soumis à ses
contraintes propres.

5. FEEDBACK – SCRUMDAY 2015
Contexte : Agiliser une grande organisation reste un chantier colossal
avec une conduite du changement à mener.
SCRUMday 2015 – mon retour d’expérience
5
19/05/2015
Problématique : Trouver la meilleure "vélocité" pour impulser ce
changement reste la clé de la réussite, parce que trop rapide donnera un
sentiment de frustration ou de passage en force, et trop lentement ne donnera
pas la visibilité nécessaire à la "survie" du projet.
Réponses : Définir les objectifs à atteindre et les délais pour y arriver. Eviter
d'appliquer sans concertation et sans associer les différents acteurs toute
méthodologie aussi bonne et populaire soit-elle. Il faut découper en étapes
l'ensemble du processus, fonctionner par itération et à chacune des étapes, il faut
récolter le feedback, mesurer l'impact du changement et adapter la méthode.
Feedback : Idéal pour embrayer une transformation agile de manière et
méthodique et itérative. En partant du principe de la dichotomie, on peut
observer le résultat escompté, évaluer les efforts à produire, puis "réduire" de
moitié l'objectif à atteindre, dans un délai plus court et adapter les "nouveaux"
efforts. Le but de ceci est de dégrossir l'objectif (de manière dichotomique), de
minimiser les efforts associés, afin de rentrer dans un processus itératif plus
simple à mettre en œuvre. On arrive ainsi à transformer une organiser de 1000 à
fonctionner comme 1 seul individu
1 - Pour parcourir la distance totale, il faut d’abord en parcourir
la moitié
2 – Pour parcourir la moitié de la distance, il faut en parcourir le quart
3 – Pour parcourir le quart de la distance, il faut en parcourir le huitièm
4 - …
La distance représente l’agilisation de l’organisation et le
Découpage en demi, quart, huitième,… correspond aux étapes

6. FEEDBACK – SCRUMDAY 2015
Contexte : Une entreprise dans le secteur de l’évènementiel qui
dispose d’une plateforme de communication grand public et qui se
rémunère sur les publicités que passent les annonceurs sur sa
plateforme en retour de la visibilité qu’elle leur offre, fait le choix de
"supprimer" la couche "manager" sur la vie / gestion de son équipe
technique
SCRUMday 2015 – mon retour d’expérience
6
19/05/2015
Problématique: Le produit / la plateforme est développée et
maintenue en interne par une équipe de développement pluridisciplinaire.
Elle a en charge les nouveaux développements, la maintenance, le support,
la R&D, un rôle consultatif sur le recrutement de nouvelles ressources de
développements,… Des réussites ont été obtenues avec la mise en place de
l’agilité, mais ils ont rapidement été confronté à la baisse de la productivité,
baisse de la motivation de l’équipe,…
Réponses : Provoquer une remise en question de l’équipe, identifier les
causes de la baisse de motivation (personnelles, professionnelles,…),
identifier les points de blocage qui peuvent inhiber l’action de l’équipe,
remettre l’équipe au centre de la problématique produit, Investir plus sur
l’équipe
Feedback: Retour d’expérience intéressant d’une équipe agile sur le
moyen terme. Bonne remise en cause de certaines pratiques managériales,
mise en place d’outils de management répondant aux problématiques de
l’équipe. La mise en œuvre de l’agilité reste vrai au niveau équipe de
développement avec une proximité avec le directeur technique sur site
mais l’équipe dirigeante reste « présente », sur un site distant
1 - Regarde maman, j’y arrive tout
seul!
2 - Oui c’est bien Lucas, mais
attention, il y a une bosse
devant toi…
Reste concentré sur la route
3 - Bien mon garçon!!
Ecoute ta mère: Elle donne de
bons conseils.
Le management dans l’agilité est assimilable à des parents qui
s’assurent que leur progéniture est suffisamment encadrée pour
faire du vélo sans grand danger.
Une plus grand liberté est accordée,…dans les limites du cadre
Défini entre management et collaborateurs.

7. FEEDBACK – SCRUMDAY 2015
Contexte : Atelier de présentation / découverte de la problématique DevOps. Sur
tous les projets informatiques, il y a d’une part les développeurs responsables de la mise
en œuvre du besoin client et les opérationnels sur lesquels reposent l’exploitation et la
mise en production de l’application développée. Il n’est pas rare que ces 2 parties ne
soient pas alignées le jour J parce qu’elles vont avoir des préoccupations différentes lors
du déroulement du projet.
Développeme
nt
Qualité
logicielle
DevOps
Opérations
SCRUMday 2015 – mon retour d’expérience
7
19/05/2015
Problématique: Sensibiliser sur ce qu’est le DevOps. Mettre en œuvre un
cas pratique pour faire apparaitre les risques d’un cloisonnement entre
développeurs et opérationnels, identifier les clés de la réussite d’un projet bien
mené.
Réponses : Communiquer en amont sur les contours et les grandes options
du développement mis en place, Créer une communauté DevOps au sein des
projets, Avoir une équipe pluridisciplinaire intégrant à la fois des développeurs et
des opérationnels partageant les mêmes problématiques liées à la vie du projet au
quotidien
Feedback: Atelier ludique sur la construction d’un robot avec des légots par
les opérationnels et développement du logiciel permettant de piloter le robot par
les développeurs. Rapide prise de conscience sur la nécessité d’un échange avec
Devs et Ops pour déterminer comment par exemple le robot prend l’information
sur son environnement lors d'un déplacement: Capteur infrarouge? Distance
parcourue?...
Le DevOps revient à tirer le meilleur parti de la triptyque
« Développement », « Qualité logicielle » et « Opérations »
(comprendre exploitation) pour répondre au mieux à la
problématique projet, donc assurer une satisfaction client
mais sans négliger les contraintes équipes
(développement, qualité, opérationnel)

8. FEEDBACK – SCRUMDAY 2015
Contexte : L’agile à l’échelle d’une équipe qui produit un livrable tester
unitairement et en intégration est courant. En général, à la sortie d’un sprint ou
d’une version, on retombe sur des principes classiques du cycle en V : des
semaines de qualification et de recette. Plus tard arrive cette phase et plus tard,
les anomalies sont remontées alors que l’on se rapproche de la date de mise en
production.
Sprint
Démonstration
RTG
Anomalies liées au
RTG / retours
démos
Analyses /
Corrections
SCRUMday 2015 – mon retour d’expérience
8
19/05/2015
Problématique: Comment paralléliser les tests de qualification et de
recette avec les sprints de développements (dans le cas de SCRUM) ou à la
livraison d’une fonctionnalité si nous somme sur du flux continu (avec du
Lean / KANBAN)?
Réponses : RTG permet d’identifier au plus tôt les tests à réaliser,
d’élargir la base de testeurs (tous les types d’utilisateurs possibles du
produit), déterminer le périmètre à tester (livret de tests). La phase de test
prend l’allure d’un rallye à travers lequel, toute l’équipe de tests
(développeurs, PO, client, contributeurs,…) va réaliser tous les cas de tests
possibles. La présence des développeurs permet d’avoir un regard sur
l’expérience utilisateur, mais également de donner des indications si des
difficultés sont rencontrées.
Feedback: Un atelier en binôme intégré dans une équipe de 12
personnes avec un rôle précis pour chaque binôme. L’ensemble forme un
système devant répondre à une problématique précise : 0 anomalies
bloquantes. RTG est pour moi un moyen immédiat de répondre à une
problématique projet des cas de tests non couverts par les longues
semaines de qualification et de recette
Le Rallye Test Game permet de paralléliser les tests
(anciennement de qualification et de recette) avec les sprints
réalisés. L’objectif étant de remonter très vite tout
dysfonctionnement pour anticiper sa correction.
Avec une population la plus représentative possible des
utilisateurs, tous les cas de tests existant sont plus
susceptibles d’être couverts

9. SCRUMday 2015 – mon retour d’expérience
9
19/05/2015

10. FEEDBACK – SCRUMDAY 2015
Orateur : Mary (avec TOM) POPENDIECK sont deux Agilistes ayant amené le
Lean vers le monde de l’IT. Après une carrière dans l’IT (développeur, manager
puis directeur produit), M. POPENDIECK s’est consacré à ses travaux qui
s’articulent autour de l’Agilité pour les entreprises dans le domaine de l’IT, inspiré
par le Lean et traitant de la problématique de la scalabilité de l’Agile.
SCRUMday 2015 – mon retour d’expérience
10
19/05/2015
Travaux : Appliquer / décliner le Lean (né en 1972 chez TOYOTA après 25
ans de mise au point), au monde de l'IT. Le principe fondateur de Lean est de
livrer des produits de qualité en juste-a-temps et avec zéro gaspillage. La
déclinaison est le « Lean Development Software » pour lequel elle a écrit un
livre en 2003.
Propos : Si l’Agile est bien pour les projets, l’Agile à l’échelle est forcément
bien. Les entreprises sont organisées en silo et savent résoudre des
problèmes propre à chaque silo. Par contre, si un problème est transverse,
cela devient plus complexe à gérer. Le parallèle donc entre les Feature Team
et les Component Team et leur capacité à résoudre différentes
problématiques associées à une fonctionnalité (Feature) ou un composant
(component) est donc établi. Faire de l’Agile à l’échelle reste lié à la qualité /
composition des équipes, de l’entreprise, de ses objectifs, et des moyens
donnés pour les atteindre.
Feedback Pour être plus complet, M. POPENDIECK propose de
s’inspirer du modèle militaire pour la composition des équipes projet. Une
compagnie est composée de pelotons, eux mêmes composées
d’équipes. Chaque sous ensemble a des objectifs et un rôle bien défini.
L’ensemble reste cohérent et fonctionnel par rapport à la mission confiée à la
compagnie. Apporter l’agilité à l’échelle dans une entreprise se fait au final :
 En comprenant l’effet souhaité par l’action de l’entreprise
 En mesurant (en continue) quand est ce que cela peut être atteint
 En apportant des orientations agiles progressivement

11. FEEDBACK – SCRUMDAY 2015
Définition : Méthode pour structurer des conversations et conférences; Fédérer des groupes de personnes (pouvant aller jusqu’à plus de
2000) à échanger sur des sujets importants / complexes,…
Objectif : Traiter un maximum de sujets en un temps record
Règles : Si à un moment donné vous vous rendez compte que vous n’êtes ni entrain d’apprendre, ni de transmettre une idée, cela veut
dire que le moment est venu de partir à la recherche d’un autre sujet
4 principes
 Les personnes qui se présentent sont les bonnes
 Ce qui arrive est la seule chose qui pouvait arriver
 Ça commence quand ça commence
 quand c’est fini c’est fini.
Feedback
 J’ai participé à 2 séances
 Projet agile : Fournir des indicateurs / donner de la visibilité à mon manager
 Transformation Agile en une semaine
 J'ai proposé une thématique sur "Comment gérer l'activité d'une équipe qui doit alimenter les autres dans un SCRUM à
grande échelle ?"
SCRUMday 2015 – mon retour d’expérience
11
19/05/2015

12. FEEDBACK – SCRUMDAY 2015
» Problématique : Sujet proposé par un participant
présentant un contexte projet où une migration technique d’une
brique de recherche doit être faite. Il y a une dimension
« découverte », « montée en compétence » de l’équipe qui fait
que l’engagement sur le délai et le périmètre est susceptible de
bouger. Comment gérer cela en mode agile et remonter des
indicateurs au plus tôt
» Assistance : Divers autres participants ayant rencontrés ce
type de problématique ou disposant d’un feedback utile sur le
sujet
» Feedback : Il est nécessaire dès le début d’avoir une équipe la
plus en accord possible avec la dimension technologique du
projet. Fonctionnant en Kanban avec un flux continu de
fonctionnalités / Features entrant dans le pipe et ne pouvant être
livré que quand elles ont passé le test final, il faut:
˃ Une période « probatoire » pendant laquelle l’équipe va
pouvoir s’étalonner par rapport à échantillon (lot)
représentatif du projet global
SCRUMday 2015 – mon retour d’expérience
12
19/05/2015
o Mesure la vélocité de l’équipe / production de l’équipe sur une période
o Remonter les indicateurs qui sont la référence sur laquelle on pourra comparer avec les futures itérations
Par « itération », comprendre uniquement le cycle de production de reporting au management. Vu qu’avec du Kanban, la production de l’équipe est en
continue, il reste possible sur demande ou à rythme régulier de produire les indicateurs sur l’avancement, la qualité, la vie de l’équipe,…
Cette dernière tache sera celle du SCRUM Master avec le burndown (gestion du RAF), le burnup (charge produite Vs charge globale et date d’atterissage
des fonctionnalités), l’avancement, l’actualité et la vie de l’équipe,…

13. FEEDBACK – SCRUMDAY 2015
» Problématique: Dans une entreprise dépourvue de toute pratique agile, comment apporter un changement agile et en voir le résultat au
bout d’une semaine
» Assistance: Gros score de participation parce que le coté feedback rapide que proposait le sujet était très (trop) captivant
» Feedback: Agir sur un changement aussi radical dans un délai limité (1 semaine) ne peut se faire qu’en imposant un ensemble de pratiques
empruntées à l’agilité. Sur les collaborateurs en place, on laisse un choix
˃ S’adapter et se mettre en accord avec les nouveaux objectifs
˃ Quitter le navire
Se posera très rapidement les problématiques RH / contrats / fiches de postes / rôles / Management / évaluation des collaborateurs…
On peut légitimement se dire que la dernière étape de l’agilité serait finalement de produire des contrats / fiches de poste / évaluation /
rôle / management agiles, c’est-à-dire qui pourrait s'adapter au rythme des changements agiles, mais cela n’est viable que pour
certains aspects cités (rôle, management, évaluation entre autres). Cependant, le coté contractuel et juridique posera un problème
dans tous les cas.
Finalement, on retiendra de cet échange que:
˃ Quand on impose un changement, les conséquences négatives reviennent très vite et sont néfastes au changement
initialement voulu. Il y a même une régression par rapport à l'état initial
˃ L’agilité et la transition vers l’agilité doit s’accompagner de la prise en compte des problématiques des équipes en place qui le
pratiqueront
˃ Il n’y a pas UNE AGILITE mais 50 NUANCES*
* Il y a eu une présentation dont le thème était « 50 nuances d’agilité ». Vidéo disponible bientôt sur infoq.com
SCRUMday 2015 – mon retour d’expérience
13
19/05/2015

14. FEEDBACK – SCRUMDAY 2015
» Problématique: Dans un écosystème où une équipe gère
l’éditorial des sites, elle peut être amené suivant les cas à:
˃ Produire un site uniquement éditorial (en standalone)
˃ Produire un site en collaboration avec une équipe
responsable d’une couche service (application métier)
˃ Mettre à disposition de toute application métier (de
services) des modèles / fragments de pages pour gérer
l’éditorial en provenance d’un CMS
» Assistance: Différents participants ayant cette problématique
d’agilité à l’échelle avec une équipe transverse qui peut selon les
cas peut avoir un en effet entonnoir sur toute la production d’une
version, étaient présents
SCRUMday 2015 – mon retour d’expérience
14
19/05/2015
 Feedback
o Proposer une organisation en Component team Vs Feature team avec un Product Backlog commun et une instance de priorisation
unique.
• Un seul flux de production,
• Un Product Backlog plus volumineux à gérer avec de grandes problématiques d’ordonnancement
o Faire deux (ou plusieurs) équipes pluridisciplinaires permettant de traiter l’exhaustivité des demandes sans dépendances externes
• Autant de Product Backlog et d’instances de priorisation qu’il y a d’équipes
• Créer des communautés pour fédérer et organiser les bonnes pratiques par domaine (Edito community, Gfx community,
Architect community, Ops community,…)
Dans tous les cas, les conclusions apportées par cet échange rejoignent les problématiques traitées lors des KEYNOTE d’ouverture par Dave
SNOWDEN et de fermeture du SCRUM Day par Mary POPENDIECK

15. FEEDBACK – SCRUMDAY 2015
» SCRUMDAY 2015 les 2 et 3 AVRIL à PARIS (DISNEYLAND)
» DAVE SNOWDEN
˃ Framework Cynefin : http://cognitive-edge.com
˃ http://en.wikipedia.org/wiki/Dave_Snowden
» MARY POPENDIECK :
˃ http://www.poppendieck.com/
˃ http://yowconference.com.au/slides/yow2014/Poppendieck-
ScalingDilemma.pdf
» INFOQ* : http://www.infoq.com
» Le blog de Xébia : http://blog.xebia.fr/
» Les différents orateurs** et participants de ces
conférences / ateliers
* Les vidéos de toutes les présentations (hors ateliers) seront disponibles prochainement sur le site infoq
* * Les noms des orateurs et entreprises concernées ont été volontairement tu. Je pourrai les fournir à la demande
SCRUMday 2015 – mon retour d’expérience
15
19/05/2015

16. MERCI DE VOTRE ATTENTION
https://www.linkedin.com/pub/sagnon-joel/19/b44/2a8
https://twitter.com/jsagnon
JOËL SIELE SAGNON
SCRUM Master / Agile
facilitateur
joel.sagnon@gmail.com
SCRUMday 2015 – mon retour d’expérience
16
19/05/2015