Agile Tour 2016 @ Lille

AGILE TOUR 2016
Compte-Rendu
Freddie DEWALEYNE
Jean-Baptiste VIGNERON

Sommaire
 L’Agile Tour en quelques mots…
 Keynote : #NoEstimates
 5 ans pour passer du Cycle en V aux Features Teams
 Où en est le contrat agile en 2016 ?
 Votre job sera remplacé par un indien ou un robot…
 Living Documentation
 Évitez la lassitude, créez vos propres formats de rétrospective
 Ce que la revue de code m’a apporté
 Mon processus de design en tant que PO sans UX designer
 J'anime une rétrospective productive
 L’agilité à 200 personnes

L’Agile Tour en quelques mots…
Présentation
 Conférences, rencontres, ateliers et échanges autour des méthodes agiles
 Evénement international, organisé dans plus de 80 villes dans le monde
 Site officiel: http://www.agiletour.org
 A Lille :
 Organisé par l’association Nord-Agile (http://www.nord-agile.org)
 13 et 14 octobre 2016 à Euratechnologies de 8h30 à 17h
 Plus de 350 participants, 25 conférenciers
 En France :
 15 villes dont Paris, Aix-Marseille, Lyon, Sophia Antipolis, Toulouse…

L’Agile Tour
Partenaires et sponsors lillois
Norsys
OCTO
OPEN
Proxiad
Zenika
AXA
Capgemini
Davidson Consulting
Décathlon
EFIDEV
Nordnet

KeyNote
Mouvement #NoEstimates
 Stoppez les estimations
 Utilisez les « story points » (1 / 3 / 5… ou S / M / L…) pour estimer les users stories
 Ne montez pas trop dans les « story points » (sinon découpez les stories)
 Utilisez les métriques pour estimer le coût réel d’une fiche
 Se baser sur les métriques projets pour connaître votre vélocité (cycle time, etc.)
 Plutôt que de ramener les story points à des jours hommes
 Une fiche estimée « M » ne prend pas le même temps de réalisation selon le projet
 Quand la story est trop grosse
 Ne pas hésiter à la découper
 Décider la partie à traiter aujourd’hui et celle qu’on fera demain
 La compréhension du besoin sera plus claire après la première livraison
 La boucle de feedback est réduite

5 ans pour passer du Cycle en V aux Features Teams
AXA
 DSI AXA France : 2000 personnes, divisés en départements
 2011 : Passage à Scrum
 2013 : Passage à Kanban
 2016 : Passage aux Features Teams
 Nouvelle organisation :
 Tribus (Département)
 Domaines (fonctionnel couvrant plusieurs produits)
 Squads (Product Owner + Scrum Master + développeurs + testeurs)
 Equipes multi-transverses
 Chapters: communauté de pratiques transverses aux domaines par rôle (PO / SM / Dev…)
 Guildes: communauté de pratiques transverses (Archi, Sécurité, Tests, Dev, UX/UI…)
 Equipes: co-localisées, compétentes et auto-organisées

5 ans pour passer du Cycle en V aux Features Teams
AXA
 Indicateurs de mesures :
 OnTime / OnScope / OnBudget
 Le turnover / La qualité (de code, de tests) / La maturité au niveau des features teams
 Réorganisations au niveau :
 Localisation
 Outils
 Organisation avec les prestataires
 Impacts au niveau communication, formations et recrutement (vu que les rôles
ont changé)

 Succès projet = satisfaction Client + satisfaction Equipe
 Les contrats de prestations en informatique aujourd’hui en France
 Forfait (eng: « Fixed-price contract »)
 3 CONTRAINTES : Périmètre (Scope) + Coût + Prix
 Les risques sont intégralement du côté FOURNISSEUR
 Régie (eng: « Time and Materials »)
 1 CONTRAINTE : Coût
 Les risques sont intégralement du côté CLIENT
http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile
Où en est le contrat agile en 2016 ?
Zenika

Zenika
 Idée
 Créer un contrat agile
 Equilibrer les risques entre le client et le fournisseur
 Engagement fort
 Pénalités partagées
 Clauses miroirs (qu’on peut lire dans les deux sens, en inversant les termes « client » et
« fournisseur »)
 Lister ce qui est prévu en cas de défaillance
 Moins de spécifications écrites (par rapport au forfait, vu qu’on est en mode agile)

Zenika
 Article 1 : Déclaration d’intention
 Coût fixé, Temps fixé
 Mais il est noté que le scope peut changer en cours de route, ou que le fournisseur
ait mal estimé la charge…
 Article 2 : Engagements pour…
 Le client de fournir un PO qui connaît l’agilité et respecte les pratiques
 Le fournisseur de fournir une « force de frappe » avec la manière de procéder
détaillée
 On détaille alors le fonctionnement de la méthodo utilisée (Scrum, backlog, sprints de 2
semaines, daily meetings, livraisons continues etc.)

Zenika
 Article 3 : Si le client veut modifier le scope
 On casse le sprint
 Les réalisations en cours ou déjà effectuées sont facturées en Régie
 Article 4 : Facturation
 Imposer une partie fixe et une partie variable dans le tarif journalier
 La partie variable est facturée selon l’estimation faite et les réalisations effectuées
 Si les réalisations sont terminées avant ou à temps, le client paie les 2 parties
 Si les réalisations prennent plus de temps, seule la partie fixe est facturée pour les jours
« en trop »

Votre job sera remplacé par un indien ou un robot
Ismael Hery
 La machine a dépassé l’homme dans certains domaines, et cela ne
devrait pas s’arrêter
 1997 : La machine « Deep Blue » d’IBM bat Kasparov aux échecs
 2014 : un ordinateur réussit le test de Turing
 Ce qui attend les hommes…
 Chômage
 La multiplication des « bullshit jobs »
 Des jobs aux responsabilités limitées
 Des jobs aux sens minimalistes

Ismael Hery
 Ce que les robots ne font pas encore :
 Créativité, Intuition
 Relationnel, Empathie, Communication
 Leadership
 Piloter d’autres machines ou des outils complexes
 Créer du « beau » et du « bon »
 Machine > Homme mais… (Machine + Homme) > Machine seule
 Certains jobs ne sont pas prêts d’être remplacés par une machine
 Les jobs où l’expérience client est meilleure avec un humain (ex: la cuisine)
 Les jobs avec un très haut niveau d’expertise technologique

Ismael Hery
 Le chemin pour ne pas atteindre le « bullshit job »
 Focalisez-vous sur ce que les robots ne savent pas (bien) faire
 Produisez au niveau des meilleurs
 Apprenez en permanence, restez débutant
 Qu’est-ce que j’ai appris ces six derniers mois ?
 Qu’est-ce que je peux apprendre dans les six prochains mois ?
 Produisez au niveau des meilleurs
 Valeur économique
 Qualité
 Apprenez à créer aussi vite que les meilleurs

Living Documentation
Arolla
 Documentation
 Passer/Transmettre du savoir
 Trier les informations accessibles et utiles pour des personnes techniques et non techniques
 Meilleurs moyens pour transmettre du savoir
 Conversations
 Mob-programming (programmation en groupe)
 Pair-programming
 La documentation est importante…
 Mais elle prend du temps et peut sembler contraignante à rédiger…
 Il ne faut pas mélanger la doc « toujours vraie » (def générales, doc d’installation…) de celle
pouvant changer dans le temps (doc technique, doc fonctionnelle…)

Living Documentation
Arolla
 Il est possible de générer de la doc à partir du code (Le code EST la documentation)
 En méthodo BDD, les scénarios peuvent être générés dans un format pour les utilisateurs et/ou le métier
 Pickles, outil de génération pour Specflow / Cucumber à partir des scénarios (HTML / DOC / PDF…)
 http://www.picklesdoc.com
 https://cucumber.io / http://www.specflow.org
 Génération de diagrammes d’architecture depuis le code
 Découpez votre architecture par domaine fonctionnel (« Domain Driven Design ») et non plus seulement par
couche technique (3 tiers, MVC…)
 Les namespaces / packages et les classes deviennent de la doc (et aussi avec l’aide des commentaires JavaDoc,
balises XML C#...)
 Utilisation des « bounded context » (http://martinfowler.com/bliki/BoundedContext.html)
 Le fonctionnel devient lisible et compréhensible à l’aider des diagrammes générés à
partir du code

Évitez la lassitude, créez vos propres formats de rétrospective
OCTO
 Une bonne retrospective est dynamique, fraîche et motivante
 Le site “retromat" (http://plans-for-retrospectives.com) est une mine d’or, il
permet de construire les retrospective en suivant 5 étapes :
 ouvrir la rétrospective, permettant de briser la glace et d’amorcer une
rétrospective dynamique
 récupérer les données, afin de récupérer les retours de chaque
 générer des idées, propositions d’amélioration
 décider des actions, engagement
 clore la rétrospective
 Terminer positivement afin d’avoir toute la motivation nécessaire pour le
prochain Sprint ! :-)

Évitez la lassitude, créez vos propres formats de rétrospective
OCTO
 Quelques feedbacks de de Scrum Master :
 utiliser des outils de chat tels que Slack irc-like permettant d’avoir des discussions dans des
chatrooms : autour de projets, technologies, problématiques particulières.
 utiliser des outils permettant de suivre les tâches d’un projet et de suivre les indicateurs
générés automatiquement (suite Atlassian : Jira, Confluence …, Pivotal Tracker, Trello, Redmine
…)
 utiliser des outils de collaboration en ligne afin de travailler avec des équipes partagées (pluri-
site, télétravail …) :
 Padlet (https://fr.padlet.com/features)
 Google Hangout
 https://www.retrium.com
 Deekit (tableau blanc collaboratif https://www.deekit.com
 organiser des événements en dehors du lieu de travail, particulièrement en début de projet :
escape games … afin de créer au plus tôt un esprit d’équipe et booster la motivation

Ce que la revue de code m’a apporté
AXA
 https://blog.axawebcenter.fr/methodologie/ce-que-la-revue-de-code-ma-apporte/
 « Egoless programming »
 Présenter son code aux autres peut faire peur…
 On juge le CODE, et non la personne qui l’a écrit
 Principe respecté: « Dur avec le code, doux avec les gens »
 Pour que la revue de code se passe bien
 Définissez des rôles : les lecteurs, le modérateur, le scribe et le time-keeper (gardien du temps)
 1 minute maxi par point relevé
 Quand une discussion vient à s’éterniser…
 Le time-keeper annonce que cela fait une minute que l’on parle du même sujet
 Le modérateur décide de continuer la conversation, de conclure, ou de réorganiser un point dédié plus tard
 Unité de mesure pour une code review : Nombre de WTF / minutes

Mon processus de design en tant que PO sans UX designer
OCTO
 UX Design : Pratique / méthodo pour apporter une réponse à un besoin donné dans un
contexte donné
 Comment introduire les pratiques UX sans perdre en efficacité ?
 Rencontrer et échanger avec les utilisateurs
 Un CP marketing
 Le client
 Vous
 Votre équipe
 Aucun d’entre eux n’est votre UTILISATEUR
 Comment faire quand vous ne pouvez pas (officiellement) rencontrer les utilisateurs
 Niveau 0 : Soyez « opportuniste » (mode pirate)
 Quand vous obtenez le nom d’un utilisateur, contactez-le
 Niveau 1 : Rendez-vous réguliers
 Niveau 2 : Ritualiser (30min / 1h par semaine)

Mon processus de design en tant que PO sans UX designer
OCTO
 Rencontrer les utilisateurs n’est pas une option / un privilège, c’est le métier du PO
 Designez le parcours avant de faire des maquettes
 N’hésitez pas à copier les autres
 Reprendre les standards existants, intégrer des patterns auxquels l’utilisateur est déjà habitué
 Ex: Recherche LinkedIn, album photo Facebook, paniers Amazon / Fnac etc
 Prototypez rapidement pour apprendre rapidement
 Construisez et documentez les patterns utilisés
 Faire un émerger un toolkit standard à la société (ex: Bootstrap, Materials…)
 Montrez les maquettes aux utilisateurs au plus tôt (pour les feedbacks)
 Tout outil de design convient : stylo / papier, Powerpoint, Balsamiq…
 Résultats :
 Utilisateurs qualitativement plus satisfaits
 Satisfaction de co-créer
 Meilleure vision de la « roadmap » pour les utilisateurs
 Moins de corrections / évolutions post-MEP
 Du temps gagné pour les équipes

J'anime une rétrospective productive
CGI
 Exercice régulier
 Enoncer les Forces et les faiblesses
 Identifier des actions d’amélioration
 Définir le cadre de sécurité
 Zone de sécurité
 Rien ne sortira de la salle
 Pas de compte-rendu, mais un plan d’actions qui sort
 Transparence
 Bienveillance
 On se rend bien compte qu’il y a un soucis, mais on veut le résoudre

CGI
 Déroulé type
 « Ice-breaker » pour bien commencer (pour libérer l’esprit, destresser)
 Récupérer les données
 Serious Game
 +/-
 Etoile de mer (Moins de…, Plus de…, A continuer, A améliorer, A arrêter)
https://leblogdumanagementdeprojet.com/2015/09/28/adoptez-une-etoile-de-mer-pour-des-retrospectives-
agile-plus-amusantes-et-plus-productives/
 4L (Like, Learn, Long for, Laked)
https://agilamat.wordpress.com/2012/10/29/la-retrospective-4l
 SWOT (Forces / Faiblesses / Opportunités / Menaces)
http://agilelucero.com/agile/swot-retrospective/
 Speedboat
http://coach-agile.com/speed-boat
 Jouez avec la créativité
 Jouez avec les émotions

CGI
 Autres formats
 Rétrospective CNV (communication non violente) http://fr.slideshare.net/patriceboisieau/usages-de-la-
cnv-en-agilit-25720840
 Ce que j’observe (ex: la build est KO)
 Ce que je ressens (ex: l’équipe n’est pas assez attentive)
 Ce que je veux (ex: soyons plus attentifs)
 Ce que je demande (faisons des revues de code pour éviter que celà ne se reproduise)
 Méthode des « six chapeaux » https://fr.wikipedia.org/wiki/M%C3%A9thode_des_six_chapeaux
 Bleu : Organisation
 Blanc : Neutralité
 Noir : Pessimisme
 Jaune : Créativité
 Vert: Optimisme
 Rouge: Emotions

CGI
 Sinon… jouez autrement !
 Jeopardy : on part de la réponse et les personnes expriment la question
 Bien choisir et maîtriser son activité
 Regrouper les idées
 Donner la priorité
 Trouver les actions
 ROTI sur la rétrospective (une note de 1 – j’ai perdu mon temps à 5 – très
efficace)

CGI
 Participer ou animer ?
 Il vaut mieux choisir, plutôt que de faire les deux
 Le mieux est de prendre un animateur externe
 Si ce n’est pas possible
 Faîtes dire votre avis par quelqu’un d’autre
 Jouez avec des casquettes : une animateur et une participant
 L’animateur…
 A une écoute active
 Gère la discussion et répartit la parole
 Gère les conflits (l’animateur n’est pas un sauveur, mais un facilitateur)
 Quand c’est à distance
 Utilisez un tableau blanc
 Ayez un animateur de chaque côté
 Privilégiez la visio-conférence plutôt que le téléphone

L’agilité à 200 personnes
Décathon
 Programme « CUBE »
 Seamless Expérience (expérience homogène)
 Proposer la même expérience quel que soit le canal (Web, Mobile, magasin…)
 Stratégie par feature et non plus par canal
 Search & Choose / Buy / Get / Connect-Interact Services /UI/UX
 Au début…
 Features Teams orientées métier
 Nouveaux silots avec obligation de résultats
 Sprints de 3 semaines
 Cycles en V cachés

L’agilité à 200 personnes
Décathon
 Etapes réalisées
 Rendre les choses visibles
 Création d’une « Oobeya Room »
 Tableaux visuels visibles de tous
 Backlogs des équipes
 Releases
 Pilotage
 Informations
 Transformation
 Rituels
 Daily Scrum
 Daily Nexus (entre scrum masters à 11h)
 Démos communes
 Le planning est figé pour tout le monde
 Les sprints commencent et finissent en même temps
NEXUS
FEATURE
SCRUM
TEAM
SCRUM
TEAM

Agile Tour 2016 @ Lille

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Agile Tour 2016 @ Lille

Similaire à Agile Tour 2016 @ Lille (20)

Plus de Jean-Baptiste Vigneron

Plus de Jean-Baptiste Vigneron (9)

Agile Tour 2016 @ Lille