Click on the logo to register on Agile Coach Camp Canada website

Tomorrow morning will be the kind of easy wake up as I’ll attend Agile Coach Camp Canada in Waterloo (Ontario) with 3 colleagues of mine from Pyxis.

Looking forward to meet you there with all the others great agile coaches

Follow #accca on Twitter

To know more about registred people, have a look at postion papers.

Ni l’un ni l’autre. Je choisis la confiance qui permet le conflit qui engendre l’engagement qui soutient l’imputabilité qui mène à se concentrer sur les résultats!

Il y a quelques semaines, j’évoquais avec Éric Laramée le fait que quelques fois, lorsqu’une chose doit être réalisée, il vaut mieux le faire sans attendre la permission puis demander pardon par la suite. J’avoue avoir succombé à cette facilité par le passé.

À la suite de cette conversation, Éric m’a dirigé vers cet article récent de Ben Snyder : “Don’t Ask For Permission When Forgiveness is Easier” dont je vous recommande la lecture.

Je n’ai pas pu m’empêcher de faire le parallèle avec la (re)lecture récente du livre de Patrick Lencioni : “The Five Dysfunctions of a Team: A Leadership Fable“.

Dans un groupe, lorsqu’une personne agit à l’encontre des autres, même s’il demande pardon par la suite, cela laisse des traces. C’est d’autant plus vrai que l’action est faite avec une intention cachée, une intention de nuire ou bien à des fins personnelles sans égards au groupe.

La prochaine fois que vous entendrez l’expression bien connue “il vaut mieux demander pardon que demander la permission”, prenez quelques minutes pour comprendre le contexte, et pour déterminer à qui profite l’action qui a été entreprise.

Cette expression révèle souvent les dysfonctionnements fondamentaux évoqués dans le livre ci-contre. Une telle action ne pouvant venir d’un membre d’une équipe telle que décrite par Patrick Lencioni, une équipe dont les membres placent la réussite du groupe avant la satisfaction personnelle.

Finalement ce que ça m’inspire c’est : “Encore de belles conversations à venir”, beaucoup d’efforts à faire sur le plan personnel et de beaux jours pour continuer à faire un métier qui me passionne.

Et vous, êtes-vous inpiré?

Click on the logo to register on Agile Coach Camp Canada website

I’ll attend Agile Coach Camp Canada in Waterloo (Ontario) with many other great agile coaches

Follow #accca on Twitter

To know more about registred people, have a look at postion papers.

Pour qu’une action se réalise, il faut un porteur et une occasion identifiée dans le temps.

Pour qu'une action se réalise, il faut un porteur de l'action et une occasion identifiée dans le temps.

Dans le tableau Kanban, lorsqu’une carte est bloquée, l’équipe à tendance à dire : « Cette carte est bloquée! Elle dépend de X, il faut que je le rappelle [...] mais il n’est pas très disponible. »

Lorsque j’entends ceci, je parie : « dans deux jours, la carte sera toujours bloquée au même endroit! ». D’ailleurs pourqoui changerait-elle de place? Il y a deux jours, la carte était là et j’avais déjà entendu la même excuse phrase, il n’y a donc pas de raison que cela change. Même cause, même effet!

Alors l’équipe me regarde avec de grands yeux et nous entamons un dialogue qui ressemble au suivant :

- moi : « Ok, qui va le faire et quand? ».

- équipe : « Il faut rappeler X, mais il n’est pas très disponible. ».

- moi : « Qui subit l’impact de la carte bloquée? ».

- équipe : « C’est nous! ».

- moi : « Qui a intérêt à ce que la carte soit débloquée? ».

- équipe : « C’est nous! ».

- moi : « Ok, qui va appeler et quand? ».

Certaine fois, je n’ai pas fini de poser la question qu’il y a un volontaire pour prendre la responsabilité de régler le problème dès la fin du daily. D’autre fois la réponse est : « Je n’ai pas le temps maintenant, je regarde mon horaire dès la fin de la rencontre et j’y place cette tâche ».

[Quelques semaines plus tard...]

L’équipe adresse chaque jour les points bloquants avec une action portée par une personne et identifiée dans le temps. Et les cartes bloquées se libèrent

Êtes-vous toujours attentifs aux : « Il faut que? »

Mettre de la pression sur le système pour faire apparaître le gaspillage

Afin de faire apparaître les goulots d’étranglement dans le processus de réalisation d’une équipe fonctionnant en Kanban, j’ai proposé de réduire les limites du WIP¹

Lors de la mise en place, l’équipe a fixé des limites confortables pour le WIP. Après deux semaines d’utilisation du tableau, l’équipe n’a pas identifié de goulot d’étranglement.
Lorsque j’ai fait ce constat, j’ai proposé au coordonnateur, lorsqu’il a remodelé le tableau à la réception du nouveau tableau, de réduire la capacité de certaines colonnes en plus des modifications prévues lors de la rétrospective.

Cela va bientôt faire trois mois que le tableau Kanban est en place et deux mois que les limites ont été baissées, et nous avons observé des difficultés telles que les suivantes :

1. Des cartes sont bloquées depuis plusieurs jours et il ne reste qu’un espace disponible dans la colonne pour passer des nouvelles demandes.
2. Il y a deux cartes dans une case.
3. Une case ‘blocage spécial’ à été crée pour sortir une carte qui est bloquée et qui n’est plus prioritaire.

En discutant avec l’équipe, il apparaît que la baisse des limites a eu l’effet escompté, puisque avant cette baisse, il y avait suffisamment de place libre pour que de nouvelles cartes puissent passer même si d’autres étaient bloquées.

Content de ce résultat, je comptais proposer à l’équipe de réduire le nombre global de cartes présentes dans le tableau, car actuellement, les limites établies permettent d’avoir un nombre que « je » juge trop important d’items en cours simultanément.
En effet les limites sont établies par étapes du flux de travail, mais les mêmes personnes travaillent sur plusieurs étapes et cela ne force pas les items à sortir le plus vite possible, certains restant même plusieurs jours dans le backlog.

Mais je me suis ravisé car mes solutions ne seront jamais meilleures que celles de l’équipe.
Alors, au lieu de proposer ma solution de réduction du nombre de cartes dans le tableau, j’ai proposé à l’équipe de travailler sur la notion de gaspillage lors d’une rétrospective.

À la suite de cette rétrospective, après avoir identifié l’attente (une carte est souvent en attente dans le tableau) comme l’un des plus gros poste de gaspillage, l’équipe a commencé à mesurer le temps passé par les cartes dans les différentes phases du processus à l’aide de la méthode proposée dans l’article « Flow. Discover Problems and Waste in Kanban ».
J’espère que ces mesures permettront à l’équipe de trouver « ses » solutions pour éliminer le gaspillage, solutions qui rendront la mienne obsolète.

Quels sont les mécanismes que vous mettez en place pour contraindre le système ? Quels sont les résultats que vous obtenez ?

Astuces d'équipe pour améliorer la mêlée quotidienne

Il y a quelques jours j’ai publié « Odeurs de mêlée quotidienne », article dans lequel j’évoquais des symptômes observés lors de mêlées quotidiennes.

Depuis, l’équipe a fait des progrès très intéressants que je souhaite partager.

Les symptômes présentés dans le premier billet sont répétés ci-dessous accompagnés des solutions ou bien des étapes des solutions mises en œuvre.

L’équipe ne répond pas aux 3 questions.

Afficher les 3 questions pour que l’équipe puisse les voir facilement chaque matin. Mais, comme on pouvait s’y attendre, le fait d’afficher les 3 questions, n’a pas eu l’effet attendu. Cette solution ne venait pas de l’équipe qui n’en a donc pas tenu compte. Pour que la mêlée quotidienne s’améliore, il faut aider l’équipe à se l’approprier.

Montrer l’exemple. Dans ce deuxième essai, à la fin de la mêlée, j’ai repris un comportement observé et je l’ai rejoué pour présenter un exemple de l’intervention attendue de chacun des membres de l’équipe. Il peut être bon de répéter le processus de temps en temps pour aider l’équipe à progresser.

L’équipe ne s’approprie pas la gestion du tableau et des graphiques de progression (burndowns).

1. Éloigner le ScrumMaster pendant un jour ou deux, ou bien, profiter de son absence. Pendant ce temps là, l’équipe continue à faire sa mêlée quotidienne.
2. Au retour du ScrumMaster, attendre la fin de la mêlée et poser la question suivante : « Êtes-vous confiant en votre engagement? [...] Quand je regarde le graphique, je ne suis pas en mesure de le savoir. » La conséquence directe de cette dernière question : une belle discussion, de très bonnes interrogations sur le fonctionnement et l’utilité des graphiques visuels et une prise en charge des graphiques par plusieurs membres de l’équipe.
3. Reposer  ensuite la question de l’engagement à plusieurs reprises. L’équipe se la pose toute seule très rapidement.

L’équipe rapporte son occupation de la veille au tableau ou bien au ScrumMaster, sans regarder les coéquipiers avec pour effet de bord ‘d’autoriser’ des conversations parallèles.

1. Éloigner l’équipe du tableau. La première fois l’équipe est déstabilisée, mais les coéquipiers comprennent vite qu’il est préférable de se préparer avant la mêlée et forment un cercle pour se parler.
2. Proposer au ScrumMaster de sortir du cercle pendant quelques temps. En se positionnant en arrière il bénéficie d’un poste d’observation privilégié. N’étant plus visible  des membres de l’équipe, ceux-ci ne peuvent plus lui parler directement et lui rapporter l’activité de la veille. Inviter le ScrumMaster à intervenir à la fin pour donner de l’information au besoin.
3. Le respect de la parole est régulé par l’utilisation d’un objet de parole que l’équipe s’approprie et se passe de main en main.

Les effets de ces petites astuces se sont très vite fait sentir dans l’équipe avec pour conséquences immédiates de ramener la mêlée à 10 minutes et à son utilité première, c’est-à-dire, un moment de synchronisation de l’équipe. Il reste alors 5 minutes pour des informations complémentaires, mettre à jour les graphiques d’avancement, ou bien retourner travailler plus vite sur les tâches de l’itération en cours.

Ces astuces ont permis de progresser rapidement vers une mêlée quotidienne beaucoup plus efficace, menée dans un temps plus court.

Un grand bravo à l’équipe pour ses apprentissages.

Et vous, quels sont vos ‘trucs’?

Photo de mêlée attribuée à http://www.flickr.com/photos/cdm/

Il y a quelques semaines de cela, après plusieurs jours sans intervenir auprès de l’équipe, j’ai pu observer, lors de mon retour, une mêlée quotidienne¹ avec quelques dysfonctionnements.

Avertissement :

Ce que vous lirez n’est pas un jugement, ce que j’ai observé ne constitue pas à mes yeux des erreurs, mais démontre plutôt un apprentissage naissant de la mêlée quotidienne.

Contexte :

• L’équipe a terminé une première itération et s’apprêtait à commencer la deuxième.
• Finalement, elle stabilise pendant une semaine l’application pour une release annoncée très tard. Son passé l’a rattrapé et la date ne peut être manquée.
• De façon autonome, l’équipe a gardé les nouvelles pratiques mises en place dans la première itération et n’est pas retombée dans le mode “panique livraison” du passé.
• Je suis présent le jour de la mise en ligne et elle a lieu sans que l’équipe n’ai eu à faire de temps supplémentaire.

Symptômes observés :

• La ScrumMaster(SM) donne la parole à tour de rôle : “c’est à toi Louis”, Louis fait le tour de la table pour venir parler.
• Une personne fait du reporting face tableau ou tournée vers le ScrumMaster,  et des conversations parallèles ont lieu.
• Personne ne donne un statut sur le format des 3 questions²
• Le tableau de l’équipe n’est pas à jour. Le statut des toutes les tâches est mis à jour en direct, le tableau ne reflète l’état d’avancement qu’après l’intervention. Cela fait perdre du temps et provoque des cassures de rythme dans la prise de parole.
• Il y a par moment des personnes en retrait ce qui donne deux “épaisseurs” au groupe.
• La ScrumMaster demande plusieurs fois ce que l’on fait de certaines tâches au tableau avant d’obtenir une réponse.
• Un bureau gêne l’espace devant le tableau, personne ne le déplace.
• Une personne est occupée pour la mise en ligne, elle n’intervient pas du tout et ne donne pas de statut aux autres membres de l’équipe.
• Deux personnes sont assises.
• Finalement, la mêlée dépasse de 5 minutes le temps imparti.

Debrief et plan d’action :

À la suite de la mêlée quotidienne, je prends quelques minutes avec la ScrumMaster pour lui demander comment elle a perçu cette mêlée, comment elle se sent. Ce que je trouve formidable c’est qu’en quelques secondes elle m’a donnée la plupart des observations ci-dessus assorties de commentaires pertinents : “c’est comme s’ils n’avaient pas encore pris la mesure le l’utilité de mettre à jour le tableau” par exemple.

S’en est suivi un dialogue ressemblant à celui ci-dessous :

SM : “Mais comment je peux faire pour changer le comportement de l’équipe pendant la mêlée ?”

Moi : “Quel est le comportement qui te dérange le plus ?”

SM : “Je dois dire aux personnes de venir quand c’est leur tour”.

Moi : “Que pourrais-tu faire le plus simple pour changer cela”

SM : ” Tu m’as déjà dis de ne pas intervenir, de laisser l’équipe faire son daily”

Moi : “Oui effectivement, peut-être pourrais-tu rappeler à l’équipe ce que tu attends pendant le daily : qu’ils fassent un statut vers l’équipe, en répondant aux 3 questions puis les laisser continuer sans intervenir, en laissant des blancs, des silences s’il y en a. Je t’inviterai à le faire rapidement sans forcement attendre une rétrospective.”

SM : “C’est vrai, je pourrais faire ça, mais ils ne répondent pas aux 3 questions”

Moi : “Les connaissent-ils, peut-être ont-ils besoins que quelqu’un rappellele ces questions”

SM : “Pour qu’ils les voient les questions ont pourrait les afficher”

Moi : “C’est une très bonne idée ça, avoir les trois questions affichées ça permet de se les mettre en tête à chaque mêlée”

Et nous avons continué la conversation encore quelques minutes.

Finalement, le bureau qui gêne devant le tableau va être poussé un peu, les questions vont être affichées, la SM va répéter le comportement attendu lors du daily et laisser l’équipe aller. Les résultats dans un prochain billet

Dans vos organisations ou dans vos équipes, comment se passent vos mêlées quotidiennes, observez vous d’autres symptômes ?

Si vous êtes coach ou ScrumMaster, comment intervenez vous pour que l’équipe prenne conscience et règle ces symptômes ?

[Mise à jour]

Pour découvrir la suite voir le billet : « Odeurs de mêlée quotidienne – Astuces pour progresser »

Une équipe peut-elle vivre sans ScrumMaster 'officiel'?

L’été dernier j’ai rejoint un projet qui avait démarré 15 mois auparavant. L’équipe chargée du développement était répartie entre 3 sites (1 à Montréal, 2 à Bordeaux). Peu après mon arrivée, il y a eu réorganisation des équipes, et dans notre équipe, nous avons proposé de ne pas avoir de ScrumMaster ‘officiel’. La question suivante se posait donc pour nous :

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’?

Je dois dire tout de suite que nous n’avons pas eu le loisir de pousser très loin l’expérimentation car le projet a été interrompu environ 6 semaines après la réorganisation. Nous avons tout de même travaillé avec ce modèle pendant 2 itérations¹.

Cette équipe était composée de 3 personnes. Deux étaient présentes depuis longtemps : depuis le début pour l’un et depuis 10 mois pour l’autre. Puis il y avait moi, nouveau sur le projet. Le coéquipier leader naturel travaillait depuis plusieurs mois sur le module dont nous avions la charge. Il y avait une bonne cohésion, nous étions à l’aise avec Scrum et nous nous sentions en contrôle!

Nous tenions notre mêlée quotidienne² sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées³ — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit⁴ régulièrement avec le propriétaire de produit⁵. Nous aidions tous à l’organisation de l’équipe, même si une très grosse partie du travail était réalisée par le leader de l’équipe.

Voici les avantages obtenus lors de ce projet

• Nous nous sentions vraiment autonomes. Nous organisions nous même nos rencontres importantes (mêlée quotidienne, maintenance du carnet de produit, réunion avec les intervenants extérieurs).
• Nous étions beaucoup plus responsables. Lorsque quelque chose allait de travers, nous ne pouvions pas dire :  «Le ScrumMaster ne fait pas son boulot ».
• Nous avions une bonne flexibilité, mais ce point relève petut-être du fait que nous n’étions que trois.
• Contrairement à ce que j’ai vu à maintes reprises, personne dans l’équipe n’était perçu comme ‘supérieur hiérarchique’.

Nous n’avons pas subi d’inconvénients, mais peut-être y en aurait-il eu à long terme.

Cependant je suis convaincu d’une chose : il y a un préalable. Cela peut fonctionner à la condition que l’équipe soit mature, tant sur le plan des personnes qui la compose que  sur le plan de la maîtrise des outils, du processus Scrum et de la communication. Je vous invite à lire, sur un thème similaire, le retour d’expérience d’Isabelle Therrien, où elle fait mention des dérives qui peuvent se produire. Dans les commentaires notamment, il est question de prendre du recul, ce qui n’est pas toujours simple quand on a la tête dans le code pour livrer de la valeur à longueur de journée.

Résumé en quelques lignes, le choix de ne pas avoir de ScrumMaster ‘officiel’ peut paraître rapide ou évident, mais tout ceci ne s’est pas décidé en un jour. De fait, même une fois en place, les questionnements suivants revenaient de façon récurrente dans nos conversations :

• S’il fait fonction de ScrumMaster, le leader doit-il prendre le titre et s’exposer?
• Ce rôle peut il être partagé, et dans ce cas, est-ce efficace?

Pour conclure, je dois dire que j’ai aimé cette expérience. Même si cela n’a pas duré bien longtemps, j’ai vu les prémices de quelque chose que je voulais vérifier depuis longtemps : « le rôle de ScrumMaster est un rôle temporaire, il a pour objectif de rendre son équipe capable de se passer de sa présence, et cela peut fonctionner ».

Avez-vous des retours d’expérience similaires à partager ?

Tableau Kanban de l'équipe "production" (première version)

Depuis quelques semaines j’ai le plaisir d’accompagner une équipe dans son adoption d’une gestion de projet en mode Agile. C’est un mandat passionnant sur plusieurs aspects :

• La motivation et l’envie de l’équipe, qui se traduit par un engagement de tous.
• L’utilisation en parallèle de Scrum et de Kanban qui rend mon intervention en tant que coach intense et très riche.

L’équipe est divisée en deux “sous-équipes” qui ont des rôles et des activités bien différentes : L’une s’occupe du volet production (newsletters, mini-sites, mises à jour de l’existant etc.) et l’autre du volet développement des nouvelles fonctionnalités pour le site Internet.

Suite à nos préconisations, chacune des équipes a choisi d’adopter l’outil qui lui semblait le mieux adapté à ses contraintes : Kanban pour l’équipe production et Scrum pour l’équipe de développement. (Ce n’est d’ailleurs pas le modèle que nous avions proposé en premier lieu)

Au cours de la première itération (l’équipe a choisi des itérations de 2 semaines), en regardant le tableau Scrum de ses collègues, un des membres de l’équipe de production (fonctionnant en Kanban) m’a dit : “Notre tableau ne se vide jamais, ça c’est correct, mais notre colonne “Done” n’est jamais pleine, ça me manque, ça donne l’impression qu’on travaille moins.”

En effet, le tableau Kanban reflétant un flux continu ne se vide jamais comparé au tableau Scrum qui a un cycle de vie de 2 semaines. De plus, l’équipe production vide la colonne “Done” lors  de la mêlée quotidienne après avoir passé en revue les items terminés.

Pour changer cette perception, l’équipe à décider de laisser toutes les tâches à “Done” sur le tableau entre chaque rétropective qui se déroule toutes les 2 semaine . En plus de se donner de la visibilité sur le travail accompli, l’équipe compte utiliser cette pratique pour mesurer plusieurs éléments :

• Les cartes sont-elles remplies correctements : date de début, date de fin, client, identifiant de la tâche, etc.
• Le nombre de cartes “urgence”  par 2 semaines.
• Le temps de sortie moyen par taille d’items.

Votre équipe Kanban a-t-elle déjà eu ce besoin de voir son accomplissement dans le temps ? Qu’avez-vous mis en oeuvre pour cela ?

In the post I didn’t have time to do this Martin said :

Life is as such as we accept more work and activities than we have time for, so claiming we didn’t have time for something seems like an understatement. In reality, what really happens is:

1. the individual didn’t want to do the work in the first place;

2. the person is procrastinating;

3. the person has difficulties in prioritizing their activities and cannot make a decision to determine which piece of work is more critical and should be completed first.

I used to get this excuse out of my hat too often in the past and that’s something I’m really trying to improve.

The tools I use are Getting Things Done known as GTD and popularized by David Allen and more recently the Pomodoro technique as they help me to manage my todos : to prioritize and to focus on doing.

The Pomodoro technique really helps to focus on the work that has to be done. Prioritize your tasks for the day, estimate, and do it focusing in small iterations : 25 minutes time-boxes + a 5 minutes break.

GTD is more big picture. But the most valuable impact from GTD is that all the work “to be done” is visible, and so that’s oblige me to make a decision : “Do I want to do it? Do I have to do it? Yes? No?”. If the answer is “NO”, I delegate it, or I delete it. No longer in my list, no longer in my mind! Sometimes I fold the idea in a “Someday/Maybe” place to delay it until I recover enough energy, or it becomes the things to do.

The last thing I did is to publicly communicate my occupations to my colleagues.

Learning to say “NO” is one of the hardest thing to do for me

How do you manage to eradicate the “I didn’t have time to do this” excuse from your vocabulary?

La première conférence Agile Tour à Montréal débute dans quelques heures et malheureusement pour les derniers arrivés, c’est COMPLET.

200 heureux participants vont profiter du programme de conférence suivant :

The one thing you need to know
Mary Poppendiek

L’Agilité s’impose dans toute l’entreprise
Jérôme Barrand

Agile et le management : le chaînon manquant
Bruno Collet

An Introduction to Business Value Engineering
Joseph Little

Introduction à Kanban et expérience pratique chez IBM Bromont
Benoit Lapointe

Convergences entre CMMI et les approches Agiles (Scrum, XP, etc.)
Richard Basque

L’Agilité dans des projets d’envergure
Léo Lachance

Le Daily Scrum pour les équipes distribuées
Steffan Surdek

Cartographier votre valeur
Louis-Philippe Carignan

Both sides of the story! Go out and motivate people to make exciting changes
Gino Marckx

Agile Mythbusters: What People Are Really Doing in Practice
Scott W. Ambler

Les 7 péchés capitaux du développeur
Freddy Mallet

Bien testé ou mal testé? Telle est la question!
Ludovic Dubois

Suivez l’événement sur twitter avec les tags #at09mtl et / ou #agiletour ou bien

Au plaisir de vous voir sur place car je fais partie de l’équipe d’organisation

• New tweetup, Agile Tour 2009 Montreal. Tweet "yes #ev1-at09mtl" to RSVP #at09mtl http://twubs.com/ev1-at09mtl #
• I just became a member of the Twub for #at09mtl at http://twubs.com/at09mtl #
• #at09mtl will be the hashtag for #agiletour #montreal #
• #agiletour #montreal more and more people on the waiting list. If you decide to cancel send me a DM, I'll make someone else happy #
• #agiletour #montreal 200 emails send to confirm registration , and 20 emails send to people on waiting list #
• #agiletour #montreal sold out See you on Tuesday 27th lucky attendees #
• RT @tbalbous: #agiletour #montreal who'll get the last seat. #
• #agiletour #montreal 2 padsas #
• RT @pyxistech: Vous êtes Agile quand : Vous classez systématiquement votre liste d’épicerie par ordre de priorité… http://bit.ly/1Okzdt #
• @pyxistech bravo pour la publication dans Les Affaires http://ping.fm/2QBnN #agile #montreal #
• #agile #scrum #agiletour #montreal 27th october! last 10 tickets to buy! Hurry up! #

Powered by Twitter Tools

Retrouvez les Pyxissiens lors des étapes canadiennes de l’Agile Tour, le lundi 26 octobre à Québec et le mardi 27 octobre à Montréal ou l’événement se tiendra à guichet fermé et rassemblera 200 personnes.

Retrouvez toutes les présentations des Pyxissiens sur le site

http://sedevelopperagilement.com/

Profitez de l’événement pour vous offrir le timer _agilely pour Ipod/Iphone et le T-shirt “What did you stand-up for today ?” en vente sur place.
La totalité des recettes de la vente des T-shirts et des applications Ipod/Iphone va à FIAN
(pour en savoir un peu plus sur l’implication de Pyxis auprès de FIAN)

Au plaisir de vous rencontrer à Montréal

UPDATE [17th august 2009] : english version available Can you grow a business profitably while improving the lives of people?

François et Martin se sont livrés à un exercice très intéressant dont vous pouvez lire le résultat : Peut-on faire croître une entreprise de manière profitable tout en améliorant la vie des gens et en s’amusant

Les personne qui se posait la question, “Pourquoi Tremeur a-t-il traversé l’Atlantique pour aller travailler à Pyxis ?”, auront une partie de la réponse et comprendront je l’espère que ces choses font du sens pour moi. Les mots qui sont écrits là ne sont pas du vent. Tout n’est pas encore parfait, mais les choses avances, j’aime (et je suis fier) y participer. Mon travail prend sens !

Ce long dialogue entre Martin et François va d’ailleurs bien au delà de Pyxis et propose une voie (et voix) différente et bien plus large que la seule organisation Pyxis

J’ai bien hâte de lire vos commentaires en bas du billet sur le blog de Pyxis, abonnez-vous au fil RSS

L’actu est riche ce soir 2 posts dans la même soirée !

Je relais le message de Laurent Morisseau sur la mailing liste XP-France

Bonjour,

Je souhaite organiser prochainement une première rencontre des
praticiens de Rennes et des environs.

Je propose à ceux qui sont interessés  de vous inscrire ici
<http://groups.google.com/group/agilerennes>  pour faciliter les
échanges.

Laurent

L’agilité prend racine en Bretagne, c’est une TRES bonne nouvelle

Bon courage Laurent pour la mise en route de ce groupe, j’espère que tu auras autant de personnes intéressées que nous pouvons en avoir à Nantes lors de chacune de nos rencontres.