Compte-rendu Agile Tour 2014 à Lille

SOMMAIRE
Compte-rendu de l’Agile Tour 2014 à LillePage 2
L’AGILE TOUR EN QUELQUES MOTS…
9H : KEYNOTE 1 – THE BUSY BEE PARADOX
10H : JE SUIS AGILE… MAIS SUIS-JE CRÉATIF ?
11H : LE LEAN PRODUCT MANAGEMENT
14H : KEYNOTE 2 – NO ESTIMATES !
15H : LE LEAN STARTUP – RETOUR XP
16H : PROJETS AGILES – ARRÊTEZ LES DÉRIVES !
17H : ETES-VOUS PRÊT POUR LE MODÈLE SPOTIFY ?

 Conférences, rencontres, ateliers et échanges autour des méthodes agiles.
 Accès gratuit
 Evènement international, organisé dans plus de 80 villes dans le monde
 Site officiel : http://www.agiletour.org/
 A Lille :
o Organisé par l’association Nord-Agile
o Le 18 novembre 2014 à Euratechnologies de 9h à 18h
o Plus de 350 participants, 25 conférenciers
 En France :
o 15 villes dont Paris, Aix-Marseille, Lyon, Sophia-Antipolis, Toulouse…
PRÉSENTATION

PARTENAIRES ET SPONSORS LILLOIS

KEYNOTE 1 : THE BUSY BEE PARADOX
Slides : http://fr.slideshare.net/HkanForss/the-busy-bee-paradox-agile-tour-lille-2014
 Scénario : échanges entre les équipes de dev et de recette
o L’équipe de recette remonte un ticket mais son traitement peut être long
o L’équipe de dev est déjà fortement sollicité pour d’autres problématiques
o Entre l’envoi du ticket au support et la réponse, la recette est bloquée
 Solution :
o Mettre le focus sur le “vrai” travail à faire pour être efficient
o Ne pas hésiter à stopper les tâches en cours et traiter l’urgence
 Deux modes de fonctionnement :
HAKAN FORSS (@HAKANFORSS) – KING
Resource efficiency Flow efficiency
Ex : Usine Ex : Ambulances
Capacité utilisée à 100% Capacité faiblement utilisée
Réactivité faible Réactivité élevée
Focus coût unitaire Focus valeur ajoutée client

KEYNOTE 1 : THE BUSY BEE PARADOX
 Les différents temps identifiés
o Temps d’initialisation (mise en place des outils, démarrage environnement… - non compensable)
o Temps de test (valeur créée)
o Temps d’attente/inactivité (attente du retour support, aucune valeur créée - compensable)
o Temps de réponse (le support traite le problème)
 Flow Efficiency
o Concentration sur la valeur ajoutée client
o Formule = Temps travail réel / (Temps travail réel + Temps inactivité)
o Lean Management – optimisation du flux de travail
 Outils et méthodes
o Utiliser des Blockers/Impediments Boards
o Reporting, defects, maintenance backlog, daily-meeting
o Garantir la comprehension du besoin par tous en communiquant et à l’aide du management visuel, tableaux…
o Penser “flux de travail” (Kanban) et non plus “tâches” (Scrum)
o Eviter les estimations, basées généralement sur l’expérience et l’historique des projets (cf. Keynote 2)
HAKAN FORSS (@HAKANFORSS) – KING

JE SUIS AGILE… MAIS SUIS-JE CRÉATIF ?
 Pour favoriser sa créativité…
CEDRIC POURBAIX (@CEDRICPOURBAIX) – EFIDEV
Connaissances
Imagination
Attitude
Ressources
Habitat
Culture
Ai-je tous ces éléments ? Ces éléments me sont-ils favorables ?
L’étincelle
Le catalyseur
Le carburant
Valeurs
Bureaux, salles…
Environnement à
ma disposition

 Créativité
o Processus qui consiste à avoir des idées originales qui ont de la valeur
o Exemple de mise en application : la D-SCHOOL à Stanford (USA)
 Les freins à la créativité
o Les cahiers des charges (on définit des tâches, des specifications trop longtemps à l’avance)
o Les applications packagées et les ERP (moins de libertés)
o Un mauvais encadrement ou un mauvais management
 L’agilité dans tout ça ?
o C’est une méthode culture
o Le cadre agile et la collaboration favorisent la créativité
o Utiliser les principes agiles : Mélée quotidienne, pair programming, backlog…
 Plus vous travaillez sur une idée, plus vous vous y attachez.
 Un manque de ressources mais une liberté d’action totale favorisent la créativité.

 Quelques citations :
o “Tout le monde est un génie ; mais si vous jugez un
poisson sur ses capacités à grimper à un arbre, il
passera sa vie à croire qu’il est stupide”, A. Einstein
o “La créativité est développée quand les succès et les
échecs sont récompensés et seule l’inaction est
punie.”
o “Si vous n’êtes pas préparé à vous tromper, vous ne
créerez jamais rien d’original.”

LE LEAN PRODUCT MANAGEMENT
SÉBASTIEN SACARD (@SSACARD) – MOBILEANGELO
 A destination:
o des grandes entreprises en cours de transformation digitale
o des entreprises travaillant en mode “silos”
 Problèmes identifiés:
o Le délai est trop long entre le moment de l’idée et son implémentation
o Le terme “valeur” peut être flou
o L’innovation dans les grandes entreprises n’est pas vue comme une source de valeur
 Solutions:
o Vocabulaire transversal
o Flux de travail optimisé et adapté
o Créer une organisation transverse par dessus les silos
o Culture, méthodes et outils

 Product Management: Organiser les équipes autour d’un produit et non plus d’un projet
o Projet : Limité dans le temps, objectifs à court terme
o Produit : Aucune date de fin, objectifs à long terme
 Qu’est-ce qu’un bon produit ?
o Il apporte des bénéfices aux utilisateurs et des profits à l’entreprise
o Généralement, on pense à un des objectifs cite ci-dessus mais pas à l’autre
 Qu’est-ce que l’innovation ?
o Ce sont des résultats d’essais et de curiosité
o Il faut intégrer le process d’innovation dans les équipes produits et ne pas le laisser “isolé”
 Qu’est-ce que la transformation digitale ?
o Changer le business model d’une entreprise à l’aide d’outils digitaux
o Exemple avec Renault:
• Avant : Construire des voitures
• Maintenant : Créer des logiciels pour les voitures

BESOINS
UTILISATEURS
PRODUIT
PROFITS
ENTREPRISE
 Produits standards
 Produits digitaux
BENEFICES
UTILISATEURS
BESOINS
UTILISATEURS
PRODUIT
PROFITS
ENTREPRISE
BENEFICES
UTILISATEURS

Bénéfices
utilisateurs
Profits
Entreprise
+ + On crée de la valeur
+ - Pas de valeur crée, pas de perte
- + On détruit de la valeur
- - ??

 Créer de la valeur en LEAN
o Identifier ce que l’on veut faire évoluer
o Identifier la chaîne de création de valeur
o Optimiser la chaîne
o Ne pas “pusher” des features supplémentaires,
mais se tenir aux demandes des utilisateurs
o Se concentrer sur le(s) besoin(s) et non
sur ce dont on est capable de faire

 Flux (Limites)
 Ce qui ne se mesure pas ne s’améliore pas
 Equipe produit ≠ Equipe marketing ≠ Equipe Engineering
 Product Management >> Project Management
 Bénéfices utilisateurs >> Profits entreprise
 Innovation >> implémenter des idées
 Experiencing >> Persuasing
 Projet => Application => Produit => Marque
Discover Design Dev Launch Improve
Consolidate
or Remove

KEYNOTE 2 : NO ESTIMATES !
HENRI KARHATSU (@KARAHATSU)
 Le mouvement #NoEstimates
o Ne pas remettre en cause les estimations, mais trouver de meilleures solutions
pour décider
o Explications complémentaires ici
 Feature coast
o Coût de la tâche
o Coût si on ne la fait pas (risques)
 Remplacer les questions difficiles par une plus simple pour pouvoir prendre
une decision
 Lead Times
o Work, Interruptions, Rework, Waiting, Queues

LE LEAN STARTUP – RETOUR D’EXPERIENCE
SARAH MORTEL (@SARAHMRTL) – EFIDEV
 Retour d’expérience sur le projet “TAIKOON”
 Quelques conseils quand on fait du Lean Startup
o Simplifier, optimiser
o Faciliter la prise en main de l’outil
o Organiser des ateliers avec les utilisateurs pour avoir du feeback
 Au niveau de notre application
o Imaginer des scenarios “fluides“ et ne pas créer des menus “silots”
o Intégrer les utilisateurs dans la conception
o Bouton “Aide” sur chaque page (Utilisation de l’outil de support UserVoice)
 Stratégie de développement de produit MVP : Most Viable Product (produit
minimum viable)
Prototyper
Ecouter
Améliorer

LE LEAN STARTUP – RETOUR D’EXPERIENCE
SARAH MORTEL (@SARAHMRTL) – EFIDEV
 Ne pas oublier ces éléments :
o Visions
o Backlog
o Sprints
o Béta-testeurs
o Sujets “fil rouge”
o Post-its avec couleurs
o Revue de backlog réguliers
En tant que …(Qui ?)
Je veux … (Quoi ?)
Afin de… (Pourquoi ?)

PROJETS AGILES – ARRÊTEZ LES DERIVES !
CYRIL DERUEL (@CYRILDERUEL) – OCTO
Slides : http://t.co/3kJ5nLVVWt
 Bonnes pratiques lors d’une mélée quotidienne
o Etre debout
o Connaître l’advancement et les obstacles
o Rappel de la direction souhaitée
o Un bon “stand-up” est perçu comme “auto-géré”
 Le Planning Game
o L’équipe est alignée sur
• Sur ce qu’il y a à réaliser
• Les points difficiles
• Les enjeux du sprint
o Le Product Owner s’améliore au fur et à mesure dans sa façon de rédiger les User Stories

 Bonnes pratiques lors d’une démo
o Avoir du feedback de la part du Product Owner et des utilisateurs
o Valoriser son travail lors de la presentation
o Rappeler les objectifs et les enjeux du produit
o Echanger et discuter
o Co-animer la démo entre Product Owner et développeurs
 Bonnes pratiques lors d’une retrospective (ex: de sprint)
o La préparer
o Rappeler les faits
o Mesurer
o Lister les améliorations à faire et les actions entreprises (3)
o Supprimer les actions obsolètes
o Montrer les résultats
o Limiter en temps
o Rédiger un compte-rendu

 Management visuel
o Burndown Chart
o Board (Scrum ou Kanban)
o Alertes
o Afficher les problèmes
o Partager les infos
o Stimuler l’amelioration continue
 Bonnes pratiques techniques
o Maitriser la dette technique
o Garder du temps pour gérer votre dette
o Faire des rétros techniques (“Techtro”)
o Un projet sans tests unitaires coule après 6 iterations en moyenne

 User Story
o Apporte de la valeur à l’utilisateur ( ≠ Technical Story)
o Est INVEST
• Indépendante
• Négociable
• Verticale
• Estimable
• Small
• Testable
 Autres bonnes pratiques
o Ne pas passer à côté du lancement du projet
o Transformer les “plaignants” et les “touristes“ en “clients des problèmes” et les régler avec eux
o Livrer en production
o Itérations parlantes
o Tests automatisés
o Aller voir les utilisateurs et avoir du feedback

ETES-VOUS PRÊT POUR LE MODÈLE SPOTIFY ?
RENAUD CHEVALIER (@CHEVALIERRENAUD) – XEBIA
 Spotify c’est
o Un site (BackboneJS et Drupal)
o Application iOS / Android ( + Windows Phone)
o Webservices en Java
 Projet : refonte du site
o Au fur et à mesure
• Le périmètre augmentait
• L’écart entre le périmètre et la réalité s’agrandissait
• Le reste à faire était inconnu
• En décembre 2012, Retard estimé à 1 an !
o Mise en place d’un audit
• La vision DSI et la vision Marketing étaient différentes
• Mise en place de Kanban et de “Features teams”

 Feature Teams
o Introduit par Henrik Kniberg
o Construction d’un produit au fur et à mesure
o Livraisons intermédiaires
o Equipes pluridisciplinaires
 Squads
o Equipes agiles autonomes colocalisées
o Esprit startup
o Chaque squad a une partie du site / de l’appli précise en charge
 Tributs
o Représente plusieurs squads
 Chapters
o Groupes d’expertises dans la même tribute
 Guildes
o Personnes de même expertise/intérêt dans plusieurs tributs

 Nouvelle organisation
1 équipe front-office
1 Product Owner
1 équipe CMS
1 Scrum Master
1 Product Owner
1 équipe Services
1 Scrum Master
1 Product Owner
1 Scrum Master
en chef
1 Product Owner
en chef

 Réunions quotidiennes
o 9h : Guildes pilotages (CP + PO + SM)
o 9h30 : Daily meeting Squad (PO + SM + Equipe)
 Réunions hebdomadaires
o Mardi matin : Réunion de synchronisation backlog entre POs
o Mardi soir : Présentation équipe (PO + Equipe)
o Jeudi matin :
• Réunion problèmes / roadmap
• Réunion par techno
− Backlog dette technique
 Fin du sprint
o Démo commune avec toutes les équipes

 Indicateurs
o Feature matrix
o Couverture produit
o Avancement
Backlog
par
couche
technique
Avant
Backlog
par
produit
(de bout
en bout)
Après

 10 questions à se poser avant de passer en features teams
o 1. Quels sont vos produits ?
o 2. Quels sont les grands ensembles fonctionnels du produit et comment vos équipes sont
organisées ?
o 3. Quel est le processus de mise en production ?
o 4. Pourquoi passer en features team ? (formaliser)
o 5. Quelle stratégie de découpe des équipes ? (Composite/Product..., collaboration,
autonomie, logistique, résistance au changement…)
o 6. De quelles communautés de pratiques avons-nous besoin ?
o 7. Comment piloter ? (Backlog product ? Backlog sprint ?)
o 8. Comment maîtriser la qualité ? (TU / BDD / Int. continue / Feature branching…)
o 9. GO / NO GO ?
o 10. Quel est le plan de communication ?

Compte-rendu de l’Agile Tour 2014 à Lille
MICROPOLE - AGENCE DE LILLE
6 RUE JEAN ROISIN – 59000 LILLE – FRANCE
TELEPHONE : +33 (03) 66 72 80 20
INFO@MICROPOLE.COM
WWW.MICROPOLE.COM

Compte-rendu Agile Tour 2014 à Lille

Contenu connexe

Tendances

En vedette

Similaire à Compte-rendu Agile Tour 2014 à Lille

Compte-rendu Agile Tour 2014 à Lille