Sophrologie et pensée Agile, par Loïc Rabault – Printemps Agile 2015

Après des années de pratique des nombreuses méthodes de relaxation, Loïc Rabault les décrit comme les multiples traductions d’un même livre. C’est de cette manière que son choix s’est arrêté sur la sophrologie, la plus complète selon lui.

La sophrologie développe la conscience de façon à harmoniser le corps et l’esprit, en chassant peurs, stress et tensions.
Source : Doctissimo

La sophrologie est une science de développement de la conscience positive. Le médecin psychiatre Alphonso Caycedo a élaboré la sophrologie en 1960, à partir des connaissances occidentales en relaxation, en hypnose et des techniques traditionnelles asiatiques (yoga, bouddhisme, méditation zen).
Source : Zen Conseil (Loïc Rabault)

L’intervenant évoque le stress comme une notion n’étant ni positive, ni négative : c’est un état de fait qui est spécifique à l’individu, relatif aux évènements vécus, qui évolue sans être toujours reproductible dans des situations semblables. Le stress est finalement nocif sur la durée et dans son intensité, et peut être généré par le changement.

La sophrologie fait parti des thérapies psychocorporelles qui agissent sur 3 dimensions : les sens, les sensations corporelles et les émotions.

Le « forking Workflow » ou « GitHub Flow »

Comme cela a été présenté dans notre comparatif des workflows Git, celui dans lequel nous allons entrer en détails aujourd’hui est particulièrement adapté à une équipe à taille humaine qui pratique des mises en production régulières.

Le concept complet de ce workflow est décrit dans ce tutoriel, à lire en priorité. Si vous avez besoin d’une user-story, le guide Atlassian vous sera probablement utile.

Un article sur GitHub récapitule les six étapes du GitHub Flow. Cette animation web permet même de visualiser le process.

Les commandes principales

Pour résumer, tout commence par la création d’une branche :

Au contraire de git branch, cette commande vous bascule immédiatement dans la branche fraichement créée, basée sur Master. Vous pouvez apporter des modifications à votre arbre de travail, commiter, pusher :

Lorsque votre fonctionnalité est terminée, déplacez vous dans le Master pour tirer vos modifications dedans :

C’est à cet instant que vous aurez éventuellement à résoudre des conflits. Pas d’inquiétude, vous serez toujours en local. Pour déployer votre merge en production, faites tout simplement :

Ce merge ajoute l’intégralité de l’historique d’une branche au master.

À noter que la commande précédente, sans paramètre, poussera toujours le contenu de votre branche master locale dans la branche master sur le serveur, peu importe si vous travaillez dans une autre branche.

Les autres commandes

Pour rafraichir votre branche avec un master qui a évolué :

Un simple git rebase master impliquerait que votre master local soit à jour. Un git merge origin/master créerait un nouveau commit.

Pour lister toutes les branches locales/distantes (-a all, -r remote) :

Pour récupérer la branche d’un collègue :

L’usage des tabulations peut provoquer des erreurs car les noms des branches sont proposés au format « origin/nom » et non « nom ».

Pour supprimer votre branche locale mais conserver la distante :

Pour supprimer la branche distance mais conserver votre locale :

Choisir un Workflow Git adapté à votre équipe

Le site Atlassian a récemment mis à jour son comparatif des différents workflows Git, véritable référence en la matière. Ce guide permet d’étudier les quatre principaux workflow.

Le workflow centralisé

Workflow Git Centralisé
Il s’agit de la manière la plus basique d’utiliser Git, utilisée en découvrant l’outil et le plus souvent souvent seul ou à tour de rôle. Son fonctionnement est simple, résistant aux problèmes, il se répare vite mais laisse entre contrepartie un Master potentiellement instable.

Les branches par fonctionnalités

Workflow Git Branches par fonctionnalités
Ce workflow est très proche du workflow centralisé, mais il introduit une notion importante : le Master doit rester stable en toute circonstance. Le développement s’effectue dans des branches qui sont créées au début de chaque nouvelle fonctionnalité. Le merge d’une fonctionnalité dans le Master n’a lieu que lorsqu’elle est finalisée et qu’elle a été testée.

Ce workflow offre la possibilité de se passer des modifications entre développeurs sans les déployer en production, ou de travailler à plusieurs en parallèle sans être parasité par des évolutions inachevées.

Le Gitflow

Gitflow
Ce workflow rajoute au précédent un dédoublement du Master en Master/Development ou Master/Release/Development voire Master/Hotfix/Release/Development selon la complexité souhaitée.

Ce workflow induit la notion de version sur le Master : des fonctionnalités sont regroupées avant un merge dans Release puis dans Master. La branche Development devient le lieu d’intégration des fonctionnalités.

Le workflow par clonage

Forking workflow
Ce dernier workflow peut être utilisé en partant d’un des deux précédents workflows : les branches de fonctionnalités sont simplement remplacées par des dépôts privés forkés par les développeurs. Le but est uniquement de restreindre les droits des contributeurs au projet (lecture seule sur le dépôt central) qui est administré par un mainteneur.

Dans ce modèle, les fonctionnalités sont signalées par des merge-requests sur une interface où le mainteneur peut faire une revue de code.

Conclusion

Choisir un workflow n’est pas chose évidente : tout dépend de la manière dont vous devez livrer votre projet ainsi que du niveau de confiance que vous avez en vos contributeurs.

Les workflows centralisés ou de branches par fonctionnalités sont bien adaptés au travail d’une équipe de développement à taille humaine. Les workflows type Gitflow ou par clonage (forking) sont adaptés au travail contraint par la livraison de versions stables, ou dans un contexte où des développeurs qui ne se connaissent pas doivent pouvoir coopérer.

Scott Chacon, développeur chez GitHub, a mis en avant l’inadaptation du Gitflow dans leur équipe. Il préfère à cela le GitHub Flow qui n’est rien de plus que le workflow de branches par fonctionnalités.

Accompagner la transition agile d’un grand projet agile par Christophe Addinquy – Printemps Agile 2015

L’intervenant de cette conférence, Christophe Addinquy,  a abordé 12 leçons apprises lors de la transition agile du grand projet Linky, en y associant des conseils.

      1. L’immersion agile
        • pas facile, pas naturel
        • une journée d’immersion : ateliers, jeux, discussions pour appréhender les mécanismes de l’agilité
      2. Commencer lentement et délibérément
        • qualité = les bons gestes, du code testé
        • les premières itérations : focaliser l’attention sur la qualité et pas le nombre de stories réalisées
        • /!\ équipes cherchent à aller vite quand même
      3. Le droit à l’erreur
        • rassurer, logique d’expérimentation
        • erreur = opportunité d’apprendre quelque chose
        • laisser l’erreur arriver car on apprend par nous-même
      4. Les tests d’acceptation
        • avant de coder
        • spécifications avec de vraies valeurs
        • permet de trouver des bugs en les écrivant
        • créer des compréhensions partagées avec les équipes fonctionnelles, développeurs…
      5. La posture du management
        • pas le droit de dire aux personnes comment elles doivent faire
        • manager : porteur de l’objectif, de la vision et du sens. Il est responsable du cadre (moyens, motivation)
      6. Veiller à l’auto-organisation
        • écouter et surveiller les phrases comme « on m’a demandé que »
      7. Craftmanship
        • la qualité du code = pré-requis de l’agilité
        • 3 axes : facteurs externes (coding dojo), injecter du savoir-faire dans les équipes (binômage, refactoring) et créer de la masse critique pour la qualité du code (augmenter le nombre de personnes agiles pour faire basculer la balance de l’autre côté)
      8. Le fond et non la forme
        • « Comment » (=folklore) : post-it, rôles, cérémonies
        • « Pourquoi » : collaboration, feedback, implication, transparence
      9. Apprendre à s’améliorer
        • amélioration continue
        • rétrospective : actions faisables, review des actions précédentes
        • pendant l’intégration : action n’importe quand
      10. L’architecture compte !
        • importance du feedback
        • ne pas regarder seulement les fonctionnalités, mais comment travailler avec au jour le jour, qu’on peut le tester
      11. Off/on : comment faire la transition agile ?
        • par petits pas : apporte une confusion j’y suis / j’y suis pas
        • bien si brutale
        • autonomie de l’équipe
        • terminer un sprint avec un livrable, des tests dans l’itération
        • pas de challenges trop élevés
      12. Parfois il faut plonger pour mieux réussir
        • quand on a compris, on ne fait plus appel à l’aide
        • on ne peut pas forcer les gens à écouter
        • phase de dégradation après la mise en place mais on remonte toujours, elle est plus ou moins longue, c’est plus facile à expliquer après cette phase

// Une interface doit être facile à bien utiliser et difficile à mal utiliser.

// Faites attention à ce que vous demandez, vous risquez de l’obtenir

        • pas de mesure de vélocité car sinon rapidité au lieu de la qualité
        • nombre d’indicateurs le plus limité possible (=1), ils doivent permettre de prendre une décision (=indicateur actionnable)

Outils et pratiques pour mieux travailler ensemble ! par Simon Jaillais & Aurélien Morvant – Printemps Agile 2015

Conférence présentée par Simon Jaillais et Aurélien Morvant ayant pour but de nous montrer des ateliers pour accompagner les gens dans le changement.

Fonctionnement

Pour commencer, ils nous ont présenté le fonctionnement des ateliers. Voici quelques idées à retenir pour une bonne organisation :

Innovation game

  • commencer et terminer à l’heure
  • respecter celui qui parle
  • une conversation à la fois
  • l’opinion de chacun compte

Pratique des 7P

Peu d’espoir quand on est dans l’improvisation, un bon atelier demande 70% de préparation.

  • Product : qu’est-ce que j’attend à la fin de l’atelier ?
  • Purpose : quels sont les objectifs ?
  • People : qui va participer (rôles, préparation, déléguer – time keeper, scribe) ?
  • Practices : quelles sont les pratiques ?
  • Preparation : préparations (post-it, vidéoprojecteur…)
  • Process : que doit-on mettre en œuvre ?
  • Pitfalls : quels sont les risques associés (distances géographiques des participants) ?

Ensuite, Simon et Aurélien ont proposé aux participants de choisir un atelier parmi ceux proposés. Pour l’atelier sélectionné, ils nous ont proposé un déroulé composé d’un certain nombre de pratiques collaboratives. Voici deux ateliers choisis.

Résolutions des problèmes par la créativité

Ice breaker : alphabet des concepts

  • une question à poser au groupe et chacun répond avec un mot correspondant à une lettre en donnant la définition de ce mot
  • phase de réflexion individuelle avant celle de réflexion en groupe
  • prendre la température du groupe

Techniques de créativité

  • Purge : sortir toutes les idées sur un post-it ou sur des grandes feuilles avec des dessins
  • Analogies : donner des contextes pour lesquels on peut rencontrer le même problème (=phase de projection). Pour chaque environnement, ramener à notre contexte (=phase de convergence)

QQOQCP : plan d’actions

  • Quoi ? Qui ? Où ? Quand ? Comment ? Pourquoi ?
  • caractériser les actions avec les questions / réponses
  • une action (=ce que je peux faire) non portée = une discussion
  • chaque personne qui ressort à une action

Cohésion d’équipe

L’arbre à personnages (=15 min)

  • plusieurs personnages dans un arbre situés à des hauteurs différentes, dans des diverses positions (de dos, seul, par groupe, en train de sourire, de tomber…)
  • chaque personne cherche sa position dans l’arbre
  • chacun vient se positionner sur l’arbre (gommettes) et explique pourquoi devant le groupe
  • caractériser l’état d’esprit pour l’animation
  • /!\ poser une question avant d’utiliser l’arbre

La crevasse (=30 min)

  • jeu en binôme, les personnes s’appuient sur les mains de l’autre en face à face (pour faire un pont) et on doit avancer le long de deux lignes droites
  • l’un sans l’autre c’est difficile de travailler
  • confiance aille dans les deux sens

Conclusion

La co-construction + cohésion est une motivation pour les équipes. Les pratiques collaboratives apportent beaucoup de valeurs, sont des bons moyens de polliniser et restent des moments privilégiés.

Le barcamp 2015

Dans la même optique qu’en 2013 ou qu’en 2012, nous avons relancé en 2015 le barcamp annuel du service, 2014 étant une année un peu trop chargée pour nous le permettre. Cette année suite à divers situations personnelles de plusieurs membres de l’équipe nous avons été contraints de rester dans les locaux de la société et de segmenter nos 4 jours en 2 fois 2 jours, quelles conséquences ? Et elles sont importantes, vous les découvrirez en détails dans le débrief du barcamp.

Les objectifs restent proches :

  • permettre à l’équipe de se former,
  • faire de la veille dans l’univers du Web, où le mouvement est continu,
  • pratiquer, mettre en oeuvre des technologies encore peu utilisées au quotidien qui peuvent donner naissances à de nouvelles manière de travailler ou de s’organiser.

Du coup pas de transport mais une organisation des bureaux différentes, il est assez nécessaire d’avoir un « grand » espace pour pouvoir si on le désire tous travailler ensemble dans la même pièce. Un petit modem 4G pour répondre au souci du nombre de ports réseaux disponibles et le tour est joué. Les ordinateurs portables (en 13 pouces) sont un outils très agréables pour passer d’une configuration bureau avec second écran à une configuration mobilité pour changer de place au bon vouloir de chacun.

Les sujets réfléchis en amont du barcamp sont nombreux, certains très liés à des problématiques rencontrées au quotidien et d’autres plus proche des envies de chacun, ces 2 aspects sont très intéressants d’un côté une veille qui répond au souci rencontré sur le terrain et de l’autre une veille pour partir vers des voies encore inconnues et qui peuvent modifiées voir révolutionnées une façon de travailler historique.

La liste des sujets :

  • Workflows git et ses branches
  • Notifications HTML
  • Gestion des favicon sur les différents navigateurs
  • Nouveautés chez Rails, Rails 5 en cours de développement
  • 25 gems indispensables, le wagon. Un article perçu dans les mois précédants le barcamp
  • Atom vs Sublim Text
  • Paperclip, foldercouch, la compression d’image et le redimensionnement
  • Système de cache, Rack cache, Dalli, Varnish/Ngix
  • Rails cache
  • Méta réseaux sociaux, facebbok / Twitter
  • Page speed, utilisation / api
  • Les images responsives
  • Susy / Grille CSS / Framework CSS
  • Mesure coût projet
  • Behavior Driven Development
  • Golden Master Testing
  • E-réputation
  • Temps réél, Rails / Faye vs Node js
  • Utilisation des em en intégration
  • Rails cache
  • Nogios
  • Selenium
  • Back office, article sur Symbioz Rails admin / Active admin
  • Appli sans largeur fixe, quelles conséquences ?
  • Definition of done
  • Sois net, revoir le blog, maj wordpress, catégories, tags, SEO
  • Bonnes pratiques intégrations sur un max de navigateurs
  • Docker
  • Vagrant
  • Santé du domaine (très générique)
  • Rspec
  • Capybara

Cette liste a été élaboré par toutes l’équipe lors de la première matinée, elle vient de sujet mis de côté durant l’année afin de les pousser lors du barcamp mais aussi de notions vues au printemps agile 2015, où Pierre-Olivier et Julien avait présenté Les TDD (Test Driven Development) en toute agilité.

Une fois les sujets établis, nous nous sommes données entre 1H30 et 2H pour étudier un sujet en binôme ou de manière individuelle puis une présentation suivait cette étude. La journée était découpée en 4 parties, 2 sujets le matin et 2 sujets l’après midi pour chaque personne.

Les sujets étudiés au cours de ces 2 fois 2 jours ont été nombreux, beaucoup d’articles sont parus sur le blog. Ils n’ont pas toujours donnés lieux à une mise en place car pas adapté, encore trop compliqué ou tout simplement par ce que le fonctionnement actuel été le bon (ex : l’utilisation de page speed).

Résultats des courses :

27 sujets étudiés, il n’en reste que 5 (Vagrant, le BDD, Golden Master Testing, E-reputation, Mesure gain projet) mais de nouveaux sont déjà dans les tuyaux, notre métier est vraiment passionnant pour cela, nous ne sommes jamais arrivé, il reste toujours un chemin, une voie à découvrir 😉

Prochain article le débrief de ce barcamp édition 3…

Software Craftsmanship, par Antoine Vernois – Printemps agile 2015

Antoine Vernois a commencé la journée par une présentation nommée « Software Craftsmanship », une session sur le développement mais le développement bien fait et sur le mouvement de l’artisanat logiciel. Cette même conférence a été filmée lors de l’agile tour de Montpellier en 2013.

Antoine se définit comme un artisan développeur, une notion très intéressante au sein de laquelle la qualité n’est pas une option.

Antoine aborde ensuite la métaphore de la dette technique, qui par analogie explique que si on ne fait pas bien les choses dès le début on prend plus de temps par la suite (comparable aux intérêts en finance) et que si ce point n’est pas corrigé rapidement on se retrouve très vite à ne payer que des intérêts ou à un figement de l’application pour éviter de payer ces intérêts. Cette analogie est un concept bien connu dans notre service. D’ailleurs, nous essayons de nous améliorer en permanence afin de ne pas être prisonnier de cette dette technique.

Antoine a ensuite évoqué le principe de Peter et le fait que cela n’est pas immuable. Il n’appartient qu’à nous d’éviter ce principe mauvais pour les entreprises.

Il a également parlé du fait que les artisans choisissent eux même leurs outils selon le contexte, et du fait qu’il faut investir un peu de temps chaque jour pour accélérer le quotidien en automatisant les tâches automatisables. Le retour sur investissement est alors rapide.

Antoine a aussi évoqué un auteur et développeur américain Robert C. Martin, co-auteur du fameux Manifeste Agile. Voyant que certains interprété le Manifeste Agile de manière inexacte (« geule de bois agile »), il l’a étendu en créant le manifeste pour l’artisanat logiciel, ou « Manifesto for Software Craftsmanship ». Il a aussi publié des livres comme Clean code, au sein desquels il dit que « le seul moyen d’aller vite, c’est de faire bien », encore une fois la qualité n’est pas une option et ne peut pas en être une.

Antoine considère qu’il faut faire un code propre notamment pour les personnes qui passeront après nous sur les projets, cette notion me semble plus qu’indiqué lorsque l’on travaille de façon agile en équipe.

Il nous indique aussi que pour lui un développeur n’est pas juste une personne qui écrit du code, cela n’est pas le premier objectif de notre métier. L’objectif de notre métier et de créer des applications et pour cela nous écrivons du code mais si demain nous pouvons réaliser une application sans écrire du code il y a de forte chance que les développeurs n’écrivent plus de code.

Il a également repris différents points du manifeste agile pour les expliquer comme notamment les relations entre les individus et le partage de connaissance avec des rencontres entre professionnels et/ou passionnés autour d’évènement comme le Printemps agile 2015. Ceci dans le but de progresser ensemble en partageant les bonnes pratiques et les expériences de chacun.

Enfin, Il invite les développeurs à choisir leurs outils de travail et leur plan de carrière. Ils doivent être les plus à même de pouvoir le faire. Si ce n’est pas le cas, Antoine invitent clairement à regarder ailleurs, « changer de boîte ». En effet, dans notre domaine il y a des postes à pourvoir.

Antoine s’appuie sur des citations bien trouvées comme « la différence entre la théorie et la pratique, c’est qu’en théorie il n’y en a pas ». Il relativise la théorie et explique ainsi que les personnes ayant de l’expérience, terrain j’entends, sont plus à même de prendre des décisions dans la conception d’un logiciel qu’une personne qui écrit la théorie (« architecte logiciel »).

Il promeut le simple au lieu du complexe qui n’apporte rien, pour Antoine un professionnel fait simple.

Par la suite, il explique aussi que dans notre métier on ne s’entraîne plus, au sens où lorsque l’on code il y a toujours un but de production derrière, il pense que cela est négatif pour notre « art » dans le sens où on ne se donne jamais le droit à l’échec sans conséquence (financière, …).

Il termine sa présentation par expliquer que si l’on veut changer de boite par ce qu’il y a du code pourri dans celle où on se trouve et bien ce n’est pas une bonne raison car il y a du code « pourri » partout et c’est comme ça. Mais il ne faut pas avoir peur du code pourri car il fonctionne déjà mal donc on peut se permettre de rentrer dedans on ne fera sûrement pas pire. Ce code pourri a un potentiel énorme d’amélioration et est le lieu propice à l’expérimentation.

Ainsi se termine la présentation d’Antoine Vernois, très instructive et ça fait du bien de voir des personnes passionnées par ce métier et le goût du travail bien fait.

Lean Start-up, par Alexis Michel – Printemps Agile 2015

Alexis Michel est chargé de développement de l’InsIDE à l’EM Normandie. Il a notamment co-organisé trois Startup Weekend à Caen et prépare l’édition 2015.

Son premier constat est le suivant : 2/3 des startups changeront d’orientation au cours de leur vie. Il recommande pour cela le livre « La Méthode Running Lean » par Ash Maurya, qui décrit comment itérer pour joindre ses idées aux besoins des premiers clients.

L’intervenant explique qu’une startup est une entreprise à la recherche de son business model. Pour cela, Ash Maurya et Alexander Osterwalder ont proposé un schéma appelé « Lean Canvas », ici traduit par Laurent Demontiers sous licence CC BY-SA 3.0 :

Avant tout projet, il faut identifier les risques principaux :

  • Est-ce que cela intéresse des clients ?
  • Sont-ils prêts à payer pour cela ?
  • Est-ce que cela est réalisable ?

La boucle d’itération proposée pour parvenir à cet objectif est la suivante :

  1. Rassembler ses idées
  2. Construire ses idées
  3. Coder les premières fonctionnalités
  4. Mesurer l’effet du travail concrétisé
  5. Apprendre de cette itération
  6. Recommencer

Puis, afin de tester son plan, une nouvelle boucle à suivre :

  1. Comprendre le problème
  2. Résoudre le problème
  3. Valider la qualité
  4. Valider la quantité

L’intervenant propose également d’avoir recourt à des métriques, dans le but de mesurer l’évolution d’un produit en production. Voici l’entonnoir Dave Mc Cure’s Pirate Metrics :

Ce schéma se répète pour chaque génération d’utilisateurs, il peut être intéressant de l’étudier à nouveau lors de chaque modification du produit ou du business model.

Steve Blanks disait : « Aucun business plan ne survit au premier contact avec les clients ».

Lean Management par Xavier Medard – Printemps agile 2015

Cette conférence avait pour but de faire découvrir le lean management.

Après un bref historique sur les débuts du lean management, qui a était inventé car il y avait des incompréhensions entre les personnes (direction et salarié), Xavier s’est appuyé sur des sources variées comme des livres, études et reportages (notamment la belle histoire de Favi, l’étude de Gallup de 2013 ou encore celui d’arte : Le bonheur au travail), que des sources vraiment très intéressantes sur le Lean mais pas que, d’un point de vue général sur le travail et pourquoi ce mal-être et des exemples de solutions pour améliorer les choses dans ce domaine.

Ces diverses sources sont intéressantes et le constat est sans appel seulement 9% des salariés sont activement engagés dans leur travail, cela montre qu’il faut changer la manière de faire et de motiver les personnes qui travaillent. Ces sources montrent aussi que des solutions sont possibles et ont déjà étaient appliquées, ils font donc s’informer sur le sujet afin de trouver sa façon de faire.

Il est aujourd’hui plus aisé qu’auparavant de connaître la situation au sein des entreprises, grâce notamment aux réseaux sociaux qui peuvent permettre de voir l’e-réputation des différentes sociétés et permettre dans certains cas de donner confiance aux futurs collègues ou bien l’inverse, il faut donc se pré-occuper de cette e-réputation qui pèse de plus en plus dans le choix de sa future société.

Dans les livres citées dans la présentation nous retrouvons :

  • « De la pyramide au réseau » de François Ost et Michel Van de Kerchove
  • « Liberté et compagnie » de Isaac Getz
  • « Machine that changed the world » de James P. Womack, Daniel T. Jones, Daniel Roos

Nous avons par la suite revus les principes Lean contre le gaspillage :

  • Surproduction
  • Attentes
  • Transport
  • Étapes inutiles
  • Stock
  • Mouvement inutiles
  • Corrections/retouches

Auxquels Xavier a ajouté 2 autres gaspillages :

  • Sécurité
  • Mauvaise utilisation des compétences

Par la suite, Xavier nous a expliqué qu’il faut passer du mode pompier : « on éteint un feu qui s’est allumé » au mode bucheron : « on empêche le feu de s’allumer ».

Il a abordé aussi quelques aspects de la culture japonaise dont est issu le Lean, avec notamment un temps non négligeable accordé à la réflexion pour la prise de décision commune qui une fois établie permet d’éviter de poser des soucis par la suite.

Il nous a été donné quelques outils pour aider à la prise de décision comme les cartographies de flux de valeurs, la méthode 5S, le management visuel (en listant toutes les idées nous pouvons les regroupées, les confrontées, en faire émerger de nouvelles et enfin prendre des décisions).

Enfin, Xavier a indiqué une règle simple et efficace, le standard dans les pratiques est la meilleure pratique du moment.

Une présentation basée sur différents supports et qui résument avec des cas concrets comme celui d’une entreprise et d’une conductrice de ligne :

La conductrice dit « je n’arrive pas à déplacer ma poubelle de déchets ».

Première réaction des cadres « nous allons te mettre des roulettes sous la poubelle ».

Mais après réflexion le cadre vient revoir la personne « mais pourquoi tu n’arrives pas à déplacer la poubelle ? ».

Réponse de la conductrice (celui qui fait sait) « car elle est trop pleine de rebuts ».

« OK, on va essayé que la machine génère moins de rebuts ».

Et ils ont réussis donc pas besoin de roulettes sous les poubelles -> économie et une machine qui génère 3 fois moins de rebuts -> économie, cela illustre la force d’un des principes du Kaisen, s’attaquer à la source des soucis et ne pas seulement corrigé une conséquence d’un souci mais cela demande de prendre du temps pour réfléchir au véritable cause et de l’investissement dans les solutions (ici étudier le fonctionnement de la machine pour limiter les rebuts) mais le résultat est bien meilleure et souvent applicable à plusieurs machine ayant un fonctionnement similaire.

Merci à Xavier pour cette présentation lors du printemps agile 2015.

Enseigner Agile, par Jean-Luc Lambert – Printemps Agile 2015

Jean-Luc Lambert est enseignant agile à l’Université de Caen et président-fondateur du Club Agile Caen. Après s’être présenté, il nous a proposé une conférence sur mesure où le public choisi les sujets qu’il va aborder.

Les sujets sont répartis sur un large tableau, où chaque colonne représente une période, et disposés sur des Post-it de trois couleurs différentes :

  • vert : c’est une bonne expérience d’Agilité
  • jaune : un incident est survenu, posant des questions
  • rouge : catastrophe, le public n’a pas saisi le message

« Planning Game » (vert)

Le premier sujet tiré met en avant un retour d’expérience où des étudiants doivent travailler sur un sujet commun imposé. À la première itération, les étudiants travaillent individuellement, mais se dispersent. À la seconde itération, ils rassemblent leurs idées par binômes, puis lors de la troisième itération par quadrinômes. Il apparait que les phases de travail collectif motivent bien plus les étudiants, parfois 2h durant.

Création d’illustrations de contes de fées (vert)

Dans ce second sujet, des étudiants en informatique sont répartis en petits groupes où sont implantés des dessinateurs professionnels. Le but est de réaliser des planches commandées par un « client » chargé de définir ses attentes. Lors de la première itération, les dessinateurs ne laissent pas l’accès à leurs travaux et refusent que les étudiants interviennent dessus. Durant la seconde itération, les dessinateurs laissent peu à peu les étudiants mettre en couleurs leurs illustrations ou y apporter des retouches.

L’exercice montre qu’une équipe fière de son travail fonctionne mieux, et qu’un client plus content créé une dynamique positive qui conduit à créer une sensation d’équipe plus forte.

L’intervenant estime que le système éducatif ne forme pas à surmonter l’échec, mais génère au contraire des étudiants qui se démoralisent vite, cachant leurs problèmes plutôt que de les exposer : ils n’osent pas poser de question mais réalisent le produit malgré tout.

Une équipe qui a eu un problème majeur (jaune)

Un binôme d’étudiants a choisi d’utiliser un logiciel en début d’année pour lequel ils avaient obtenu de l’école une licence valide. Malheureusement plusieurs mois après, au moment de réaliser le projet, la licence a expiré. L’intervenant explique ici toute l’importance de ne pas chercher un fautif, pour ne pas dégrader l’ambiance du groupe, tout en précisant le rôle du manager qui doit tout remuer pour apporter une solution.

En joignant les étudiants, le professeur et les interlocuteurs concernés, l’intervenant est parvenu à obtenir une nouvelle licence. En outre, montrer ouvertement qu’on cherche à résoudre un problème est une attitude qui tend à rassurer l’équipe et le client : il est bien plus efficace d’escalader un problème que de l’affronter.

Des étudiants contestataires (rouge)

Ayant exercé dans deux filières différentes, imagerie et monétique, l’intervenant fait part de sa sensation de l’existence d’un formatage plus ou moins résistant au changement selon le cursus. Si les TD avec les étudiants en imagerie se passent sans accrocs, ceux en monétique se heurtent à des étudiants fermés au dialogue.

Au cours d’un TD, un groupe réussi l’exercice, deux groupes le contestent tout en le réalisant à contre-cœur et le dernier groupe voit ses membres s’éviter. Aucun des groupes n’acceptera un débriefing sur l’exercice, pas même celui l’ayant réussi.

Une étudiante surprenante (jaune)

Suite à un brainstorming à l’aide d’un mur de Post-it, une étudiante annonce à l’intervenant qu’elle compte reproduire l’expérience dans sa propre association. Le groupe, composé de membres d’âge très varié, est en effet dirigé par une minorité âgée contre les envies d’une majorité plus jeune. La minorité se compose de membres qui refusent le dialogue, bloquent le changement et manipulent les plus jeunes.

Le brainstorm proposé par l’étudiante fait apparaitre clairement le double langage des anciens, dont les idées sont en opposition avec les aspirations de la majorité. C’est l’échec du dialogue : le groupe éclate, les anciens quittent l’association. La jeune génération lance enfin les nouvelles activités tant attendues dans un élan de motivation général.

Cette anecdote souligne qu’il est parfois nécessaire de se séparer des éléments bloquants dans l’intérêt du groupe.