Méthodes Agiles… l’article le plus lu sur Qualitystreet!

Posté par jc-Qualitystreet le 22 juin 2012

“Méthodes Agiles: une belle définition” est un article que j’ai écrit en nov. 2007. C’est actuellement l’article le plus lu sur Qualitystreet… il méritait bien un petit focus. Les commentaires de l’époque sont également SAVOUREUX Sur ceux là, je dis COLLECTOR!

Pour ceux qui veulent lire l’ORIGINAL: Méthodes Agiles une belle définition

Le coaching agile est une activité qui a le vent en poupe, mais quand on parle d’agilité, de quoi parle-t-on exactement?

Méthodes Agiles: une belle définition

Celle de Veronique Messager Rota, dans Gestion de projet : Vers les méthodes agiles :

“Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients”

Voilà qui est clair, précis et tout à fait fidèle aux 4 valeurs et 12 principes de l’Agile Manifesto, ce signal fort lancé en 2001 par 17 personnalités de l’industrie logicielle (Beck, Cockburn, Fowler, Jeffries, Marick, Schwaber, Sutherland …) en réponse à un malaise et aux insuffisances et difficultés liées aux méthodes de développement traditionnelles :

• Les individus et les interactions plutôt que les processus et les outils
• Des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive
• Collaboration avec le client plutôt que la contractualisation des relations
• Acceptation du changement plutôt que la conformité aux plans

Agilité: une définition

Aujourd’hui le développement Agile transforme le business ; la France semble enfin s’en apercevoir, et l‘agilité :

“ capacité d’une organisation à créer de la valeur et à ravir son client, tout en favorisant et en s’adaptant -à temps- aux changements de son environnement (Grosjean, 2011)

pénètre toutes les couches de l’Entreprise:

Scrum est devenu incontestablement la méthode la plus populaire. C’est aussi la méthode Agile que je porte dans mes missions de Coaching Agile tant ce framework est pertinent pour initier le process agile de l’organisation, symbole d’une agilité qui ne peut fonctionner qu’en contexte. L’agilité modifie donc notre façon de concevoir des produits, et d’envisager un Projet Informatique (notamment en termes d’estimation, de planification et de suivi)… un choc culturel pour beaucoup de personnes, d’équipes ou d’organisations. Mais les Méthodes Agiles vont impacter également la notion de contrat et bouleversent surtout la façon d’exercer nos propres métiers…

Le jeu en vaut-il la chandelle ? Je réponds OUI, sans hésitation; les bénéfices sont en effet bien réels (comme le montre cette dernière étude ou ma propre capitalisation):

• Visibilité
• Vélocité
• Adaptabilité et réactivité (dimensions clés du Time to market)
• Réduction des risques
• Qualité
• Efficacité

Beaucoup chercheront à comparer les différentes méthodes Agiles (XP, SCRUM, DSDM, ASD, AUP …), c’est intéressant, certes… Mais, plus que de méthodes, je parlerais davantage de techniques, de pratiques à piocher ici ou là, dans XP, dans SCRUM, dans Lean, à essayer, à adapter, à intégrer sur un socle stabilisé mais souplepropre à chaque organisation, en respectant quelques principes fondamentaux (discipline nécessaire):

• Itératif (courtes)
• Incrémental (avec en plus des livraisons de fonctionnalités opértationnelles à chaque itération)
• Collaboratif
• Timeboxing
• Focus sur les Tests, à chaque itération
• Feedback Client et Utilisateurs

Toutes ces pratiques intégrables et ajustables ainsi que la remise au premier plan du FACTEUR HUMAIN sont la vraie RICHESSE des Méthodes Agiles.

Des Méthodes qui véhiculent malheureusement encore pas mal d’idées reçues : du point de vue de la documentation, de la planification, de l’offshore, du CMMI ou même de l’Ergonomie et de l’Expérience Utilisateur …

Voici les commentaires de l’époque: (il y a des “perles”…)

22 réponses à “Méthodes AGILES: une belle définition”

1. Bob Sponge dit :

   21 mars 2008 à 16 h 23 min (Modifier)

   “Des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive”
   “Collaboration avec le client plutôt que la contractualisation des relations”

   J’aime beaucoup… c’est typiquement les bobards de commercial de SS2i!

   J’ai fait de l’extrême programming en 2002 dans mon ex SS2i, sur un projet interne.
   Le produit est devenu obsolète, et l’idée d’une évolution fut très vite rangée au placard compte tenu du coût initial, de l’investissement fourni par le client et surtout du manque de documentation.

   Aujourd’hui, Chef de projet MOA je rencontre toujours quelques charlots vantant les mérites des “méthodes modernes”… mon calcul est simple : sur du long terme on multiplie par 2,5 les coûts par rapport à une méthode classique, car en fait il faut repartir de zéro presque systématiquement (le turn-over est tel dans les SS2i que maintenir une équipe projet pendant 1 ans tient du miracle!).

   D’autre part, beaucoup de SS2i s’enorgueillissent de proposer du forfait Offshore, mais derrière il ne s’agit que d’applications type portail de service “génériques”, en “prêt à porter”.

   Le métier n’est connu que par le client et de lui seul, c’est une illusion de croire qu’un développeur indien ou roumain va comprendre la subtilité de ce dernier!!
   Surtout sans une expression de besoin ou un cahier des charges (complète et claire fournie par le client), et même là il faut compter avec le niveau de rédaction et de compréhension de l’anglais de chacun…

   Par expérience, j’ai pu tester les solutions Offshore… Le bilan sur des applications métiers, ça fait froid dans le dos!

   Bref, je le dis et réaffirme: la méthode Agile est une approche “pause café” et “au doigt mouillé” qui à part pour les start-up, sur le dépôt de bilan, n’a pas sa place dans le monde industriel.

2. jc-Qualitystreet dit :

   21 mars 2008 à 23 h 31 min (Modifier)

   Une position quelque peu radicale mais des questions soulevées qui se révèlent tout à fait intéressantes.

   Preuve que certaines idées reçues ont la vie dure … c’est le cas pour la documentation. Agilité ne signifie pas absence de documentation mais une documentation au plus juste, appropriée par rapport au contexte et toujours synonyme de valeur.
   Un peu plus dans ce billet:
   http://www.qualitystreet.fr/?200...

   Le contexte offshore est un contexte particulier, qui nécessite une approche approfondie et une adaptation des pratiques Agiles.
   De récentes études tendent à montrer que les deux approches font plutôt bon ménage même si leur cumul nécessite encore plus de rigueur et de discipline…
   Un peu plus dans ce billet:
   http://www.qualitystreet.fr/?200...

   Pour le reste il serait intéressant de nous faire profiter d’une courte rétrospective de votre projet XP de 2002, quelles pratiques XP vous avez mis en oeuvre, dans quel contexte, qu’est ce qui n’a pas marché précisément, pourquoi avoir basculé sur ce mode, quel était le point de vue de l’équipe …la façon de communiquer ce projet, y a t- il accompagnement, étiez-vous dans une démarche de conception centrée utilisateur, avez-vous fait appel à un ergonome ? et j’ose à peine poser la question, y a t-il eu dans tout cela quelques éléments positifs ?
   D’autres projets alimentent-ils vos stats ?
   L’agilité a gagné en maturité depuis 2002 mais vous pourriez permettre à certains de ne pas tomber dans les mêmes travers.

   Visibilité, vélocité, réduction des risques, qualité sont des bénéfices bel et bien réels, dont chaque acteur peut observer les bienfaits qu’il soit chef de projet, analyste, développeur, ergonome, client ou utilisateur …
   Je n’ose imaginer que le développement itératif, un focus sur les pratiques de test et de qualité, un pilotage par les risques ne puissent vous être profitables au quotidien, en SSII ou ailleurs; ce sont des aspects à creuser !!
   J’irais même plus loin, dans une approche Kaizen (amélioration continue) voyons en quoi vos process actuels qui semblent être déjà satisfaisants peuvent s’améliorer ? Identifions les leviers sur lesquels s’appuyer, travaillons sur les points faibles en y testant, en glissant ici ou là, pourquoi pas, quelques pratiques agiles …

   Bref, gardons le meilleur, multiplions les pratiques Agiles, les sources d’inspiration (Scrum, XP, UP, Lean) et gardons l’Esprit Agile !

3. Dav dit :

   22 mai 2008 à 23 h 49 min (Modifier)

   Nous subissons en ce moment une méthode Agile de la part de notre prestataire. Sous prétexte de vouloir éviter “l’effet tunnel”, on se spécifie rien. Résultat : on a recommencé 4 fois le boulot. Là, je suis fatigué de perdre mon temps à recetter des trucs pas finis : pour la prochaine itération, j’ai fait moi-même des spécifications ergos que j’ai envoyé au prestataire !
   A mon avis : avec ce type de méthode, on préfère employer une armée de développeurs débutants qui feront des trucs vites faits/mal faits, plutôt que d’engager un bon ergonome. C’est la vision “informaticienne” par excellence.

4. jc-Qualitystreet.fr dit :

   23 mai 2008 à 2 h 57 min (Modifier)

   Etre Agile ne signifie pas “ne pas spécifier” mais “specifier autrement” tout en privilègiant un produit qui marche (c’est à dire testé !) pour mesurer l’avancement du projet.

   Il serait là aussi interessant d’analyser en profondeur les causes de ces dysfonctionnements …dans un objectif d’amélioration continue. D’ailleurs, vous même avez déjà trouvé quelques remèdes.

   La collaboration efficace Client - Développement, le travail d’équipe, le feedback permanent et pas seulement en fin d’itération sont les vraies clés de la réussite. En lisant entre les lignes, ces éléments semblent faire défaut sur votre projet. Etes vous situés au même endroit ? Discutez-vous les user stories et des élements du backlog ? Faites-vous des scrums quotidiens ? Echangez vous régulièrement sur ce qui est produit ? Jouez-vous la “Transparence” ?…

   L’agilité vous aura permis de vous apercevoir rapidement (c’est le cas semble-t-il , c’est déjà ça) de ces problèmes et de les corriger au plus tôt !

   Je suis d’accord avec vous sur le fait que les besoins d’ergonomie et de prise en compte de l’experience Utilisateur sont aujourd’hui trés fort sur les projets Agiles. L’agilité offre un contexte favorable : encore faut-il l’exploiter !

   L’emploi d’une armée de développeurs débutants n’est quant à lui pas lié à des contextes Agiles / Non Agiles.
   L’agilité nécessite maîtrise et discipline… et je me contenterai de signaler que si des débutants arrivent sur le projet (ce qui est évidemment envisageable), ils monteront naturellement en compétences …

   Si vous souhaitez que nous en discutions davantage et que nous envisagions des solutions pour que vous ne “subissiez” plus ces méthodes Agiles, n’hésitez pas à me contacter.

5. sth dit :

   4 août 2008 à 10 h 37 min (Modifier)

   J’entends parlé de CMMI, de méthode Agile, de cycle de développement en V, inctémental, evolutionnaire… que de confusions !

   La définition de Veronique Messager Rota est débile et montre l’incompétence flagrante de nombreux managers en France.

   La méthode Agile ne s’adresse pas à tout type de projet. A l’embarqué certainement pas. A la TMA, certainement pas. Au développement web, oui mais sous certaines conditions.

   L’agilité nécessite une TRES GRANDE compétence dans l’identification et l’analyse des risques: Le point faible des chefs de projets en France. La gestion des risques est l’activité la plus difficile dans la gestion de projet.

   Vous ne comprennez pas ce que je vous dis? Alors n’utiliser la méthode Agile, vous allez planter votre projet et votre carriere. Faites appel à votre BON SENS !!!!

   Je ne suis pas contre la méthode Agile. Je suis même pour, je l’ai même pratiqué, mais sur le projet qui le permettais (1/100).

   Pour info: En soft embarqué(mobile platform): 5ppm sans agilité, 1 450 ppm avec agilité.
   En dev web (ajax, php5, flex,..): 1 ppm avec agilité

   Vous ne comprenez toujours pas? Ne faites plus de conseil en qualité.

6. Samuel Martin dit :

   25 septembre 2008 à 0 h 53 min (Modifier)

   De très bons constats qui mériterait des exemples concrets. En tant que développeur ingénieur et bien que connaissant assez bien le domaine et les termes, il n’est pas toujours facile d’entrevoir la réalité dans les arguments avancés.

   PS: Sth je n’ai rien compris. Il n’y a peut être rien a comprendre aussi.

7. Eric Jallas dit :

   2 octobre 2008 à 12 h 01 min (Modifier)

   Ne comprenant pas ce que signifiait “5ppm sans agilité, 1 450 ppm avec agilité” j’ai parcouru le WEB pour comprendre.

   Je n’ai trouvé que cela :
   (1) When uppercase, PPM refers to project portfolio management.
   (2) When lowercase, ppm refers to page per minute.

   Par ailleurs pour moi ppm signifie “partie par million”. Bref comme je ne voudrai pas mourir ignorant, pourriez-vous me donner l’information. Merci d’avance.

   Enfin un commentaire : “Vous ne comprenez toujours pas? Ne faites plus de conseil en qualité.” pourtant il me semblait que la bonne compréhension d’un discours par l’auditoire était un critère important de qualité… Dans ces conditions que vaut l’affirmation ci-dessus. Merci de m’éclairer aussi sur ce point.

8. jc-Qualitystreet dit :

   2 octobre 2008 à 13 h 17 min (Modifier)

   Eric, je ne suis pas sûr que vous obteniez un jour une réponse de Sth 

9. Jason dit :

   15 décembre 2008 à 18 h 13 min (Modifier)

   Le prosélytisme autour des méthodes agiles, tel que vous le pratiquez, représente une véritable régression dans le monde de l’informatique. Quoiqu’on en dise, c’est le retour à “j’analyse au fur et à mesure et j’avise” de grand papa.
   Vous perdez de vue que toute analyse n’est pas intégralement décomposable. Vous tirez des conclusions à partir de succès sur des cibles dont on ne peut juger de la teneur, ni de la pérennité…ni de la justesse du coût.
   Si les grattes-ciels étaient conçus avec ce genre de méthode, ils coûteraient très cher…et se casseraient tous la figure au premier coup de vent. Vous, vous parlez de maisons individuelles. Mais vous ne semblez pas en avoir conscience.
   Le méthodes agiles, c’est “l’analyse pour les nuls”. Ca permet a une équipe faible d’obtenir un résultat empirique (et cher), ce qui est mieux que pas de résultat du tout. Mais ce n’est certainement pas un processus industriel permettant de bâtir des systèmes complexes.
   Et ça nous amène à leur principal paradoxe : elles attirent des compétences faibles, alors qu’il faut des compétences fortes pour en éviter les pièges.

10. Pat dit :

    19 janvier 2009 à 20 h 19 min (Modifier)

    Les méthodes AGILE n’ont rien de magique… et c’est certainement une partie du problème. Mais les échecs avec les méthodes conventionnel sont aussi courante. Alors… comme certain le dise déjà.. le problème est peut-être pas la méthode.

    Ca me fait penser à cathédrale vs bazar et au modèle Open Source
    fr.wikipedia.org/wiki/La_…

    Ca me rappel aussi la théorie des constructals, qui est en train de rejoindre l’ingégnerie industrielle justement…
    fr.wikipedia.org/wiki/Th%…

    À vous de juger

11. Llib Etag dit :

    24 janvier 2009 à 19 h 28 min (Modifier)

    Quand quelqu’un s’énerve c’est qu’il a des doutes.

    Si Jason, sth et les autres ont des ‘arguments’ contre la mise en place de méthodes agiles, qu’ils les expliquent car dire c’est nul n’a aucune porté sur l’auditoire et ne fait en rien avancer le débat ou la discussion.

    Les méthodes agiles ne sont pas une fin en soi, mais si l’on considère les ressources humaines comme l’une des composantes primordiale pour la réalisation d’un projet, je dirais que les méthodes agiles mettent en valeurs les hommes plus que d’autres.

    Malheureusement pour Jason, les méthodes agiles sont étudiées pour être mise en place dans le secteur du batiment.
    Pas de chance, Harvard publie de temps à autre quelques rapports sur ce sujet, allé cherche bien et tu trouveras.

    D’autre part, il est important de rappeler que certaines SSII se disent agile alors qu’elle n’utilise pas réellement ces méthodes.
    Ceci créé une confusion et un profond désarroi quant aux clients ayant décider de faire confiance à ces entreprises.
    La conclusion a de tels pratiques est une baisse de confiance dans ces méthodes ainsi que l’émergence d’une horde de mauvaises langues pensant avoir travaillé de manière agile alors qu’il n’en est rien.

12. fab dit :

    28 mai 2009 à 9 h 28 min (Modifier)

    J’ai trouvé l’article assez intéressé mais les commentaires encore plus.

    Personnellement, je suis chef de projet en informatique depuis plus de 10.
    J’ai commencé, comme à peu prés tous les CP je pense, sans aucune méthologie de pilotage. Durant ces années je me suis donc contenté de “suivre” mes projets.
    Un jour, ma société m’a fait suivre une formation PMI (Project Management Institute) puis quelque mois plus tard j’ai eu l’occasion de découvrir sur le terrain CMMI.
    Depuis maintenant 4 ans, je pratique CMMI sur la plupart de mes projets.
    Je pense pouvoir dire aujourd’hui que je “pilote” mes projets, et non plus que je les “suis” comme auparavant.

    Je n’ai pas réellement d’expérience des méthodes Agile mais cela m’intéresse beaucoup de part mon expérience de CMMI et de part le fait que ces méthodes sont souvent opposées.

    Personnellement, je pense que toutes ces méthodes (CMMI, Agile, ITIL, etc.) sont très utiles mais que le plus important est de rester très pragmatique.
    Pourquoi vouloir les opposer ?
    Pourquoi vouloir prétendre telle ou telle méthode universelle ?

    Il me semblerait plus intéressant d’identifier des typologies de projet et de proposer une méthode applicable pour chaque typologie plutôt que de vouloir définir des méthodes universelles.
    Bref, se concentrer sur le projet (qui reste le but ultime) plus que sur la méthode (ce qui correspond assez bien au 1er précepte du manifeste Agile il me semble)

    Comme il a été dit précédemment, je ne vois comment on peut prétendre qu’une méthode peut fonctionner à la fois pour des projets de développement de 100 jours, de 1000 jours, de 10000 jours, des projets de TMA, des projets d’informatique embarquée, de développement web, etc.

    Bref, aujourd’hui, je suis plus à la recherche du retour sur expérience de chefs de projet ayant pu appliquer (concrètement et réellement) l’une ou l’autre de ces méthodes afin d’en faire une synthèse plus que d’une méthode miracle.

13. Sylvain dit :

    7 mars 2010 à 19 h 23 min (Modifier)

    Je me permet de rappeler que tout développement doit tenir compte de l’architecture d’entreprise existante, une étude de faisabilité, une étude de marché, des évaluations et preuve de concept de progiciel (ou composantes) à intégrer et d’une architecture d’information solide.

    C’est souvent ce qui manque au départ d’un projet de développement ! d’où les conséquences que l’on connait.

14. Jerome dit :

    18 mars 2010 à 10 h 35 min (Modifier)

    @sylvain, hélas il arrive souvent que l’architecture d’entreprise puisse être vieillissante, et donc plus du tout adaptée ni aux réalités du marché, ni aux besoins d’évolutions soutenues, imposés par Internet par exemple.

    Là où “Agile” est intéressant, c’est de pouvoir repartir sur des bases complètement nouvelles “assez facilement” comparé à des méthodes classiques.

    il faut tout de même noter, que seule une direction d’entreprise est en mesure de soutenir et de rendre viable de telles approches. Les charges finales restent importantes. Observations : gros gros bénéfices pour les utilisateurs (clients), l’innovation, et les phases de recette 

    Ces méthodes ont la particularité de favoriser le travaille en équipe pluridisciplinaire, ce qui manque cruellement dans beaucoup d’entreprise, encore organisées en silot. C’est un vrai vecteur pour la conduite du changement en organisation.

    Jerome.

15. icare dit :

    13 août 2010 à 10 h 28 min (Modifier)

    Bonjour à tous,

    J’ai lu avec attention les posts précédents, et j’avoue que j’ai l’impression de vivre le grand débat JAVA contre .NET, microsoft contre LINUX.
    Je pense qu’il faut faire preuve de bonne intelligence dans l’utilisation de méthode, je suis Directeur de projet dans un grand groupe, et par expérience sur des gros projets, la méthode agile ne permet pas une maîtrise des coûts, clairement.
    En revanche, il existe depuis la nuit des temps plusieurs méthodes pour des projets, le cycle en V, le Cycle itératif (qui ressemble étrangement à la méthode Agile), et quelque soit la méthode, les documentations sont les mêmes, alors maintenant à chacun d’être intelligent pour adapter les volumes de documentation ou rythme du projet et à sa complexité.
    Je pense surtout qu’on essaie de trouver des méthodes pour des non informaticien, je m’explique depuis 15 ans maintenant, je me rend compte que les profils en informatique sont de moins en moins pointus, on assiste plus a du bricolage qu’a de la vraie programmtion rigoureuse, l’époque ou on programmait en pur C, il fallait être de très bon niveau et extrêmement rigoureux. Aujourd’hui on assiste à une mutation des développeurs qui n’ont plus qu’à faire du drag and drop pour développer alors là oui ça peut-être agile, mais j’aimerais qu’on s’arrête sur les performances de ces applications, zéro …

    Cdt

16. Félix-A. Bourbonnais dit :

    7 février 2011 à 21 h 23 min (Modifier)

Méthodes AGILES: une belle définition http://bit.ly/ey2EnE

Agile Day Valtech: Management Agile, la Prez!

Posté par jc-Qualitystreet le 20 juin 2012

L’agile Day Valtech 2012 fut un véritable succès. Bravo à Laurent (Carbonnaux) et à l’équipe d’organisation de ce bel évènement, notamment Laetitia et Olivier….

A titre personnel, mon atelier “Petits Outils de facilitation à l’usage des Honnêtes Gens” donna lieu à de très beaux échanges. Vous étiez nombreux, tous dans un très bon état d’esprit et je me suis moi même enrichi de nos discussions et de vos retour d’expérience. J’ai vraiment apprécié ce moment. Donc Merci.

La présentation consacrée au Management Agile, “Dans la peau du Manager Agile” fut une nouvelle fois extrêmement bien accueillie. Notre ROTI à grande echelle dans l’auditorium Valtech fut impressionnant. Merci.

Voici la présentation…

Agile Day Tunisia: Intense et Formidable!

Posté par jc-Qualitystreet le 13 juin 2012

Rapide feedback en images sur ce très bel évènement organisé le 2 juin dernier à Tunis. Pour un compte rendu détaillé, n’hésitez pas à vous rendre chez mon camarade Alex…

Inutile de vous dire que toute personne se trouvant  à côté de Laurent dans un avion ne peut pas dormir. Avantage cela dit, il ou elle ne verra pas le temps passer, n’est-ce pas Oana Cette année 2012 Laurent vous parlera avec émotions de…. Tribal Leadership…

Arrivée à Tunis: UN BEAU CIEL BLEU, étonnant, non!

Apéro Agile, le soir en attendant le dîner…

Samedi 2 juin, on était pas loin d’être les premiers: Ultra motivés!

Les badges étaient prêts…

Tout comme un très beau livret de présentation!!

Environ 500 présents, + de 1000 inscrits, un trés bel endroit, des sponsors, un trailer, la TV… et  6 semaines de préparation. Incroyable!

L’amphi était bien rempli…

Que dire quasiment plein!

Mais on avait pris du retard…
alors, Alex se mit à danser

et Laurent à chanter.. :)

Pour un très bon feedback finalement

Du coup, on célébra  avec un marshmallow challenge géant, dans la joie et la bonne humeur!

A la fin de la journée, on était tous crevés!

Mais on avait le lendemain pour récupérer au Café des…

Pour conclure, quelques remerciements à tous ceux qui ont rendu ce premier Agile Day Tunisia possible et qui en ont fait un succès:

• Ghazi El Khamsa et Nizar GRINDI, les deux co-organisateurs de l’évènement mais aussi l’ATUGE et les sponsors
• Laurent Sarrazin, initiateur du “truc” avec Ghazi et énorme facilitateur côté Paris
• Pascal Pezard, praticien agile chez HR Access, notre GO local, de la Marsa à Sidi Bou Said
• Mes camarades agilistes, Céline, Oana, Jean-Laurent, Alex pour leur bonne humeur et ces valeurs humaines qui les habitent
• Bilel Bouraoui et l’Equipe de Zouz (1ere STARTUP tunisienne), pour le superbe dîner que nous avons passés en leur compagnie
• Tous les participants de cet Agile Day pour leur enthousiasme et leur envie d’apprendre
• Ceux qui ont assisté à mes 3 sessions (Management Agile, Agile UX,  Facilitation) pour leur feedback et leur intérêt

Bref, juste pour vous dire que je serais particulièrement honoré de faire partie de la seconde Edition de votre Agile Day Tunisia, en 2013

Valtech Agile Day Paris 2012, c’est FORT et c’est dans une semaine!

Posté par jc-Qualitystreet le 11 juin 2012

Une journée, 17 sessions, des Guests et des collègues Agilistes qui portent haut les couleurs de Valtech!

Découvrez le programme:

A titre personnel, j’y animerai deux sessions (12h et 16h30) mais j’aurai surtout plaisir à échanger avec vous de ces thématiques qui me tiennent à coeur: Management Agile, Coaching, Facilitation ou encore Agile UX.

En espérant donc vous y croiser…

Transition Agile: Pensez à votre CoP Manager Agile!

Posté par jc-Qualitystreet le

C’est-à-dire votre Communauté de pratiques pour Manager impliqué dans votre écosystème Agile…

Je vous rappelais dans un précédent billet que l’une des activités du Manager Agile était d’initier et de soutenir les communautés de pratiques Agiles, notamment celles des ScrumMasters, des Product Owners, des Testeurs ou encore des Spécialistes UX…

Mais le besoin est fort, notamment dans les grosses organisations de créer pour le Manager lui-même et ses pairs, LEUR PROPRE COMMUNAUTÉ DE PRATIQUES… une CoP Management!

« S’il n’y a pas de rencontres physiques ça ne marche pas » Un manager Agile

Echange & Collaboration, Apprentissage, Soutien et Cohérence sont les maitres mots de cette nouvelle dynamique…

Les objectifs de cette CoP Management Agile sont les suivants :

• Échanger sur les pratiques de management Agile & Lean avec des personnes qui vivent la même chose que vous
• Propager les bonnes idées, ce qui marche dans l’organisation
• Rassembler les managers par delà les équipes ou les lignes organisationnelles
• Coordonner et assurer la nécessaire cohérence dans la façon d’aborder et de gérer les équipes

L’ambition finale étant de construire l’identité commune du Manager Agile dans une organisation donnée car même si dans les grandes lignes les activités de ce nouveau Management Agile & Lean se recoupent, les spécificités d’un contexte organisationnel, le secteur d’activité, l’ADN même de l’entreprise, influencent largement le quotidien des personnes.

Note:

« Une communauté de pratique est un groupe dont les membres s’engagent régulièrement dans des activités de partage de connaissances et d’apprentissage à partir d’intérêts communs ». Etienne Wenger

Agile Coaching BookClub#2… avec en Guest Véronique Messager!

Posté par jc-Qualitystreet le 5 juin 2012

pour son nouveau livre dont la sortie est prévue courant Septembre…

En guest : Véronique Messager

A peine de retour de Tunis et d’un premier et incroyable Agile Day Tunisia qui restera dans les mémoires de tous, nous avons enchaîné Laurent et moi même avec notre second Agile Coaching BookClub, toujours dans le cadre de ma mission de supervision de coachs agiles Internes.

Un book club un peu particulier puisque l’équipe de coachs agiles internes recevait dans ses murs, non sans une certaine émotion, Véronique Messager, auteur de “Gestion de projet: vers les méthodes Agiles” mais aussi et surtout auteure d’un futur livre sur notre sujet de prédilection: le COACHING AGILE.

De beaux échanges: de l'écoute, de la bienveillance et du feedback

L’exercice est aussi un  peu spécial dans le sens où notre lecture commune portait sur un ouvrage, certes bien avancé, mais toujours en cours de rédaction. Merci à Véronique pour sa confiance et pour avoir joué le jeu du Bookclub! Pas facile de se mettre dans cette posture même si le Feedback est avant tout constructif et bienveillant: son bouquin a été véritablement décortiqué!

De beaux échanges

Au programme:

• Ouverture et check-in
• Nos impressions générales + échanges
• Questions de Véronique + échanges
• Cloture

Le temps est passé très vite… Véronique a écouté avec attention nos impressions générales, pris pas mal de notes et surtout a su répondre à nos interrogations.

Des impressions générales...

Contrairement à d’autres Bookclub et puisque l’ouvrage n’est pas finalisé, elle était arrivée avec ses questions auxquelles nous avons répondu collectivement…

Vero Arrivait aussi avec ses questions

Bref, merci à tous, une nouvelle fois, un bon moment et de beaux échanges!

J’aime vraiment mon métier quand il me place au coeur de telles situations…