« Auto-organisation » ne signifie pas « faire tout ce que l’on veut »

Auto-organisationDernièrement j’ai été confronté à plusieurs discussions sur le principe d’auto-organisation de l’équipe qui m’ont fait réfléchir à ce que cette notion véhiculait.

Je profite de cet article pour vous donner mon avis sur les 3 points suivants :

  • L’auto-organisation vue par l’équipe comme étant synonyme de liberté totale
  • L’auto-organisation structurée suivant un certain processus
  • L’auto-organisation comme technique de protection

Tout d’abord un petit rappel sur la notion d’auto-organisation des équipes Agiles. Continuer la lecture de « « Auto-organisation » ne signifie pas « faire tout ce que l’on veut » »

Le futur de l’agilité

Agilité souplesseLa semaine passée j’ai participé à la très belle conférence SoftShake de Genève qui mélange de nombreux genres sur 2 jours.

Le matin du 2ème jour, mon ami et organisateur @jacquescouvreur a proposé à des représentants des tracks Java, Agile, Mobile, Microsoft, Programmation Fonctionnelle et Web, de parler chacun pendant 4 minutes (chrono en main) sur le sujet suivant : A quoi ressemblera mon domaine (track) dans 2 ans ? Dans 5 ans ? Dans l’absolu, et aussi sa place dans le développement logiciel global

Cette petite surprise était vraiment particulièrement adaptée à l’état d’esprit de cette conférence.

J’avoue avoir beaucoup réfléchi à la façon d’aborder cette question, et j’ai finalement opté pour l’angle « L’agilité, c’est donner du sens »

Si vous avez 3 minutes, je vous invite à écouter cette présentation que je remercie, énormément et sincèrement, Christophe Pache (@chpache) d’avoir enregistré (vous retrouverez la photo dont je parle en début de présentation en entête de cet article)

Exercices agiles ou l’apprentissage efficace

Depuis longtemps je suis convaincu que la pratique est la meilleure façon d’apprendre, et c’est pour cette raison que je facilite les exercices agiles (ou jeux agiles) dans le cadre de mes formations et de mon coaching (j’ai d’ailleurs créé le jeu du Casino Game que je mettrais à disposition de la communauté très prochainement).

La semaine dernière nous avons donné avec Fred un cours en Master Miage I à l’université décomposé en 3h de Travaux Dirigés (session obligatoire) et 3h de cours magistral (session facultative). Sur la base des feedbacks des étudiants de l’année dernière, nous avons cette fois ci commencé par le TD qui comprenait 2 jeux : « Artistes et Spécifieurs » et « XP Game », puis le lendemain nous avons fait le cours théorique. Continuer la lecture de « Exercices agiles ou l’apprentissage efficace »

Agile Toulouse 2010

AgileToulouseJeudi dernier, j’ai assisté à une très belle édition de la conférence Agile de Toulouse dans les locaux de l’IUT de Blagnac.

Claude m’avait hébergé et nous avons du nous lever tôt pour arriver avant tout le monde et donner la dernière main à la préparation.

Après une ouverture de la conférence par Thierry Cros et les mots de sponsors, j’étais tout de suite dans le bain pour présenter une expérience réussie de Product Owner sur un mode un peu décalé puisque j’ai utilisé les fables de Jean De La Fontaine pour illustrer mes propos (session que je referais à Grenoble le mois prochain). La salle était plutôt bien remplie et les questions nombreuses en fin de session … avec même quelques questions sur la contractualisation agile et les échecs en mode agile.

Continuer la lecture de « Agile Toulouse 2010 »

Des outils agiles

Outils Agiles

Ceux qui me connaissent savent bien que je ne suis pas un fervent partisan des outils agiles … enfin surtout pas en première approche.

J’aime bien que les équipes que je coache réalisent par elle même, avec le temps, quel pourrait être l’avantage d’utiliser tel ou tel outil. Donc dans un premier temps, et surtout en cas de premier projet pilote,  je préconise l’utilisation d’outils simples (post It et tableau pour les itérations, tableur pour le reste).

Lorsque l’équipe est devenu plus mature sur l’agilité, elle sait ce qu’elle cherche à obtenir et la transition vers un outil se fait sans risque de perdre les acquis de l’agilité. Ce peut être des outils complets comme IceScrum de mon ami Claude ou the-scrum de Nicolas, ou du lourd comme VersionOne ou Rally, ou alors des outils bien spécifiques comme Cucumber lorsque l’équipe décide de passer au BDD (Behaviour Driven Developement).

Quoiqu’il en soit, si les outils vous intéressent, je vous invite à lire le résultat de cette étude sur l’utilisation des outils agiles : http://blog.klover.se/2010/08/12/agile-tool-survey-results/

C’est la rentrée

rentree des classes

Et nous voilà reparti pour une nouvelle année avec plein de nouveautés 🙂

si, pour de nombreuses personnes qui comme moi ont des enfants scolarisés, l’année démarre en Septembre 🙂
.
.
.
.

  • Des changements chez Agiletoyou avec des forces vives supplémentaires … Yeah !
  • Des nouveaux challenges comme la mise en place d’une contractualisation agile pour les marchés publics … Pas facile !
  • Plusieurs conférences en Septembre où je suis orateur … Chouette !
  • La finalisation de la conférence AGILE GRENOBLE 2010 le 23 novembre à Grenoble sponsorisée par l’Agile Alliance, la METRO et de nombreuses sociétés de la région … Encore un effort !

Je vous donnerais plus de détail au fil du temps sur ces évènements mais je vous souhaite à tous une bonne reprise et beaucoup d’agilité pour la période à venir.

Un prix pour l’agilité

FT 01Un projet logiciel réalisé en mode agile depuis 9 mois, dont je coach la MOA et la MOE, a reçu le prix Agile en Avril 2010 dans le cadre des ITN Awards 2009 (sélection au niveau corporate des projets les plus représentatifs réalisés en 2009).

Les points clés de ce succès sont :

  • L’utilité du nouveau produit et l’innovation technologique
  • La tenue des jalons très courts et un coût final inférieur au budget initial
  • Le fonctionnement en « équipe » avec une implication très forte des utilisateurs finaux.

Le choix d’une réalisation en mode agile a donc fortement contribué à ce succès car elle a permis :

  • D’établir une réelle collaboration entre MOA et MOE
  • D’obtenir une implication active des utilisateurs (toutes les 2 semaines pour donner du feedback sur l’incrément de produit réalisé)
  • De faire émerger une équipe de réalisation performante et fortement proactive
  • De piloter via une métrique simple et fiable : La vélocité !

C’est vrai que je ne cours pas après les prix, mais quand même, cela fait vraiment plaisir quand cela arrive, alors autant le célébrer un peu 🙂

Sessions retenues pour Agile France à Paris

speaker-2010Après être venu en touriste l’année dernière à cette superbe manifestation, j’ai décidé en 2010 de proposer quelques sujets et 2 d’entre eux ont été retenus :

  • Une présentation+atelier sur les métriques pilotées par le comportement (Behaviour Driven Metrics) que j’animerais avec Manu
  • Les bonnes pratiques du Product Owner mise en œuvre sur un projet qui a très bien réussi

Ce sont des créations faites spécifiquement pour cet évènement, souhaitez moi bonne chance 🙂

Voir ci-dessous pour plus de détails

Continuer la lecture de « Sessions retenues pour Agile France à Paris »

Agilité pour MOA

AgileImprovementsDernièrement un client m’a demandé un court argumentaire pour inciter une MOA (le représentant du client) à se renseigner sur l’agilité. La problématique était présentée de la façon suivante : « La MOA veut savoir ce qu’est l’agilité avant de consentir à se la faire présenter !  » et il fallait donc proposer quelque chose de court, concis et percutant.

Après quelques jours de réflexion, j’ai proposé le questionnaire suivant :

  • Votre besoin fonctionnel est-il parfois incomplet au T0 du projet ?
  • Identifiez-vous de nouveaux besoins en cours de réalisation ?
  • Attendez-vous longtemps pour voir une première version ?
  • Avez-vous des difficultés à vous faire comprendre de la MOE ?
  • Voyez-vous vos planning dériver avec le temps ?
  • Vous demandez-vous parfois ce que fait la MOE ?
  • Découvrez-vous beaucoup de bugs en fin de cycle ?
  • Souhaitez-vous augmenter votre productivité ?

Si vous avez répondu OUI à l’une de ces questions, alors les méthodes Agiles peuvent vous aider à mieux faire car

  • La possibilité de changer le besoin fonctionnel est intégré structurellement dans la méthode
  • Une version démontrable est livrée régulièrement (tous les 2 ou 3 semaines)
  • Les échanges entre MOA et MOE sont permanents et riches d’enseignements
  • La prédictibilité de la MOE est basée sur le travail réellement terminé et non sur une estimation de la progression
  • La visibilité est totale et permanente sur toutes les activités
  • Les tests sont faits en continu pour éviter les effets « Big Bang » de fin de cycle
  • Les gains de temps sur l’ensemble du cycle (de l’expression de besoin au déploiement) sont très significatifs

Avec quelques recommandations pour passer à l’Agilité

  • Se former, car même si la méthode semble simple, c’est plus complexe qu’il n’y parait
  • Se faire accompagner, car c’est plus difficile qu’il n’y paraît et les bénéfices seront obtenus plus rapidement
  • Démarrer au plus tôt en mode Agile, c’est-à-dire dès la collecte des besoins, car tous les acteurs sont concernés et pas seulement la MOE
  • Accepter et mettre en œuvre les changements induits par la méthode (réunions en présentiel, disponibilité en continu …)
  • Comprendre que l’agilité est avant tout un état d’esprit et non juste une « autre méthode »

Qu’en pensez-vous ?

[Humour] Chuck Norris est Agile

402px-Chuck_norris_toilet_paperTraduit de l’anglais (préalablement de l’allemand) sur un pointeur donné par LaurentG, petit délire autour de l’agilité qui m’a fait rire 🙂

  • Chuck Norris est Scrum Master et Product Owner en même temps
  • Chuck Norris peut faire des sprints de 6 mois
  • Chuck Norris porte des TimeBoxer short
  • Chuck Norris ne déplace pas les postIt sur le tableau, il bouge le tableau
  • Chuck Norris n’estime pas, il sait
  • Chuck Norris s’appaire tout seul
  • Chuck Norris est autoriser à arriver en retard au Stand Up
  • Chuck Norris s’assoie lors du Stand Up
  • Chuck Norris a tout terminé à la fin du Sprint Planning Meeting
  • Chuck Norris n’estime pas les User Story, mais les User Story le respecte
  • Chuck Norris écrit d’abord le code et jamais les tests
  • Chuck Norris ne craint pas les bugs, mais les bugs le craignent
  • Chuck Norris ne connait pas le Kanban, il n’a pas de limite
  • Chuck Norris ne tire pas, il pousse
  • Quand Chuck Norris dit « c’est terminé », alors c’est vraiment terminé
  • Chuck Norris ne déploie pas, il développe directement sur les machines de production
  • Chuck Norris sait que pour établir un burn-down, il faut du Napalm
  • Chuck Norris n’a pas de burn-down, tout est brulé autour de lui
  • Chuck Norris ne répond qu’à 2 questions lors du Stand Up … il ne connait jamais de problème
  • Chuck Norris n’a pas besoin de prioriser le Product Backlog
  • Chuck Norris réalise plusieurs User Story en parallèle
  • Chuck Norris n’utilise pas le Développement Piloté par les Tests. Chuck Norris pilote lui même
  • Chuck Norris est le Product Backlog
  • Chuck Norris est Scrum Master certifié sans avoir le certificat
  • Chuck Norris n’a pas besoin d’Acceptance Test. Chuck Norris accepte ou pas !
  • Chuck Norris n’a pas besoin de rétrospective. Le process Chuck Norris est parfait
  • Chuck Norris écrit des tests qui passent avant d’avoir écrit le code
  • Chuck Norris gagne toujours au Poker Planning

Et je rajouterais

  • Chuck Norris n’a pas de plan de release. Chuck Norris sait ce qui est à faire
  • Chuck Norris a une vélocité de 50 000 points
  • Chuck Norris termine le Product Backlog à chaque itération

D’autres idées ?