agilite, coaching, facilitation

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 17 juin 2012

Evenement Agile / PMI le 21 juin 2012 à Sophia Antipolis

J'ai le plaisir de vous annoncer que je vais être orateur dans un évènement des plus singulier, une matinée sur l'agilité à Sophia Antipolis, organisée par le chapitre PMI (Project Management Institut) France-Sud - Branche Côte d'Azur.

Cet évènement à la particularité de réunir les 3 sujets qui me passionnent en ce moment, agilité & non dogmatisme, transmettre par l'expérience et les conférences participatives :)

  • Non dogmatisme car organisé par le PMI et conçu dans un esprit d'ouverture
  • Transmettre par l'expérience car l'évènement est conçu dans un mode Scrum (questions, backlog, itérations etc...)
  • Conférence participative car .... et bien mode Scrum dit co création et interactions avec les individus :)

Pour plus d'informations, le programme et les inscriptions

Ce sera aussi l'occasion de parler d'Agile Tour Sophia 2012 et de la communauté locale :)

mardi 20 décembre 2011

Les niveaux de maitrise de l'agilite


C'est un point sur mon parcours et une clarification des métiers du « milieu à Gilles » pour sortir de ce terme vague « d'agiliste » et présenter un cheminement pour les « coachs Agiles » qui souhaitent se professionnaliser.

Lire la suite...

lundi 19 décembre 2011

l'agilite un sujet de trop

L’agilité est elle morte ? Faut il la tuer ? La défendre ? S'en aider ?

Peut être que la vérité est tout simplement ailleurs, l'agilité est devenue un sujet qui parle, aide, et qui ne faillit jamais, vous ne trouvez pas ça étrange que l'agilité fasse autant de choses ?

Lire la suite...

lundi 26 septembre 2011

nouvelle version : charte du coach agile professionnel

Voici la nouvelle version de la charte d'exercice du Coach Agile Professionnel : la charte

Cette charte est développé selon un modèle de contribution Open Source (et je ne suis que chargé de sa maintenance).

J'ai créé une liste de diffusion pour échanger, commenter, enrichir cette charte et plus généralement sur le thème du coaching agile professionnel : AgileCoachPro_fr

mardi 17 mai 2011

ScrumBan ? ou Scrum incrémental ?

Pour moi ScrumBan est la simple évolution de Scrum,

On part d'une gestion de projet itérative qui livre son lot de fonctionnalité, puis itérative et incrémentale qui livre un logiciel à chaque itérations (Scrum dans les grandes lignes) puis gestion de produit incrémentale, là l'équipe à une maitrise suffisamment ses outils pour pouvoir faire livrer un nouveau logiciel à n'importe quel moment.

"ScrumBan" au delà du discours, c'est simplement Scrum sans la contrainte des itérations, avec une nouvelle manière d'optimiser les flux issu du Lean.

Je préfère l'appeler "Scrum incrémental".

Ca permet de s'assurer que l'équipe sache déjà faire du Scrum en itératif et incrémental (qu'elle puisse livrer un logiciel utilisable à chaque itération), avant de passer à "ScrumBan"... qui pourrait vite déguiser une livraison de fonctionnalités sans itérations et sans logiciel utilisable...

La révolution quand même c'est que la livraison n'est plus dépendante d'une contrainte de temps : l'itération (avant c'était la contrainte technique : la fin du projet) mais maintenant se fait en fonction de la demande du métier.

Soirée production de contrat types pour Scrum

La soirée sera lundi 23 mai au 90, rue Baudin Levallois Perret.

J'ai bien aimé la limite de taille imposé par meetup ça m'oblige à faire simple :

“Entant que Coach Scrum, je souhaite proposer aux SM, PO et Dev que j'accompagne des contrats à signer, définissant leurs engagements et leurs interactions (contrats tri-parties), dans le but de simplifier la compréhension et l'adoption de Scrum.”

les inscriptions se font ici : http://www.meetup.com/frenchsug/events/17841511/

L'atelier sera animé par moi en mode agoractif, pour 12 personnes maximum avec comme objectif de faire un livrable le soir même.

Donc premier livrable lundi soir :)

à lundi

mercredi 11 mai 2011

Peut on "se planter" pendant une itération ? - suite

Ce billet est là est la suite de : Peut-on se planter pendant une itération ?

«Previously on your blog» : Une équipe à produit 5 points au lieu de 38 à la fin de l'itération, un membre de l'équipe considère que c'est un échec.

Ce n'est pas un échec, une itération une itération (sert entre autre) à mesurer la capacité à produire et s'adapter en fonction, pas d'espérer tenir un planning.

C'est un succès, même si c'est à la fin de l'itération ! Scrum à permis à quelqu'un de mettre en lumière que 33 points (38 prévus -5 faits) ne méritent pas d'être livrés (ou ne sont pas fait). C'est un succès par rapport à une méthode de projet classique d'avoir empêcher leur livraison à la fin de l'itération et permis une re-priorisation dès l'itération d'après (inspecter et s'adapter).

Un échec serait d'avoir livré ces 33 points de tâches ou de considérer qu'elles sont faites.

  • C'est aussi une occasion de s'améliorer, on peut commencer par se demander :

Est ce que le client est content avec ces 5 points ? Considère t-il qu'il en a eu pour son argent ? Est-il prêt à continuer ? (avec une capacité à produire de 5 ? peut il trouver une telle valeur ajouté dans son produit pour que l'équipe soit rentable en livrant 5 points ?)

Puis d'ou vient cette différence ? Qui s'en est rendu compte ? Y a-t-il eu un problème dans la relation avec le client ? Les tâches n'ont pas étés correctement comprises par le développeur ? La définition de terminée technique n'a pas été respectée ? Une tâche estimée à 5 valait-elle en fait 40 de complexité ?

Ou que sais je encore....

  • Puis à quel moment on s'en est rendu compte ?

Ce qui est le plus important c'est ce moment de prise de conscience, à quel moment l'inspection à permis de réaliser cette différence entre le but estimé et la réalité ?

Si c'est avant la revue de fin d'itération, est ce à 20%, à 30 % ou à 80 % de l'itération ? Que l'alerte à été donné et que l'on à pu faire le nécessaire pour ré-adapter l'objectif de l'itération en fonction de la nouvelle estimation de la capacité de production réelle de l'équipe.

  • Et après ce diagnostique fait, on peut se demander «comment faire en sorte que cette prise de conscience puisse être faite plus rapidement ?».

Pour peu à peu amener les membres du processus Scrum à avoir cette prise de conscience de plus en plus rapidement.

Ce sera peut être à la moitié de la prochaine itération (au lieu de 80%), puis à 20% de l'itération d'après, puis lors d'un échange lors de la planification de l'itération suivante.

C'est comme cela que l'équipe n'a plus peur de se tromper, qu'elle acquière de la bouteille, de l'assurance et peut s'engager au maximum.

Dans une logique Agile, on considère qu'il est beaucoup plus productif de s'adapter à la de capacité de production réelle, plutôt que de maintenir l'équipe entre l'espoir et la crainte de la non tenue d'un planning.

L'agilité, une histoire dont vous êtes le héros !

L'agilité utilise traditionnellement la métaphore suivante pour expliquer les relations et les interactions entre les développeurs et les clients :

Une poule et un cochon sont ensemble. La poule suggère : « Ouvrons un restaurant ensemble! » Le cochon y réfléchit et dit : « Et comment allons-nous appeler ce restaurant?» La poule de dire : « Coco-bacon! » Le cochon de répliquer : « Pas question! Je serais totalement engagé dans cette entreprise, alors que tu serais seulement impliquée! »

Scrum en déduit que les « poules » ne peuvent dire aux « cochons » comment faire leur travail et la métaphore s'arrête sur le refus du cochon. Je propose de continuer ensemble l'histoire, histoire d'imaginer ce qu'il peut se passer après et cette fois c'est la poule qui à le choix :)

La poule : «J'ai besoin de ce restaurant, rassure toi, il n'y aura qu'une dizaine de couverts par service". Le cochon réplique: « Il n'en n'est pas question ! Je serais totalement engagé dans cette entreprise, alors que tu serais seulement impliquée! c'est donc normal qu'il s'appel "au bon bacon" »

c'est à ce moment là que la poule, comme souvent choisit de prendre la pilule bleue...

La poule : «tu as gagné, j'ai besoin de ce restaurant, j'accepte qu'il s'appelle "Au bon Bacon" ».

Le cochon : «j'accepte le nom et ça tombe bien mon métier c'est le bâtiment, par contre vu la qualité de tes oeufs, tu vas avoir un grand succès, il faut prévoir grand dès le début du chantier, je dis ça parce que j'ai du métier, si tu fait agrandir après, ça te coutera beaucoup plus cher, il faut prévoir au moins 500 couverts».

Le cochon commence par appeler ses copains architectes, ils creusent les fondations, bâtissent.

Puis, le projet prend du retard (une histoire compliqué entre la taille du tourne broche et le système d'évacuation, une question de dynamique des fluides, le cochon est ravi de l'expliquer avec moult équations à la poule). Ca va couter plus cher que prévu, le cochon explique au poulet qu'il faut qu'il vende quelques plumes pour finir le restaurant.

Le cochon est toujours rassurant, «Ca coutera tjrs moins chers que si tu avais du faire agrandir suite à la forte affluence qu'il ne manquerait pas d'y avoir à l'ouverture» . Le cochon surenchéri, "Et grâce à notre mode de fonctionnement, nous avons pu voir le problème bien avant l'ouverture du restaurant, on à évité le drame».

La poule est toujours rassuré, la méthode de travail du cochon est optimum, il peut voir l'avancée du restaurant chaque semaine, il voit le matériel installé petit à petit, à chaque nouvelle machine il vérifie bien qu'elle fonctionne, qu'elle se connecte avec les autres et qu'elle sera très utile le jour ou les clients seront là pour de vrais.

Puis viennent les frais de personnels, puis les normes de sécurités, mais comme dit le cochon «Tu comprend avec 500 couverts, il faut du monde pour exploiter ce restaurant».

Puis viennent les frais d'assurances.... La poule finit par être totalement plumé, mais le cochon est toujours rassurant, le restaurant fonctionne parfaitement et dès l'ouverture, il pourra vendre des omelettes pour récupérer ses plumes.

La poule effectue la recette de fin de chantier, sans surprises grâce à la merveilleuse méthode du cochon (qui à bien montré que le matériel est testé régulièrement).

Tout va pour le mieux, le restaurant est magnifique, l'euphorie est à son comble, il signe, finit de payer ce qui lui reste à payer ouvre le restaurant et... attend ses premiers clients....

Mais elle peut aussi choisir la pilule rouge :

Et s'exclamer « C'est n'importe quoi "Au bon bacon", le seul moyen de faire du lard c'est de te tuer... Voyons tu ne va pas finir sur un croc de boucher ! Pas de ça chez moi ! On va l'appeler le palais de l'oeuf, par contre il nous faut un cuisinier, tu en connais un ?»

Le cochon répondit penaud «Non, mon métier c'est le bâtiment», il se séparèrent.

La poule se mit en quête d'un cuisinier et elle en rencontra un... La poule : «Bonjour, J'ai des oeufs, tu sais cuisiner, j'aimerai ouvrir un restaurant, mais nous n'avons pas d'outils, comment faire ?». Le cuisinier ne s'offusqua pas, il savait que la Poule avait encore beaucoup à apprendre sur son métier, il répondit simplement : «fait moi confiance, c'est mon métier».

Le cuisinier pris un oeuf, il le prépara avec ce qu'il avait à disposition, des herbes sauvages qu'il savait choisir et le fit cuire grâce au soleil, puis le rapporta à la Poule.

La poule : «le résultat à l'air bien appétissant, faisons le gouter à un client !». Ils trouvèrent un fin connaisseur en oeufs, il gouta, fut très content, en voulu d'autre. Le cuisinier, en professionnel, lui demanda ce qu'il pouvait faire pour que cet oeuf soit encore plus à son goût.

Le client lui répondit «Hum voyons, ce que j'ai par dessus tout, c'est les oeufs durs et ils sont plus pratiques à transporter, vous comprenez je travail dans la ville d'a coté et ce serait merveilleux de pouvoir avoir de tels oeufs pour mon déjeuner !».

Le cuisinier répondit, : «Nous pouvons tout à fait le faire, comprenez que cela nous demande quelques investissements, pourriez-vous vous engager à nous en acheter chaque jours pendant 1 mois et nous faire une avance, en échange nous vous faisons l'oeuf dur au même prix que l'oeuf que vous venez de gouter ?».

Ils se mirent d'accord.

Le cuisinier et la poule ont pu investir dans le nécessaire pour faire des oeufs durs, ils ont choyer leur premier client qui c'était investit dans le développement de leur affaire et au bout de quelques semaines, ils ont commencer à sympathiser.

Le client un jour leur demanda simplement «alors comment vont les affaires ?». Nos deux compères soupirèrent «on est en phase de développement, on est prêt à grandir, il nous faut plus de clients».

Le client surpris, s'écriât «ha bon ? c'est amusant ça, par ce que mes collègues au travail sont très jaloux de mes magnifiques oeufs que je mange le midi, si vous voulez, je peux vous inviter à la pause déjeuner pour faire un évènement dégustation, je suis sur qu'ils vont les adorer».

La poule et le cuisinier ont eu régulièrement de nouveaux clients, vécurent heureux et prospèrent, durablement car ils n'oublièrent jamais que leur métier était de nourrir leurs clients, pas de faire de l'immobilier.

vendredi 6 mai 2011

Une certification : c'est nécessaire

Une certification c'est un passage nécessaire dans une démarche de formation, ça doit valider à la fois le savoir, le savoir faire, les savoirs êtres et la manière dont l'apprentis à intégré et c'est approprié cette formation (via la création de quelque chose de nouveau, traditionnellement, le "chef d'oeuvre").

Dans le monde Agile nous avons la Scrum Alliance qui délivre actuellement:

*  des attestations de présences aux cours Scrum
*  suivit d'un diplôme de connaissance sur Scrum (via un QCP)
*  des attestations de mise en pratique de Scrum (Praticien certifié)
*  des attestations sur la capacité à former sur Scrum
    (et la validation des supports de cours)

Le tout se fait par correspondance (certes avec des exigences d'implications dans la communauté et dans les évènements Scrum) mais au final je ne vois pas trop de différence pour l'instant avec une attestation de "pouvoir représenter la franchise Scrum".

Alors qu'un processus de certification c'est avant tout un acte de reconnaissance et de mise en autonomie.

Une reconnaissance de la part de celui ou ceux qui ont suivit l'apprenti lors de son parcours, un acte symbolique qui permet de passer du rapport au père, qui à accompagné (lorsqu'il n'était pas encore autonome) dans la découverte d'un métier) au rapport aux pairs (reconnu comme un égal et confirmé dans son aptitude à pratiquer, créer, transmettre).

Et surtout il ne faut pas perdre de vue que personne n'est fiable à 100%, tout le monde peut faire des erreurs et surtout on à un inconscient.... Ce qui fait que ce n'est pas possible d'avoir un recul total sur ce que l'on fait et pour moi c'est une question d'humilité d'avoir passé des certifications et d'avoir des moments réguliers ou je peux faire superviser ma pratique professionnelle.

Par contre, en aucun cas une certification doit être mise en avant ou servir à la vente, l'accompagnement est avant tout une relation, il y a des milliers de coach, de Scrum Master, le tout est de trouver celui qui sera le bon pour vous et de vous demander par qui vous avez envie de vous faire accompagner.

le contrôle : la valeur numéro 1 de l'agilité, et si on était plus congruent ?

C'est intéressant de rappeler d'ou viennent les mots, le contrôle, viens des doubles rouleaux sur lesquels on inscrivait les comptes pour éviter qu'ils soient falsifiés, bref quelque chose de plutôt utile.

Dans l'agilité, j'entend souvent le discours théorique "le contrôle c'est pas bien", dans les faits, le contrôle est omniprésent.

Dans l'ingénierie, grâce aux tests et à leurs automatisation, on contrôle en permanence si le code produit bien les modifications de données prévues.

Mais dans les rapports humain on ne pas peut pas vraiment contrôler quelqu'un, on peut lui donner des ordres, vérifier la bonne exécution de son travail (ça reviens à contrôler les résultats, ce qu'industrialise l'agilité), on peut contrôler la manière d'obtenir les résultats demandés (les critères de qualité de code dans la définition de terminée) à la rigueur on peut contrôler l'identité de quelqu'un...

Par contre si on introduit la notion de rôle (c'est amusant, le monde est petit, "rôle" vient de "feuilles roulées portant un écrit"), pour récemment avoir le sens de "système d'obligation et de droits déterminant l'ensemble des comportements d'une personne légitimement attendus par les autres".

Et là on peut contrôler la personne au travers de ses comportements, on lui dit quels comportements il doit adopter et on vérifie si le rôle est bien joué...

Alors que l'on pourrait plus simplement parler de positionnement et contrôler les résultats obtenus (ce que fait naturellement l'agilité avec les tests). Et je trouve que c'est beaucoup plus simple d'expliquer à un chef de projet qu'avec l'agilité (via Scrum), son positionnement c'est d'être au service de la relation entre le client et les développeurs, de fixer les attentes et les engagements de chaque parties (ce que fait naturellement un contrat de coaching), plutôt que de parler de "rôle de Scrum Master".

Ca serait se focaliser sur l'état d'esprit, et de proposer une forme qui ne sera pas tout le temps la même, ça serait comme faire de l'accompagnement "à façon", un peu comme faire un logiciel "à façon" au lieu de "passer l'entreprise à un ERP", un concept révolutionnaire dans l'agilité :)

Ce qui me surprend toujours c'est l'ambivalence du discours institutionnel Agile vis à vis du contrôle, l'Agiliste ajoute généralement une couche de contrôle trop importante, dit que c'est pas bien, mais se refuse à passer une certification....

Ca fait quelque temps que je suis convaincu qu'il faut se professionnaliser, à minima se former faire certifier ce que l'on à appris en formation, analyser ses pratiques professionnelles, faire contrôler la qualité de son travail par une supervision régulière, faire comme n'importe quel professionnel de l'accompagnement, bref être en congruence avec ce que l'on prône.

C'étais à titre personnel, je me suis formé et j'ai un peu évangélisé (j'ai fait la première session sur l'accompagnement professionnel il y a 3 ans à Agile France) maintenant il est peut être temps de parler collectif, de l'avenir du marché Agile...

Et je pense il est vraiment temps qu'il y ai une visibilité professionnelle (voir associative) sur une démarche de professionnalisation autour de l'Agile (pour ne pas parler de congruence...)

Vous avez en pensez quoi ?

jeudi 5 mai 2011

Peut on "se planter" pendant une itération ?

C'est une question intéressante, suite à un échange sur une liste parlant de Scrum je reste étonné que personne n'ai relevé cette erreur, mais c'est l'occasion de rappeler les bases.

(une itération, ou sprint est une période de temps fixe pendant laquelle une équipe de développement à estimé pouvoir produire un nombre de points de complexité représentant un volume de tâches à réaliser).

Rappelons d'abord ce qu'amène l'agilité par rapport aux modes projets

Dans un mode projet traditionnel, on garantit :

  • la tenue d'un planning
  • le nombre de fonctionnalité livrée
  • le coût pour le client (enfin on essaye, la tradition des avenants en fin de contrats reste tenace)

=> On ajuste les écarts avec la qualité du code livré (mode L'arrache pour boucler et tenir les engagements qui entraine une baisse de qualité si on à sous-estimer la charge et sur-qualité ou développement de fonctionnalité non demandée si on a sur-estimer la charge).

Dans un mode agile, on sort du mode prédictif pour être dans un mode adaptatif, on garantit :

  • la date de livraison (fin d'itération)
  • le coût pour le client
  • la qualité (définie par la "définition de terminé")
  • l'indépendance du client (à chaque livraison le logiciel est utilisable avec un code suffisamment clair pour être éventuellement repris par d'autres, le client peut donc dire "stop" ou "encore"), on s'adapte avec ce qui à été livré.

=>On ajuste sur le nombre de fonctionnalité livrée (on n'est pas dans un projet, il n'y a pas de check liste à finir, simplement un service à rendre au client qui doit être rentable pour que le client continue).

Pour le cas pratique exposé sur cette liste de diffusion, L'équipe à livré 5 points au lieu de 38 et l'itération à été qualifiée de "ratée"

Dans une logique Scrum, il faut simplement constater que l'équipe une capacité à livrer de 5 points de complexité, elle ne va donc pas s'engager sur plus de 5 points pour la prochaine itération (on peut aussi prendre la moyenne des points livrés pour le prochain engagement, selon le contexte).

Scrum invite aussi à comprendre d'ou vient la différence, à vérifier si le client est satisfait de l'argent que lui à couté cette itération et de voir si il est prêt à continuer à payer l'équipe à ce tarif là.

Dans un mode agile, l'équipe s'engage à faire de son mieux, à livrer une qualité constante et à ne pas mettre le client en situation de dépendance, le client paye pour voir et si l'équipe à envie d'être renouveler elle à intérêt d'être rentable et de communiquer beaucoup avec le client.
Donc on ne peut pas se planter, on peut ne pas avoir été rentable... et si on ne sait pas dire quand l'itération à été rentable, il vaut mieux arrêter tout de suite de dire que l'on fait du Scrum et de parler de "gestion de projet itératif".

Considérer qu'une itération peut être "ratée" en expliquant que l'on a pas tenu le planning c'est que l'on est en mode projet itératif... A la rigueur une itération ratée, c'est une itération pendant laquelle la relation client tellement déplorable (et une relation ça se fait à 2) qu'après celle là, le client ou l'équipe dit Stop, rien à voir avec des critères de performances d'atteinte de résultats hérités de la gestion de projet (ça se trouve l'équipe à largement rentabiliser son salaire avec les 5 points de complexité livré).

Scrum n'est pas simple, c'est subtil, et ça vient d'une autre culture de travail, c'est délicat à appliquer en France car (entre autre) on à pas exactement le même marché du travail ni la même mobilité professionnelle....

jeudi 28 avril 2011

Les livres c'est chez Jean

J’ai eu la chance de découvrir le Monde en "tique", un bel endroit ou j’aime passer du temps, découvrir de nouvelles choses.

Je pourrais faire le choix d'Amazon qui sait très bien me proposer des livres, des produits dans mes centres d'intérêts mais ne me sort pas de mon univers connu, par contre Jean me connait et lui me fait découvrir de nouveaux centres d'intérêts.

Et grâce à un minimum de veille j'ai déjà lu les livres qu'Amazon me sugère bien avant qu'il me les propose.

Par contre c'est au monde en "tique" que j’ai découvert mes premiers livres sur la vente, sur le coaching...

Je ne vois pas comment Amazon, alors que je commandait que des livres du style Practices of an Agile developper ou encore du zombie survival guide , aurait pu me proposer le non moins excellent : comment devenir Coach,

pourtant Jean l'a fait et quelque années plus tard, ça donne des résultats surprenant : Agilité et coaching : des gènes communs ?

C'est comme cela que je conçoit une relation commerciale : un échange entre passionnés, ce qui ne pourra jamais être en concurrence avec un quelconque système automatisé.

Et vous vous acheter vos livres ou ?

Agilité et coaching : des gènes communs

C'est intéressant de voir d'ou vient le coaching,

Certains professionnels ont eu plus de succès que d'autres dans leur métiers, ils ont commencé à former (sur le savoir) leurs collègues, puis à être tuteur pour leurs transmettre le savoir faire.

Ensuite ils sont devenus consultants, et sont aller sur le lieu de travail de leurs clients pour les conseiller sur la mise en application de ce qui à marché chez eux et apporter à leurs clients les meilleures pratiques.

Après cette étape, ces consultants sont passés de j'accompagne sur à j'accompagne quelqu'un, ce qui à donné le coaching professionnel. l'idée étant d'accompagner quelqu'un pour qu'il découvre par lui même ce qui fonctionne le mieux pour lui, de lui permettre de gagner de la bouteille et d'être autonome.

Actuellement l'agilité touche à la fin du conseil (on passe les gens à Scrum, on ne fait pas de l'accompagnement à façon) et découvre tout juste le coaching.

avec un peu de recul (cela fait 3 ans que je me suis formé au coaching) je suis surpris de voir que dans les pratiques Agiles, il y a déjà des fondamentaux du coaching.

  • C'est un mode de régie, on achète du temps, le client se fait coacher pendant quelques minutes, après il décide si cela lui convient et à chaque itération (on parle de séance de coaching), il peut dire stop, il n'y a pas de création de dépendance, on demande juste une séance de clôture.
  • L'objectif du coaching doit être aussi clair test unitaire (le test passe ou pas, l'objectif est atteint ou pas); d'ailleurs je préfère parler de développement dirigé par les objectifs au lieu que de développement dirigé par les tests, les tests n'étant qu'une manière de fixer les objectifs que doit atteindre le code.
  • L'objectif à atteindre ne doit dépendre que du client, en coaching d'équipe, l'objectif ne dépend que des personnes présentent dans l'équipe, pour éviter la dépendance.

C'est comme dans l'agilité et le travail en équipe pluridisciplinaire (toutes les compétences pour faire le logiciel doivent être présentent dans l'équipe pour que l'équipe puisse livrer un logiciel utilisable sans dépendre d'autres services).

  • On établi un contrat clair avec le coaché, ce contrat définit les rêgles du jeux ainsi que le mode de fonctionnement (ce qui s'apparente à la définition de terminé et la charte de projet).
  • Cela demande une forte implication du client, c'est pourquoi il paye d'avance ( il se fait rembourser si il souhaite arrêter), on en parle pas beaucoup dans l'agilité, mais une itération commencé devrais être payé d'avance.
  • C'est le client qui sait ou il va et comment il va vous utiliser, comme dans l'agilité, c'est son produit, c'est son objectif et il vous à disposition pour avancer.

Je travail actuellement sur le programme pédagogique d'une formation de coach pour les coach agiles et je me dis qu'un bon coach agile, peut rapidement devenir un bon coach tout cours, il suffit qu'il change ses pratiques d'ingénierie par des pratiques de coaching avec une formation adapté.

Et vous, vous sentez vous coach dans l'âme ?

Un coach ou un coach ?

Coach et coach, c'est un mot qui à plusieurs sens, selon si on l'utilise dans un contexte Français ou dans un contexte Américain.

Ces mots n'ont pas suivi le même cheminement, pour la France, le coach était à l'arrière des diligence et avait pour charge de conduire les voyageurs à bon port.

Le coa(t)ch au US est l’entraineur de l’équipe de football américain, un positionnement beaucoup plus directif, pour ceux qu’il accompagne, c’est aussi lui qui était le chauffeur du bus qui amenait l’équipe au match, c'est pourquoi les bus s’appel «coach».

On a donc deux positionnement et deux métiers différentes pour le même mot, on coach sur l’agilité, sur Scrum, c'est les coach "en quoi", ou on accompagne des clients vers leurs objectifs.

Nous sommes à cette période charnière dans l'agilité, formateurs sur l'agité Scrum etc..., puis consultant, puis coach Scrum, coach agile, puis se mettre à accompagner leurs clients vers leurs objectifs.

La particularité de l'agilité c'est que les germes de cette profession de "coach en qui" sont déjà présents, que ce soit dans les pratiques d'ingénierie ou dans Scrum, il y a des similitudes étonnantes.

Et vous êtes vous accompagné sur quelque chose ou accompagné par quelqu'un ?

Musée des usages disparus : Comment transformer son Iphone en GPS ?

Je vous vois venir, vous allez me dire que votre Iphone fait déjà GPS.... et bien pas exactement...

L'iphone et le GPS dépendent tout deux du réseaux de satelittes pour vous localiser, la différence c'est qu'avant l'Iphone, ce que l'on appelait un GPS ne demandait que la présence du réseau satellite et était autonome pour le reste...

Pour afficher une carte et l'itinéraire sur votre Iphone, il vous faut une carte SIM, son code, un abonnement DATA, l'accès à un réseau qui supporte les flux de données et un tas de câbles et de services en état de fonctionnement jusqu'aux serveurs de google maps.

Rassurez vous :) il y a une application qui permet de transformer son Iphone en GPS : http://www.offmaps.com/ , grâce à cette application vous pouvez télécharger des cartes sur votre Iphone et les utiliser sans avoir accès à Internet.

Ca m'étonne de voir que sous le prétexte de "nouveaux usages", je me retrouve à être de plus en plus dépendant à une multitude de services et de couches technologiques tout en faisant disparaitre les usages de base, une sorte de régression technologique.

Dans le même style, je me rappel que les mobile Nokia (il y a 7/8 ans) permettaient de bloquer ou d'autoriser les appels entrant de certains groupes de contacts; on pouvait faire en sorte d'être joignable que par la famille et les amis après 20h, les autres vont directement sur le répondeur, idem pour les numéros masqués.

Ce qui me parait impossible sur les Smartphones actuels (en tous cas sur l'Iphone).

Vous avez vu d'autres usages simples qui ont disparu ces derniers temps ?
Ce serait l'occasion de faire une section "usages disparus" au musée de l'informatique :)

jeudi 27 janvier 2011

Amap retour d’expérience 1/4 : c’est quoi une Amap ?

Quand je me suis intéressé au Lean, en 2007, j'ai commencé à voir comment l'appliquer dans ma vie de consommateur.
J’avais à l’époque un abonnement à un panier bio dans un système de paniers de légumes Bio, sans relation directe avec le producteur et je souhaitais avoir une relation commerciale plus proche de mes valeurs, de mon lieu de vie et tout simplement connaitre la personne qui produit les légumes que je consomme.
je vais vous raconter ici ce que mon parcours dans les Amaps m'a appris et en quoi cela a enrichi ma vision de l'agilité.

Lire la suite...

lundi 11 octobre 2010

cercle sur le forum ouvert à Paris le 18 octobre 2010

Bonjour,

, je vous propose de nous retrouver pour un cercle sur le forum ouvert le lundi 18 octobre juin à partir de 19h au café livre au 10, rue Saint-Martin, 75004, Paris (en face de la tour St Jacques),

Si le cœur vous en dit, amenez vos amis, vos collègues ou vos clients intéressés par le Forum ouvert : plus on est de gens passionnés, plus on a de conversations passionnantes!

Notre point de rencontre est facile d’accès par tous les transports en commun. Si vous ne pouvez être là pour souper, n’hésitez pas à venir seulement prendre un verre!

J'aurai le plaisir de partager avec vous les rencontres que j'ai faites avec des facilitateurs Haitiens cet été.

J’espère avoir le plaisir de vous voir à cet évènement.

lundi 13 septembre 2010

La charte d'exercice du coach agile professionnel

Cela fait quelques années que je me demande ce que c'est pour moi d'être un professionnel de l'accompagnement Agile.

Après avoir partagé mes réflexions avec d'autres professionnels du métier tels que Jean François Hélie , Jean Claude Grosjean et Alexis Monville, nous avons souhaité mettre au point un texte fédérateur ou chacun d'entre nous puisse se reconnaitre avec sa vision, son style, autour de l'essence de notre pratique.

Voici notre vision du coach agile professionnel ; qu'en pensez-vous ?

Lire la suite...

vendredi 4 juin 2010

rencontre sur le forum ouvert à Paris le 16 juin 2010

Bonjour,

L'été approche, je vous propose de nous retrouver pour un cercle sur le forum ouvert le mercredi 16 juin à partir de 19h au café livre au 10, rue Saint-Martin, 75004, Paris (en face de la tour St Jacques),

Si le cœur vous en dit, amenez vos amis, vos collègues ou vos clients intéressés par le Forum ouvert : plus on est de gens passionnés, plus on a de conversations passionnantes!

Notre point de rencontre est facile d’accès par tous les transports en commun. Si vous ne pouvez être là pour souper, n’hésitez pas à venir seulement prendre un verre!

Ce sera aussi l'occasion de vous montrer un outil de coaching inspiré de mon expérience des forums ouvert que je réalise dans le cadre de mon master en coaching : le cercle de reconnaissance

J’espère avoir le plaisir de vous voir à cet évènement.