mardi 27 octobre 2009
Albums Photo Agile Tour
Agile Tour Grenoble 2009, c fini
Agile Tour Grenoble 2009 est fini… après des mois de préparations, je suis très ému par les retours que j’ai pu obtenir. 300 personnes étaient présentes durant cette journée. Les agilamis du CARA étaient partout : à l’accueil, à la gestion du temps, dans les sessions. Un cadre de prestige avec un amphithéâtre plutôt confortable. Des horaires respectés à la minute près. Un grand merci aux 20 orateurs pour le niveau de leur intervention, certains d’entre eux sont venus de très loin ;-) De Stockholm pour Henrik Kniberg et d’outre-Atlantique pour Elisabeth Hendrickson !
Merci aussi aux sponsors de l'étape grenobloise : leur donation est précieuse pour un évènement de cet ampleur!
Je tiens à remercier du fond du cœur mes co-équipiers de l’organisation de cet évènement : Georges Allemand, Emmanuel Huguonnet, Anne-laure Dalban, Alexandre Boutin, Yves Crespin, Cédric Bourgeois, Arnaud Pierrel, Laurent Laslaz, Laurence Hanot, Pierre Maciejewski, Jérôme Barrand, Arnaud Pierrel, Jean-François Jagodinski... Tout le monde a donné de son temps, de son énergie et je crois qu’on peut être fier du résultat !
Le dépouillage des 220 feedbacks recueillis à la fin de la journée nous attend et un rapport de synthèse sera très bientôt disponible en ligne. De même que les présentations seront très bientôt en ligne ;-) Enfin, on se donne rendez-vous très prochainement pour faire la rétrospective grenobloise. Au fait, si un volontaire (extérieur aux organisateurs) est partant pour animer cette rétrospective, qu’il nous contacte !
Pour les plus curieux, voici mon album photo Agile Tour Grenoble 2009.
mardi 15 septembre 2009
Premier BarCamp à Grenoble

Qu'est-ce qu'un BarCamp ? Quand cela se passera-t-il ? Comment s'inscrire ?...
Toutes les réponses à vos questions sur la page web dédiée : http://barcamp.org/
mardi 8 septembre 2009
Agile Tour Grenoble 2009, c parti!

Les méthodes agiles visent à améliorer l'efficacité des entreprises et la satisfaction du client final. Ces méthodes proposent de nouvelles approches en termes de pratiques de développement logiciel, de gestion de projet (MOA/MOE), mais aussi sur les aspects organisationnel et de management dans l'entreprise. Sur un plan financier, les méthodes agiles permettent de réduire significativement le coût du changement et assurent au maître d'ouvrage de disposer d'un produit fonctionnel fiable, testé et utilisable en production tout en respectant le budget fixé initialement.
L'Agile Tour est un évènement à but non lucratif organisé dans 18 villes à travers le monde, il vise un public de décideurs, d'acheteurs, de managers et d'informaticiens qui souhaitent découvrir ou approfondir les méthodes agiles. Durant la journée vous seront proposées des sessions variées en simultané dans plusieurs espaces (retours d'expériences, exposés techniques, ateliers pratiques …) animées par des orateurs internationaux et locaux de renom:
- Henrik Kniberg, l’auteur du fameux “Scrum and XP from the trenches”;
- Marie-Pia Ignace, l’une des créatrices de l’Institut Lean France;
- Elisabeth Hendrickson, experte reconnue dans le domaine du test et de la qualité logicielle en mode Agile;
- Jérôme Barrand, professeur à Grenoble École de Management, fondateur de l'Institut d'Agilité des Organisations et auteur du livre "Le Manager agile" ...
Bénéficiez d’un tarif spécial en vous inscrivant dès maintenant pour l’évènement de Grenoble. S'inscrire !
vendredi 14 août 2009
XP-Days Paris 2009

Ce fut la seconde fois que j'assistais à l'évènement et cette fois en tant qu'orateur. J'étais assez fier d'arborer mon teeshirt rouge pompier Pyxis, qui d'après certains témoins, pouvait se voir à des kilomètres à la ronde. Bon, depuis Anne-Laure m'a ramené une taille S de son voyage au Québec et j'espère que l'effet sera un peu plus atténué. J'ai principalement animé l'atelier XtremMiles ou autrement dit "séance de codage XP autour du fameux jeu des mille bornes"! J'avoue avoir été déçu par la faible participation du public à cet atelier : je mets ça sur le compte peut-être d'un manque de communication de notre part sur le déroulement de l'atelier, mais aussi par l'envie du public d'aller vers des sujets moins techniques? Eh... n'oublions pas que coder c'est l'activité la plus importante dans nos métiers : sans code, pas de produit, pas de service ;-) Précisons aussi que cette année, nous avions décidé de démarrer l'atelier avec la base de code générée l'année dernière... oups... on peut alors comprendre que c'est dur de reprendre le code déjà écrit par un tiers... mais n'est-ce pas là notre lot quotidien de développeur? J'aime beaucoup la formule qui définit la qualité de code de cette façon : "un code de qualité c'est un code qui peut évoluer facilement dans les mains d'une autre personne"... eh oui, nous sommes nous-même toujours enclin à trouver que notre code est beau, mais ce n'est pas le plus important : est-il "vraiment beau" pour un autre? J'ai pris pas mal de plaisir en codant avec Arnaud Bailly, Vincent Tencé, Yves Crespin et d'autres dont je ne connaissait pas le nom.
Ma seconde intervention fut une courte démonstration de GreenPepper, un produit Pyxis qui gagne a être connu en vertu de ses fonctionnalités avant-guardistes et de sa capacité à s'adapter à des tonnes d'outils du monde JAVA, .NET et très bientôt Ruby. C'est surtout Vincent qui a mené la danse, le test agile c'est vraiment son dada, il assure! Les outils pour faire des spécifications exécutables, du BDD ou du TDR murissent petit à petit. Je suis intimement convaincu que nous n'en sommes qu'au début et que demain, la validation manuelle des spécifications fonctionnelles ne sera qu'un lointain souvenir ;-)
J'ai eu le plaisir d'assister à la session de Géry Derbier sur "Les 90 minutes d'une équipe remarquable". J'ai adoré sa prestation, son humilité et ses propos qui touchent juste : on ne mettra jamais assez l'accent sur la communication! Sans que Gery n'ait prononcé le mot de "Core Protocols", j'ai bien reconnu ces outils mise en œuvre durant la session. Cette session m'a donné envie d'animer une session de ce genre à Grenoble (ce que j'ai fait depuis). L'objet de cette session était de donner des outils pour briser la glace et ouvrir les canaux de communication au sein d'une équipe en pleine formation.
J'ai assisté à la session "Scrum est-il dangereux?" présentée par Eric Lefevre-Ardant et Guillaume Tardif. J'avais l'impression d'assister à un jeu de rôle où deux camps s'affrontaient à coup de phrase chocs : il y avaient les "pros" et les "contres" de Scrum : une palme d'or tout de même de la meilleure interprétation à certains "contres" qui se forçaient outrageusement à dire du mal de Scrum ;-) J'ai pu voir alors certains de mes collègues (formateurs Scrum) devenir vraiment rouges, souffler ou bien répondre à devant tant de mauvaise foi. Certains témoignages marquants sur de douloureuses implémentations de Scrum m'ont toutefois ému. L'intervention dont je me souviens le mieux c'est celle d'Emmanuel Gaillot en réponse à :
"On ne peut pas dire qu'un outil soit dangereux, cela dépend de son utilisation! Cela dépend de la main qui le tient..."
Emmanuel répond alors "Et quand il s'agit d'un revolver, tu dirais la même chose?" ;-)
J'ai donc passé un bon moment, et au final, je reste bien persuadé que Scrum est un superbe outil pour notre profession, une réelle opportunité de rendre meilleures nos organisations, en particulier sur le plan humain et social.
En dehors des sessions, j'ai manqué de temps pour « rézoter »mais j'ai tout de même discuté un moment avec Jacques Couvreur et François Bachmann, qui m'ont complètement impressionné avec leur entreprise personnelle du jeu Alchimiste Agile, jeu qu'ils veulent commercialiser, c ENORME.
A l'année prochaine, sans faute pour un Agile France 2010 encore plus fun!!!
mercredi 1 juillet 2009
Leçon apprise n°3 - Les intéractions et les individus

ont plus de valeur que
"les processus et les outils"
Cela signifie qu'il est plus important d'expliquer, de communiquer les valeurs, les principes, les comportements attendus, de favoriser la communication d'adulte à adulte, bref de gérer les humains que de veiller à la mise au point des processus et de la mise en œuvre des outils. Il s'agit là d'une petite révolution culturelle car bien souvent dans nos organisations, on s'attache à ce qu'il doit être fait, plutôt qu'a la façon dont les choses sont faites.
Les approches agiles sont des moteurs à apprendre non seulement quoi faire, mais aussi mieux faire la prochaine fois. Les comportements associés sont à la fois des aptitudes à communiquer, inventer et décider en équipe mais aussi la faculté individuel de se remettre en cause pour faire mieux, pour d'améliorer en continue. Faire mieux ne veut pas dire aller plus vite : c'est de la qualité des interactions de l'équipe dont nous parlons. Une mesure de cette qualité réside avant tout dans une écoute active des individus de cette équipe : accorde-t-on cette oreille attentive? Cette activité pourrait faire partie des attributions d'un Coach Agile, mais n'est pas aussi le rôle des managers de l'organisation de communiquer les valeurs et les comportements attendus des uns avec les autres?
mercredi 17 juin 2009
Lecon apprise n°2 - Adapter la structure

Deuxième billet sur mes leçons apprises lors d'une expérience de 4 ans d'application de Scrum/XP chez un éditeur de logiciel à Grenoble. Avant, je veux clarifier le terme "structure". Ce que je veux dire par "structure" c'est la cartographie de l'organisation en terme d'organigramme : la pyramide hiérarchique ou chaîne de commandement... on oppose souvent l'approche projet à cette structure pyramidale. En approche projet, on va travailler en mode transverse à de nombreux départements ou services.
Constat
En agile, les choses deviennent pire : on veut créer des équipes dédiées pluri-disciplinaires. De nouveaux rôles transverses apparaissent et on a du mal à les placer sur l'organigramme de l'organisation. A l'inverse des rôles existants se voient "dépouiller" de leurs activités du fait du changement de méthode. Dans notre cas, à l'époque, les chef de projets, responsables d'équipe et leaders techniques (architectes) ont eu beaucoup de difficultés à faire "leur trou" dans cette nouvelle façon de travailler. Le fait d'avoir conserver un grand moment une structure de l'entreprise inadaptée, cela a nuit au bon déroulement de la transition. Je n'ai jamais compris pourquoi cela semblait si compliqué de modifier la structure en place.
Pistes d'amélioration
- Ne pas attendre pour introduire (valoriser) les nouveaux rôles dans la structure de l'organisation
- Adapter ou supprimer la définition des rôles existants si ils sont obsolètes
- S'appuyer sur une description processus/responsabilité plutôt que structure/autorité
- Dans une approche processus, le rôle de ScrumMaster prend tout son sens : c'est le gardien ou le pilote du processus, à l'échelle d'un projet, d'une équipe
- Maintenir un backlog de transition agile pour y consigner justement les adaptations de structure à conduire
- Impliquer la RH le plus tôt possible dans la transition car le système de mesure de la performance individuel doit être adapté à cette nouvelle façon de travailler
jeudi 11 juin 2009
Leçon apprise n°1 - Transition en douceur

Leçon apprise n°1 - Transition en douceur
La transition vers l'agilité à laquelle j'avais assisté et dont j'étais aussi acteur, fut menée en mode "big-bang" : du jour au lendemain, tous les projets de l'entreprise furent gérés en Scrum. Le travail de préparation avait essentiellement porté sur des études de livres et la recherche de prestataires en formation et conseil agile. Nous avions organisé une grande réunion (ou plutôt une grande messe) pour expliquer les changements imminents et les raisons de ce changement. Je ne remets pas en cause ce que nous avions fait, mais je pense que nous manquions de maturité sur la gestion du changement à l'échelle de l'entreprise, et surtout sur les individus. Nous n'aimons pas changer quand quelqu'un décide à notre place, mais nous aimons changer si cette décision vient de nous... à méditer ;-)
J'aime l'image du lièvre et de la tortue : ne pas confondre vitesse et précipitation. Vouloir tout changer c'est bien mais savoir aider les autres à changer c'est mieux. La majorité des personnes veulent mieux faire, veulent s'améliorer et si elles vous paraissent hermétiques au changement, c'est que le problème ne vient pas forcément d'elles mais peut-être de de votre façon de leur parler et de les écouter.
Les bonnes pratique que je vois pour une transition en douceur sont les suivantes:
- Impliquer un maximum de personne dans la décision de changer (et pas seulement le management et la direction)
- Présenter ce changement "possible" à tout le monde (formation, ateliers...) avant de démarrer
- Commencer avec UN projet pilote avec LES personnes qui souhaitent changer
- Etre attentif aux arguments des personnes qui ne veulent pas changer et les entendre
- Gérér formellement un "backlog" de transition en toute transparence en y agrégeant les idées de tous
- Identifier une équipe en charge de ce "backlog"
lundi 11 mai 2009
Le lycée collaboratif existe, depuis 1982

Des élèves en difficulté scolaire peuvent y trouver leur compte et réussir ici (obtenir leur diplôme BAC) ce qu'ils échouent dans une structure traditionnelle. Des élèves témoignent qu'ils sont confrontés à des expériences inédites : travail en équipe, collaboration avec des adultes, tout cela leur donnent une grande confiance en eux. Ici, ils ont le droit de l'ouvrir, s'exprimer... ailleurs on leur disait seulement d'écouter et de travailler. Dans cet établissement, la sanction n'a plus lieu et l'autorité a été remplacé par la responsabilisation. Son taux d'obtention au BAC est le plus bas de France (50%) et s'explique par le fait qu'il y a dans cet établissement une plus grande proportion de jeunes en situation de difficultés scolaire.
Éducation, éducation... quelle sont tes critères de succès?
vendredi 17 avril 2009
Une question de confiance

jeudi 19 mars 2009
Vers une Administration Agile?

Hier matin, j'ai entendu le médiateur de la république française qui parlait de son rapport publié aujourd'hui, dans une émission de radio nationale sur le service public.
Voici un commentaire de ce rapport sur les Echos:
Déficits d'information, réponses aléatoires, sentiment d'arbitraire : dans son dernier rapport publié hier, le médiateur de la République, Jean-Paul Delevoye, ne ménage pas ses critiques vis-à-vis de l'administration. A l'heure de la RGPP (révision générale des politiques publiques) et de la modernisation des services publics, il semble que les effets positifs pour les usagers tardent à se concrétiser. Jean-Paul Delevoye a notamment insisté, hier, sur le manque d'attention porté aux réclamations des usagers : « Ce n'est pas une question de moyens, mais plutôt de culture. La gestion des réclamations est cruciale pour améliorer la qualité de service. Ce qu'ont très bien compris les entreprises privées, mais pas encore l'administration. »
D'après les propos que j'ai entendu, le médiateur de la république a reçu cette année 65 000 courriers des citoyens français. 65% concernent des demandes d'information, des réponses erronées ou contradictoires données par les administrations. Il s'interroge "Pourquoi de nos jours, à l'ère de l'information, c'est si difficile pour le citoyen de connaître ses droits?". D'après lui, plus que jamais, les citoyens ont besoin de réponses, ont droit à l'information!
La journaliste de l'émission lui demande
"Et les fonctionnaires? Peuvent-ils être plus performants?"
Sa réponse est à peu près la suivante:
"Les employés de l'état sont les autres victimes du système en place; les lois sont trop compliquées, il n'y a pas assez de délégation, de droit à l'erreur; on ne fait pas appel à l'intelligence et au bon sens des agents, mais plutôt à leur capacité à suivre des procédures trop lourdes; il y règne la culture de la faute, et non pas celle de l'erreur; le législateur doit simplifier les textes. Ce qui compte c'est la qualité du service, la satisfaction des utilisateurs, et cela passe par changer la culture en place."
Hum... voudrait-il faire du refactoring des lois existantes? Voudrait-il rendre le système moins hiérarchique? Laisser plus d'autonomie aux employés? Voudrait-il rendre "lean" notre administration? Houla... J'avoue que ce genre de discours, ça me fait du bien, même si ce n'est pas pour demain ;-)
mercredi 18 mars 2009
Esprit Agile à Marseille

Environ 25% du public avait déjà « pratiqué » de l'agilité. La présentation d'eXtreme Programming m'a fait me rappeler que XP n'est pas « juste » un ensemble de pratiques d'ingénierie, comme on le présente généralement, mais bien une méthodologie à part entière, avec de fortes similitudes - il est vrai - avec Srum. Thierry a bien insisté sur les aspects humanistes de l'Agile, ça m'a plu! Le terme « Développement responsable », ça m'a bien plu aussi. Le retour d'expérience, quand à lui, m'a un peu frustré, time boxing oblige, j'aurai voulu en savoir plus: Eric Barthelemy de la société ViaXoft nous a présenté très humblement les choses qui ont bien marché, mais surtout les «difficultés» rencontrées et les « adaptations » effectuées durant leur mise en place agile pour le développement de leur produit interne.
Parmi les questions posées dans l'auditoire, on a senti une certaine tension lorsque la question des « aspects financiers » fut lancée : c'est un peu déconcertant de devoir justifier des bienfaits financiers d'une démarche, lorsqu'on a passé près d'une heure à expliquer que la principale motivation de cette démarche était justement d'augmenter la valeur ajoutée du produit réalisé... mais cette défiance est légitime tant on est formatés à suivre une méthode sans trop s'interroger sur son efficacité.
J'ai retrouvé Jean-Marie Daumas avec plaisir, on a bien échangé.. Ce fut super de rencontrer enfin Claude et Thierry, en chair et en os, autrement que par blogs interposés! Je fis aussi la connaissance de Karine Mazet, correspondante du French Scrum User Group dans la région PACA et ScrumMaster chez ViaXoft. Surprise pour moi, il y avait des agilistes praticiens venus de Montpellier pour cette soirée! Comme quoi, beaucoup de régions étaient présentes ce soir-là!
Pour conclure, souhaitons que l'Esprit Agile se diffuse le plus possible. Pour cela, on a besoin de bras, beaucoup de bras, pour faire du vent, pour agiter les consciences ;-)
mardi 10 mars 2009
Approches Agiles dans les grandes entreprises

Voici le témoignage de François Beauregard sur Visual Studio Talk Show, président de Pyxis Technologies qui nous livre sa vision actuelle des choses après plusieurs années de pratiques.
Le podcast est ici. Bonne écoute!
mercredi 18 février 2009
Esprit Agile

Un nouveau feu s'allume près du Vieux Port, on le distingue à peine du haut de la Canebière, il annonce la naissance d'une nouvelle tribu. Bienvenue à "Esprit Agile"! Que votre esprit soit aussi pur et aussi puissant que le Mistral ;-) Une nouvelle communauté agile démarre à Marseille. Invitations lancées pour le 17 mars prochain. J'espère vous y rencontrer bientôt...
dimanche 8 février 2009
Amélioration continue : trouver l'erreur...

C'est quoi l'amélioration continue? C'est un terme qui revient souvent ici et là...
- l'amélioration continue est l'un des quatre domaines des exigences de la norme ISO 9001 (v2000), par là, elle entend des mesures et des enregistrements de la performance à tous les niveaux ainsi que l'engagements d'actions de progrès efficaces.
- le mot Kaizen en japonais désigne une philosophie de travail, qui signifie un changement constant, une amélioration continue à petits pas qui n'a pas de fin. Cette méthode est utilisée dans diverses méthodologies comme le Lean, le Kanban, le PDCA, etc..
- dans Scrum, le temps de la rétrospective est mis à profit pour améliorer les pratiques de l'équipe.
Notre environnement tolère-t-il les erreurs? Où bien vise-t-il à sanctionner les personnes, et à identifier les fautes? La culture de la "faute" est propice à un climat où chacun fuit ses responsabilités, chacun vise à assoir sa propre position en cachant le plus possible les éventuels dysfonctionnements. Fuyons ses environnements de travail pour des environnements où l'amélioration est récompensée! Alors, regardez autour de vous et... trouvez l'erreur...
lundi 2 février 2009
Le CARA à la soirée Agile Alliance

Le 15 janvier dernier, s'est tenue une soirée organisée par l'Agile Alliance à Vincennes. Le but de cette rencontre était de faire connaissance avec les différents groupes et associations qui soutiennent localement l'agilité. Il était donc important que le CARA y soit représenté! Nous partîmes en grand renfort (à cinq) depuis Grenoble vers la capitale...
Les membre du board de l'Agile Alliance étaient présents et disponibles. Les discussions (in english, sir) fuseaient dans toute la salle, tandis que des petits canapés et le champagne étaient servis. En parallèle aux discussions informelles, il nous a était demandé de travailler, de remplir de grandes feuilles blanche pour expliquer comment nous voulions que les organisations soient connectées les unes aux autres. Dans un second temps, sur la base des dessins faits aux murs, nous échangions tour à tour sur les façons d'aider chaque organisation locale dans sa mission. En plus d'un soutien financier, l'Agile Alliance pourra contribuer à nos évènements, notamment en y envoyant des orateurs clefs.
Au final, je dirais mission réussie et j'en veux pour preuve ce cliché rapporté par Eric Lefèvre sur son blog. Le CARA y est bien représenté! Notez aussi une mention spéciale pour nos Coding Dojos!
mercredi 21 janvier 2009
Le mythe de l'auto-organisation?

- c'est la personnes qui effectue une tâche, qui sera la plus à même d'estimer correctement le temps nécessaire à sa réalisation, d'anticiper les problèmes à venir ou de proposer des pistes d'amélioration.
- l'efficacité d'une personne se voit améliorer si elle fait preuvre de plus d'autonomie : il est plus motivant d'être l'acteur de ses propres décisions, plutôt que de "subir" la décision d'une tierce personne.
Mais bien souvent, on associe auto-organisation avec chaos; le sens commun nous incite à croire que si il y a pas de chef il n'y aura pas de décision. On nous dit que le consensus est une utopie (merci Thomas ;-) pour son billet). Heureusement, nous ne sommes pas obligés d'adhérer à ces croyances.
Sur un terrain de sport, les membres de l'équipe savent ce qu'ils doivent faire, ils ont été entrainés par un coach... l'intelligence de leur jeu est plus élevée que la simple somme des intelligences de chacun. Pouvons-nous en dire autant dans nos projets?
Mais quelles sont les conditions nécessaires à cette auto-organisation? 3 axes pour tenter de répondre à cette questions :
L'équipe est-elle réellement identifiée?
Les membres peuvent-ils compter les uns sur les autres à tout moment? Les membres de l'équipe sont-ils des ressources partagées ou des membres investis et impliqués? Scrum insite sur ce point grâce à la fameuse blague des cochons et des poulets. Clairement, une bonne pratique consiste à se focaliser sur le moins de choses possibles à faire à la fois. J'aime la remarque d'un collègue qui me disait un jour "A la maison, le matin, est-ce qu'on est efficace si on se brosse les dents en habillant le petit dernier, tout en préparant son biberon, alors que le téléphone sonne..."
Les membres d'une équipe partagent-ils un objectif commun?
C'est souvent le cas mais on constate trop souvent qu'il existe des enjeux personnels, des incompréhensions, bref, toutes sortes de freins à la cohésion de l'équipe sur l'objectif, la façon de l'atteindre ou simplement une décision le concernant. Il n'y a pas de solution miracle pour adresser ce point. Travailler la communication et le développement interpersonnel des acteurs du projet sont des pistes à considérer. Suivre des formations en communication c'est excellent, personnellement ça m'a ouvert les yeux sur pas mal de choses. Mais n'oublions pas le rôle du coach d'une équipe... j'ai bien dit coach, pas chef ;-) Son but est bien de faire grandir l'équipe, d'aider cette dernière à gagner en auto-organisation. Mais au delà de l'objectif commun de l'équipe, il y a les valeurs, les croyances et les motivations de chaquun des membre : sont-elles alors compatibles avec celles des autres membres? Sont-elle alignées?
L'équipe peut-elle décider?
Quel est la zone de contrôle de l'équipe? Quel est son pouvoir de décision? Quels sont les moyens mis à disposition de l'équipe? Dans Scrum ce n'est pas l'équipe qui décide du "quoi faire?", c'est plutôt le Product Owner. Néanmoins, c'est l'équipe qui est responsable du "comment faire?". Or, toute décision engage des moyens (réallocation de ressource, changement de méthode, etc...). Si une équipe n'a pas de tels moyens, peut-elle réellement décider?
Si l'une de ces conditions n'est pas remplie, peut-on encore espérer l'auto-organisation? J'avoue que ma vision du travail d'équipe est largement inspiré des Core Protocols. C'est que j'y trouve des principes simples, claires, pragmatiques et universels (enfin à quelques cultures près). Ca me parle le simple et le pragmatique! De votre coté, de décidez-vous pour laisser plus d'autonomie à vos équipes? Si vous êtes dans une équipe, êtes-vous aligné avec les objectifs de votre équipe?
dimanche 18 janvier 2009
Première formation CSM à Grenoble!

dimanche 11 janvier 2009
Groupe des Utilisateurs Français de Scrum
Je souhaite la bienvenue à cette toute nouvelle formation : le SUG-France (Scrum User Group en anglais dans le texte) dont la première rencontre se tiendra à Paris le 19 mars prochain en présence de Jeff Sutherland (l'un des pères fondateurs de Scrum). Le groupe herbergé sur meetup compte déjà plus d'une centaine d'inscrits! Les fondateurs du groupe envisagent de créer une association à but non lucratif, sorte de relais local en France de l'association internationale ScrumAlliance. Pour info, il existe de très nombreuses "antennes" de la ScrumAlliance à travers le monde.