Étiquette : agile

  • La Joie

    jpeg

    Douglas McGregor présentait sa théorie Y en explicitant une croyance : « travailler est aussi naturel que jouer ou se reposer ». Richard Sheridan, co-fondateur et CEO de Menlo Innovations, explique que la joie dont il parle dans son livre Joy, Inc. est cette sorte de joie.

    Joy, Inc. est le meilleure défenseur du binomage que j’ai lu jusqu’à présent. Par binomage, j’entends 2 personnes qui travaillent assises au même bureau sur le même ordinateur. J’aimerais dire que cette approche a été popularisée par le Pair Programming. Il se trouve que l’efficacité de la plus petite boucle d’apprentissage possible n’a pas la popularité qu’elle devrait avoir. Le paralèlle exposé du binomage dans la chirurgie est intéressant à réutiliser.

    Richard Sheridan présente les pratiques à l’oeuvre à Menlo. Les praticiens Agile en reconnaitront certaines, ou découvriront des façons alternatives de mettre en oeuvre des valeurs et principes similaires. Pour donner quelques exemples :

    • Un espace de travail ouvert et reconfigurable facilement permettant au personne de rassembler leurs bureaux lorsqu’elles travaillent ensembles sur le même projet
    • Une réunion quotidienne réunissant l’ensemble de l’entreprise tous les jours à 10h (un cercle de 70 personnes…)
    • Walkies, un rituel pour couper l’après-midi ou l’ensemble de l’entreprise fait une promenade à pied ensemble
    • Show & Tell, la revue d’itération… à l’envers… car c’est le client qui présente à l’équipe ce qui a été réalisé…
    • Un processus d’entretien, de recrutement et d’accueil qui place l’adéquation de la culture en priorité. Il n’y a pas de système de cooptation chez Menlo.
    • Un attachement à la compréhension des objectifs des utilisateurs, avec l’usage des personas… bien avant que l’on en parle dans le logiciel, avec en prime un titre amusant : high tech anthropologists
    • Faire des erreurs rapidement, comme une façon de faire croitre les personnes et les affaires
    • Bébés et enfants au bureau

    A leader is best when people barely know he exists. When his work is done, his aim fulfilled, they will say: we did it ourselves. Lao Tzu

    • Une culture pour développer des leaders pas des chefs
    • Le planning en utilisant des cartes proportionnelles à l’effort (et de l’espace pour la semaine proportionnel à la capacité)
    • L’utilisation de couleur pour différentier la maintenance des nouveaux produits
    • L’utilisation du TDD (Test driven development) ou développement piloté par les tests (on code le test avant la fonctionnalité)
    • Livrer un logiciel fonctionnel chaque semaine au client
    • Uniquement des équipes colocalisée, considérant qu’aucune technologie ne peut actuellement remplacer le fait d’être présent
    • Durée et horaire de travail fixe (40 heures par semaine), considérant que le travail flexible ne l’est pas tant que cela et fait déborder le temps de travail au détriment du reste (et donc n’est pas soutenable pour les personnes… et donc pour l’entreprise). Lorsque les personnes sont hors du bureau, elles le sont totalement (ou Menlo trouve un arrangement temporaire pour permettre le travail depuis la maison pour une période spécifique)
    • Importance de connaitre la façon de répéter quelque chose de la même façon (standard, checklist) permettant l’amélioration
    • Responsabilisation (Accountability), en illustrant l’exemple du processus d’estimation, n’incluant aucune peur et de la transparence en interne et en externe
    • Communication alignée entre l’interne et l’externe. Si vous ne pouvez dire la vérité au monde… alors vous devez changer votre culture…
    • 50% de réduction sur les factures en échange d’actions ou de royalties (gros succès enregistré sur ce point)
    • Réduction de 25% pour de la flexibilité sur la date de livraison (inventé durant la récession de 2008)
    • L’impact important de réussir à « terminer » les choses sur le bonheur des employées

    Vous comprenez à la lecture de cette liste que je pense que ce livre mérite d’être lu, même si je vais continuer à travailler pour démontrer la valeur des équipes distribuées et du travail asynchrone sur l’efficacité et le bonheur des équipes.

    La photo des bureaux de Menlo Innovation illustrant l’article est issue de l’article de J.D. Booth pour Corpmagazine.com

  • Etre l’entreprise agile de demain

    Ce jeudi 5 juin 2014, j’ai donné une conférence sur le thème du management et de l’organisation, lors du ScrumWine hébergé par Lectra.

    Pour illustrer mes propos, j’ai utilisé le cas de eNovance une entreprise qui grandi en restant agile.

    Les retours sur la conférence étaient excellents et je remercie tout ceux qui se sont manifestés. Je suis très heureux d’être parvenu à faire passé les messages sur l’évolution des modèles de management au 21ème siècle.

    Je suis aussi flatté par les retours indiquant que cette conférence mériterait d’être donné sur de plus gros événements, peut-être même en conférence d’ouverture !

    Un grand merci à tous !

    Merci également à l’équipe Ayeba qui a contribué à préparer cette présentation.

    J’inclus dans cet article le support de présentation que j’ai utilisé pour cette session pour permettre à ceux qui y ont assistés de récupérer les références que j’ai proposé.

    Le support n’est pas très explicite sans le discours associé.

  • Agile et Openstack

    Atlanta-How-do-youCe mardi 13 mai 2014, j’ai donné une conférence avec Frédéric Lepied (VP Software Engineering chez eNovance) à l’Openstack Summit qui se tenait ce printemps à Atlanta.

    L’objectif de la session était de présenter comment, chez eNovance, nous combinions Agile et Open Source pour faire grandir les équipes et contribuer à Openstack.

    are-you-too-busy-to-improve2Pour illustrer les pratiques agiles, j’ai utilisé deux illustrations issues du blog de Hakan Forss dont je vous recommande la lecture. Hakan explique les pratiques et les situations qu’il rencontre en utilisant des briques Lego. L’illustration sur la rétrospective « Too busy to improve » a fait le tour du monde.

    Les pratiques agiles misent sur la localisation de l’équipe dans un seul lieu, alors même que les projets open source accueillent des contributeurs de toutes les parties du monde.

    De cette contradiction apparente nous avons développé des pratiques dont l’adoption nous semble être une bonne approche pour développer une organisation agile à grande échelle.

    Pour ceux qui ont participé aux sessions que j’avais eu le plaisir de donner au Scrumday ou à Mix-IT, le contenu est bien sur très différents puisqu’il n’était pas nécessaire d’expliquer le fonctionnement du projet Openstack.

    La vidéo de l’intervention :

     

    La photographie d’illustration de l’article est de Cédric Soulas.

  • Kanban pour l’IT

    Il y a presque 2 ans, j’avais écrit un petit article pour annoncer l’arrivée du livre Kanban pour l’IT de Laurent Morisseau.

    Je viens de recevoir la deuxième édition de l’ouvrage (merci @lmorisseau).

    Première impression ?

    Le livre est 2 fois plus gros !

    L’explication de l’auteur est simple, la première édition était pour les coachs, la deuxième édition se veut plus accessible pour tous les membres des équipes.

    En feuilletant l’ouvrage, j’ai découvert des chapitres complètement nouveaux concernant l’extension du kanban à d’autres domaines que le développement logiciel.

    Je remarque aussi plus d’illustrations et je savoure la préface de Claude Aubry (@claudeaubry).

    Bravo !

    A lire donc !

     

     

  • Développer des produits avec des équipes distribuées

    Après la conférence que j’ai donné le 10 avril pour le ScrumDay, je suis en train de préparer celle que je donnerais lors de Mix-IT le 30 avril 2014.

    Le résumé de la session est assez similaire entre les deux, voici celui du ScrumDay :

    De nos jours, presque tout le monde sait faire grandir une infrastructure de machines en mode distribué, avec une très bonnes communication entre elles, et en évitant les points uniques de défaillance (c’est une traduction de SPOF, single point of failure). En y réfléchissant, des serveurs distribués à travers le monde ne sont pas si différents que des équipes distribuées, elles ont besoin de connexion et de synchronisation…

    Vraiment ?

    Nous sommes des humains … pas des machines …

    Dans cette session, nous allons voir comment eNovance, une société qui conçoit des produits destinés à bâtir des infrastructures informatiques, d’ou le pitch initial… Nous allons donc voir comment eNovance a fait grandir son équipe de développement produits en mode distribué en suivant les valeurs et principes Agile. Cette session expliquera comment nous nous appuyons sur nos Product Owner pour guider nos contributions à des logiciels libres constitutifs de nos produits. Nous verrons par exemple comment nous planifions nos itérations en suivant le rythme donné par le projet Openstack. Nous verrons également comment nous organisons nos scrums, sprint planning, sprint review et retrospectives en nous adaptant à des équipiers positionnés sur différents fuseaux horaires.

    La session présentera le mode de fonctionnement d’un projet open source emblématique : Openstack. Ainsi que la façon de contribuer de l’équipe eNovance.

    La différence entre les sessions va se jouer sur plusieurs aspects :

    • l’expérience acquise par la première présentation,
    • les retours et les questions des participants,
    • les questions posées par un des organisateurs de Mix-IT qui vont orienter la présentation sur des aspects différents.

    Franck Depierre, l’organisateur qui a posé ces questions stimulantes, m’a demandé de préciser certains points. Les questions sont en gras :

    • Pourquoi faudrait-il avoir toutes les équipes distribuées qui travaillent ensemble ?
      Ce sont les membres des équipes qui sont distribués à travers le monde. Pour une équipe qui développe un produit, les équipiers sont répartis entre les bureaux de Bangalore, Paris, Montreal et San Francisco, de plus certains équipiers travaillent de chez eux (Hambourg, Dallas, San Francisco, New-York, Bordeaux, Toulouse…). Les équipes sont composées de personnes ayant les compétences nécessaires pour développer le produit, leur localisation n’est pas un critère de choix.
    • N’est-il pas plus simple de faire l’intégration sans avoir de communication entre équipe ?
      Nous préférons une approche ou l’équipe livre un produit déployable. Les produits sont modulaires et combinables entre eux : une infrastructure cloud de base peut être associée à l’usine de développement logiciel par exemple.
    • A qui est destiné cette session ?
      A des agents de changement dans l’organisation, à ceux qui, dans le flux de développement d’un produit, s’intéresse à faire évoluer l’organisation de leurs équipes.
    • On a l’impression que tout est bien dans le meilleur des mondes. Quels sont les freins, les problèmes qu’il faut identifier ? Est-ce uniquement un pb de product owner ? Ne pourrais-tu pas donner des recommendations pour tout les profils de l’organisation ?
      Tout est encore loin d’être bien dans le meilleur des mondes… La distance créée de nombreux problèmes que nous n’aurions pas avec une équipe colocalisée et des communications face à face (on s’en doute)… Je compte évidement aborder ces difficultés et les solutions que nous avons identifiées pour l’instant.
    • Est-ce qu’un coach ou facilitateur aide à ce mode de travail ? Si oui, est-ce que le coach doit être unique et intervenir sur tous les sites ? Est-ce qu’il faut monter une équipe de coaches ? Quelles sont les réunions à mettre en place ? Sur quel cycle répétitif, basé sur Scrum ?
      C’est mon role dans l’organisation. Nous formons progressivement une équipe de personnes intéressées qui diffusent dans leurs équipes la culture agile et open source de l’entreprise. Et oui, avec une approche itérative 🙂
    • Comment justifier que les équipes distribuées sont plus viables que les colocalisées ?
      Les équipes distribuées permettent de regrouper des personnes compétentes sur un produit sans avoir besoin de leur imposer une localisation… Dans l’idéal, je préférerais que toutes les personnes puissent travailler dans la même pièce.

    Il me reste une semaine pour revoir la session afin de maximiser la valeur des messages à transmettre ! Vous pouvez également me poser des questions via Twitter, en commentaire de ce billet ou par mail pour que je les prenne en compte dans ma préparation.

    Pour en savoir plus sur cette édition de Mix-IT 2014, consultez les actualités et particulièrement les articles présentant le programme.

     

    [modification du 15 novembre : la vidéo de la session de Mix-IT vient d’être publiée http://www.infoq.com/fr/presentations/produits-avec-equipes-distribuees]

  • Cargo Cult

    Cargo Culte est une chanson de Serge Gainsbourg que je vous propose d’écouter en fond sonore de cet article.

    Le Culte du Cargo est un ensemble de rite pratiqué dans les iles de Mélanésie visant à imiter les pratiques des colons occidentaux en espérant les mêmes effets. Par exemple, construire des avions en bois, des tours de contrôle, des opérateurs radios pour espérer recevoir du ravitaillement par avion comme cela se passait lorsque des militaires occupaient le lieu durant la seconde guerre mondiale.

    La question se pose alors, ne sommes-nous pas nous même conduits à reproduire par mimétisme des pratiques vues ailleurs en espérant les mêmes effets… sans vraiment comprendre le sens de ces pratiques.

    La référence au culte du cargo reparait régulièrement lors de l’introduction des méthodes agiles dans les organisations. Il faut dire que certains reproduisent les cérémonies : daily scrum, sprint planning, revue… sans en avoir compris leur utilité…

    Voir également, le discours de Feynman Cargo Cult Science mettant en garde contre la science approximative.

  • Coaching Agile

    title_pageCoaching Agile, le livre de référence de Rachel Davies et Liz Sedley est enfin traduit en français grace à Fabrice Aimetti.

    Fabrice est connu pour ses nombreuses traductions d’articles et d’ouvrages traitant du coaching, des méthodes agiles, du lean et plus généralement de ce qui touche aux organisations et aux personnes.

    Coaching Agile présente les outils vous permettant de vous développer et de développer votre équipe.

    Le livre comporte des sections spécifiques dédiés au développement logiciel, même si les autres aspects abordés peuvent s’appliquer à des équipes en général.

    Coaching Agile est disponible sur Leanpub.com en version numérique et sur Lulu.com en version papier.

  • Pédagogie agile

    Une petite note pour présenter en une vidéo et un lien, l’approche de pédagogie agile proposée par Christian den Hartigh.

    Vous pouvez lire les articles de son blog ici : http://pedagogieagile.com/
    Vous découvrirez ainsi comment il met en oeuvre un kanban avec ses élèves, alterne l’apprentissage individuel et l’apprentissage en groupe, et bien d’autres choses…

    Agile et Kanban from christiandh on Vimeo.

    Christian était en visite ces deux derniers jours chez eNovance… Et je suis impatient de constater l’impact qu’aura eu cette visite autant pour lui que pour les personnes d’eNovance !

  • Chief Agility Officer

    Des entreprises Agiles ?

    Salesforce.com a été fondée en 1999. Elle est introduite en bourse en 2004 et lève plus de 100 millions de dollars. Ce premier épisode peut être considéré comme un très beau parcours. En 2007, Salesforce.com est positionnée comme «leader» sur le quadrant magique de Gartner de son domaine et toujours en 3ème position du classement Forbes des entreprises en forte croissance. Toujours un succès donc…
    Reprenons le film de ces 8 premières années vu de l’intérieur. Il y avait initialement 3 personnes à la R&D et 4 versions majeures par an. 7 ans plus tard, plus de 200 personnes à la R&D, plus qu’une seule version majeure par an, et le nombre de fonctionnalités délivrées par équipe décroit. Les principales causes sont un manque de visibilité par tous les acteurs à toutes les étapes du processus, des feedbacks tardifs à la fin du cycle de livraison. Le cycle de version est de plus en plus long et imprévisible. La productivité par équipe décroit au fur et à mesure que les équipes grandissent.
    La situation en cette fin d’année 2006 est critique. La décision est prise de mener une transformation radicale vers l’agilité. Cette transformation se fera sur les premiers mois de 2007 et conduira à un renversement complet de la tendance avec 60 fonctionnalités critiques délivrées dans le 9 premiers mois de l’année.
    L’organisation et les méthodes mises en oeuvre prennent racines dans les valeurs et principes des méthodes agiles.
    Ce que l’on retire de l’histoire de Salesforce.com, c’est que même avec une idée excellente sur un très bon marché, le destin d’une startup, innovante et rapide au départ, peut l’amener à devenir une organisation sclérosée, incapable d’innover et de délivrer à court terme.
    Spotify est une autre illustration de l’apport de l’agilité à la croissance d’une entreprise. Spotify a doublé son nombre de clients en passant de 3 millions à 6 millions au cours des 12 derniers mois. Ils ont également doublé le nombre d’utilisateurs de leur service en passant de 15 millions à 30 millions sur la même période. Avec une équipe actuelle de 300 développeurs, ils peuvent continuer de faire grandir leur base de client et relever de nouveaux challenges, comme : «doubler le nombre de fonctionnalités offertes aux utilisateurs cette année».
    L’étude du BCG «transactions en confiance» a montré que plus de 60% des coûts ajoutés par les entreprises et leurs clients sont des coûts de transaction… des coûts qui disparaitraient si l’on travaillait seul… ou qui sont considérablement réduits lorsque l’on s’attache à revoir les modèles d’organisation produisant ces coûts. Cela peut-être une première base pour évaluer les bénéfices de la mise en oeuvre de l’agilité, en se donnant comme objectif de réduire ces gaspillages qui représentent 6 personnes sur 10 dans les organisations classiques.
    Mais le bénéfice induit par un mode d’organisation permettant l’expression des talents de l’entreprise est bien plus important en terme de fidélité, de réactivité, de créativité et d’innovation. Les entreprises de ce type étant tellement plus performantes (x100) que leurs concurrentes sur le long terme (comme NovoNordisk comparée à Lilly ou Pfizer, Canon comparée à Xerox ou Kodak).

    eNovance

    eNovance est positionnée sur un marché en pleine mutation. Tous les voyants sont au vert pour que l’entreprise devienne un leader international, en conservant sa capacité à délivrer rapidement ainsi que sa capacité à pivoter en anticipant les évolutions du marché.
    eNovance dispose aujourd’hui d’atouts considérables pour réussir dans cette voie. Les premiers d’entre eux sont la maîtrise et l’autonomie des personnes présentes. L’autre atout est l’existence d’un but plus élevée que l’entreprise elle-même : le logiciel libre (vous reconnaitrez ici les Autonomy, Mastery, Purpose proposé par Daniel Pink dans Drive ou dans son TED talk)
    Ces 3 éléments combinés entre eux constituent un formidable moteur de motivation pour les personnes.

    Agile

    Introduire l’agilité à tous les niveaux de l’organisation permettra de construire une entreprise en capacité de répondre rapidement au changement, de s’adapter en continu, de délivrer rapidement de la valeur à ses clients.
    En étant Agile, eNovance sera en capacité de proposer à ses clients des produits et des services agiles, et les accompagner dans leur transformation d’organisation.
    C’est pour créer et nourrir cette culture de l’agilité dans toute l’organisation que j’ai rejoins eNovance en tant que :

    Chief Agility Officer

    Un agiliste positionné au « C-Level » d’une entreprise ?

    Ce n’est qu’appliquer une des recommandations qu’a émise l’un des signataires du manifeste agile, Jim Highsmith : « Where an organisation has a strategic goal of business agility, such as Google, then Agile practices need to become part of the organisational DNA.  He [Jim Highsmith] recommends the creation of a senior role of “Chief Agility Officer” tasked with creating and nurturing an Agile culture that pervades the whole organization. «  from the article of  Shane Hastie . Jim Highsmith is one of the original writer of the Agile Manifesto.)

    Le Chief Agility Officer agit avec chaque personne pour développer une organisation favorisant l’autonomie, la responsabilité, la collaboration, l’amélioration continue et le développement des talents.

    Et ainsi avec des eNovancers heureux, construire le Netflix ou le Spotify du Cloud 🙂

     

     

     

    La photographie d’illustration est de violetagk

  • The Agilists à l’AgileTour Bordeaux

    2013-11-08 15.31.19Nous avons eu la grande joie, Bruno Sbille et moi-même, de donner une nouvelle session de « The Agilists » lors de l’édition 2013 de l’AgileTour Bordeaux qui s’est déroulée le 8 novembre.

    J’ai particulièrement apprécié l’accueil qui nous a été réservé dans l’amphi comble de l’Epitech ! Un grand merci pour vos applaudissements lors de chacune des 5 scènes que nous avons jouées devant vous !

    Je publie ci-contre la photo du feedback wall… C’est la seule que j’ai vu ce jour là sortir de l’échelle… Et cela fait vraiment plaisir de réussir à passer le message 🙂

    Et un autre grand merci pour les tweets très sympathiques lors de la session !

     

    Le support que nous avons utilisé pour cette session est intégré ci-dessous.