AGILE TOUR 2016Compte-Rendu

Freddie DEWALEYNEJean-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 TourPartenaires et sponsors lillois

Norsys

OCTO

OPEN

Proxiad

Zenika

AXA

Capgemini

Davidson Consulting

Décathlon

EFIDEV

Nordnet

KeyNoteMouvement #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 TeamsAXA 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 TeamsAXA 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

Où en est le contrat agile en 2016 ?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)

http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile

Où en est le contrat agile en 2016 ?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.)

http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile

Où en est le contrat agile en 2016 ?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 »

http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile

Votre job sera remplacé par un indien ou un robotIsmael 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

Votre job sera remplacé par un indien ou un robotIsmael 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

Votre job sera remplacé par un indien ou un robotIsmael 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 DocumentationArolla 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 DocumentationArolla 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étrospectiveOCTO 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étrospectiveOCTO 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 designerOCTO 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 designerOCTO 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 productiveCGI 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

J'anime une rétrospective productiveCGI 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/

Speedboathttp://coach-agile.com/speed-boat

Jouez avec la créativité Jouez avec les émotions

J'anime une rétrospective productiveCGI 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

J'anime une rétrospective productiveCGI 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)

J'anime une rétrospective productiveCGI 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 personnesDé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 personnesDé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

FEATURESCRU

MTEAM

SCRUM

TEAM