Agile France 2012

Vous rêvez de rejoindre les geeks rétro-hypes amoureux des éditeurs de texte du siècle dernier ? Les codeurs hard-core qui peuvent programmer n'importe quoi dans un émulateur VT100 ? Les experts clean-cut qui savent débattre des heures durant des vertus comparées d'Emacs et de vi - tout en restant intéressants ? Vous en avez marre de vous sentir intimidé/e par les commandes shell obscures et les raccourcis claviers ? Cette session pourrait bien être pour vous.

Vous avez toujours voulu apprendre à vous servir de vi pour de vrai, de manière accélérée, et d'effectivement vous rappeler les commandes que vous apprenez ? Cette session est assurément pour vous.

Nous expérimenterons une manière d'enseigner et d'apprendre vi (et en fait, n'importe quel autre outil informatique) à travers un processus d'apprentissage accéléré inspiré des pratiques de la "Chasse au Langage" (Language Hunting) - "un model d'apprentissage agressif et adaptable de jeux collaboratifs permettant à tous et de tous âges d'étendre leur curiosité culturelle, d'approfondir l'apprentissage autonome, de développer des talents de mentoring, tout en parlant de plus en plus couramment des langues étrangères." (http://www.languagehunters.org/)

Vous avez dit Selenium ? L'outil qui permet d'automatiser les tests fonctionnels ? Multi-langage ? Multi-plateforme ? Et vraiment intéressant pour garantir la qualité de votre projet tout au long de sa réalisation ?
Oui, il s'agit bien de l'outil multi-tâches que l'on gagne à connaître dans un monde Agile où la qualité de votre application ne peut pas être négligée.

Mais jusqu'à quel niveau avez-vous utilisé l'outil ? Avez-vous industrialisé durablement et efficacement vos tests avec et ce, à moindre coût ? Par cette présentation, découvrez ou plutôt re-découvrez Selenium qui, avec toutes ses facettes, pourra vous amener beaucoup plus loin que vous ne le pensiez.

Notre expérience de coaching agile sur un projet impliquant plus de cent personnes nous a permis d'identifier que la polycompétence est un facteur clé de succès à cette échelle.
Nous avons donc travaillé avec les équipes Scrum pour lever les principaux freins à la polycompétence et mieux expliciter son fonctionnement.
Cette session partage avec vous les fruits de ce travail.

Objectifs et bénéfices de la session pour les participants
Comprendre les enjeux de la polycompétence dans une équipe Scrum et pourquoi c'est un facteur clé de succès dans un projet de transformation Agile à grande échelle. Reconnaître les freins usuels et trouver des pistes pour les lever.

“You can’t control what you can’t measure.” Cette citation célèbre de Tom DeMarco souligne toujours l'urgence dans nos projets informatiques de répondre aux questions : quand ? pour quel prix ? avec quelle qualité ?

Ces questions correspondent aux enjeux auxquels sont soumises les DSI aujourd'hui : réduire les couts, créer de la valeur, gagner du temps, maitriser les risques. En fait, la question des métriques en informatique est aussi vieille que le domaine et cela fait plus de 30 ans, face à la "crise du logiciel", que le sujet agite les professionnels.

Dans la vie de tout les jours, la situation est contrastée : les "KPIs" sont à la mode, mais les études montrent pourtant que les métriques sont parmi les outils les moins utilisés. Est-ce parce que les données récoltées sont trop souvent d'une utilité limitée ou trop coûteuses à obtenir ?

A travers cette session, nous nous intéressons aux métriques et kpis utilisés dans les autres DSI ? Comment mesurer la qualité ou la performance ? Quid de la satisfaction de vos utilisateurs ou de vos équipes ? Plus largement, que change la progression des approches lean, agile ou lean startup ? Est-ce vraiment si important de mesurer pour contrôler ? On a montré dans d'autres domaines scientifiques, depuis Heisenberg en physique quantique ou l'effet Hawthorne en psychologie sociale, comment l'observation pouvait affecter le comportement du sujet observé : qu'en est-il dans nos DSI ? Et que se passerait-il si toutes ces données étaient publiques ?

Vous pratiquez l’agilité et vous êtes fiers de votre tableau de postIT qui trône dans un coin du bureau.
C’est bien, mais il y a tableau et Tableau !
Êtes-vous certain que le votre est beau, si si c’est important, et plus encore, vous permet-il de visualiser rapidement l’état de votre projet et ses dysfonctionnements ?
Je vous propose un atelier en 2 itérations pour créer de beaux et utiles tableaux en équipe, saurez-vous relever ce challenge ?

Dans l’IT, on rencontre des directrices, des manageures, des conceptrices, des ergonomes, des responsables produit : oui, les femmes font partie intégrantes des équipes IT. Pourtant une catégorie se fait rare : les développeuses.
Pourtant, en tant que coach agile, il m’a semblé que les équipes mixtes étaient plus performantes. Est-ce une intuition justifiée ou une vue de l’esprit ?
J'ai décidé de creuser le sujet, par des interviews, des recherches personnelles, dans et hors du domaine informatique. Et j’ai aussi commis pas mal de gaffes, car le sujet passionne mais est pollué de stéréotypes très "collants". A présent, je suis convaincu que, pour qu’on avance, ce sujet mérite un traitement neutre et précis : c’est ce que je vais essayer de vous proposer.

Je résume cette recherche en deux questions :
- pourquoi y’a-t-il si peu de développeuses ?
- est-il intéressant pour votre équipe d’y remédier ?

Le backlog peut-il être public? Comment obtenir un feedback d'un grand nombre d'utilisateurs? Faut-il utiliser un issue tracker? un story tracker? Une session pour les Product Owner d'un produit public, d'un site internet, d'une application mobile.

« Bonjour, nous sommes déjà agiles depuis 2 ans, nous livrons tous les mois en production, mes clients sont contents, mon sponsor épanoui, mon équipe est soudée et je souhaite plus d’agilité. 15 jours de coaching devraient suffire, non ? ». Comment répondre à ce challenge peu fréquent ? Au cours de cette session, fruit d’un retour d’expérience au sein d’une grande banque d’investissement, le client et le coach décriront leurs points de vue respectifs, les pièges à éviter et les enseignements qu’il faut tirer de la « kanbanisation » d’une équipe (en partie offshorisée) de plus de 20 personnes sur un projet critique. Décidemment, améliorer ce qui marche est parfois bien plus délicat que de "sauver" des projets à la dérive. Surtout dans les esprits !

"I release early and often".
Voici comment s'exprime le hacker Eric Raymond lorsqu'il retrace son expérience de développeur d'un logiciel open-source (Eric Raymond, The Cathedral and the Bazaard).
"Deliver working software frequently ..." c'est aussi un des principes qui découle du manifeste Agile.

Ces propos concordent. Est-ce une simple coÏncidence ? Ou il y a-t-il des liens entre les communautés Agile et Open Source ?
Je vous propose dans un premier temps d'explorer les analogies entre les principes et les pratiques des Hackers et ceux des Agilistes: l'essai d'Eric Raymond propose un aperçu des pratiques à l'oeuvre lors de la construction de produits tels que Linux et Fetchmail, c'est un point de départ pour notre exploration.

Mais les Agilistes composent également avec des valeurs. Et Pekka Himanen dans son livre "The Hacker Ethic" s'est penché sur les valeurs qui animent les Hackers. Après avoir présenté ce livre, je vous propose que nous mettions en regard les valeurs des Agilistes et celles des Hackers.

La qualité de l'expérience utilisateur est un enjeu majeur pour les éditeurs : comment intégrer UX et Agile pour la meilleure synergie ?

L’exigence d’une qualité d’expérience utilisateur s’étend désormais des services internet et mobile à l’ensemble de notre environnement de travail. Ainsi, les éditeurs de logiciels doivent maintenant dépasser la complexité technologique de leurs produits pour proposer à leurs clients des services à valeur ajoutée faciles d’utilisation. Fort d’une solide expérience dans le développement de ses produits en mode agile (équipes de développement distribuées dans 4 pays), Axway intègre l’expérience utilisateur depuis plus de 2 ans dans les différentes phases de définition et de conception de ses produits. Respectivement responsable User Experience (Sophie Pilverdier) et Product Manager(Arnaud Bedel) chez Axway, nous vous proposons au travers de nos retours d’expérience, de partager les bonnes et mauvaises pratiques ainsi que les bénéfices et challenges pour une synergie Agile-UX.

La méthode Scrum est conçue pour organiser un travail d’équipe (de 2 à 7 personne environ). Qu’en est-il sur un projet avec un développeur unique ? Qu’en reste-t-il ? Est-ce toujours pertinent ? Je vous propose de vous présenter un retour d’expérience de l’application de Scrum sur un projet de développement en java ou je suis intervenu "en solo". Je peux supposer que cette pratique pourrait tendre à se développer avec la multiplication des applications pour mobile qui ne réclame pas l’intervention d’une équipe.
Cette présentation sera l'occasion d'insister une fois de plus sur le fait que "l'équipe" ne se limite pas à une population de développeur.

Cette présentation a déjà été jouée une fois (en version réduite sous la forme d'un Quicky) à Scrum Day 2012

Comment introduire les pratiques agiles dans vos équipes de développement ? Comment gérer le changement ? Comment quitter sa zone de confort ? Je vous présenterais les valeurs sur lesquelles je me repose, les pratiques que j'utilise et les risques nécessaires pour devenir un manager qui fait grandir ses équipes.

Parfois anticipé, souvent évité mais toujours redouté, le mur s'immisce dans vos projets là où vous ne l'attendiez pas. Un changement d'organisation à opérer ? Une nouvelle fonctionnalité à mettre en place ? Ou bien, un nouvel outil à utiliser ? Qu'importe sa forme initiale, le mur peut survenir dans vos projets (surtout lors d'une transition Agile) en prenant la forme de l'échec.
Souvent difficile à vivre, parfois néfaste pour un projet, le mur possède donc une bien mauvaise réputation qui n'est pourtant pas toujours justifiée...

Je vous propose donc, à travers divers exemples de coaching Agile, une vision différente de ce mur, à qui je vais tenter de redonner ses lettres de noblesse !

Ken Schwaber : "I estimate that 75% of these organizations using Scrum will not succeed in getting the benefits that they hope for from it".

Les participants sont invités à soumettre des propositions de retours d'expérience.
Le public priorise les propositions qui seront traitées dans l'ordre, dans la limite du temps fixé.

Le porteur du retour d'expérience décrit dans une phase timeboxée le contexte et les problèmes rencontrés.

Tous les participants peuvent l'interroger pour approfondir et analyser (dans une phase timeboxée).

Une synthèse est effectuée en fonction de différents critères : problème de contexte, de valeurs, de méthode, de manque de formation, de personne...(dans une phase timeboxée)

Des pistes d'améliorations sont proposées par les participants. (dans une phase timeboxée)

Le porteur du retour d'expérience donne son feedback sur les pistes proposées. (dans une phase timeboxée)

On passe au retour d'expérience suivant en suivant le même canevas.

Pas de solution toute faite, mais un cadre de réflexion collective sur les leçons à tirer des échecs. Objectif : s'améliorer !

Une découpe fine ("carpaccio") en user stories est idéale pour un projet agile (ou même un project non-agile comme le mien): on voit le progrès, il est facile de changer de direction, la complexité reste faible.

Mais avant de commencer à découper, il faut trouver et préparer le "filet de boeuf".

Cet atélier vous permet d'expérimenter avec deux anciennes techniques (qui marchent toujours) qui vous permettent de découper graduellement un grand problème dans des petites stories:
* le diagramme de contexte
* la tables des evènements

Dans l'atelier vous travaillerez en petits groupes sur des problèmes que j'apporte. J'explique une technique; vous l'appliquez; vous en tirez vos conclusions.

Atélier limité à 30 participants

Un REX de ma mission actuelle, au sein d'une équipe chargée de gérer, de faire évoluer et d'administrer l'usine logicielle (avec maven, intégration continue, qualité de code et tout le toutim) d'une grande banque.
Dans un premier temps je disserterai sur l'intérêt d'une telle équipe :
Pourquoi la présence d'une équipe "UL" ? Pourquoi imposer et encadrer au lieu de laisser les MOE "s'autogérer" ?
Dans un deuxieme temps je disserterai sur la gestion agile d'une telle équipe :
Pourquoi l'agilité ? Les écueils à y appliquer Scrum, et la mise en place (réussie) de Kanban.

Je me baserai sur les deux articles que j'ai posté sur le blog Valtech.

Ce présentateur ne s'est pas présenté à la conférence ...

Aujourd’hui, alors que le marché ne parle plus que d’industrialisation, la réalité des équipes de développement ne s’est pas éloignée de l’artisanat. Pendant des années, de nombreux éditeurs de logiciel se sont escrimés sur le sujet, proposant des méthodes très riches, systémiques, souvent inutilisables sans mettre en œuvre des outils si complexes qu’un individu normalement constitué ne pouvait les appréhender. Si complexes qu’après être utilisés en début de projet, au prix d’efforts extrêmes, ils étaient rapidement mis au placard.

Nous avons tous en tête quelques projets qui ont pris un mauvais tournant. Ces projets sont riches d’enseignement, mais souvent délaissés : on préfère enterrer les problèmes plutôt que de les disséquer.

Si une méthode garantissait le succès d’un projet, cela se saurait. Les intégristes de la méthode, s’ils existent encore, sont en voie de disparition. Lorsque toute l’énergie de l’équipe se focalise sur le respect aveugle d’une méthode, le risque que la cible initiale (réussir le projet) se déplace loin des exigences du terrain est très fort. La méthode doit rester un support au projet, un accélérateur structurant, un guide de formateur, un outil pour capitaliser les bonnes pratiques, la bonne méthode est celle qui est tellement en osmose avec le quotidien des équipes, croire qu’une équipe peur réussir à mettre en pratique une méthode sans le support d’outils relève de l’utopie. Mais croire qu’une méthode va réussir parce qu’on a mise en place des outils dont l’objectif principal est de mettre en œuvre une méthode l’est tout autant.

Pour conclure la réflexion, la confusion la plus importante serait de croire qu’un bon mixte Outils-Méthodes suffit pour s’affranchir de tout problème. Le premier facteur clé de succès d’un projet, ce sont les hommes. Penser que les référentiels d’amélioration des processus, les méthodes et les outils favorisent une industrialisation capable de réduire les individus à des simples pions facilement remplaçables et externalisables serait une grave erreur.

Au contraire. Méthodes et outils doivent permettre aux individus d’exprimer pleinement leur potentiel en réduisant et en automatisant les tâches à faible valeur ajoutée, en fournissant un support transverse de collaboration et de workflow et des gains de productivité. C’est la somme des potentiels individuels, bien coordonnés, qui garantit le succès final du projet.

Nous vous proposons un retour d'éxpérience sur l'initiation d'une transition agile à grande échelle, dans un domaine d'une centaine de personnes dans le monde de la Finance.
Nous vous explirerons par où nous avons commencé, les pratiques mises en place, les difficultés rencontrées et les solutions mise en oeuvre pour accompagner le changement.
Ce retour d'expérience sera l'occasion d'exposer le point de vue du client et celui du coach.

Une part des difficultés rencontrées dans l’adoption des méthodes agiles est liée au rôle que joue le client, et aux relations qu’il noue avec l’équipe de développement.
Pourtant sa participation à la réalisation de son produit est l’un des facteurs clés de réussite du projet.

Pour le client, ou son représentant, passer d’un fonctionnement classique à un mode agile n’est pas seulement une nouvelle façon de travailler, avec de nouveaux outils…
Il s’agit surtout d’un changement profond dans son rôle, dans ses relations, dans sa vision des choses.
C’est un changement de paradigme.
Qui demande une certaine ouverture d’esprit, une certaine remise en question, et donc du courage.

Quel est le chemin à parcourir ?
Quelles sont les aides sur lesquelles s’appuyer ?

Mettre en place de l'agilité sur un projet complexe, dans un environnement industriel, avec un délai court (5 mois) et basé sur une solution du marché, c'est déjà en soi un challenge. Mais lorsqu'on cherche un peu de retours d'expériences sur le sujet et que l'on n'en trouve pas, on se dit qu'on est peut-être un peu fou, un peu rêveur ou complètement à côté de la plaque.

Nous souhaitons donc vous donner, en avant-première mondiale, nos feedbacks sur la construction d'un PLM (Product Lifecycle Management) en mode agile :

* comment livrer de manière incrémentale un produit basé sur une solution déjà présente ?
* comment impliquer des acteurs du monde industriel dans la définition et les tests d'un produit logiciel ?

Nous vous présenterons les bénéfices constatés et les difficultés rencontrées dans la mise en place de ce processus, quelles impasses nous avons faites et ce que nous avons appris.

Au delà de NUnit, la plateforme .Net offre de nombreux outils pour tester les applications, avec une palette d'outils aussi large que riche.

Durant cette session, nous aborderons par exemple :
Comment booster vos tests unitaires avec des outils comme Pex et Moles
Comment mettre en place des spécifications exécutables avec Expect
Comment tirer parti efficacement des tests d'IHM sur des applications web avec WatiN

Vous aussi, vous en avez assez du Planning Poker, qui dure un temps infini ?

Venez tester un nouveau format de réunion d'estimation.

En moyenne, 90 stories en moins de 20 minutes, reproduit plusieurs fois sur plusieurs équipes. Avec un niveau de confiance aussi élevé que pour le Planning Poker.

Courage et Communication : Restons critique, mais ouvert d'esprit !

Session ludique de combat (dojo, battle) : Deux équipes s'affrontent pour ou contre l'agilité, elles argumentent. Le public vote.

8 joueurs minimum répartis en 2 camps (volontariat ou tirage au sort) : pour ou contre l'agile, mais avec un praticien agile dans chaque camp - Le reste du public a droit de vote -

Animateurs
- juge Ti (*) : impartial et irréfutable rôle : limite le temps de parole de chaque équipe comptabilise les voix, inscrit les scores
- animateur : explique les règles, assiste les équipes, demande le vote du public

Déroulement : n itérations de 5 minutes. Tirage au sort (toss). Une équipe démarre sur un sujet (attaque). 1 mn 30 d'argument maxi. L'autre équipe répond sur la même durée (défense). Le juge et le public peuvent apporter une argumentation complémentaire. Le public vote : quelle équipe s'est montrée la plus convaincante ? Deuxième round en inversant l'ordre. Après un nombre de rounds décidés initialement, l'une des deux équipes est désignée vainqueur.

Bénéfices pour les participants
Oser affronter la critique, les mythes, le non-dit. Dépasser le stade des croyances. Partager du feedback. Progresser par le débat. Forme ludique d'appropriation de l'agilité dans une entreprise où un groupe a déjà expérimenté l'agilité sur un projet et peut "jouer" contre une équipe de débutants qui arrive avec ses idées reçues, ses peurs... Outil de conduite du changement et d'essaimage de culture agile.

Tout le monde a fait cette expérience. Confortablement assis dans un salon de coiffure, votre coiffeur vous demande si la température vous convient. Simple question, simple réponse. L'ajustement de l'action est immédiate : tourner le robinet d'eau chaude à gauche ou à droite…

Pourquoi ce qu'un coiffeur fait facilement tous les jours, un manager dans une entreprise serait incapable de le faire ? Est-ce si difficile ?

Agir sans vérifier les résultats de son action est pourtant souvent inefficace et parfois même dangereux.

Manager depuis 10 ans dans le développement logiciel, je souhaite parler du feed-back dans le management et comment mettre concrètement en place cette culture au sein de l'entreprise.

Le management carotte/bâton ne fonctionne pas ! Il est nécessaire de laisser plus d'autonomie aux salariés et cela n'est possible qu'avec la sécurité qu'apporte le feed-back.

L'objectif de cette session est de vous permettre d'améliorer la dynamique de votre équipe agile.

Nous sommes persuadés qu'une bonne dynamique est la clé de la performance d'une équipe, et qu'il existe des outils pour l'améliorer. Echanges d'information pertinents, analyses de problèmes, prises de décision, recul, auto-discipline : ces quelques éléments deviennent critiques lorsque votre projet entre dans la tourmente.

Au cours de cette session, nous vous raconterons l'histoire -vécue- d'un gros projet en situation critique qui a dû effectuer en urgence un virage vers l'agile. Plus précisément, c'est l'histoire de ces équipiers et de leur collaboration que nous vous raconterons, comment ils sont passées d'un fonctionnement issu d'une culture hiérarchique à un fonctionnement basé sur l'autonomie et la responsabilité partagée, alors que la pression d'une situation critique se faisait sentir. Comment ils sont devenus une force formidable pour le projet et ont attaqués un par un les problèmes qui les freinaient.

Vous prendrons le temps de détailler plusieurs outils issus du coaching d'équipe que nous avons utilisés -debriefing, rôles délégués-, quand et comment les mettre en oeuvre, et les résultats qu'ils ont apportés. Nous espérons que vous pourrez par la suite les appliquer dans vos équipes avec les résultats aussi probants que ce que nous avons observé.

On entend très souvent dans les couloirs des entreprises: "L'agilité c'est une méthode de développement utilisée par les développeurs"…
Une phrase dangereuse et aggressive.
L'agilité présente plus de similitudes avec une culture qu'avec une méthode ou une technique. Devenir agile, signifie donc beaucoup plus qu'adopter un nouveau processus de développement. Il s'agit d'un changement culturel important qui implique toute l'entreprise. Afin de réussir cette transformation, il est nécessaire que ces principes soient compris, assimilés et supportés par les managers.
Je vous invite à faire un voyage dans l'univers du manager, issu d'une culture d'entreprise traditionnelle, un peu autoritaire, qui fait difficilement confiance, parfois même un peu paranoïaque… Analysons un peu son comportement afin de mieux comprendre les notions qu'il est nécessaire de lui transmettre et les points sur lesquels il faudra insister afin de s'assurer qu'il ne sera pas un frein à l'adoption de l'agilité mais en deviendra un des principaux moteurs.

Silverpeas est un produit créé en 1999 par une start-up qui a compté jusqu'à 40 développeurs. C'était l'époque bénie des Weblogic, Orion ... où on savait coder avec UltraEdit et sans tests des EJBs BMP. Peut on continuer à faire évoluer un tel code ? Comment fait on pour continuer à faire vivre ce produit 10 ans après avec une équipe de 5 développeurs ? Ne comptez pas entendre parler des derniers frameworks à la mode,il y aura du sang et de la sueur et Chuck Norris ne viendra pas vous sauver...
Un retour d'expérience les mains dans le cambouis jusqu'aux coudes pour vous montrer que rien n'est jamais perdu.
Un bon rappel aussi pour toutes les applications que vous développez, pensez que dans 10 ans il y en aura peut-être qui devront continuer à les faire évoluer ...

Nous avons essayé d'appliquer le manuel à la lettre : daily, démo/rétro, itérations courtes, post-its, product owner ... .
Mais tout n'a pas fonctionné comme sur des roulettes :
* manque de maîtrise / équipe débutante ?
* problème de Product Owner ?

Nous allons faire un retour d'expériences sur nos pratiques «agiles»
des années précédentes.
Énumérer ce qui a réussi, parler de ce qui n'a pas fonctionné.
Philosopher sur les dérives d'une généralisation agile.
L'agilité nous a permis de gagner des contrats, de démarrer plus vite mais
nous a-t-elle permis de réussir nos projets ?
Nous allons essayer de creuser pourquoi fait on les choses ?

Comment a démarré la transition agile? Combien de temps cela a duré? Quels outils avons-nous utilisés? Comment sommes-nous passé d'un modèle de "Cycle en V" à un processus itératif? Quels outils avons-nous utilisé pour réaliser des tests automatisés de non-régression, de volume et de performance? Comment avons-nous intégré à notre fonctionnement agile deux équipes de testeurs et de développeurs situé à l'autre bout du monde? C'est ce que je vous propose de découvrir lors de cette session!

Retour d'expérience sur la mise en place et les premiers effets d'une gestion de portefeuille de projets dans une entreprise à agilité variable

Dans une entreprise de taille moyenne qui foisonne de projets et dont les niveaux de maturité agile varient considérablement selon les équipes, à quoi sert et comment se vit au quotidien un portefeuille de projets ?
Plus que le simple backlog des projets de l'entreprise, il est tout à la fois le réceptacle des rêves, attentes et besoins, l'étendard de la vision stratégique et celui qui sans cesse ramène l'entreprise à la réalité de ses contraintes et de ses limites : de temps, de budget, de capacité, d'organisation....

Après une brève description du contexte, ce retour d'expérience parcourt le chemin ayant permis d'aboutir à un portfolio de projets en place et vivant : idées de départ, premières solutions imaginées, écueils rencontrés, ce qui n'a pas marché du tout, ce qui a bien marché, etc... Il présente le portfolio tel qu'il est aujourd'hui et les axes d'amélioration qui se dessinent après quelques mois de pratique

Diversité, Apprentissage, montée en compétences et partage de connaissance sont les clés de voute d’une Agilité, qui encourage toujours plus de Collaboration et de Feedback.
Le design d’interface de qualité est aujourd’hui un élément différenciant. Dans un contexte agile, cette activité va donner de la valeur, faire gagner du temps, booster la créativité et l’innovation. Entre opportunités et nécessité, elle sera néanmoins menée sans excès, au plus juste, avant tout dans un esprit collaboratif et Agile pour au final n’en être que plus riche !
Au programme :
• L’approche design studio au démarrage des projets agiles pour définir la posture ergonomique du produit, explorer des solutions, tester des hypothèse ou construire une dynamique d’équipe.
• Des workshops intermédiaires et "Backlog refinement" notamment pour construire et affiner les design d’interface en donnant du sens aux User Stories
• Les clés du sketching, paper prototyping ou d’outils simples comme Balsamiq

Retour d'expérience de la mise en oeuvre du contrat agile publié par Xebia et mis en open-source en Novembre dernier. Nous aborderons les REX suivants et les points qui changent pour chacun d'eux:
- Engagement à l'itération ou au global et indicateurs associés
- Equipe fournisseur dédiée ou équipe mixte client-fournisseur
- Product Owner côté client ou côté fournisseur
- Scrum Master côté client ou côté fournisseur

Nous terminerons par une synthèse des commentaires reçus jusqu'ici par les différents relecteurs.

Le binômage est une des pratiques pilier de l'eXtreme Programming. Adulée par les uns, décriées par les autres, il est de bon ton dans les discussions courtoises de la qualifier d'"utile, mais pas tout le temps". Nous allons dans cette session nous intéresser à tout ces autres moments, en creux, ceux où le développeur préfèrerait ne pas binômer et où par les circonstances les plus extraordinaires il s'est néanmoins vu attribuer la compagnie d'un collègue avec qui il doit partager son espace de travail et de réflexion. Par le biais de saynètes illustrant notre propos et dans un élan totalement anti-pédagogique, nous espérons montrer par le mauvais exemple comment efficacement tuer toute dynamique vertueuse de binômage, et par conséquent aider celui qui en a besoin à retrouver calme et solitude.

Et si l'agence tous risques utilisait Scrum? Vous ne vous êtes jamais posé la question? Tentons ensemble d'entrevoir ce que cela donnerait !
Sous pression et avec des impératifs, l'équipe légendaire va devoir mener a bien une mission pour le moins délicate, qui trouve de nombreuses similitudes avec nos projets d'entreprise.
A travers cet exemple riche en souvenirs et en humour, venez comprendre l'utilité de l'agilité au sein d'un projet sous contraintes qui doit se dérouler sans accros.

La définition d'une vision claire et partagée est un facteur clé de succès de la construction d'un produit. Mais comment obtient-on une vision claire, et surtout partagée ? Comment ne pas s'enliser dans des débats sans fin lorsque tout le monde y va de sa proposition ?

Le but de cet atelier est d'aider les participants à formaliser leur vision produit en présentant une démarche de brainstorming basée sur des ateliers ludiques.

Nous mettrons en pratique plusieurs techniques issues des innovation games et du gamestorming pour aboutir à une vision en un temps record et sans douleur. Les participants définiront leur vision d'un produit en utilisant les techniques telles que Cover Story, Context Map, Product Box, ou le bodystorming. Nous détaillerons au préalable les différentes étapes pour conduire ce type d'atelier -divergence, exploration, convergence - et les différents formats qui peuvent être utilisés.

FACILITER, cela consiste à aider un groupe, une ou des personnes, à apprendre, explorer, trouver des solutions, atteindre un consensus… Souvent négligée, la facilitation est pourtant une vraie discipline, désormais au cœur de nos activités en Entreprise.
C'est dans un mode Show & Tell et sous forme de pattern (Problème, contexte, solution) que je vous invite à découvrir ces petits outils & techniques de facilitation si simples mais terriblement efficaces au quotidien. Vos retours d’expérience sur les techniques présentées seront encouragées.
Vous connaissez tous le ROTI ou le Vote à 5 doigts, vous en découvrirez d'autres...

Vous voulez découvrir le Kanban par la pratique?
Vous voulez savoir combien de dollars vous allez gagner avec votre nouvelle start-up en 21 jours? Et si vous ferez-vous les bons choix d'injection, de sélection ou d'allocation pour établir le nouveau record?

Alors venez relever le challenge atelier Kanban avec quatre plateaux GetKanban et trois coachs (Laurent Morisseau, Dimitri Baeli et Guillaume Lours) pour vous accompagner!

Vous y découvrirez comment fonctionne un système kanban avec ses limites kanban, les classes de service et les cartes de contrôles avec cet atelier ludique.

L'atelier peut accueillir une vingtaine de participants.

Venez apprendre des techniques de développement agile dans cette session de 2 heures, dont le fil directeur est le développement d'une CoffeeMachine. C'est l'occasion idéale pour apprendre tout un tas d'astuce de développement tout en tentant de résoudre un exercice.

Après une introduction rapide aux techniques de développement agile vous serez soumis à des itérations de 20 minutes durant laquelle votre PO vous donnera une série d'instructions afin de programmer une CoffeMachine. Le tout sera encadré par Simon Caplette et Jean-Laurent de Morlhon qui vous aideront dans vos choix et décisions.

Votre design initial résistera t'il à la succession des itérations ? Vous pourrez utiliser le langage de programmation de votre choix.

Pour cette session, vous devez amener votre propre ordinateur portable.

Exercice de 90 minutes dont le but est de montrer (1) aux "clients" comment découper les besoins métier aussi finement que nécessaire pour tenir dans n'importe quelle taille d'itération ou de sprint, (2) aux développeurs comment les meilleurs développeurs travaillent aujourd’hui en décomposant leur effort en de très nombreux épisodes courts produisant du code entièrement fonctionnel, testé, visible par l'utilisateur final.
Cet exercice plutôt intense montre bien à la fois au côté métier et au côté développement comment travailler avec des incréments très fins tel que cela est pratiqué dans les contextes agiles actuels. A l’issue de cette session, les participants auront également appris un exercice leur permettant à leur tour de disséminer cette pratique dans leurs entreprises.
Il est nécessaire d’avoir au moins entre un tiers et la moitié des participants équipés d’un PC avec un IDE installé. N’importe quel environnement et langage de développement conviennent.
Cet exercice a été mis au point par Alistair Cockburn. Je l’ai présenté à Agile France 2011. Je l’ai utilisé plusieurs fois dans le cadre de coaching de projet agile.

L'évolution des sites internet et des applications depuis quelques années a mis un accent croissant sur l'utilisabilité et l'expérience utilisateur - qui aujourd'hui ne souhaite pas réaliser une application simple d'emploi pour ses utilisateurs ? Cependant, ceux qui se sont essayés à l'exercice sur des applications "grandeur nature" ont pu en mesurer l'extrême difficulté. Même dans un contexte agile, lorsque l'équip peut itérer et intégrer le feedback des utilisateur, comment prioriser au mieux les très nombreuses demandes d'évolutions ? Et comment organiser l'interface utilisateur de sorte qu'elle reste simple et accessible, itération après itération ?

Dans cet atelier, Régis Medina vous montrera comment le kaizen, l'approche rigoureuse de résolution de problèmes mise en oeuvre par les praticiens du lean, peut être utilisée pour piloter l'amélioration continue d'une application. Valeur, gaspillages, management de la performance, PDCA, "genchi genbutsu", réduction du lead time... vous découvrirez comment utiliser tous ces principes pour construire des applications qui enchantent vos utilisateurs !

En travaillant sur une application grand public existante, vous serez amenés à :
- définir la Voix du Client pour cette application
- concevoir des indicateurs de performance liés à l'utilisation du produit
- créer un "value stream map" du principal cas d'utilisation de l'application
- apprendre à identifier les 7 familles de gaspillages dans son utilisation
- structurer les évolutions dans des cycles PDCA

J'ai animé cette session à deux reprises (SPA 2011 + First European Lean IT Summit), elle a reçu d'excellents retours à chaque fois.

L'INSEE (institut national de la statistique et des études économiques) a un vaste système d'information développé et maintenu par environ 200 développeurs. L'INSEE a commencé à s'intéresser aux méthodes agiles il y a quelques années. Nous avons mis en place plusieurs pratiques agiles sur nos projets récents et nous avons mis en place SCRUM et de pratiques d'XP sur un projet pilote, la modernisation de la collecte du recensement (projet HOMERE).

Cette présentation est un retour d'expérience sur ce que nous avons mis en place et comportera 3 parties :
1: les pratiques agiles "de base" mises en places sur nos projets récents(mise en place de tests unitaires+d'une plate forme d'intégration continue+ découpage de la phase développement en itération de taille fixe)
2: retour d'expérience sur la mise en place d'une démarche test driven developpement
avec fitnesse sur un projet pilote (conj2).
3: retour d'expérience sur la mise en place de SCRUM et de pratiques d'XP sur le projet HOMERE.

Mener un projet Agile, c’est proposer un produit incrémental, itératif et adaptatif. Pour cela l’agilité nécessite un client impliqué, une communication exacerbée, un cadre de travail. Ces composantes n’apparaissent malheureusement pas de manière spontanée ! Il est nécessaire de préparer et de poser les bases du cadre de travail. La phase d’exploration adresse ce besoin, sur une durée variable adaptée au contexte du projet, elle permet de construire la relation et les bases de la communication qui concourent bien souvent à la réussite d’un projet agile. Cette phase adresse de nombreux sujets tels que : la montée en compétence fonctionnelle de l’équipe de réalisation, une meilleure compréhension technique pour le Product Owner, les voies de communications à envisager et promouvoir, l’outillage, l’organisation en temps contraint en posant les bases (durée et horaires), la définition des acteurs clés de la méthode, les rôles de chacun, les règles de fonctionnement, … Cette conférence présente comment gérer la phase exploratoire et apporte des retours d’expériences concrets sur des projets où elle a pu être mise en œuvre.

L'année passée je vous ai présenté l'outil "Conflict Resolution Diagram" (http://www.slideshare.net/agilecoachnet/conflict-resolution-diagram-tutorial-french) pour résoudre les conflits.

Maintenant, c'est votre tour!

Dans cet atélier nous allons appliquer l'outil CRD sur les conflits que vous amenez.

Si vous voulez participer dans cet atélier:
* Familiarisez-vous avec l'outil CRD. Regardez au moins la présentation
* Préparez un conflit (du type 1, 2 ou 3) dans un domaine qui touche aux sujets de la conférence. Ne remplissez que les 2 "conditions préaliables"
* Rejettez le compromis
* Soyez prêt à trouver une solution

Atélier limité à 20 participants.

Sur scène, les improvisateurs doivent faire vivre une histoire et garder le public réceptif, sans texte et sans préparation. On nous donne un thème, et en définissant un personnage, un lieu et une action, on est parti pour jouer avec quelqu'un d'autre qui a forcément une idée complètement différente. Comment y arriver ? Etre réactif ? Ne pas être trop brutal en imposant son idée, ne pas s'écraser complètement non plus ? En restant fidèle a des grands principes : Ecoute, Accepte, Percute, Anime, Construis, Joue le jeu, Innove, Amuse-toi, Ose ! Le tout au service d'une Histoire qui doit avoir du sens. Impensable si l'équipe n'est pas en confiance et soudée. Tiens, mais on dirait qu'on parle d'Agile...

Session limitée à 12 participants

On a beau dire que nous sommes tous différents et que nous voyons le monde à travers nos lunettes, nous sommes tout de même souvent certains d’avoir raison. Cette session va explorer le monde de nos perceptions au travers de la relation interpersonnelle. Au cours d'un atelier exigeant pour les participants, nous verrons comment nous pouvons parfois être sclérosé dans notre relation à l'autre. Or, sans relation il n'y a pas de communication efficace et sans communication pas d'agilité . Un atelier au delà des recettes agiles de cuisine pour commencer à saisir comment j'entre en relation avec l'autre pour m'améliorer. Session totalement repensée depuis l'AT Lille 2011.
30 personnes maximum.

Il y a quelques années de cela, je me suis mis au TDD. J'avance doucement dans la mise en oeuvre de cette discipline.. Je me heurte aujourd'hui à des questions et des situations face auxquelles je reste parfois littéralement bloqué...
Mon plus gros souci, c'est certainement de ne pas avoir de gourou du test unitaire avec moi, pour me montrer les bonnes pratiques et me permettre d'avancer. Il y a bien les blogs, les bouquins les vidéos de James Shore ou d'Eric Mignot, je n'ai malheureusement pas le temps de tout parcourir...

Si vous êtes comme moi, en quête de réponses pour vous permettre de franchir un palier dans la pratique du TDD ou l'écriture de tests unitaires, cette conférence est faite pour vous ! Cela requiert tout de même une (toute) petite expérience et n'aura pas pour but d'exposer les rudiments.
Si vous avez une expérience à partager sur ces sujets, cette session est également pour vous, car c'est VOUS qui allez nous permettre à tous de progresser ! Et peut être repartirez-vous en ayant aussi appris quelque chose...

En effet, c'est le format un peu particulier de cette session, où l'orateur (moi) pose un certain nombre de situations que VOUS, le public, allez m'aider à résoudre. Elle se veut donc être totalement participative ! Je n'aurai moi-même pas les réponses aux questions ou situations que je vous exposerai. Vous aurez même la possibilité de proposer vos situations !

Pour des raisons pratiques, les exemples de code seront en C# (et NUnit). Mais si vous savez lire du Java, ou tout autre langage C-like, ça ne posera pas de problèmes !

En espérant vous compter nombreux !

L'Agile, c'est bien. En un mois, on connait la capacité de l'équipe. On peut alors planifier.

Pardon ? Un mois ? Oui, mais quand le projet est prévu sur deux, c'est déjà trop tard !

Venez voir ce qui change lorsque l'on fait un projet court. Nous vous présenteront également les préconditions d'un projet Agile court réussi.

Etes vous prêts à lancer votre prochain petit projet agile ?

Angoissé, impatient, heureux, stressé, confiant, triste, fébrile, épuisé, cool,... Vous vous sentez comment ? Demain, c'est démo !

A la fin du sprint, vient le moment de la démo : un incrément de logiciel est montré. Que se cache-t-il derrière l'apparente simplicité de cette cérémonie ? Nous verrons à quoi sert la démo, proposerons quelques astuces pour la préparer et l'animer. Parfois, ce n'est pas facile : "on n'a pas tout fini !", "on développe des APIs", "le client n'est pas là", "tout le monde râle" ... On en parlera aussi.

Bref, comment faire de vos démos des meeting avec un roti à 5 doigts !

Pour que notre histoire soit aussi la votre, prenez 5 minutes pour répondre à cette enquête

En 2011, nous avons eu l'occasion de réaliser le rêve de tout agiliste. Un client a fait réaliser deux fois le même site web, un en mode agile, l'autre en mode "classique". A votre avis qui a gagné ?
Je vous présenterai le contexte de cette expérience à première vue étonnante et nous regarderons en détail les différences et leurs conséquences.

Jusqu'à présent, j'ai toujours pensé qu'entre agile et cycle en V il "n'y avait pas photo"... Bon, maintenant en plus j'ai la photo !

- de la mise en place de Scrum
- de l'accompagnement pro-actif de la forte croissance grâce à l’agilité...
- de l'atteinte de nouvelles limites et l'apparition de nouveaux effets de bord

...

Petit retour d’expérience de l’agilité chez PriceMinister …
L’agilité n’est pas seulement un état d’esprit poussé par quelques développeurs gaulois dans leur coin … mais une vraie profonde remise en cause de l’organisation.
A travers ce retour d’expérience, nous allons montrer les différentes étapes de la mise en place de l’agilité, depuis les balbutiements, jusqu’à l’accompagnement pro-actif de la stratégie de la société.
Et comme l’idée n’est pas de montrer que ce qui fonctionne bien … nous essayerons de nous attarder sur les difficultés rencontrées à chaque étape.

Vous aimez l'organisation qui vous emploie ?
Vous consacrez une énergie considérable à tenter de la faire changer ?
Parfois vous avez réussi ?
Souvent, vous avez échoué ?

Si vous avez répondu "oui" à ces 4 questions, vous êtes probablement ce que j'appelle "un agent du changement".

Cette session est une occasion de rencontrer d'autres agents du changement, et de donner ou recevoir de l'aide sur les problématiques concrètes des participants.

Au passage, vous découvrirez un format d'atelier que vous pourrez réutiliser dans votre organisation.

15 participants maximum.

Solution Focus est une approche de la gestion du changement au niveau des personnes, des équipes et des organisations qui repose sur un principe simple et non conventionnel : s'épargner le travail d'exploration du problème et prendre la route directe vers la solution. Cette approche sur mesure apporte aux individus membres d'équipes, aux coachs et aux managers une approche élégante, simple et performante pour définir et mettre en oeuvre des solutions. Elle a démontré des résultats probants dans son domaine d'origine des thérapies brèves et est depuis plusieurs années maintenant utilisée dans les organisations.

Je vous exposerai brièvement les principes et techniques de base de cette approche ; je vous expliquerai comment je mixe cette approche et certaines techniques issues des Innovation Games pour conduire une rétrospective ; enfin dans la plus grande partie de cette session les participants se livreront eux-mêmes à une séance de coaching mutuel utilisant cette approche. J'utilise ce dernier exercice puissant au démarrage d'une équipe.

Quelle est votre première réaction quand quelqu'un annonce qu'il a trouvé une erreur dans votre application?

Chagrin? Tristesse? Douleur? Rage?

Pourquoi pas gratitude, plaisir ou espoir?

Cette session est destinée à tous ceux qui ont (encore) des erreurs dans leur code. Chaque erreur est une opportunité d'améliorer votre produit, votre processus et votre équipe.

Découvrez quelques techniques simples pour changer des problèmes en opportunités:
* Systems Thinking
* Root Cause analysis (Current Reality Tree)
* Rapport A3
*...

Cette présentation interactive contiendra des histoires belges (avec des examples de l'application de ces techniques) et quelques petits exercices.

En ce moment, j'applique ces techniques sur un grand projet. J'espère pouvoir vous montrer les résultats lors de la prochaine conférence Agile Paris. J'espère que vous reviendrez pour montrer vos résultats.

Nombreux sont celles et ceux qui ont rejeté l'Agilité suite au choix d'une méthodologie qui n'était pas adaptée au contexte de leur projet. Or, Scrum n'est pas la réponse universelle à toutes les problématiques, et le Kanban ne peut pas être mis en place sur tous les projets. Faut-il abandonner l'Agilité pour autant ?

Dans les années 70, Bruce Lee révolutionna les arts martiaux en développant une méthode de combat rassemblant les éléments les plus efficaces de multiples systèmes sous le nom de Jeet Kune Do, méthode évolutive et adaptative portée sur l'efficacité avant tout.

Bruce Lee était-il un agiliste ? Le nunchaku était-il la réponse à tous ses problèmes ? Le Scrum Master doit-il forcément porter une combinaison jaune ? Toutes les réponses, et bien plus encore, dans cette présentation qui vous donnera les bonnes questions à vous poser avant de choisir la méthode Agile adaptée à votre contexte et de la faire évoluer selon vos besoins.

Directeur des développements, J'anime depuis plus de 8 mois, plusieurs réunions portfolios mensuelles dans mon entreprise

Chaque mois, devant un mur de post-it des directeurs de différents services (commerce, marketing et technique) se réunissent avec un objectif :
Prioriser des projets inévitablement trop nombreux pour des équipes inévitablement trop petites …

Je souhaiterais partager avec vous cette expérience : les premiers pas (quoi une réunion sans powerpoint !? c'est vraiment sérieux ?), les heureuses surprises, mais aussi quelques moments de solitude (3 mois de développement pour ça ?).

L'idée principale étant d'accepter de ne pas s'occuper uniquement de "faire les choses bien" mais aussi de "faire les bonnes choses" !

Les obstacles se suivent et ne ressemblent pas. Pourtant, qu'ils soient techniques, organisationnels ou structurels, chaque solution à ces problèmes dépend des hommes et femmes qui l'actionneront. De la même façon, la meilleure idée du monde ne verra jamais le jour si les équipes n'arrivent pas à travailler ensemble. L'humain est au centre plus que jamais.

Je vous raconterai comment la confiance ne se décrète pas, ainsi que les pistes suivies pour que développeurs, marketing, production, product owners, scrum masters et direction évoluent dans un climat de collaboration plutôt que de défiance. Nous parlerons de one on one, d'ateliers, d'objectif commun, de confiance, de communautés de pratiques, de fun, d'humilité.

Après leurs tribulations à l'ITSMF Day, puis au Scrum Day, Sylvaine & Laurent reviennent vous présenter la suite de "Sweet Rupture". Cette fois-ci, nous vous raconterons comment utiliser le modèle GROW de Sir Whitemore pour une croissance agile, ludique et épanouissante, en jouant avec des innovation games, dans une Game-Room.
Et si grandir est parfois un peu douloureux, vous prendrez bien quelques vitamines mentales concoctées par Sylvaine !

A bientôt !
Sylvaine et Laurent.

PS: et ne le répétez pas : la saison 04 est presque bouclée : elle sera
non-violente, et en spirales ;)

J'ai présenté récemment "A la recherche du temps perdu", qui est une suite de conseils pour améliorer sa façon de s'organiser et de travailler.

Mais je dois avouer que cette tyrannie de la recherche de la productivité me pèse un peu.
Je vais donc vous présenter des techniques pour occuper tout son temps en en faisant encore moins, tout en sauvant les apparences.

Vous aurez droit à de nombreux conseils très pratiques pour réduire la productivité aussi bien au niveau individuel qu'au niveau du groupe.
Bien entendu, toutes les techniques que nous allons voir ont été testées et sont d'une efficacité redoutable.

Le bénéfice pour vous sera de montrer à tous vos collègues à quel point vous êtes compétent parce que vous serez débordé tout le temps, ce qui est une preuve que vous faites le travail de plusieurs personnes et donc que vous méritez une augmentation.

Faire le contraire de ces conseils pourrait vous amener à plus d'efficacité, mais il va de soi que je vous le déconseille fortement.

Notes:
Non, ceci n'est pas une session pour le 1er avril !!!
Cette session est vraiment sérieuse, et aborde de vraies problématiques agiles.
La présentation peut varier entre 30 minutes et plusieurs jours, j'ai mis 1 heure pour être confortable.

L’agilité prône l’autogestion des équipes, l’auto-organisation. En regard de l’organisation dite traditionnelle (Cycle en V) pratiquée depuis des années , le rôle de Chef de Projet semble passer à la trappe au profit de concepts agiles fort alléchant. Cependant, le rôle de chef de projet n’est pas mort. Il continue, évolue et devient un acteur majeur de l’enrichissement, de la montée en compétence de l’équipe Agile. Accompagner les projets, les soutenir, chercher de nouvelles pratiques, polliniser autour de soi, … le travail du middle management ne fait que commencer …

Je vais vous parler des tests utilisateurs dans un contexte Agile.

Il s'agit des pratiques simples, faciles à mettre en place, qui vous permettront de tester vos applications avec des utilisateurs, afin de:
* trouver des points défaillants en terme d'ergonomie
* mieux comprendre la façon dont l'utilisateur perçoit l'application
* trouver des idées pour de nouvelles fonctionnalités

Ce feedback nous permet de livrer une application toujours plus facile à utiliser, et plus adaptée aux besoins des utilisateurs.

Ces pratiques valorisent la plupart des projets, mais *surtout* les projets Agiles, car:
* il s'agit déjà d'une démarche itérative
* les acteurs du projet sont convaincus de la valeur de feedback
* il y a la possibilité de modifier le scope / priorités à la volée pour prendre en compte ce feedback

Grâce a tout cela, un projet Agile est un contexte très favorable pour les tests utilisateurs. Alors, pourquoi ne pas les faire régulièrement ?

Bien souvent, il y a de nombreux a-prioris concernant les test utilisateurs : méthodologie complexe et démarche coûteuse.

Mais ce n'est une fatalite, il existe aussi une approche des tests utilisateurs très simple, peu chère, qui maximise le retour sur investissement. Lors de cette séance, nous allons voir ensemble quels sont les points clés pour mettre en place ce type de méthode.

Vous êtes référent techique, expert, développeur senior, codeur agile ? Vous souhaitez partager votre expérience du Coding Dojo, ou connaître celle des autres afin de structurer votre approche ?
Rejoignez-nous pour une session "Entre Technical Leaders" (*) où nous partagerons nos expériences et construirons ensemble un "Guide du Dojo" strictement issu du vécu des participants.

La session sera en mode "cercle de pratique" : une discussion structurée, facilitée par un animateur, et ouverte aux vétérans comme aux débutants ; le guide produit en séance sera retranscrit dans les heures qui suivront la session.

(*) Note : les sessions "Entre Technical Leader" (ETL) sont des cercles de pratique que nous animons habituellement à Octo Technology afin de structurer notre approche sur le rôle peu documenté de Technical Leader. Nous aimons tellement ça que nous voulons partager ces cercles avec d'autres techniciens agilistes. Laproduction d'un "guide" sur un thème prédéfini nous aide à focaliser nos discussions.

Les test d'acceptances automatisés et le « Behavior Driven Developement » sont peu mis en pratique par rapport aux tests unitaires automatisés et au « Test Driven Development ». Pourtant, c'est une pratique gagnante à moyen et long terme. Alors qu'est-ce que le BDD et les tests d'acceptances automatisés ? Quels sont les gains envisageables ? Quels sont les nouveaux champs à explorer ? Et à quoi cela ressemble dans la vrai vie ? Nous découvrirons cela ensemble.

Pensez-vous pouvoir construire la tour Eiffel en un sprint ? Saurez-vous aller plus vite que vos concurrents ? Votre Product Owner gardera-t-il confiance dans votre équipe alors que votre objectif sera d’ériger la tour de Pise ?
A l’occasion de cette session ludique, nous vous invitons à venir vous affronter lors d’un jeu de Kapla titanesque !
Votre objectif sera de construire les plus beaux monuments de la planète, dans une simulation accélérée d’un processus Scrum.
Notre équipe de choc vous guidera durant cette compétition sur des points clés du processus Scrum :
- Le chiffrage collaboratif
- Créer une relation de confiance avec le Product Owner
- L’instauration d’une équipe auto-organisée
- Le reporting visuel
- La mise en place d’un processus d’amélioration continue

Vous êtes forts en travaux manuel (ou pas), vous avez envie de reconstuire le monde ou simplement de passer un moment convivial avec l’équipe de So@t au grand complet ? Alors venez découvrir ou redécouvrir Scrum lors de cette session de jeu inédite !

Un projet de développement logiciel impliquant 80 personnes, distribuées sur 9 équipes réparties dans 4 pays.
Un produit devant soutenir une activité de plus de 5 000 000 de transactions de vente par jour.
Une première mise en production au bout de 6 mois.
Et de nouvelles fonctionnalités tous les deux mois.

Qui a dit que l’agile n’était pas adapté aux gros projets ?

Nous partagerons avec vous un retour d’expérience sur la mise en place de méthodes agiles à large échelle : feature-teams, communautés de pratique, interactions avec des équipes off-shore, livraisons fréquentes et mises en production par un simple clic, prise de décisions collaboratives…

A l’issue de cette session nous aurons partagé avec vous :
* Nos Do’s & Don’t à propos des méthodes agiles lorsqu’elles sont appliquées à de gros projets
* Les modèles d’organisation que nous avons mis en oeuvre
* Nos meilleures pratiques pour diriger des équipes projets géographiquement distribuées
* Les outils et les compétences clés pour démarrer un tel projet

Les méthodes agiles nous parlent de l'importance de l'amélioration continue et d'utiliser chaque itération ou sprint comme une opportunité d'apprendre et de s'améliorer. Pour cela, la prescription est simple : une réunion de rétrospective à la fin de chaque itération. Est-ce vraiment si simple ? Pourquoi tant de développeurs se plaignent que leurs rétrospectives n'aboutissent qu'à peu de choses ? Pourquoi tant de managers expriment des doutes sur le ROI de ces réunions supplémentaires ?

Partant de l'hypothèse qu'il y a eu de la perte en ligne lors de la transplantation du Kaizen (terme japonais désignant l'amélioration continue) de la communauté Lean vers la communauté Agile, cette session est une invitation à retourner aux fondamentaux. Après une introduction théorique minimaliste sur le Kaizen, les participants pourront mettre en pratique les concepts.

L'objectif est, qu'à la fin de cet atelier, chacun ait posé un bon problème selon le formalisme PISCAR et ait clarifié sa façon de s'y prendre pour mieux comprendre ce problème.

J'ai adapté le jeu "Artistes et Spécifieurs", développé initialement par Alistair Cockburn, pour illustrer les principes du lean: Satisfaire complètement ses clients par une qualité irréprochable, maîtriser puis réduire les délais et les coûts par l'élimination des gaspillages et le développement des personnes par la résolution des problèmes.

L'atelier met en évidence l'importance de bien comprendre et communiquer avec son client, et de s'assurer que l'on répond efficacement à ses attentes (notamment par le management de la performance et la résolution de problèmes.)

Aujourd’hui, dans un environnement incertain et instable, le manager est en quête du Graal de la prédictibilité pour réussir ses projets. Nonobstant les risques dus aux spécifications, les incertitudes technologiques et l’urgence des livraisons, le maillon le plus imprévisible reste encore les comportements des participants au projet.
Alors comment accroître les chances que ces comportements deviennent plus «prévisibles » ? Comment augmenter la probabilité qu’une personne, pleine de personnalité, s’aligne sur l’objectif et qu’elle y colle ?
A la croisée entre processus agile et psychologie sociale, cette présentation explique comment Scrum répond à ces besoins et fonctionne si bien humainement pour produire du logiciel. Les participants à cette session s’éloigneront pendant une heure de l’imaginaire culturel agile pour découvrir l’envers de la médaille. A sa sortie, ils gagneront en liberté et réalisme à l’heure d’injecter un changement humain dans une organisation.

Un des dangers actuels de l’agilité est sa focalisation sur le processus et la réduction du gaspillage.

Malheureusement, être créatif et innovant nécessite de faire beaucoup d’essais avant de trouver une idée qui marche.

Quelques sociétés préconisent l’utilisation de 20% du temps de travail sur des projets personnels créatifs, mais très peu de ces initiatives sont couronnées de succès, ce qui fait que la méthode des 20% est de plus en plus abandonnée.

Je vais vous présenter une nouvelle méthodologie pour améliorer la créativité d’un groupe: Brainstorming Agile Contraint Systématique ou « BACS ».
Cette nouvelle méthode permet d’être créatif en réduisant le gaspillage.
Elle se fonde sur 3 principes:
1) la solution est proche du problème
2) avant de proposer des solutions, il faut simplifier le problème
3) la solution d’un problème est un mélange de plusieurs idées

Pour les connaisseurs, ma méthode est une version simplifiée d'ASIT, qui est elle même une simplification de TRIZ (utilisée en Lean Six Sigma).

La session se décompose en 2 parties:
1) 45 minutes sur ce qu'est la créativité et ses obstacles
2) 1h de pratique de la méthodologie BACS

Une démarche agile est itérative et incrémentale. Même si il existe des outils ou des pratiques adaptées, gérer l'aspect incrémental avec une base de données relationnelle est souvent laborieux. Cela crée un tout cas des frictions dans l'avancement du projet. Depuis quelques années, nous avons à notre disposition d'autres modes de persistance qui permettent de limiter ces frictions, et même potentiellement d'améliorer les performances et la capacité à monter en charge de nos applications.

A travers cette session, je vous propose de découvrir les bases de données orientées document, et plus particulièrement MongoDB, en vous montrant comment ce type d'approche peut vous apporter de la flexibilité sur la gestion des données, et vous aider à construire votre couche de persistance des données de façon incrémentale.