Pour couper court à la polémique Scrum vs XP, je vous invite à lire l’excellent post de Denis (XP sans Scrum, Scrum sans XP) auquel je souhaite ajouter quelques mots.La méthode Scrum fonctionne également dans un contexte non logiciel ce qui est plus délicat pour la méthode XP. En effet, il est très efficace d’utiliser la méthode Scrum pour générer de la documentation ou pour gérer un projet personnel. La méthode XP est indissociable des pratiques d’ingénierie logicielle XP et dans les 2 contextes évoqués, plusieurs pratiques XP ne sont pas applicables, et au niveau de la méthode XP,  l’étape de « refactoring » n’est pas toujours réalisable en dehors d’un contexte logiciel.

La faiblesse et la force de Scrum vient de la définition du DONE (ou Terminé) qui est un aspect fondamental de la méthode (sans DONE pas de succès possible) mais dont la méthode ne précise pas la façon d’obtention.

La force vient de la liberté offerte à l’équipe pour obtenir le DONE et  permet d’appliquer Scrum dans de nombreux contextes hors du logiciel, puisque seul le DONE est vérifié.

La faiblesse vient du manque de pratiques pour obtenir le DONE dans un contexte logiciel. Il me semble donc naturel d’emprunter certaines pratiques proposées par XP car ce sont bien les plus efficaces (TDD, Pair Programming, Intégration Continue …).

Donc pas de guerre, mais simplement une façon intelligente d’utiliser les aspects les plus performants de chaque approche.

Alors, pourquoi ne pas passer au RX (Recrutement eXtrème) comme décrit dans cet intéressant article paru sur CIO : Hiring Software Developer: The Agile Aptitude Test.

Cet article, même s’il concerne uniquement le recrutement d’un groupe de développeurs (il faut qu’il y ait plusieurs postes ouverts pour que la méthode RX fonctionne), est très intéressant sur les points suivants:

• Il faut recruter sur la base du talent ou potentiel de chaque individu et non de ses compétences techniques (car l’entreprise doit mettre en place des moyens d’acquérir les compétences manquantes)
• Si vos développeurs travaillent en binôme, il faut estimer leurs aptitudes à fonctionner en paire. Donc quoi de mieux que de les appairer dès le recrutement et voir comment chacun d’eux contribue à la réussite de la paire afin d’éviter de recruter des individualistes.
• L’environnement de recrutement doit représenter l’environnement de l’entreprise. Donc si vos équipes travaillent en open space, et discute des points techniques dans des espaces ou il y a des sofas et des tables basses, il faut que l’environnement de recrutement soit similaire, et bannissez les bureaux fermés où seules 2 personnes peuvent s’asseoir.

J’ai eu l’occasion de recruter de nombreux ingénieurs logiciels depuis 10 ans (que ce soit pour une SSII ou pour un grand compte) et j’ai toujours pratiqué une approche traditionnelle avec un entretien en tête à tête avec le candidat, puis débriefing avec les autres personnes qui avaient pratiqué le même type d’interviews. Si l’on met un peu de Lean dans cette approche, on s’apercoit très rapidement des nombreux gaspillages générés, en particulier le temps passé avec les candidats non retenus. L’approche RX m’intéresse fortement, lorsque le contexte s’y prête bien sur, et j’espère avoir un jour l’occasion de l’essayer

Même si je pratique l’anglais régulièrement la lecture d’un livre en Français est plus reposant qu’en anglais.

L’auteur parle plusieurs fois dans son livre de définir un « but » à l’itération comme un moyen pour :

• Garder l’équipe focalisée sur ce qui doit vraiment être délivré
• Communiquer simplement à l’extérieur de l’équipe sur ce qui va être réalisé durant l’itération

Je n’ai jamais essayé cette technique et je fais confiance à Henrik lorsqu’il dit qu’elle marche pour lui, mais je me demande s’il est vraiment réaliste de définir un but dès le début du planning de sprint. Cela ressemble à du PUSH et non du PULL – c’est à dire que l’on décide à priori ce qu’il faut faire sans se préoccuper de la capacité de production de l’équipe.

Par contre je ne remets pas en cause l’utilité de définir un but à l’itération comme outil de communication externe et de focus de l’équipe, mais il me semble plus agile de définir le but une fois le planning de sprint réalisé et l’estimation des tâches connues.

La différence vient surement du fait que chez Henrik, l’équipe utilise principalement le calcul des « user points » (qui me semble être parfaitement maîtrisé) comme un outil de définition du contenu de l’itération alors qu’ici nous découpons les stories en tâches estimée en heure et nous nous arrêtons lorsque le temps disponible de l’équipe est trop faible pour prendre une story supplémentaire. Cela permet donc à Henrik de définir un but « à priori » ce que nous sommes ici incapable de faire car nous n’avons pas encore mis suffisamment de focus sur ces aspects … toujours et encore quelque chose à améliorer.

Bref la lecture de ce livre m’a fait réfléchir et progresser … encore merci aux traducteurs