Agile France 2012

Application des principes de la Communication Non Violente dans la gestion d'un projet Agile
- rappel du protocole de la CNV
- situations jouées en mode normal puis en utilisant les principes de la CNV (sur les 3 scènettes présentées, 2 seront jouées par les animateurs et une par des personnes du public)
- debrief avec le public, conclusion et références

Cette présentation sera co-animée avec Laurent Sarrazin, responsable du centre Agile de la SGIB (banque d'investissement de la Société générale).

Comment faire pour rendre une organisation agile? Est-il possible de changer son système d’exploitation organisationnel de sorte que l’agilité devienne possible dans toute l’organisation? La réponse est oui mais cela nécessite de remplacer l’ancien système d’exploitation “sous-jaçent” - le noyau dur de l’organisation, la structure, le système de pouvoir en place, les processus de prise de décision - par un nouveau système d’exploitation organisationnel qui inclut - des processus de prise de décision rapides, une nouvelle structure organique, un nouveau système de pilotage dynamique centré sur la réalité, une clarté sur les autorités en jeu, de nouvelles capacités à gérer les tensions et les transformer en évolutions pertinentes de l’organisation, une nouvelle conscience de ce que sont les organisations... Le système que je vais vous présenter s’appelle l’Holacratie™.
Vidéos: http://bit.ly/yRA2V5
http://bit.ly/rbHbvu

Objectifs de l'atelier:
Comprendre comment mettre en place l'agilité dans une organisation avec cette nécessité de d'abord en changer la structure et le système d’exploitation. Explorer & découvrir - par l'expérience - des méthodes, processus et outils qui permettent cela.

Durée: cet atelier peut durer moins de 3h, il est flexible.

Vous savez développer, et vous rêver depuis longtemps de monter un business avec un logiciel codé par vous-même ?
Vous ne savez pas par où commencer, mais vous comprenez les bénéfices d'un processus itératif et incrémental ?
Cette session est faite pour vous !

Pendant cette session, vous mettrez le pied à l'étrier de votre démarche entrepreneuriale, en pratiquant les outils fondamentaux du lean startup.

20 participants max.

Lorsque, sur un projet informatique, il devient difficile d'ajouter de nouvelles fonctionnalités et que la
maintenance devient un véritable calvaire, c’est le signe que la dette technique s’est accumulée en excès et
qu’il est temps de la rembourser.
Dans la majorité des cas, cette dette trouve son origine dans des compromis faits sur les choix de
conception et de réalisation, souvent pour des raisons de temps.
La dette doit être gérée de manière permanente sur les projets : cela passe par de bonnes pratiques de
développement telles que le refactoring systématique, le pair programming, les tests unitaires, etc, mais
également par la mise en place d'outils d'intégration continue et de mesures de la qualité du code qui nous
permettront de diminuer efficacement cette dette.

Vous travaillez toute la journée, vous courrez dans tous les sens et pourtant, le soir, vous avez la désagréable impression de ne pas avoir avancé…

Vous êtes Program Manager et les projets que vous gérez sont systématiquement en retard…

Vous êtes développeur, vous avez 5 chefs de projets et vous commencez à saturer…

Vous êtes client et votre fournisseur tarde à livrer ce qu’il s’était pourtant très rapidement engagé à produire…

Cette simulation ludique vous donnera peut être une piste de réflexion.

Qu’est-ce que le Systems Thinking ? Au cours de cet atelier, vous découvrirez le Systems Thinking, une approche visant à comprendre les systèmes et les paramètres influents à l’oeuvre pour les rendre sain ou... malsain.
Cette approche permet la résolution des causes racines des problèmes en les faisant émerger comme éléments du système.
Les exemples de systèmes permettent d’appréhender pourquoi le Systems Thinking est important : le système circulatoire de notre corps est un système, le département ventes de l’entreprise, le système de démarrage de la voiture... mais aussi, bien sur l’éco-système.

Description : Le lean est un système de management qui vise à améliorer l’efficacité opérationnelle d’une organisation.
Le lean repose sur trois principes :

* satisfaire complètement les clients
* réduire les délais et les coûts par l’élimination des gaspillages
* en développant les personnes par la résolution de problèmes

Cet atelier a pour but de faire découvrir les principes et techniques du lean à travers une simulation : une chaîne de montage de cocottes en papier, utilisée ici comme métaphore d’une chaîne de fabrication de logiciel – analyse, conception, développement, validation, déploiement.

Vous découvrirez les principes et techniques de base du lean : amélioration continue (kaizen), management de la performance, management visuel, management de la qualité (jidoka), mise en flux, etc.

Développer un jeu est un jeu... d'enfants!
Vous rêviez d'être développeur, ou tout simplement curieux de voir comment on se sent quand on est aux commandes de la machine?
Sans aucune connaissance préalable d'un langage ou même de notion de programmation, vous allez vivre l'expérience du développeur.
Le niveau peut paraître certes enfantin. Mais comme il s'agit d'un "serious game", nous allons nous replonger dans une situation d'adultes: mener un projet logiciel à son terme.

Vos collègues développeurs deviendront pour l'occasion chef de projet, ou scrum master, ou product owner ou ingénieur qualité. Et ensemble, sous forme de 2 équipes ou plus, vous allez tenter de gagner le challenge: livrer un produit fini dans le temps imparti. En observant 2 façons de faire: une agile et l'autre pas.

Que les meilleurs gagnent...
(1 PC sous Windows nécessaire par équipe, 1 CD d'installation sera fourni)

Mesdames et Messieurs, bienvenu dans la galaxie des tests unitaires (GTU pour les intimes).

Vous avez été sélectionné parmi une population de développeurs triés sur le volet. Nous savons que vous avez déjà (souvent) visité la planète du TDD. Que votre jauge de couverture de code frise les 80 %. De plus, le satellite jUnit n'a plus de secret pour vous. Bref, vous êtes un baroudeur des tests unitaires.

Mais votre âme d'aventurier interstellaire vous susurre tous les jours que vous pourriez faire plus de vos tests, que les outils que vous utilisez ont des limites. Ou alors vous en avez marre du train train de votre planète, avec ses fameux monts assertEquals.

Pas de panique ! N'ayez plus peur de découvrir les nombreuses zones cachées de cette galaxie des TU. Ensemble, nous approcherons du code étrange. De plus, vous repartirez avec 42 billets gratuits vers les meilleurs outils du voyageur inter-galactique.

Ensuite, nous irons voyager du côté de la planète mutante avec le Mutation Testing.Notre voyage commencera par visiter le monde du BDD, Behaviour Driven Developement, ou plus simplement le Spec Testing.

Et pour finir notre voyage, nous nous rendrons dans le système solaire du Property Testing.
Venez, vivez et devenez un aventurier des tests. Un explorateur qui aura vu tous les tests. Et qui saura qu'au-delà de sa planète une vaste galaxie existe.

A partir d’un persona, dénommée Josiane, nous relaterons comment nous avons réussi à stopper un projet en difficulté commencé 8 mois plus tôt et à repartir de zéro pour livrer 4 mois plus tard.

Nous verrons comment Scrum a permis de mettre en évidence les problèmes qui étaient latents et nous a amenés à remettre en cause ce projet.

Nous évoquerons notamment les freins aux projets (humains et techniques) et les outils que nous avons utilisés pour les supprimer. Nous aborderons ainsi les techniques de persona, d’innovation game (product box), de stories mapping et des différentes manières de dynamiser l’équipe. Ces techniques nous ont notamment permis de nous consacrer aux développements de fonctionnalités pertinentes pour le client final. Enfin nous verrons dans quelles mesures le projet a été un succès.

Fruit d’une réflexion autour d’un mémoire de 3ème cycle en management des Systèmes d’Information, cette session modélise comment les fondamentaux de l’agilité peuvent être placés sur UNE roue de Deming. Elle décrit l’articulation des valeurs et des principes agiles qui me semblent les plus importants pour les SI. Elle va « plus loin » que la vision classique et propose un modèle humain, managérial et technique qui permet d’appréhender la cohérence et l’efficacité de l’ensemble pour entrer dans l’amélioration continue des organisations. Une session dense pour cesser de « faire » un instant et pour penser l’Agilité comme un Système. Difficile de twitter en même temps...

Trop souvent le BDD (Behavior Driven Development) est de suite relégué au rang de Test d'Acceptance (donc au niveau des IHM) et on écrit trop vite l'équation BDD = ATDD.
Je vous propose de découvrir la face caché de l'iceberg BDD, et par la pratique de SpecFlow, voir des exemples concrets de tests "unitaires" dirigés par le comportement qui viennent renforcer, voir même devenir la base de tous les tests de vos composants logiciels, quelque soit leur rôle.

Pour cela, une étape importante, sera celle du choix du langage (le fameux Domain Language) qui permet de décrire des comportements, ceux des composants logiciels, plutôt que celui des utilisateurs humains. Une réconciliation avec le DDD? (Domain Driven Design)

Cette session est un retour d'expérience. Elle se propose d'abord d'expliquer comment transposer les meilleures démarches de gestion industrielle aux pratiques administratives et faire des économies insoupçonnées.
En effet, un regard "Lean" sur les activités tertiaires permet de mettre en évidence des "gaspillages" pouvant représenter plus de 70% des coûts ! De très nombreux exemples sont donnés, illustrant des approches en finance, sur les achats ou sur les services support informatiques.
Mais il ne suffit pas d'identifier les gains possibles : encore faut-il aller les chercher ! Et pour cela, la pleine collaboration de ceux qui subissent - et créent - les gaspillages est indispensable. Mais que faire de ceux qui, s'étant pleinement investis, ont allégé ou supprimé leur poste ?
Par rapport aux années précédentes, l'accent est encore plus mis sur l'approche "lean culture" versus le "lean outil". Le débat avec l'assemblée portera beaucoup sur : "mais que faire des gains de productivité ? Cela ne doit-il pas être un deal clair dès le lancement du projet ?"

Plan de la session proposé :
A. Lean Office :
- Une définition
- Intérêt d'une telle démarche
B. 5 outils organisationnels pour améliorer la performance administrative
- Le management visuel
- L'identification des gaspillages
- Le problem solving
- L'élaboration de «standards»
- les concepts de «file unique» et de complexité des opérations
C. Que faire des personnes qui ont supprimé leur job ? Les promouvoir !
D. Débat

L'idée de cette présentation est de décrire un ensemble de bonnes pratiques afin de devenir plus agile dans le management d'équipe:

- gérer son équipe (utilisation des cérémonies de SCRUM)
- gérer son temps (gestion d'un agenda global)
- gérer ses activités (basé sur le "Getting Things Done" mais dans une version évoluée)
- gérer ses émotions (description du mécanisme de l'émotion)
- gérer les conflits (description et application du protocole de la CNV)
- gérer son chef (comment restez soi-même avec votre chef)

Toutes ses pratiques ont été mises en place et testées dans le management que j'exerce aujourd'hui.

Ma PO se fait désirer, mon directeur de projet code, mon Scrum Master est un pervers, Néo trompe Trinity avec Proxy, va moudre …

Décodage : La PO Métier est indisponible, le chef de projet tient à continuer de décider de presque tout et en plus il code, le rôle de Scrum master est tenu par le coach Agile, l'application "Trinity" est perturbée par le paramétrage du proxy du poste de travail standardisé "Néo", la PO Proxy a du caractère et s'exprime …

Ajouter à cela seulement 2 développeurs, dont un à Paris (à mi-temps) et l'autre à Montpellier, chacun isolé dans leur technologie (PHP et FLEX) ! Un contexte idéal pour faire un peu d'Agile, non ?

Objectif de ce retour d'expérience :
Montrer qu'il est possible, même si le contexte n'est pas idéal, voire rédhibitoire par certains côtés, de réussir un produit et d'atteindre un degré d'agilité élevé, à condition d'être aidé par un coach et de bénéficier de pas mal de chance !

Le contexte idéal est rare, beaucoup de gens hésitent à se lancer. Nous souhaiterions faire passer les messages suivant :
• Michel LEJEUNE : N’attendez pas de vous trouver dans la situation idéale pour y aller. Vous aurez peut-être de bonnes surprises et si vous avez de mauvaises surprises, le coach sera là pour limiter les dégâts.
• Jérôme BATAILLER : Pour votre première fois en Agile, de toute façon, faites-vous accompagner. C’est la garantie de ne pas trop se planter et la promesse d’aller plus loin, si c’est possible.

Présentation en binôme, avec Jérôme BATAILLER chef de projet.
Déjà aux programmes de l'Agile tour 2011, à Montpellier et Sophia.

S’il existe une valeur phare pointée par l’agilité, c’est bien la communication face à face. L’ingénieur apprend à mettre en relation des systèmes informatiques hétérogènes, à envoyer et recevoir des messages d’objet à objet mais reste plutôt démuni, peu outillé quand il s’agit d’interactions entre les êtres humains. Cette session aborde la première difficulté rencontrée par tout membre d’un projet agile : savoir écouter l’autre. Facile, direz-vous ? C’est pourtant une des choses les plus difficiles à faire, surtout dans les conflits ! Au cours de cet atelier, nous aborderons les fondamentaux de l’écoute à travers des petits exercices et appréhenderont pourquoi le coaching est « l’art de l’écoute et du questionnement ».

On parle de plus en plus de jeux dans notre quotidien professionnel, notamment dans les organisations agiles. Mais est-ce bien sérieux ? Et puis entre Serious Games, Innovation Games, Gamification, Serious Play et j'en passe, franchement... on s'y perd !

Cette présentation a pour but de faire un tour d'horizon des différentes formes de jeux utilisées dans le monde professionnel et de vous transmettre le lexique de base. J'illustrerai au moyen d'exemples les apports de ce mode de travail mais aussi les limites à respecter pour que le jeu en vaille la chandelle. Vous repartirez avec des idées pour animer vos réunions de travail interminables, pimenter vos séances de pair-programming ou inculquer des valeurs agiles à votre équipe.

Le succès -- et la difficulté -- pour un développeur, ça peut être de réaliser des prodiges techniques, de résoudre des problèmes intéressants, de choisir et maîtriser ses outils, de se former continuellement. Mais ça ne suffit pas. Pour réussir un projet, il faut former une équipe qui marche. Et une fois en équipe, les difficultés changent. Cinq développeurs en succès ne forment pas une équipe qui marche.

Les projets échouent rarement pour des raisons techniques, mais souvent pour des raisons systémiques, c'est à dire relationnelles.

Vous souvenez-vous d'avoir, durant votre parcours scolaire ou vos premières années de travail, été formé pour réussir en équipe ?

Pour réussir en équipe faites-vous appel à "l'esprit d'équipe" ? A "l'engagement" ? Au "leadership" ?

Dans cette session, à travers des retours d'expérience, nous parlerons de quelques modèles, outils et pratiques qui permettent de surmonter trois difficultés du travail en équipe, à savoir:
- comment exercer toute sa créativité ?
- comment livrer à temps, tout le temps ?
- comment se confronter mutuellement ?

"On ne peut pas vous donner de dates, on est en agile !"

Cette réplique d'une équipe à son client interne, remontée par un prospect, m'a fait bondir : au contraire, une bonne implémentation d'une démarche Agile doit donner plus de visibilité et de fiabilité sur les délais.

Nous verrons dans cette session comment construire un plan de release fiable en s'appuyant pourtant sur des éléments d'incertitude comme la liberté laissée à l'équipe de fixer sa limité d'engagement à chaque itération.

Utiliser les outils de qualité de code et ajuster leur configuration dans une dynamique agile: les itérations, le pair programming, la propriété collective du code, le TDD, l'intégration continue.

Nous vous proposons un retour sur nos expériences autour des ateliers : les outils utilisés, les concepts mis en avant, les réactions, souvent surprenantes des enfants. Nous vous donnerons les ingrédients pour faire un bon Coding Goûter… Pour vous donner envie, parent ou pas, de participer ou d'en démarrer un !

A la suite de cela il vous sera proposé une table ronde / débat, dont l'objectif sera de discuter des intérêts et problématiques autour de l'idée de faire découvrir la programmation aux enfants : Par exemple : répond-on à un besoin ? Est-ce vraiment bénéfique ? A quoi doit-on surtout veiller afin de rendre l'exercice utile et intéressant ?

Les tests sont accusés de tous les mots ; ils coutent cher, prennent du temps à développer, sont complexes à maintenir, etc. Et il faut bien reconnaître que ce constat est souvent exact, ce qui n’encourage pas les chefs à les budgéter. Pourtant, les tests sont à la base d’une démarche qualité digne de ce nom. Des méthodes comme les TDD (Test Driven Development) placent les tests au cœur des développements et s’en servent comme d’une force pour guider les équipes ; les promesses sont nombreuses.

Toutefois, et c’est une situation que je retrouve de manière récurrente à chaque fois que je rejoins un projet, je constate que les acteurs (développeurs, chef de projet, testeurs, architectes, etc.) se demandent par quel bout prendre cette affaire. Qui fait quoi ? Quand ? Comment ? Pourquoi ? Quid de l’agilité ? Les TDD posent de nombreuses questions et imposent des pratiques délicates : c’est magique mais ça ne marche pas tout seul.

Pendant longtemps, je me suis demandé comment répondre aux attentes (budget, planning, organisation, turnover, complexité, normes, code, habitudes, etc.) spécifiques de chacun. J’ai tenté d’identifier les éléments qui me paraissaient essentiels et qui couvraient la majorité des cas. J’ai cherché une version simplifiée, facile à mettre en œuvre et à mécaniser, quitte à ne pas respecter tous les principes des TDD. Progressivement s’est alors dessinée 3T : les Tests en Trois Temps.

La méthode 3T diverge des TDD en proposant des mécanismes plus simples qui suffisent dans la plupart des cas. 3T s’adresse principalement aux développeurs mais inclue de quoi satisfaire les autres membres de l’équipe, à commencer par le chef de projet. Le point de départ de la méthode est le cahier des charges, à partir duquel on tire un jeu de règles, pouvant être présentées/pensées sous forme de fiches et/ou de post-it, et intégrables avec Scrum et/ou Kanban par exemple. L’écriture des tests et du code de production, réalisée par des personnes différentes, est ensuite guidée et mécanisée en grande partie.

Durant cette présentation, je propose de revenir rapidement sur les enjeux des tests, de comprendre ce qu’ils apportent et pourquoi ils ont mauvaise presse (tests bidons, tests de complaisance, tests non maintenus, etc.) Je passerai en revue les raisons qui rendent les équipes mal à l’aise vis-à-vis des TDD. Enfin, je présenterai les Tests en Trois Temps (3T) à travers une mise en situation simple.

A noter que 3T a déjà été présentée sur Developpez.com à travers plusieurs articles (http://icauda.com/articles.html#3t) :
* Proposition des Tests en Trois Temps ;
* Miniroman humoristique d’une équipe mariant Scrum et 3T ;
* 3T sur un cas pratique en 5 minutes.

Dans notre rôle d’engagement manager sur des transformations agiles au sein des DSI de plusieurs grandes sociétés multi-nationales, la question du ROI Agile (ou pourquoi adopter les pratiques Agiles ?) est quasiment systématiquement une des premières questions que nous pose toute la chaine de management que nous sommes appelés à côtoyer à tous les niveaux de l’entreprise, de la direction générale aux responsables opérationnels, en passant par tous les niveaux de management intermédiaires à la fois côté IT et côté métier. Mais entre la présentation générale de l’agilité faite aux commanditaires de la transformation et la réalité du terrain, il y a très souvent un très grand écart de compréhension des apports et coûts d’une transformation agile ou même d’une plus simple adoption des pratiques agiles sur un programme ou un sous-ensemble de projets. L’engagement manager et les coachs de la transformation se retrouvent très rapidement enlisés dans des problématiques de rigidité opérationnelle et organisationnelle où la promesse initiale de l’amélioration de l’efficacité opérationnelle apportée par l’agilité devient difficile à concrétiser.
Cette présentation vise, sur la base de retours d’expérience récents, à démystifier la question du ROI agile aux dirigeants voulant se lancer dans une transformation agile et à leur présenter des modèles de transformation qui permettraient d’éviter les écueils fréquemment rencontrés aujourd’hui et mesurer ce qui est mesurable.

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.

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 ?

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 !

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.

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!

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 ?

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 !

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/)

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.

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 ;)

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.

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.

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.

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.

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

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 !

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.

« 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 !

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.

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.

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

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

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...

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

"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.

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é.

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.

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.

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

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 …

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.

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 !

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" !

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.)

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é.

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.

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.

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.

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.

“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 ?

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.

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.

- 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.

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.

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

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.

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 ?

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.

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.

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 ...

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.

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

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.

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.

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

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.

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.

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 ?

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.

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

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 ?

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.

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.

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.

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.

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.

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.

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'é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.

Le Scrum Master est un facilitateur. Quand on explique ça, ça tombe à plat et il y a comme un malaise. Même en expliquant le terme et en allant un peu plus loin dans la définition (protecteur de l'équipe, aide au PO, aide à résoudre les problèmes, etc ...), je ressens toujours des interrogations (légitimes) chez ceux qui n'ont jamais travaillé avec.

Alors j'aimerais vous faire vivre 24h dans la peau d'un Scrum Master, décrypter avec vous les différents "patterns" de Scrum Master et réfléchir autour de ce rôle ô combien nécessaire mais somme toute assez peu connu.

En octobre 2011, Jeff Sutherland et Ken Schwaber ont publié une nouvelle version de Scrum. Cette version est épurée, et ne contient que les principes fondamentaux. Je vous propose de les présenter.

Les débutant en Agilité trouveront une bonne introduction à la méthode Agile la plus utilisée. Un agiliste averti sera peut être surpris de ne pas trouver la Burndown Chart comme artéfact de Scrum...

La Scrum Master Academy est le maillon manquant entre une formation certifiante qui ne certifie pas grand chose et un bon Scrum Master. Basé sur l’expérience terrain de Gilles et Jean-Laurent, la Scrum Master Academy a pour vocation de former des Scrum Master d’élite. Conscients que les méthodes agiles n’imposent pas de règles d’or, mais qu’il est difficile de s’améliorer sans avoir des codes de bonne conduite, nous avons listé un ensemble de 50 règles que nous enseignons à nos Scrum Masters.

Ces règles sont des conventions qui donnent des repères au Scrum Master débutant et questionnent le Scrum Master expérimenté. Venez découvrir dans cette session les règles les plus importantes et leur explication.

Nous sommes en décembre 2011.
Le projet de remplacement de l’ensemble des sites Internet d’une grande marque a commencé en février et aujourd’hui, le besoin du client n’est toujours pas exprimé. Les différents «workshop» n’ont pas permis de converger. La tentative d’écriture de spécifications générales a déjà produit 850 pages de documents... Mais pas de signature.

C’est à ce moment que l’on nous a appelé pour mettre en place Scrum. Scrum étant identifié comme la seule solution pour sauver le projet.

Scrum peut-il sauver ce projet ?

What's the difference between unit tests, functional tests and end to end tests ? Which ones do I have to use and when ?
Let's try to understand how we can give a value to the automated tests for "non-developers" and how we can rely on them.
What's the relationship between a QA engineer and automation testing ? Are the tests telling the truth about the actual state of the system ? Let's talk about how automation testing can influence and improve the software development cycle.

Of course the talk and the slides will be in english :)

On aimerait tous travailler sur du code bien propre, développé en TDD, remanié selon les grands principes de design orienté-objet. Seulement voilà, il arrive parfois que l'on se retrouve à développer avec du code Legacy, ce fameux code existant et vieillissant que l'on n'a pas écrit, qui n'a jamais été testé. Celui où le prototype est parti en production, celui où le tech-lead historique a changé de boite, celui où personne ne comprend ce qui se passe sur cette application.

Le but de cette session est d'expliquer comment reprendre la main sur cette complexité et comment se mettre en ordre de batailler pour développer efficacement malgré les contraintes du code legacy.

Cette session présente ce qu'est le code Legacy, d'où il vient, comment se remettre à écrire des tests unitaires pour ce type de code et comment le refactorer. Cette session revient aussi sur quelques retours d'expérience de projets agiles avec du code legacy.

Enfin, un Kata de programmation aura lieu au cours de cette session, pour montrer comment tester et refactorer du code legacy.

Programmer est une tâche incroyablement ardue. Il faut faire preuve de discipline, assister semaine après semaine à un Dojo Développement, apprendre à dérouler ses katas les yeux fermés. Et le reste du temps surmonter la peur qui étreint à chaque nouvelle ligne de code : est-on sur le point d'insérer un vilain bug dans un logiciel en production, qui pourrait coûter à son propriétaire plusieurs millions d'euros ?

Malgré tout et bien souvent, programmer est également une tâche jouissive. Et s'il nous arrive souvent de le penser, nous le gardons généralement pour nous. Il est rare que nous codions juste pour le fun (comme disent nos cousins québecois), juste pour célébrer combien nous aimons notre vie de programmeur.

Cette session tentera de changer cet état de fait. Nous allons coder pour le plaisir, avec le secret espoir que certains des participants aimerons ce qu'ils verront, décideront que c'est ce qu'il y a de plus cool au monde, et chercheront à reproduire l'expérience partout sur la planète.

La tendance printemps/été de l'agilité est à l'entrepreneuriat.

En effet, l'agilité nous a enseigné comment faire pour réaliser nos logiciels. Maintenant que nous maîtrisons notre processus de création logiciel, nous aimerions bien pouvoir faire de l'innovation et des produits qui rapportent.

Venez découvrir dans cet atelier les bases du Lean Startup et mettre en pratique des outils comme le Lean Canvas sur un cas concret. Ces outils vous permettront de matérialiser le premier Business Model de votre produit et de vous mettre sur les rails de l'apprentissage : quels seront mes utilisateurs, quelles sont les hypothèses de mon plan, mon produit est-il viable? Puis, nous verrons comment itérer sur ce premier plan.

Le Lean Startup est-il la prochaine évolution de l'agilité? Venez essayer et en discuter!
Atelier : 20 personnes max.

Essais, erreurs, manipulation et partage seront les maîtres mots de cet espace.

Si vous avez un truc qui marche, un machin qui marche pas encore, ou un bidule que vous n'avez pas encore essayé, c'est le moment de venir avec. Si vous êtes curieux de manipuler et que vous n'avez pas peur de vous tâcher, venez-aussi !

Pas de slides.
Pas de blah blah.
Avec un clavier sous les doigts.

(Si vous avez un laptop, venez avec.)
300 participants au maximum.

Avez vous remarqué que l'on échange des idées plus librement et de façon plus riche au cours de discussions informelles autour d'une table de café ? Oui sans doute.
C'est le but du World Café : créer des espaces d'échanges autour d'un thème, collecter les idées, bâtir sur celles déjà exprimées, et repartir éclairé de nouveaux points de vues.

Vous souvenez vous des valeurs Scrum ? Non pas celles-ci, ce sont celles d'XP, celles de Scrum. Oui ? Non ? Pas grave on va les rappeler, et surtout au delà des mots vous allez explorer ces valeurs en assemblant vos points de vue.

Format = Atelier interactif pour 30 pers maxi - sur 1h30
Animateur = Jf Jagodzinski