SFEIR, la métamorphose Agile

Sujet de saison : la rétrospective

Gaelle — Thu, 05 Jan 2012 12:56:00 +0100

En cette période de vœux et de résolutions quoi de mieux qu’une note sur la rétrospective ! Car que sont les résolutions si ce n’est une sorte de rétrospective de l’année écoulée, et des souhaits pour que la suivante nous paraisse plus productive, agréable ou décisive selon les cas. Je ne parle pas ici des vœux types, que l’on oublie aussi vite qu’on les a émis, mais des vrais résolutions, celles qui ont une réelle influence sur notre vie, privée ou professionnelle. En cela l’exercice des résolutions de début d’année est similaire à celui recherché lors d’une rétrospective de sprint. Par son déroulement ritualisé, la retro doit permettre aux participants, non pas de faire une liste de souhaits irréalisables, mais de déterminer quelques axes d’amélioration.

Cette cérémonie semble souvent déviée de son but initial, et quand elle n’est pas supprimée, par manque d’intérêt ou ‘de temps’, elle peut très facilement dériver vers un bilan rapide du sprint passé, en occultant l’aspect de recherche d’amélioration pour les suivants.

C’est partant de ce constat, que durant le dernier laboratoire Agile Sfeir, nous nous sommes penchés sur le sujet, cherchant des pistes pour dynamiser les rétrospectives et un déroulement pouvant servant de trame, où chacun pourra piocher. A la fin de la session, un challenge a été proposé aux participants : sélectionner un ou deux exercices parmi la liste proposée et tenter de les introduire dans le déroulement des rétrospectives à venir. Le résultat de ce challenge sera connu au prochain laboratoire… En attendant j’ai pour ma part eu la chance de pouvoir présenter l’équivalent de notre atelier aux Scrum Masters du projet auquel je participe, qui ont bien accueillis cette ‘rétrospective de rétrospectives’ . En attendant de voir les changements qui en découleront... Voici la trame que nous avons établie, qui est à adapter pour chaque équipe bien entendue, la rétrospective restant une exercice interne à celle-ci.

Ouverture de la cérémonie :

Vote de confiance

Objectif : définir le niveau de confiance des présents vis à vis des personnes présentes

vote anonyme
de 1 à 5
Si un seul vote en dessous du seuil donné (ex 1) : la retrospective est annulée, et le Scrum Master travaille avec chacun en individuel

Vote d'itération

Objectif : Chacun note l'itération passée, et devra répondre à la question : "qu'aurait il fallu pour mettre juste un point de plus ? »

vote non anonyme
de 1 à 5
permet de commencer à récupérer les informations

Exemples d’exercices d'animation pour récupérer les axes d'améliorations

Keep-drop-start

chacun note sur des post-it ses impressions sur

Ce qui fonctionne pour l'équipe
Ce qui ne va pas
ses intérrogations
les choses à commencer

timeline

Sur une ligne de temps, chacun va aller positionner les faits qu'il considère comme marquants, en positifs ou négatifs

radar "motivation"

Chacun note son ressenti sur les critères suivants

son autonomie
sa maîtrise des technologies utilisées
sa vision de la finalité du travail de l'équipe

==> un radar peut alors être réalisé individuellement, puis pour l’équipe

Résolution des problèmes soulevés

Selon la quantité de problèmes soit tous les résoudre, soit effectué un vote pour déterminer les thèmes à traiter en priorité lors de la session.

Définition du 'backlog' de sortie de retro

Pour les tâches nécessitant un investissement en temps, ne pas hésiter à les inclue dans le backlog du sprint suivant .

ROTI

Retour sur le temps investi
Vote simultané des participants sur la rétrospective en elle-même

boite à idées pour l'animation de la rétrospective

bouger! : le fait de ne pas toujours rester assis autour de la table, mais de créer des ateliers de travail, peut aider au dynamisme de la rétro
Timeboxer : partir d'un temps fixe, et s'y tenir : en moyenne 1h pour une IT de 2 semaines.
Changer d'animateur : dans certaines équipes, il peut être bénéfique pour améliorer la communication ou l'interet, de changer d'animateur à chaque retro.
Définir des responsables pour les taches à effectuer

Cette trame ne doit pas être un frein à la rétrospective mais juste une aide, à enrichir, modifier et faire vivre selon les équipes.

Sur ce, je souhaite à tout le monde une très bonne année, pleine de vraies résolutions et de rétrospectives productives…

Notre quatrième Laboratoire Agile

Djamel — Tue, 05 Jul 2011 20:43:00 +0200

Le 18 juin dernier s'est tenu notre dernier Laboratoire Agile dans les locaux de SFEIR à Suresnes. Au programme :

Une présentation de GTD (Getting Things Done) par Jonathan VERRECCHIA.
Une présentation de Scrum et Kanban par Ganiyou AKADIRI
Un bref retour d'expérience par Djamel FERRADJI
Notre traditionnel Agile Game de fin de session proposé par Oana JUNCU : le Ball Point Timing

Atteindre "l'état de Zénitude totale" ?

C'est en appliquant au quotidien GTD que Jonathan arrive à cet état. La méthode GTD peut s'appliquer aussi bien dans la vie professionnelle que dans la vie privée. Elle est adaptée dès lors que l'on accumule les facteurs favorisant le stress : toutes ces choses que l'on doit faire, toutes ces "petites boucles" (ces taches que l'on doit réaliser et qui nous reviennent en mémoire au cours de la journée et qui polluent notre vie quotidienne.)
GTD permet de supprimer ces "petites boucles", de réduire le stress et de ce fait d'augmenter la productivité au quotidien. On est plus serein : la créativité revient alors, et le temps pour les choses importantes est au rendez vous.
Comment GTD permet cela ? Lister toutes les taches à réaliser, puis les organiser par thème :

Les TODO : TODO Home, TODO Work, TODO Home ou Work (=TODO Commun)
Celles à mettre dans un agenda (les Rendez vous, les taches ponctuelles)
La liste "Un jour peut être"

Quand l'ensemble des listes est vide, il est possible d'aller voir dans la liste "Un jour peut être" : C'est celle où nos envies, où nos souhaits sont répertoriés.
Des outils sont à disposition pour pouvoir gérer ces listes : Google Task Canevas (au travers de Gmail), des plugins navigateurs, des applications mobiles.
Quelques conseils donnés par Jonathan :

limiter le nombre de point d'entrée (idéalement garder le mail et bannir la messagerie du téléphone mobile)
si une tache prend mois de 2 minutes, la réaliser immédiatement
savoir déléguer si on n'est pas la personne la plus qualifiée pour réaliser une tache

Ainsi, lorsque la liste de tache est vide, on arrive à un sentiment de libération. Le potentiel créatif est augmenté, le stress disparait et le sentiment de "zenitude totale" s'installe.

Jonathan nous a également parlé de la technique du Pomodoro : afin d'éviter toute interruption extérieure (source de diminution de productivité), chacun dans un groupe se met à travailler durant 25 minutes (c'est la durée où l'on est le plus efficace). Un outil pour mesurer le temps commun est à disposition à l'adresse suivante : tomatoi.st

Merci à Jonathan pour sa présentation : il était vraiment convaincu par GTD et très enthousiaste. Le sentiment général des participants était que GTD paraissait plutôt être une méthode de motivation.

Scrum vs Kanban par Ganiyou

Qu'est-ce que Scrum ?'' Il s'agit d'une Méthode Agile dédiée à la gestion de projet et qui focalise l'équipe sur un même but. Elle intègre le client durant tout le projet Elle permet d'augmenter la productivité des équipes et de coller au plus prêt des besoins du client Elle est constituée de Sprint et se base sur du développement itératif et incrémental. Un produit sera découpé en plusieurs petites fonctionnalités (les User Stories) et le temps sera découpé en périodes (les Sprints) Elle repose sur une organisation constituée des rôles suivants : le Product Owner (le client), le Scrum Master (une personne de l'équipe de dev) et l'équipe de dev A la fin de chaque Sprint le produit est livrée et prêt à être testé.

'' Qu'est-ce que Kanban ?'' Kanban, mot d'origine japonaise (fiche ou étiquette), car mis au point par les usines Toyota. Le principe est une gestion de production à zéro stock. Il s'agit également d'une méthode Agile Il est "Just in Time", i.e. faire ce qu'il faut et pas plus (le "minimum syndical", à un moment précis). Des cycles de production sont mis en œuvre. Contrairement au Scrum, il n'y a pas de rôles

'' Scrum et Kanban sont tous les 2... :''

"Just in Time"
Agile et Lean (=réduction de tous ce qui n'apporte pas de valeur Ajouté)
Pour la limitation du travail à faire
Pour la livraison rapide et fréquente du produit
Pour l'auto organisation des équipes
En organisation du travail par la division des éléments

'' Les différences entre Scrum et Kanban :''

Il n'y a pas d'itération de durée fixe
Scrum gère le temps en Sprint (de ce fait un livrable est attendu en fin de Sprint) alors que Kanban est en livraison continue du produit
Scrum ne permet pas l'ajout de User Story en cours de Sprint, alors que Kanban le permet à condition de prioriser les nouvelles tâches.

Après un bref retour d'expérience sur la mission de Djamel, nous avons clôturé notre Laboratoire Agile par le traditionnel Agile Game. Le jeu proposé par Oana, le Ball Point Timing, consistait à passer dans un temps donné un maximum de balles à chacun des membres de l'équipe. Au delà de l'aspect jeu, nous avons pu nous améliorer au cours des différentes itérations (nous sommes passés de 13 à 45 balles !!) et constater que l'équipe apprend des erreurs pour s'améliorer. On peut faire confiance à une équipe auto organisée : elle est responsable et peut évoluer.

Une première, le Coderetreat Parisien

Oana Juncu — Tue, 05 Jul 2011 11:49:00 +0200

Samedi dernier, nous avons organisé avec Jean-Laurent de Morlhon et Adrian Bolboaca venu spécialement de Lille pour cela, la première session de coderetreat parisien. Avec Adrien, j'avais essayé depuis le mois de mars de mettre cela en place, mais il semblait que la communauté des développeurs parisiens n'adhérent pas à ce concept. La session de samedi dernier nous a montré que ce n'est pas le cas.

Le format

Le coderetreat est une session qui s'organise un samedi, et s'étend sur une journée et sont but est d'améliorer les techniques de développement en appliquant des concepts de code bien formé et des techniques comme le TDD (Test Driven Development). Elle est composé de plusieurs sessions ( maximum 7, d'habitude 6) de 45 minutes de code, une rétrospective de 1à minute et une pause de 5 minutes. A chaque itération des binômes de développement sont formés et le langage de programmation est au choix. Le code produit pendant la journée est pour le même exercice, souvent le jeu de la vie de Conway. Le démarrage est prévu pur 8:30, la fin pour 17:00.

L'objectif

Pendant le coderetreat , les participants sont encouragés à se focaliser sur l'amélioration de ses techniques de développement, non pas de "finir l'exercice". Comme disait Adrian samedi dernière, il n'y a pas d'objectif de performances, le but est de d'apprendre pour s'amuser. Une des règles des codesretreats est d'effacer le code produit après chaque itération. De toute façon les binômes changent et le langage peut aussi être changé. L'initiateur des coderetreats est Corey Hanes, vous pouvez voir comment ça fonctionne sur son site.

Pourquoi un samedi matin à 8:30 ?

La raison de cette programmation est de former un groupe des personnes qui sont vraiment passionnés par l'amélioration de leurs techniques comme développeurs. Ce n'est pas du boulot infligé, c'est pour ceux qui le développement est aussi un hobby : le "coders' garage band".

La session parisienne

L'exercice choisi a été le classique jeu de la vie. La première itération a été libre de choix en terme de recommandation et de règles. Ca a démarré très fort avec Java, JavaScript, Scala et Haskell comme langages.

La 2ème itération a introduit les règles du simple design:

  1. Passer les tests
  2. Le moins de duplication de code possible
  3. Claire : Relever l'intention du code ( le nommage doit être claire, etc)
  4. utiliser peux de composants ( dans le sen d'éléments).

Les élements du simple design se trouvent sur le site de Jerry B. Rainsberger

La 3ème itération a été la plus dure, car le TDD a été introduit dans cette itération. Avec cette itération , tous les problématiques de conception (top-down, bottom-up) se sont relevés. Aussi, une des réflexion à se faire est "Est mon test unitaire vraiment unitaire?". Les règles "TDD as if you ment it" on été expliqués par Adrian tels que décrits sur le site de Gojko Adjic.

La 4ème et la 5ème itération ont introduit des nouveaux règles comme, "renoncer à la "primitive obsession", avoir des méthodes avec seulement 2 imbrications au maximum, exclure les conditionnelles, etc.

La 6ème itération est retourné sur un format libre, mais avec tous les enseignements de la journée. Elle a bien montré que les contraintes son source de créativité et de motivation pour réussir.

Le bilan

Une forte volonté d'amélioration est ressortie de cette première session. Il y a eu même des participants qui sont restés pur une ...7ème itération! Nous sommes partis diner vers 19:00. Quelques retours sur cette session: On peut faire des tests unitaires sur JavaScript TDD n'est pas facile, mais c'est particulièrement bénéfique pour comprendre l'exercice. Binômer est déjà une bonne prémisse pour s'améliorer, car on voit divers approches qui peuvent donner des nouvelles idées.

Eh, oui, ce n'est surement pas le dernier coderetreat à Paris!__

Remerciements

A Adrian Bolboaca, qui est venu de Lille à ces frais pour animer cette session. A Jean Lauren de Morlhon (XEBIA) pour nous soutenir et organiser la mis à disposition de locaux , le déjeuner et et de toute la logistique. A tous les lèves-tôt qui sont venus avec leurs ordinateurs, des petits yeux et un grand enthousiasme pour participer à cette session fun.

Le troisième laboratoire agile

Michelle — Mon, 13 Jun 2011 19:10:00 +0200

La troisième séance des laboratoires agile SFEIR s’est décomposée en trois parties : Tout d’abord une présentation sur la méthode pour rendre une entreprise agile, puis une seconde qui nous a fait découvrir les rétrospectives et pour clore cette session un nouvel Innovation Game « Le jeu des Concepteurs et des Artistes ».

Partie 1 : Comment rendre une entreprise agile

Rendre une entreprise n’est pas chose aisée. L’agilité se construit par des démarches collaboratives à travers des actions concrètes managées de manière agile.Tout ceci peut se décomposer suivant ces différentes étapes :

Démarrer un projet agile : Au cours de cette étape il faut intéresser le client à l’agilité. Pour que le projet puisse aboutir les différents acteurs doivent avoir un bon état d’esprit mais aussi un esprit critique et combatif. L’ensemble des éléments doivent être compatibles. Les jalons sont posés et les différents outils sont présentés comme par exemple le backlog, le paper board et les post-its, ainsi que les process de communications
Bootcamp sur cinq jours : Décor, Story board, Casting, Story board et l’outillage
Accompagnement Agile sur 5 jours : Cet accompagnement nécessite d’avoir un rôle d’observateur afin de pouvoir recadrer et/ou préconiser. Il permet aussi de contrôler qu’il n’y a pas de désaccord dans les échanges MOA et MOE mais qu’il y a surtout une dynamique d’équipe.

Partie 2 : la rétrospective

La rétrospective est le pivot central de l’agilité, elle permet d’améliorer la productivité de l’équipe et s’inscrit dans une démarche d’amélioration continue. Les idées de chacun sont mises à profit. Elle se décompose ainsi :

Check-in : un stand up où chaque participant peut évoquer ce qu’il attend de cette rétrospective. Cette étape permet d’impliquer chacun des participants et donc de conserver un esprit d’équipe.
Collecte des données où est fait le bilan de l’itération précédente. Sont alors identifiés les points forts mais aussi les points faibles.
Explorer : pour chaque fiche, un maximum d’informations doit être recueillies afin d’identifier les axes d’amélioration à mettre en place. Cette analyse des fiches permet de découvrir ce qui a bien fonctionné, comprendre ce qui n’a pas fonctionné et trouver des moyens pour s’améliorer.

Les différentes fiches sont ensuite classées en fonction de leur importance et ce par l’intermédiaire d’un vote.

Plan d’action : lister les actions à mettre en place pour les futurs itérations et qui seront transmises par mail avec

QUOI : l’action à mener QUI : personne chargée de réaliser l’action QUAND : date à laquelle l’action devra être réalisée

Check-out : vote de confiance

A lire:

Agile Rétrospective : Making Good Teams de Esther Derby, Diana Larsen et Ken Schwaber

       Project retrospective de Norman L. Kerth

Partie 3 : Jeu - Les Concepteurs et les Artistes

Dans une équipe il y a deux 2 concepteurs qui décrivent un tableau à réaliser et plusieurs artistes qui dessinent. Trois itérations ont été réalisées afin d’identifier les points forts et les points faibles.

Première itération :

Les concepteurs écrivent en français la description du tableau
La description est soumise aux artistes
Si les artistes ont des questions, ils les soumettent par écrit aux concepteurs
La transmission des documents écrits se fait par un représentant désigné de chaque groupe
L’échange oral n’est pas permis

Deuxième itération :

La description écrite se fait par chaque élément du tableau
Quand les concepteurs sont satisfaits d’un élément du dessin exécuté, ils passent au prochain.

Troisième Itération :

Les concepteurs regardent le dessin le temps nécessaire pour le retenir
Les concepteurs décrivent le dessin aux artistes qui doivent le dessiner
Tout type d échange est permis, sauf l’échange de rôles
Après le début de l échange, les concepteurs ne peuvent plus regarder le dessin

Pour la première itération la rétrospective a fait apparaître qu’un seul artiste était moteur et donc pour la seconde itération l'action a été mise sur la participation de l'ensemble des artistes. Au cours de la troisième itération différents artistes ont participé à la réalisation de chaque élément du tableau ce qui a désorienté l’artiste dessinant le tableau final.

UNE SECONDE SEANCE DES LABORATOIRES AGILES SFEIR

Nicolas — Mon, 09 May 2011 20:48:00 +0200

La seconde séance des laboratoires agile SFEIR avait deux objectifs majeurs : le premier, une présentation des principes d’INNOVATION GAMES, quand au second il consistait à initier la mise en place d’une boite à outil SFEIR destiné aux différents collaborateurs de l’entreprise et leur permettant de débuter sereinement leurs missions en clientèle sur la base d’artefacts fiables, efficaces et surtout adaptatifs (les contextes étant souvent très différents).

Partie 1 : présentation des INNOVATION GAMES

Cette première partie débuta par une présentation théorique des INNOVATION GAMES et se poursuivit par une mise en pratique par deux jeux du panel disponible : SPEED BOAT d’une part et BUY A FEATURE d’autre part.

a) Présentation théorique

Concernant ce que l’on nomme INNOVATION GAMES on peut, à mon sens, retenir les avantages suivants :

- ils facilitent les liens entre les personnes d’une équipe et donc la coopération (ambiance détendue)

- ils permettent de focaliser l’attention des participants en les sortant de leurs tâches quotidiennes

- ils permettent de retenir facilement les messages clés en affichant des résultats exploitable de manière très visuelle.

- Ils gomment le temps d’un jeu les hiérarchies éventuelles d’un groupe (qui entament parfois les potentiel créatif global) => Tous les joueurs sont au même « niveau », puisque soumis aux même règles définies à l’avance.

Ne pas perdre de vue le but de l’exercice : - Ce n’est pas du jeu pour du jeu : obtenir des éléments de décision est le but final

Le déroulement du jeu a toujours trois phases :

1) ouverture : présentations des limites, des règles et de l’objectif du jeu

2) Exploration : les participants se prêtent au jeu et « produisent » des résultats sur la base de propositions diverses et potentiellement divergentes

3) Focalisation du groupe par l’intermédiaire du facilitateur dans le but d’obtenir des résultats exploitables, partagés et satisfaisant pour chaque joueur.

b) Mise en pratique par l’exemple concrets

Les participants ont ensuite pu se lancer dans deux jeux proposés :

b1) BUY A FEATURE – Acheter les évolutions d’une future voiture commercialisable

Rappel du principe : permettre à des individus d’intérêts potentiellement divergents de négocier les évolutions d’un produit de manière rapide, efficace et ludique. Ce que l’on peut retenir est la manière totalement différente d’aborder le jeu pour les deux équipes. La première s’est immédiatement entendu pour éliminer des features et s’est ensuite concentrée sur la négociation d’une liste restreinte d’items – partie fermée La seconde a négocié sur tous les items du début à la fin du jeu – partie ouverte

Liberté prise par rapport aux règles initiales du jeu : en fin de partie, on propose une mise additionnelle, ne permettant pas à un joueur d’acheter une nouvelle feature, mais lui permettant de s’exprimer sur l’évolution sur laquelle il aurait miser ensuite.

L’idée est ici de classer en 3 catégories les items proposés :

- Items achetés de manière concertée

- Items rejetés de manière concertée

- Items achetés selon une volonté individuelle

=> Résultats exploitables. Objectif du jeu rempli.

b2) SPEED BOAT – Contrairement au premier jeu, le sujet du SPEED BOAT est laissé ici à l’appréciation des candidats Rappel du principe : identifier les ‘ancres’ plus ou moins importantes ou contraintes qui empêchent un projet d’avancer (la longueur de l’ancre et le gain de vitesse associé permettant d’identifier l’importance de la contrainte perçue par les participants).

Deux éléments importants ressortent du déroulement de ce jeu

- Définir un départ et une cible permet de compléter et de clarifier de manière efficace le jeu du SPEED BOAT

- L’un des groupes a choisi de regrouper ses ancres à la fin du jeu, l’autre non => Cela tend à montrer que, selon les problématiques exposées, le traitement des problèmes peut se faire par grandes avancées ou non.

Partie 2 : initialisation de la boite à outils SFEIR

La seconde partie de la séance consista en une présentation des premiers éléments d’un objectif de plus long terme : la mise en place d’une boite à outil SFEIR. Elle permettra aux collaborateurs de ne pas arriver les mains vides en clientèle mais munis d’une série d’outils efficaces et adaptatifs pour faciliter leur intégration dans la mission.

Premier ITEM étudié : le backlog produit.

La base de tout projet AGILE.

Une concertation en séance a conduit à définir plusieurs éléments ‘de base’ applicable systématiquement et ce, indépendamment du contexte client. Le format est aujourd’hui un fichier EXCEL (format flexible, agile).

Et maintenant…

Pour la suite des évènements, un wiki va être initié afin que chaque membre de la communauté puisse apporter ses retours d’expérience, enrichisse la panoplie des outils et améliore la connaissance globale du groupe sur divers sujets d’agilité.

Fenêtre sur le Scrum Day 2011

Gaelle — Fri, 29 Apr 2011 22:51:00 +0200

Le 31 mars dernier s’est tenu le scrum day 2011, organisé par le French Scrum User Group. Plus de 25 sessions étaient programmées, il a donc fallu, pour les près de 500 personnes annoncées, faire des choix. Le titre de cet article est inspiré des conférences auxquelles j’ai assistées, où ce qui ressort est l’importance de l’humain dans la gestion des projets. Car si dans chaque session, le cadre Agile a été rappelé, l’accent a finalement été porté sur la ressource première : les collaborateurs. Au-delà des outils utilisés, ou non utilisés, comme pour Harvey Wheaton, qui nous a présenté son retour d’expérience sur l’intégration de l’agilité dans le monde du développement de jeux vidéo, et pour qui rien ne vaut l’affichage sur le mur, même pour le backlog (uniquement photographié, pas même mis sous Excel) : Rien ne sera efficacement réalisé sans une vraie adhésion des intervenants. Comme le rappelle Véronique messager (conférence « ScrumMasters, devenez le coach agile de votre équipe ») : « Les personnes font le succès du projet ». Sa session était orientée plus sur l’aspect psychologique que méthodologique de l’agile : recentrer le rôle du ScrumMaster sur son coté de faciliteur et de protection, devenant la personne qui permet à l’équipe et à chacun de ses membres de s’élever et à prendre confiance en ses capacités. « Confiance », voilà un autre des mots clés de la journée : confiance des membres de l’équipe entre eux, et vis-à-vis du ScrumMaster ; confiance du Product Owner vis-à-vis de l’équipe de réalisation, Confiance du client… Autant d’éléments primordiaux pour être en situation de réussite. Ainsi, lors de son retour d’expérience sur la mise en place d’un proxy PO, Bertrand Dour (conférence « Le product Owner « proxy » . Mise en place de l’agilité dans un environnement à forte culture « cycle en V ») nous expose les difficultés rencontrées quand cette confiance manque à un ou plusieurs niveaux. Dans le cas exposé, le sponsor pour la mise en place de l’agilité était très faible, le métier peut disponible et divisé en plusieurs entités « concurrentes ». La place du PO dans ce contexte n’a pas semblé aisée et, malgré les premiers résultats positifs et un bilan qui l’est tout autant, le climat n’est pas encore optimal pour un « mode agile » tel que décrit dans l’idéal par les intervenants de la journée. Ceci étant surement très liés aux habitudes ancrées de travail en cycle V. Dans tout domaine il est difficile d’admettre que ce que l’on a appris et appliqué depuis longtemps n’est peut-être pas la meilleure façon de faire. Là encore, on frôle des domaines bien éloigné de ce que l’on étudie dans les parcours « informatique ». Dans sa conférence intitulée « Quarante ans de crise, dix ans d’agilité », Laurent Bossavit, de[ l’Institut Agile|http://institut-agile.fr/], nous met face à ces paradoxes : aucune formation Agile existante actuellement, des jeunes diplômés qui doivent « désapprendre pour réapprendre » … Il présente l’Agile comme une évolution de « rupture ». C’est-à-dire comme un produit de niche, se développant à un moment où il n’est considéré comme adéquat par le public, et qui d’évolution en évolution fini par détrôner l’ancien produit phare, en entrainant sa chute (l’exposé est basé sur la comparaison avec le développement des appareils photos numérique, et la « mort » des appareils classiques). Ceci rend l’adhésion plus difficile encore… Et malgré ces discours « humanistes » il est peu probable, que dans des contextes commerciaux demandant toujours plus de rapidité, l’ensemble des conseils de la journée puissent être appliqués et suivi… A chacun d’y piocher ce qu’il peut pour avancer dans ce sens !

Retrospective Facilitators Gathering (RFG) 2011 : L'énergie , le Talent et la Collaboration

Oana Juncu — Wed, 27 Apr 2011 13:10:00 +0200

L'Evénement

La réunion des experts des rétrospectives Agile est une initative appartenant à Diana Larsen et Esther Derby les auteur d'un des livres les plus populaires sur le sujet "Agile Retrospectives, Making Good Teams Great". L'événement réunit des spécialistes dans la facilitation - surtout des coachs Agile des tous les horizons (surtout d'Amérique du Nord et Europe). Il se déroule sur 4,5 jours et le format utilisé est l'Open Space.

L'endroit

Les organisateurs choisissent toujours un endroit particulier, qui favorise l'émulation créative. Cette année, Taos, située dans le New Mexico, en pleine terre des indiens Navajo, a été une fois de plus un endroit étonnant. Chargé de culture, c'était une des destinations préférées de l'écrivain D.H.Lawrence et de l'artiste Nathalie Goldberg.

L'Open Space

Le principe d'organisation de l'Open Space s'appuie sur l'auto-organisation de l'agenda de l'événement par les participants mêmes. Ils proposent des sessions et prennent en charge la facilitation. Les principes de fonctionnement de l'Open Space se basent sur la responsabilité des participants ( "le principe "Bumble-bee", the law of two feet", etc). Cette année, l'Open Space a été facilité par Ainsley Niels , qui est le directeur du programme Agile Open dans le cadre de l'Agile Alliance .

Le bagage des nouvelles et bonnes idées

Plus que les notes prises en sessions (d'ailleurs le format est très interactif, tous les participants contribuent, ce qui laisse peu de temps pour faire l'écolier), ce qui est important est ce qui marque les esprits : des idées, des concepts, des mots avec forte charge sémantique. Nous les prenons dans nos bagages de connaissance au retour, pour les développer, enrichir, partager. Voici ce que j'ai apporté de RFG11 dans mes valises :

Animer des Rétrospectives sur le l'Avenir tel que nous le voulons ou que nous le supposons. Cet exercice permet d'aligner la vision et les objectifs de l'équipe sur le parcours projet.

Affiche les problèmes dans l'espace de "radiation d'informations : Rendre les problèmes visibles permet parfois de les résoudre plus vite.

Distinguer les niveaux d'expérience des niveaux de compétences : Il est utile de réaliser quel est le niveau d'expertise requis dans un contexte donné et avoir des bonnes compétences à ce niveau, plutôt que cibler l'excellence à tout prix. Cela peut être même dommageable, car on risque de déployer de l'énergie inutilement.

Soutenir l’apprentissage d'un groupe: Une démonstration brillante sur la façon sur laquelle la connaissance collective soutient l'avancement d'un groupe, nous a été faite par Diana Larsen via la méthode d’apprentissage WAYK. Cette méthode est utilisée pour apprendre des langues étrangères par la technique des conversations similaires. Diana travaille sur le rapprochement entre WAYK et des techniques Agile.

Vérifier nos présomptions par la double boucle d’apprentissage (Esther Derby) . C'est un de mes sujets favoris car je suis en train d’utiliser une technique de rétrospective via des "questions défi" afin de mettre à l'épreuve nos "vérités établies".

Le creuset des nouvelles techniques utilisées dans les diverses phases d'une rétrospective de la "set-teh Sage" au "take Action". Citons quelques techniques : Future Backwards, Comics Design, Draw your problem, Question Matrix, 2 minutes question, cloud of buzzwords, etc.

Le Continuum de l'Open Space

Un des "phénomènes" les plus forts des évènements comme le RFG est l'échange continu des idées. Réunir un groupe d'experts passionnés par un sujet a des effet bénéfiques sur le sujet même. Les participants continuent à discuter des sujets qui les intéressent en dehors et au-delà de l'agenda établi pour héberger les sessions, dans un nouvel cadre espace-temps sans frontières, un Continuum Open Space.

ScrumDay : tirer le meilleur de Scrum et Kanban => Scrumban ?

Anne Sophie — Fri, 08 Apr 2011 14:53:00 +0200

Pour entamer ma journée au ScrumDay, et parce que je n'avais pas encore pu assouvir ma curiosité sur les principes Kanban, je me suis rendue à la conférence Scrum et Kanban, tirer le meilleur des deux, animée par Antoine Vernois, le renommé Claude Aubry et Fabrice Aimetti. Présentation plutôt interactive avec passage de témoin entre les 3 animateurs, mais qui a parfois manqué de peps. ROTI 3/5.

Le pitch : Scrum est la méthode agile la plus populaire. La transition à Scrum représente souvent un changement radical pour certaines organisations. Venant directement du Lean, le Kanban appliqué au développement de logiciel s’affirme comme une pratique alternative intéressante, en particulier pour les activités de support. La présentation, faite par les traducteurs du minilivre de Kniberg et Skarin, montre comment tirer le meilleur de Scrum et Kanban, selon le contexte.

Scrum et Kanban sont toutes les deux des méthodes Agiles, basées sur l'empirisme (mode itératif), Scrum étant plus cadré, Kanban plus ajustable. Chaque itération se décompose ainsi :

Planifier (au plus près du début de Faire car il est facile d'estimer ce qui peut être fait dans la période immédiatement à venir),
Faire (en projet informatique, Scrum s'adosse souvent à XP - eXtreme Programming)
Livrer (avec revue de sprint),
Améliorer le processus (Kaizen, Inspection et Adaptation : feedback et rétrospective)

...et reprendre au début.

Les différences majeures entre les deux méthodes sont :

d'abord la fréquence différente des actions listées ci-dessus :

quand Scrum impose un enchainement de l'ensemble de ces tâches, Kanban permettra de planifier chaque action à des fréquences différentes (et qui resteraient logiques, ex : livrer chaque semaine, planifier tous les 15 jours, rétrospective tous les mois)

ensuite la gestion du périmètre du sprint :

Scrum aurait tendance à vouloir se conformer au périmètre initial du planning, tandis que Kanban permettrait le remplacement d'une tâche par une autre (si équivalente en terme de complexité et si non entamée) en cours d'itération et selon la priorisation

- puis la gestion du taskboard :

réinitialisé à chaque itération Scrum via le planning game, il est en Kanban plus simplement conservé et alimenté au fil de l'eau. Cependant, pour conserver un volume "à faire" stable par itération, en Kanban, des règles de limitation de l'en-cours sont mises en place pour que le stock de chaque état d'en-cours soit fluide et ne risque pas de devenir un point de blocage. On en profite pour rappeler que les tâches doivent traitées intégralement (état "done").

La gestion des perturbations :
Nos 3 animateurs conseillent Scrum pour une équipe projet qui est ainsi,en cours d'itération, à l'abri de toute perturbation extérieure (impactant la prochaine itération), tout en recommandant plutot Kanban pour les équipes de support ou opérationnelles : la gestion des perturbations est prévue (impact immédiat).
Dans le cas d'une équipe gérant plusieurs projets, le taskboard est unifié. Des codes couleur ou des couloirs peuvent être mis en place, et les sprints successifs seront :

en Scrum, composés de tâches d'un seul projet, pour éviter les perturbations liées au switch de projet/de produit
en Kanban, composés à l'envi, mais de façon équilibrée, de tâches d'un seul ou de plusieurs projets selon les priorités.

Le parallèle entre ces deux méthodes finit par nous mener à la conclusion logique : il faut adopter la méthode choisie à la réalité du projet.

Antoine Vernois, Claude Aubry et Fabrice Aimetti concluent par ces quelques assertions :

Soyez agiles pour la mise en oeuvre du projet
Essayez les choses par vous même
Ne soyez pas trop dogmatiques
Soyez et restez Agiles

Les Laboratoires Agile

Oana Juncu — Mon, 28 Mar 2011 14:03:00 +0200

A l'occasion du printemps, le pôle Agile et Direction de Projets a mis en place les Laboratoires Agile, un espace de découverte, échange et bien sûr, amélioration continue!

La raison d'être : de "l'Agilisation" à la "veille Agile"

Le pôle Agile a la volonté de créer une identité de groupe. Nous comptons construire cette identité à la fois autour des compétences Agile de ses collaborateurs et de leur volonté de découvrir et évoluer dans ce domaine. Les laboratoires Agiles auront comme mission d'être un révélateur de nouvelles vocations, des pistes à explorer; des idées surprenantes et, à la fin de réussir l'alchimie du groupe.

Les Laboratoires Agile sont un espace collaboratif où chaque membre du pôle sera amené à contribuer. Il n'est pas réaliste de penser qu'on peut créer une cohésion, ou faire adhérer un groupe de compétences seulement par une participation passive à une séance de déroulement de présentations choisies sur des critères dont la légitimité n'est pas confirmée.

La cérémonie

Pour les raisons évoquées, nous accordons une attention particulière au protocole de choix de sujets. A chaque session il y a le moment de divergence ( brainstorming sur les sujets intéressants à explorer) et convergence ( vote, sélection et choix) sur le programme de nos prochains ateliers des Agilistes SFEIR. Tous les collaborateurs du pôles seront amenés à contribuer à cet atelier. C'est la condition incontournable pour avoir des résultats pertinents et obtenir le phénomène d'évolution que nous attendons de cet évènement.

Pour maîtriser l'intérêt des laboratoires nous utilisions les protocoles de "check-in" au début des sessions au modèle utilisé dans les rétrospectives, et "ReturnOnTimeInvested" - retour sur le temps investi - à la fin.

L'état d'esprit

Notre groupe partage les valeurs mises en avant il y 10 ans par le Manifeste Agile. Celles qui nous sont les plus chères sont la collaboration comme facteur de réussite sur un projet commun, la co-décision responsable, la cohésion autour d'un but commun , la volonté d'évoluer.

Le calendrier

Les Laboratoires Agile ont lieu tous les 3èmes vendredi du mois après-midi. Le carnet de bord de chaque session sera publié sur notre blog, vous pouvez déjà lire le premier ici.

BootCamp du Laboratoire Agile !

Anne Sophie — Mon, 21 Mar 2011 18:00:00 +0100

Nous sommes heureux de vous relater le BootCamp du Laboratoire Agile SFEIR le 18 mars 2011 !

C'est l'occasion également de vous présenter notre groupe du 1er jour : Cédric, Djamel, Gaëlle, Ganiyou, Michelle, Nicolas, Oana, Tariq, Thierry et moi, un harmonieux mélange d'Agile ready, d'Agile followers, d'Agile users et d'Agile promoteurs (présentés en ordre aléatoire...)!

Sur notre agenda:

1- Thierry rappelle les principes de l'Agilité

2- L'équipe liste et cible ses attentes quant au Laboratoire Agile SFEIR

3- Démo de l'outil de gestion de projets agiles RALLY - Impressions

4- Le traditionnel Shi fu mi

Tour Flash sur l'Agilité

Thierry décrit les grandes lignes de l'agillité en passant par le manifeste Agile qui a fêté ses 10 ans en février (http://agilemanifesto.org/iso/fr/).

Je retiens comme points d'attention les éléments suivants :

- Itérations

il est ardu d'avoir une idée précise du produit final, et qui reste en adéquation avec le besoin actualisé du client, dès le début d'un projet. Le découpage en lots n'est pas forcément la bonne solution pour s'assurer d'obtenir un outil utilisable, car s'il manque une pile au pont, le pont est fragilisé. En revanche, esquisser le pont dans son ensemble peut être une bonne première étape.

- Livraisons régulières

l'importance d'avoir une application toujours opérationnelle et bien commentée : cet argument fort pour la promotion de l'Agile permet aussi un gain important de la confiance du client, et donc facilite la collaboration avec lui, avec les utilisateurs : les tests automatisés, les outils de build automatique, les itérations, ... concurrent à cet état. Alors, est-ce faciliter l'accompagnement au changement ?

- Daily Standup

établit pour chacun une forme de contrat moral passé avec et pour l'équipe du projet auquel on appartient : engagement de contenu, de délais, échange d'information. C'est un rappel quotidien de la poursuite d'un but commun qui sera plus facilement atteint avec la bonne volonté de tous.

- Rétrospectives

où l'on fait un bilan sur la période (le sprint, l'itération) écoulée, mènent l'équipe à la maturité : il faut du courage dans l'échange pour dire et savoir dire, et le faire dans le but d'améliorer l'itération suivante. Même si l'on se sent en terrain connu, que tout avance bien, se demander comment améliorer encore cet état de fait, ou bien comment le transposer à une autre partie du projet qui elle fonctionne moins bien. Ne pas rester dans sa zone de confort, source de stagnation, alors que la zone d'efforts est source de réussite !

- La défense du pair programming

on constate que la concentration du duo en pair programming est largement plus intense, surtout si l'on se coupe des perturbations extérieures (internet, messagerie). Plus spécifique lorsque l'on peut s'attendre à des difficultés pour une tâche particulière : le DOJO : une équipe de développement est constituée pour un sujet donné, et se concentre autour d'un poste de développement sur lequel chacun tour à tour prend la main sur le clavier et participe à son échelle à la réalisation de la tâche.

Qu'attendez-vous des Laboratoires Agile?

Les sujets qui nous chatouillent sont là, sur les post-it, et certains se recoupent et recueillent de nombreux suffrages : ils seront abordés lors des tous prochains Laboratoires Agiles : Comment lancer un projet Agile ? (ASD, TTR, OJU) et Quel outillage Agile pour SFEIR ? (GSA, NTO, OJU)
Suivez-nous, nous entrerons dans les détails bientôt...

RALLY Software

Oana a organisé avec Phillip McKenzie (Rally Software) une conférence téléphonique avec démonstration par prise en main à distance de l'outil RALLY : Rally permet de gérer plusieurs projets Agile par la même interface, et même de suivre la répartition des équipes sur l'un et l'autre projet. La seule contrainte : que chaque projet suive la même périodicité d'itérations.
Il est très intégré, s'interconnecte avec la majorité des outils des grands acteurs du marché : Clear Quest, Mantis, Bugzilla pour le reporting de fiches d'anomalies ou autres, Quality Center, Fitnesse pour les tests automatisés, Hudson, anthillpro pour le build automatique, etc... et reste ouvert à d'autres outils par un simple script
A la fin de la présentation, une floppée de questions est posée à Phillip qui répond bien volontiers. Lorsqu'il aura raccroché, la discussion se poursuit quelques instants.

(RALLY SOFTWARE : http://www.rallydev.com/)

Déjà décrit par Thierry dans un précédent billet comme un des outils les plus polyvalents et de référence, pour le suivi de projets Agile, (sources rapport Forrester), il a quand même suscité l'étonnement (est-il Agile-friendly de permettre de prévoir les surcharges de travail pour un équipier donné, à qui des tâches peuvent donc être affectées ?), mais recueille les faveurs de ceux ayant utilisé d'autres outils en situation réelle, comme Agilo.

Shi Fu Mi

Le débrief sur ce premier après-midi se traduit par une majorité de votes 4 et deux votes 5. Les deux 5 s'expliquent par une adhésion à l'acte fondateur des Laboratoires Agile : la voie est ouverte ! (Ce n'est pas pour rien que ce blog s'appelle On Agile Way) Pour tous, une bonne occasion d'échanger, de progresser, etc...

Le recrutement en mode Agile

Oana Juncu — Mon, 14 Mar 2011 12:25:00 +0100

Nous nous organisons selon le principe "Si on croit que l'Agilité est le meilleur mode de fonctionnement, alors appliquons-le à tous nos services". Le service recrutement en fait partie. Alors, l'équipe Agile de SFEIR a mis en place des séances de coaching interne avec notre équipe de recrutement..

Les 3 raisons pour un recrutement en mode Agile.

Parmi les motivations de" l'agilisation" du service recrutement, les 3 plus importantes sont peut-être les suivantes.

Adopter sur le terrain les valeurs de l'Agilité

C'est difficile d'affirmer de connaître la saveur Agile si on a lu la recette, mais jamais goûté le plat. Comme des éléments d'organisation SCRUM , et Kanban sont facilement adoptables, Anaïs soutient derrière son bureau le Taskboard de l'équipe recrutement.

Soutenir un dialogue opérationnel avec le candidat

Nous pensons que les agilistes ont besoin d'avoir un dialogue sur leur terrain d’intérêt. Rester dans les déclarations d'intention n'aura que peu, voir pas de succès à établir un échange. Le service de recrutement a un rôle majeur à jouer, car on ne peut par reprendre un premier contact, comme on ne peut par faire une première impression. Et il faut donner l'envie de savoir plus....

Etre un bon séismographe Agile :

L’intérêt confirmé doit être partagé par les deux acteurs. Non seulement un candidat doit sortir de l'entretien en pensant avoir passé un moment dans une entreprise Agile, nos chargés de recrutement doivent partager cette impression. Mais comment faire, sans base de connaissance sur les profils? Je ne crois pas qu'apprendre un nuage de buzz-words comme "SCRUM Master", "Product Owner", "Sprint", "XP", "Coach Agile" soit suffisant. De plus il faut "détecter la personnalité Agile". Quelle est cette mystérieuse personnalité? La meilleure façon est d'organiser son travail en mode , disons SCRUM, et observer la dynamique mise en place.

Les Product Owners de l'équipe de recrutement ...

Sommes nous tous les sferienns concernés par la croissance. Voici l'exemple de ma story bien formée en mode BDD :

En tant que "Leader pôle Agile" j'ai besoins que "le recrutement" "organise un Daily Scrum" pour "comprendre les pratiques Agiles

Une TMA Agile. La gestion SCRUM des équipe TMA

Pierre — Thu, 03 Mar 2011 18:06:00 +0100

La TMA, un centre de services

Le rythme de fonctionnement de la TMA est naturellement proche de l'agilité.

!Quels sont les principe de fonctionnement TMA? Chiffre et approuver le développement des évolutions, Planifier les livraisons avec le client, Gérer des nouvelles versions du logiciel dans des nouvelles releases; Gérer le changement par le contrôle continu de la non-régression, Livrer fréquement, etc;

Comment travaillons-nous en projet SCRUM?

Capacité de changement du périmètre en fin de chaque sprint; Définition du périmètre du logiciel sous forme de liste d'user stories (le très populaire backlog) Définition de l'effort de développement pour chaque user story ( compexité vs. charge) Planification du sprint Livraisons sur un rythme itératif d'un logiciel testable

le rapprochement est évident. la mise en place l'est peut-être moins. C'est pour cela que nous oeuvrons avec l'équipe TMA pour "l'agilisation" du plateau TMA. Qui sont nos sponsors? Les Product Owners internes, ceux qui ont le lien opérationnel avec le client.

!!Le plan de bataille

Créer le backlog : sur un plateau multi-projet, quel est le contenu du backlog le plus pertinent? Nous avons décidé de créer le backlog par équipe.c'est un backlog multi-projet. L'estimation ou le planning poker : c'est la clé du succès. Le planning poker est l'activité primordiale pour partager entre les membres de l'équipe de développement la même compréhension de ce qui doit être développé. C'est aussi une pratique hors pair pour responsabiliser les développeurs sur le contenu et la qualité du logiciel qu'ils vont coder. Les sprints . de sprints courts semblent plus pertinents que des sprints longs. La durée choisie est une semaine. En début de sprint, l’incontournable sprint planning aura lieu. Le stand-up meeting (le daily Scrum) - Les 10 minutes pour faire le tour des 3 questions: "Qu'ai-je fait hier, quelles sont les difficultés que j'ai rencontrées, qu'est-ce que je compte faire aujourd'hui?", est aussi une activité incontournable? Le bilan du sprint : mise en place du protocole de réception de la nouvelle version du logiciel La rétrospective : Nous allons nous focaliser sur des formats rapides, l'objectif de chaque rétrospective est de fournir un plan d'action à suivre. Ce qui est important dans les rétrospectives est d'avoir une suite applicable.

Nos défis__ Comment gérer l"adaptabilité et l'implication du client sur des cycles aussi courts? Quels sont les tests d'acceptations pertinents? Comment gérer la non-régression dans un dispositif qui n'a pas été pensé "test-compatible"?

...Mais nous sommes prêts à les relever !

Agilité et Haute Montagne : une rencontre au sommet

Thierry — Fri, 24 Dec 2010 10:39:00 +0100

Quel peut être le rapport entre l'Agilité et la Haute Montagne ? Essayons de décortiquer ce qu'est une expédition en haute montagne.

Tout d'abord, l'histoire commence par une rencontre : souvent un groupe de personnes et un guide. Au début, c'est clairement le client (utilisateur final) dont le but est d'arriver au sommet et un accompagnateur (guide qui possède des connaissances techniques poussées et des ascensions peut être similaires). Ca me rappelle quelque chose...

La première étape est une rencontre qui détermine :

le but (tout le monde partage cette vision) : arriver au sommet,
l'équipe qui va participer à ce challenge
le matériel à prendre (un peu l'architecture et les outils)
la façon d'y arriver, par étapes (détermination du camps de base et des autres camps jusqu'au sommet, un peu comme des itérations...)

Les personnes apprennent à se jauger, se mesurer, et cerner les compétences et facilités de chacun. L'important est de se connaitre, se faire confiance, voir lier des premiers liens et affinités... dans la limite du raisonnable bien évidemment....

Une fois cette vision macro de l'expédition partagée par tous, la date de départ est fixée et l'expédition se lance le jour J. A l'origine de l'histoire, il y a un guide (disons la MOE) et un groupe client (MOA / utilisateurs finaux). Une fois la cordée lancée, chacun connait sa place, mais il n'y a plus qu'une équipe solidaire, prête à affronter les intempéries ensemble. C'est une vraie équipe projet qui n'a plus qu'une seule obsession : le sommet, la réussite du projet. La cadence est celle du groupe et non celle d'un individu, même si le guide joue le rôle de garant et surveille la cadence. Ne serait ce pas un scrum master finalement ?. Le rythme est soutenu mais soutenable. Le groupe est solidaire et est lié par une corde. Cela ressemble beaucoup à une itération : le but est de mener l'équipe au camp suivant, Tous sont liés par la corde.

A l'arrivée au camp, c'est l'heure du débriefing (tiens, une rétro ?). Chacun met sur la table sa vision de ce qui c'est bien ou mal passé. Ceci afin de s'améliorer pour le lendemain et éviter peut être de commettre des erreurs similaires.

La Haute montagne semble donc être un exemple naturel de la mise en pratique de l'Agilité. Les similitudes sont assez nombreuses. Ce sont des pratiques rigoureuses mises en oeuvre dans un milieu, parfois difficile, voir hostile, mais avec un haut niveau de satisfaction de la part des participants et un succès très souvent au rendez vous.

Le backlog peut il contenir des stories techniques ?

Thierry — Fri, 03 Dec 2010 10:28:00 +0100

Bonne question souvent posée, mais souvent évitée... Essayons de voir ce qu'il en est.

Quelle est l'origine de cette question ? Dans les différentes DSI, on souffre souvent du clivage MOA/MOE. La MOA voyant le côté utilisation par l'utilisateur final d'un produit; La MOE souhaitant y apporter des améliorations techniques. La méthodologie Agile se veut fédératrice en amenant tous les intervenants à partager une vision produit. C'est pourquoi le backlog contient généralement des stories apportant une vision "utilisation finale" du produit. Mais pour définir un produit ne faut il pas se poser au moins deux questions : à quoi ça sert ? De quoi est-il fait ? En effet, son utilisation peut être optimisée si sa matière suit les avancées technologiques. Une raquette c'est fait pour jouer au tennis, mais c'est bien mieux en matériaux composites plutot qu'en bois...

Alors pourquoi hésite-t-on à mettre des stories techniques dans le backlog ? Tout simplement parce que l'on parle de "user stories" et que cette connotation de user est purement fonctionnelle. On pense immédiatement à l'utilisateur final du produit. Le développeur, le futur exploitant du produit ou simplement un batch peuvent pourtant être définis comme des users du produit. Ils ont dans ce cas pleinement leur place dans le backlog en tant que users. Dans une application, créer un service qui sera utilisé par un batch peut être considéré comme une storie technique, et elle doit bien figurée dans le backlog. On obtient alors : "En tant que batch bidule, je récupère les données blabla à l'aide du service truc afin de les agréger". Néanmoins, il faut conserver la vision produit et amélioration de celui ci. Une storie technique doit amener quelque chose en plus, que ce soit une facilité d'exploitation ou de maintenance. Par exemple, des états faits sous poi et/ou itext peuvent être refondus en Jasper, qui apporte, via eReports, une facilité d'utilisation et de l'indépendance en termes de design de l'état. Le backlog demeure la responsabilité du Product Owner et il s'agit de le convaincre de l'utilité de cette storie technique. Charge à lui de l'inscrire au backlog. Bonne négociation....

Agile Tour PARIS 2010

Oana — Thu, 04 Nov 2010 13:00:00 +0100

La session parisienne de l'Agile Tour 2010 s'est déroulée dans les locaux de la FIAP, un espace convivial, confortable et très professionnel.

Comme dans toute conférence intéressante, le programme propose des sessions intéressantes, qui donnent envie d'être écoutées toutes. C'est dur d'être dans 5 salles en parallèle, et c'est encore plus dur quand pour ceux qui font partie d'équipe d'organisation.

Pour ma part, je me propose d'être plus présente l'année prochaine, pour cette année les autres organisateurs ont fait des merveilles en étant partout!

Très intéressante la session de Damien Thauvenin sur l'implémentation de Kanban avec ses clients et l'utilisation d'un plateau multi-projets / même équipe, pour optimiser les flux et gérer les stocks des demandes. La formule de la mise en place du processus Lean entre les clients et les fournisseurs est vraiment à retenir pour tous ceux qui souhaitent faire du développement Agile onsite. Bon, ça ne résolue pas les problématiques de positionnement du Product Owner, mais j'ai retenu un terme très adapté aux projets Agiles sur le terrain:

le "Proxy PO".

Joli essai également sur "l'Agile insoutenable", ou comment on peut - par des mauvais réflexes et pratiques implémenter "l'Agile Tayloriste";

Ne pas avoir pu participer qu'a deux session, je reste avec l'impression qu'il a eu peu d'ateliers, mais elle peut être fausse.

les participants à mon atelier la mesure et la perception du succès de l'Agilité venant su mode 'Chaos" ou réglementé "Cycle en V" se sont pris au jeu et ont défini leurs attentes en terme de dynamique Agile. Le résultat a été plus concentré sur les valeurs partagées de l'Agilité que dans les objectifs recherchées dans la mise en place d'un projet Agile en venant des 2 mondes. Est-ce que cela veut dire que l'histoire et l'expérience de chacun compte moins que ce que nous souhaitons atteindre?

Interview Thierry Trepied

François Wauquier — Fri, 08 Oct 2010 16:53:00 +0200

· Pouvez-vous vous présenter rapidement ?

Ma participation à des projets de grande dimension (refonte du SI de TF1 Publicité menée par Accenture), puis mon rôle de Responsable Etudes et Développement d’AIG Marketing Europe France (Marketing Direct dans le monde de l’Assurance), ont été des expériences significatives dans la recherche d’une méthode projet optimale. En intégrant la DSI de M6, j'ai mis en pratique les méthodes Agiles (Scrum et XP). Convaincu par cette vision projet, j'intègre SFEIR an avril 2010 en tant que Directeur de projets et Coach Agile.

· Qu'est-ce que l'agilité pour vous ?

Une méthodologie qui permet de fournir un produit très rapidement et le plus en accord possible avec les besoins métier, dans un contexte d'échanges, de confiance et de découverte.

· Le manifeste agile prône les valeurs suivantes:

1. Les individus et les interactions plutôt que les processus et les outils

2. Un logiciel qui fonctionne plutôt qu’une documentation détaillée

3. La collaboration avec le client plutôt que la négociation de contrats

4. Accepter le changement plutôt que suivre le plan

Laquelle de ces valeurs est la plus importante selon vous ?

Les "individus et les interactions" car de ce principe les autres peuvent en découler.

· Quelles méthodologies agiles connaissez-vous ?

Scrum et XP pour la mise en pratique. Lean pour quelques notions.

· L'agilité, est-ce plus : de la gestion de projet, de l'ingénierie logicielle, de l'organisation d'entreprise ?

C'est une façon de penser et de faire. C'est donc adaptable à tout type de contexte que ce soit MOA, MOE en informatique ou un autre secteur de l'entreprise. Scrum est plus de la gestion de projet et XP plus côté développement. Le lean a souvent été employé dans les organisations de type industriel (né chez Toyota).

· Qu'est-ce que l'agilité change pour le développeur ?

Il devient autonome, prend part aux décisions, dialogue avec le client et est facteur d'amélioration et de qualité.

Il a désormais une vision complète du besoin, connait les objectifs et les contraintes. Dans un cycle classique, on lui attribuait une tache à effectuer dans un certain temps...

· Qu'est-ce que l'agilité change pour le manager ?

Le suivi est quotidien; Il connait exactement l'état d'avancement de son application et ce n'est plus un chiffre sur un planning donné un peu au pifomètre (le célèbre "on en est à 80 %"...)

· Qu'est-ce que l'agilité change pour l'utilisateur ?

Le produit devient ce dont il a besoin à l'instant t et non une demande formalisée il y a 6 mois, voir plus. Le produit colle au métier et donc répond précisément à ces attentes.

· Qu'est-ce que l'agilité change pour vous, à votre poste chez sfeir ?

Si j’ai rejoint sfeir, c’est pour pratiquer l’agilité…

· Comment les technologies RIA peuvent-t-elles faciliter la mise en place de l'agilité ?

Je ne suis pas sûr du lien entre technologie et agilité. Elles introduisent un facteur d'échange plus important avec l'utilisateur car les possibilités de mise en place graphique sont variées, ce qui n'est pas le cas avec un écran type AS400...

· Quelles évolutions avez-vous vu dans le paysage informatique avec l'apparition des méthodes agiles?

Les échanges entre SSII et client final n'étaient auparavant basés que sur des contrats. L'agilité a amené de la confiance et des échanges plus intenses et si possible sur du long terme. Mais c'est surtout du point du développeur qui n'est plus un pion dans un espace de travail mais une personne avec un nom qui échange directement avec le client.

· Voyez-vous des convergences ou des divergences entre l'agilité et CMMI ?

Je ne connais pas trop CMMI, je passe ;)

· Que pensez-vous du "lean software development" ?

Je (re)passe...

· Quelles sont les différentes prestations agiles proposées par Sfeir ?

Tout ce qui concerne l'agilité, de la découverte et la formation, à la mise en place d'un centre de services en passant par du coaching.

· Comment abordez-vous les aspects contractuels d'une prestation agile ?

Nous prônons un système de confiance et si possible à long terme avec le client. Le mode régie est donc le bienvenu.

LE Manifeste Agile traduit en francais

François Wauquier — Fri, 08 Oct 2010 16:25:00 +0200

The Agile Manifesto a été traduit en français.

C'est l'alliance Agile qui a créé ce programme, avec à sa tête Henrick Kniberg , auteur de Scrum XP from the trenches et Kanban and Scrum, que je vous recommande au passage.

12 langues ont maintenant leur version et 18 autres sont en préparation.

Pour la version française, bravo à Club Agile Rhône-Alpes, Arnaud Pierrel, Bruno Orsier, Christophe Deniaud, ainsi que Claude Aubry, François Beauregard, Laurent Bossavit, Nathalie Gilbert et Alexandre Boutin

Le Product Owner Agile : peut-il être multi projets ?

Thierry — Tue, 05 Oct 2010 14:36:00 +0200

S’il y a un rôle déterminant dans la méthodologie Agile, c’est celui de Product Owner. Il doit être présent et à disposition de l’Equipe, prioriser, spécifier et valider les stories. Tout ceci dans un laps de temps d’une itération. Son implication et sa capacité à alimenter l’Equipe sont les facteurs majeurs de réussite du projet.

Dans ces conditions, doit-il se consacrer à 100 % à son projet ou peut-il être multi projets? Et dans ce cas, comment être multi taches ?

Au cours d’une précédente expérience professionnelle, j’ai appris à pratiquer la méthodologie Agile. Pour débuter, j’étais Product Owner d’une application à développer « from scratch ». Je me suis consacré à ce projet à 100 % pendant une durée de 9 mois environ avant de devoir prendre dans mon escarcelle d’autres projets en cours, orphelins de PO.

Cette phase d’apprentissage a fait ressortir quelques points :

le PO a au moins une itération d’avance de spécification sur l’Equipe ;

il doit toujours avoir à l’esprit la vision et la version de son produit à livrer et le partager avec l’Equipe ;

plus il teste l’application tôt (si possible dès la livraison de la fonctionnalité), moins il a à gérer les retours.

L’augmentation du volume de mon portefeuille projets m’a amené à travailler de la façon suivante :

constituer une équipe de « Product Owners »

de ce fait, déléguer un certains nombres de taches (par exemple écriture des cas de test)

au fil de l’eau, se désengager des projets « qui roulent »

Pour se faire, j’ai recruté un analyste, pour qui le métier était inconnu, mais avec un esprit clair, ouvert et vif. Je l’ai formé sur le « projet qui roule » en méthode Agile :

Au début de chaque itération, je spécifie les règles de gestion métier, les cas de test à la marge. Il se charge alors d’établir les cas de test ;

Nous itérons également sur un passage de connaissance métier lié au différentes stories à traiter.

Il participe aux ateliers de travail utilisateurs afin de s’imprégner de leur vision, de leurs besoins et d’un langage métier.

Petit à petit, il prend en charge la recette des fonctionnalités livrées par l’Equipe.

A ce stade, je reste encore le PO, mais nous entrons dans une phase où nous pouvons être considérés comme backup l’un de l’autre. Les seules différences entre nous deux sont :

Une connaissance métier plus approfondie due à mon passif (difficile à changer…) ;

Je suis interne et il est externe. Mais est-ce une condition nécessaire pour être PO ? A priori non dès l’instant où il peut s’appuyer sur une MOA interne à forte disponibilité.

Etant donné cet état de fait, je me positionne désormais en backup et le nomme PO du projet. Il le prend dorénavant en charge de bout en bout, et sait qu’il peut compter sur moi en cas de besoin.

Ce cycle de formation à la méthode, passage de connaissances métier et endossement de la cape de PO a pris environ 3 mois.

Il est évident qu’il s’agit d’une charge de travail supplémentaire, mais étant donné qu’il a pu monter en compétence rapidement sur la rédaction des cas de test (Fitnesse) et recetter les stories, c’était aussi une charge de travail en moins. La constitution d’une équipe PO s’est avérée comme étant une stratégie payante. Il faut cependant être très claire en termes de communication vis-à-vis de l’Equipe (qui est le PO référent ?) et savoir se coordonner précisément sur les fonctionnalités à embarquer.

26/05/2010 - Thierry TREPIED Directeur de projets – Coach Agile SFEIR Groupe

Synthèse du rapport Forrester

Thierry — Tue, 05 Oct 2010 14:22:00 +0200

Publié le 06/05/2010, ce rapport donne une évaluation des outils du marché sur ADM (Agile Development Management Tools). Il s’agit d’apporter les fonctionnalités des outils ALM à la gestion des projets Agiles. Outre cette approche orientée évaluation des outils (mise en évidence de leurs faiblesses ou de leurs points forts), il permet surtout de faire un état des lieux du marché sur la pénétration de la méthodologie Agile.

Une méthode innovante devenue la norme

35 % des organisations mettant en place des projets informatiques le font en méthodologie Agile. Cette méthode ressort comme étant flexible, intéressante pour les développeurs, dynamisante pour l’Equipe. Il en résulte néanmoins que dans le cadre d’un suivi, les « post it » sont très vite dépassés si plusieurs projets sont gérés en parallèle. De plus il s’avère que ce marché est porteur pour les éditeurs… D’où ce besoin de mise en place d’outils destinés à une gestion de projet automatisée et un suivi de plus haut niveau des projets.

Les pré-requis

- Partager l’information en temps réel quelque soit la localisation, le nombre de projets en cours. Intégrer une gestion de projets industrialisée (reporting) à la méthodologie Agile. - L’Automation : une évidence dans l’intégration continue, les tests automatisés, … - La rétrospective : récolter les informations lorsqu’elles surviennent et les réutiliser.

D’après Forrester, la montée en compétence en Agile pour l’équipe est basée sur 2 points : - les projets doivent accepter les changements et mettre en place une intégration continue. - Les managers « responsables produits » doivent répondre rapidement au besoin business même si ceux-ci sont définis sur des roadmaps annuelles.

Une vision projet à différents niveaux

Le diagramme ci-dessus montre que les besoins de reporting de l’Equipe projet (contrôle de l’avancement itératif) font partie intégrante du besoin en reporting du management (vision produit voir dépendance multi produits). La visibilité du projet doit être très précise au niveau du développement (quotidienne, suivi de taches) alors qu’elle est plutôt macro au niveau du management (quotidienne également, mais avec une vision produit).

« Scrum, oui mais… »

Scrum est majoritairement utilisé mais chacun a tendance à se l’approprier et à l’adapter. Par exemple la validation d’une story peut avoir lieu selon les cas lors des tests, ou encore lorsque les tests automatiques passent ou encore suite à une revue de code. D’autre part, la combinaison de Scrum et de XP devient monnaie courante. Scrum est une méthode idéale pour débuter l’Agilité, c’est à priori la meilleure approche, néanmoins il est nécessaire de la compléter d’une boite à outil en vue d’un besoin de suivi et de management du process. La grille d’évaluation prend en compte cet aspect modulaire de Scrum.

Une planification a 3 niveaux : - produit - itération - individuel

En vue d’automatiser cette vision planning à tous les niveaux, Forrester a étudié les forces et faiblesses des 10 premiers acteurs du marché. La grille d’évaluation est basée sur 152 critères répartis comme suit : - 117 portés par l’offre de l’outil - 20 sur sa vision stratégique - 15 sur son taux de pénétration du marché Agile

Ci-dessous le diagramme montrant la répartition des éditeurs en fonction de la grille de critères (Offre, vision stratégique et présence sur le marché) :

Pour résumer

IBM et MKS sont les deux acteurs les mieux placés actuellement sur le marché. Atlassian, CollabNet, et Microsoft ont des stratégies agressives qui devraient s’avérer payantes dès 2010. Rally Software offre le meilleur équilibre entre la capacité de ses produits et ses perspectives stratégiques. HP, Serena Software sont nouvellement intégrés sur la marché et devraient prendre de l’ampleur. VersionOne manque de souplesse.

Enfin ce dernier tableau peut aussi orienter le choix de l’éditeur car il présente le coût des licences :

En complément de cette synthèse, vous pouvez retrouver le podcast : “Agile ADM Tools Wave: Surprises And The Future Of ALM.”

Retour d’expérience : la perception Utilisateur de la méthodologie Agile

Thierry — Tue, 05 Oct 2010 14:20:00 +0200

La méthodologie satisfait très majoritairement tous ceux qui la pratiquent et sa prise d’ampleur le confirme. Peut-on alors parler de succès limité à la conduite/gestion de projet ou étendre ce succès aux clients/sponsors des applications ? En particulier le « client final » (utilisateur de l'application) s’y retrouve-t-il ?

Chaque cas est bien évidemment particulier sachant que la mise en place de la méthodologie peut être soit portée par la gestion de projet (scrum) soit portée par le développement (XP).

Même si dans la majorité des cas ce sont les deux qui vont de paire...

Je fais donc le choix d'utiliser ma propre expérience afin de mettre en exergue les difficultés rencontrées et les succès majeurs de cette méthode. Tout d'abord, plantons le décor : nous avons appliqué Scrum (AMOA) combiné avec XP (plateau de développement composé de prestataires). Je suis client (chef de projet / product owner) de plusieurs applications :

1er cas : un projet de refonte d’une brique du SI,

2ième cas : un nouveau projet (application from scratch),

3ième cas : un projet « purement technique » (mise en place d’un ESB).

Les utilisateurs concernés sont des populations métiers bien différentes et ont une vision distincte des applications.

Considérons chaque cas :

Dans le 1er cas, l’application souffre d’un comparatif avec l’existant en plus de nouveaux besoins à implémenter. Dans un premier temps, l’application a été découpée en 3 lots distincts afin de pouvoir délivrer en 3 phases l’application complète. Un suivi de projet utilisateur en alternance avec les planning games est mis en place. Les utilisateurs sont porteurs et très enthousiastes quant au fait de voir l’application grossir en emportant leurs besoins. Cette satisfaction va de paire avec la volonté de voir leurs nouveaux besoins apparaître sachant que la refonte (éléments de base) n’est pas encore terminée… Puis vient la date fatidique de mise en production du lot n°1. Et là patatra : « on ne peut pas mettre en production une application qui ne couvre pas tout le périmètre ! ». Est-ce un problème de communication de la part de l’Informatique ? A priori non, car ce découpage et ce lot de livraison sont en permanence rappelés. Il s’avère que l’utilisateur n’est finalement prêt à basculer que si son environnement de travail bascule d’un coup. Il ne conçoit pas de gérer une partie des données dans l’ancien système et l’autre dans le nouveau. La méthodologie a dans ce cas complètement satisfait les utilisateurs, même s’ils n’ont pas eu l’occasion de profiter de mise en production incrémental plutôt qu’une bascule complète vers cette application. L’Equipe quant à elle, est surmotivée par cette application qui leur permet de s’exprimer pleinement avec des interfaces riches, et une méthodologie de développement ultra communicante en accord avec leur façon de voir les choses.

Dans le 2ième cas, il s’agit de mettre en place une application, qui par la même occasion, met à plat les interactions entre trois services allant du back au front office. L’application est rapidement développée mais sa mise en place est décalée, ceci à cause d’un point purement business. Une fois en place, elle est vécue dans un premier temps un peu comme une contrainte car chaque service voit alors clairement les dépendances les uns vis-à-vis des autres, puis elle devient enrichissante car facilite les échanges et évolue très rapidement. Cette facilité de l’Agile est exploitée de façon très poussée par les utilisateurs et donc répond très bien à leur besoin. Par contre, l’Equipe le vit beaucoup moins bien car ils ont l’impression de faire et défaire en permanence : « pourquoi se presser puisque de toute façon on va revenir dessus… ». Même si, en tant que Product Owner, je remonte le fait que l’application est très satisfaisante pour les utilisateurs, le moral de l’équipe est difficilement maintenable au beau fixe et la lassitude se fait souvent sentir. De ce fait, la méthodologie est de temps en temps ressentie comme une contrainte (peu de binômage), même si de leur point de vue, aucune autre méthode n’est envisageable.

Enfin le 3ième cas est plus un projet technique et je suis donc l’utilisateur final est tant que PO et chef de projet. Chacun des deux premiers exemples entrainent un besoin à mettre en place dans cet ESB. De ce fait, la méthodologie Agile répond parfaitement car on ne sait pas réellement ce que l’on doit mettre en place dans cette application et on le « découvre » pour la prochaine itération. La façon de concevoir cet ESB sous forme de scénarios a satisfait d’une part le client dont le besoin émergeant est pris rapidement, et d’autre part l’Equipe qui voit les fruits de ses efforts utilisés peu de temps après leur développement.

En conclusion chaque projet a été ressenti de façon différente :

par les utilisateurs finaux selon le périmètre de l’application, l’impact sur les process métier. Le point commun remonté est le fait que, grâce aux livraisons itératives, ils ont à disposition un produit fonctionnel qui leur permet de valider rapidement la conformité avec le business ;

par l’Equipe, selon la variété du produit, l’utilisation du refactoring et le résultat de leur travail qui était utilisé rapidement ou non.

La méthodologie a fait l’unanimité, même s’il convient de bien réfléchir à la façon de la vendre auprès des différents intervenants afin de ne pas les frustrer quand à la rapidité avec laquelle sera mise en place la produit.

11/05/2010 - Thierry TREPIED Directeur de projets – Coach Agile SFEIR Groupe