2 for Scrum and Scrum for 2 …

Régulièrement, des personnes viennent me voir pour me dire que compte tenu de la taille réduite de l’équipe (2 personnes), elles n’ont pas l’intention de mettre en place l’ensemble des cérémonies Scrum (les réunions comme les « Daily stand up » ou « Demo »)

Même si cela ne me plait pas vraiment,  en général je laisse filer car je n’ai pas vraiment d’arguments à leur opposer et je ne connais pas vraiment les risques qu’ils encourent à se comporter comme cela. Bien entendu, si la taille de l’équipe est de 3 ou plus, j’évoque les besoins de synchronisation, de prioritisation et de communication pour inciter ces personnes à mettre en place toutes les cérémonies Scrum. Mais s’ils ne sont que 2, je suis généralement moins convaincant car moins convaincu.

J’ai donc décidé d’expérimenter par moi même « Scrum for 2 » puisque je suis en charge d’un nouveau projet  où nous sommes 2 dans l’équipe (je rassure ceux qui me connaissent, il n’a rien de technique).

Je suis le Product Owner, Laurent est le Scrum Master et l’équipe de réalisation est constituée de Laurent et Moi 🙂

Nous allons appliquer la méthode « in the book » ce qui me permettra de mieux appréhender la plus value apportée par chaque cérémonie et avoir plus d’arguments à opposer à ceux qui veulent faire sans.

Bref, c’est une action à suivre …

Travailler moins pour produire plus

Depuis déjà longtemps je recommande aux managers qui veulent améliorer leur productivité de ne pas charger leurs équipes à 100% et de ne pas les obliger à travailler plus longtemps.

A première vue, c’est contradictoire. En effet, comment produire plus en planifiant moins de tâches à réaliser et en travaillant moins d’heures.

Mais en fait, ca marche. C’est mon retour d’expérience personnel pour l’avoir mis en pratique sur des projets dont j’étais le chef de projet (cycle en V).

J’ai trouvé une explication rationnelle de ce phénomène dans le Lean Software Development qui explique, entre autre, que la meilleure productivité est atteinte lorsque l’on fait 1 seule tâche à la fois (passer d’une tâche à une autre génère un gâchis de 45 minutes ==> 3 tâches par jour = 2 heures de productivité nulle = 30% du temps de travail non productif). Le principe du ‘Pull’ plutôt que le ‘Push’ contribue également fortement à ce résultat.

Scrum implémente ces principes par structure puisque les efforts de l’équipe sont focalisés sur un seul objectif à la fois qui est la tâche de plus haute priorité et que le ‘pull’ est de rigueur lors du sprint planning meeting.

Il est donc rassurant de voir des mesures qui viennent confirmer ce que je recommande depuis plusieurs années. Le graphique qui illustre cet article est basé sur des mesures réelles chez OpenView Venture Partners et montre clairement que les équipes Scrum atteignent leur maximum de productivité autour de 35 heures (rappelez moi la durée légale du travail en France ?) et que même en travaillant 60 heures par semaine, les équipes en Waterfall n’atteignent que 50% de cette productivité.

Hyperproductivité avec Scrum

Superbe post sur le blog de Jeff Sutherland (en anglais) avec la description précise de la méthode utilisée par Scott Downey chez MySpace, pour mettre en place Scrum dans ses équipes.

Scott (Agile Coach) propose une méthode en 7 points pour passer à Scrum

  1. Toutes les personnes de l’équipe doivent être formées par Scott à Scrum avant le premier sprint
  2. La durée de chaque sprint est d’une semaine (*)
  3. La définition du done est prédéfinie par Scott (User Story terminée + Code terminé + Pas de défauts connus + Approuvé par le Product Owner + Prêt pour mise en production)
  4. Toutes les estimations sont faites en « story points »
  5. Un « radiator » physique est utilisé et les tâches sont représentées par des Post-It
  6. Toutes les cérémonies (Démo, Rétro, Revue PB, Estimation, Engagement du Sprint) sont regroupées en 1 seule réunion de 4 heures par semaine maximum
  7. Le multi tâche est INTERDIT, le travail doit se faire dans l’ordre des priorités

Aucune dérogation n’est autorisée et l’équipe doit se plier à ces règles (qui sont donc parfois imposées) tant que l’équipe n’a pas prouvée sa maturité en remplissant les 3 critères suivants

  1. L’équipe est Hyper Productive (>240% des objectifs initiaux)
  2. L’équipe a réalisé avec succès 3 sprints consécutifs
  3. L’équipe a identifié une bonne raison business pour changer une des 7 règles précédentes

Je viens de finir la lecture complète … et je suis totalement bluffé !

(*) A un développeur qui dit « mais en 1 semaine, je n’ai le temps de rien faire« , Scott répond simplement « alors une simple règle mathématique me conduit à penser que tu produiras 4 rien en 4 semaines« 

Agilité et country

Qui a dit que je n’étais pas Agile !

Pour ceux qui ne sont pas convaincu, jetez un oeil sur le Blog de Bruno, et admirez mon groupe de danse country en pleine démo le week-end du 6-7 septembre (je suis celui avec le chapeau … c’est pourtant facile … bon, j’ai également une moustache!).

Sinon, pour ce qui est de la line danse, je n’ai pas encore trouvé qui est le product owner et il est vrai que la définition du done varie un peu suivant l’état de fatigue du danseur … mais quel bonheur de se faire plaisir sur cette musique !

Dans 15 jours c’est démo à la foire au chèvres de Champ sur Drac … interdiction de rire 🙂

Bravo ManU !

Je me joins à Claude (qui doit travailler la nuit à Toulouse car son post est daté de 00:06) pour féliciter ManU pour son excellent article sur les pratiques agiles de son équipe et surtout par ses illustrations grâce à de nombreuses photos réelles de leur espace de travail (je le sais, j’y étais il y a 2 jours).

Je recommande TRES FORTEMENT de prendre le temps de lire attentivement le document décrivant le retour d’expérience de ManU

Lean chez THALES

Suite à ma présentation du « Lean Software Development » dans le cadre d’une soirée des Anciens Elèves de l’Ensimag, Emmanuel Chenu et Nicolas Blanpain de Thales à Valence (Drôme) m’avaient demandé de faire la même présentation sur leur site, et nous avions convenu de la date du 9 septembre (hier).

A mon arrivée, je suis accueilli par Manu et Nico accompagné de la responsable de la communication qui m’apprend que des affiches ont été faites et que des relances ont été envoyés aux employés. Après un tour rapide des bureaux (en particulier le bel open space Agile dans lequel travaille l’équipe de Manu et Nico) nous nous dirigeons vers la salle de présentation.

La salle fait près de 120 places et elle sera entièrement remplie !

Honnêtement je ne m’attendais pas à avoir autant de personnes devant moi, mais ce n’est pas une première pour moi alors cela ne m’a pas stressé outre mesure. Après une introduction du responsable Lean chez Thales (oui, oui, ils ont lancé cette démarche en interne), j’ai fait environ 1h45 de présentation devant une assemblée constituée à 45% de personnes du Logiciel et 55% de personnes de l’électronique ou autre.

J’espère avoir été suffisamment bon pour créer de l’intérêt ou de la curiosité pour cette approche parmi les participants et que cela aidera Manu, Nico et quelques autres dans leur « croisade » pour implémenter les méthodes Agile au sein de leur société.

Un grand merci à Manu, Nico et toutes les personnes de Thales qui ont fait de cette présentation un succès.

Programme Agile Tour 2008

Eh bien non désolé, vous ne trouverez pas le programme de l’étape Grenobloise sur ce Blog aujourd’hui. Pourtant je peux vous garantir que nous y travaillons assidument et nous espérons être en mesure de le publier dans les prochains jours.

En fait c’est un exercice plutôt difficile car nous avions trop de sujets et nous avons du faire une sélection en éliminant des sujets potentiellement intéressants. Mais le méthode Agile nous a aidé, plusieurs itérations sur un grand mur blanc sur lequel les sujets étaient positionnées nous a permis de converger assez vite, enfin quand même 3 heures d’efforts. Nous sommes maintenant en cours de validation de la disponibilité des orateurs et de la durée proposée avant de communiquer officiellement.

Quelques indiscrétions, mais chut, ne dites pas que c’est moi qui vous l’ai dit :

  • Un « keynote speaker » Grenoblois
  • Une 12aine de sessions planifiées

Bref, une belle conférence en perspective

Priorités !

Lors d’une de mes premières expériences professionnelles la Direction Qualité de la société diffusait des posters pour illustrer des bonnes pratiques logicielles. L’un de ces posters représentait un croisement à 4 routes avec une ambulance, un camion de pompier, une estafette de gendarmerie et une voiture de police qui arrivaient en même temps au carrefour, gyrophare et sirène à fond. La légende de ce poster était « Lorsque tout est prioritaire, il n’y a plus de priorité »

Cette entreprise n’était certainement pas Agile, mais voulait diffuser une bonne pratique qui consiste à définir ses priorités à l’avance et pas lorsque la question se pose.

Les méthodes Agile intègre cette pratique, souvent structurellement. Par l’intermédiaire du « Product Backlog », Scrum oblige à prendre des décisions sur ce qu’il faudra réaliser en premier et les visualiser dans un document unique. Ces décisions sont parfois difficiles à prendre mais sont nécessaires pour gagner en productivité ensuite.

J’entends parfois « C’était pourtant évident que c’était très important » pour fustiger une équipe technique qui a manqué un échéance. Mais que veut dire « très important » relativement aux autres tâches qui étaient également importantes … nul ne le sait. Nous étions dans le cas d’un véhicule prioritaire qui arrive au carrefour où 3 autres véhicules prioritaires sont déjà présents et dans ce cas, pensez-vous que la meilleure méthode est de faire descendre chaque chauffeur sur la route pour discuter avec les 3 autres et négocier de passer en premier car son action à lui est « très importante » ?

Pour que l’équipe soit efficace, les priorités du produit doivent se décider en amont de l’équipe de réalisation, pensez-y !

Scrum – Premier echec

Cela devait bien arriver et c’est malheureusement arrivé !

Il y a 4 mois, J’ai coaché un projet en interne (durant 3 sprints de 2 semaines) pour aider les équipes à gagner en maturité sur la méthode Scrum que l’équipe utilisait depuis 3 mois. Je considère que ce coaching a porté ses fruits puisque l’équipe a pris conscience de certains de ses dysfonctionnements et a cherché à y remédier par elle même avec mon support. Le motivation de l’équipe était alors très bonne et la productivité supérieure à ce qu’elle avait été (bien que nous ne disposions pas de métriques fiables – comme une mesure régulière de la vélocité)

Aujourd’hui, force est de constater que ce projet s’éloigne de la méthode Scrum. Ce n’est pas encore visible sur la forme car l’équipe parle encore de Sprint, de « Scrum of Scrum » et fait des rétrospectives, mais sur le fond tout est changé et je vais me permettre de donner ma vision personnelle des raisons qui ont conduit à cela.

  1. Le management n’a pas eu suffisamment confiance dans la réussite de l’équipe auto-pilotée et a (re)commencé à faire du micro management pour se rassurer car lui aussi subit une très forte pression de la part de son management pour délivrer à temps
  2. Le conflit de priorité entre Produit (nouvelles fonctionnalités) et Engineering (Stabilité) n’a pas été résolu. La méthode Scrum oblige à prendre une décision, à la rendre visible dans le backlog et permet de focaliser les énergies sur 1 objectif commun. Plutôt que de prendre des décisions difficiles et lourdes de conséquences, les 2 entités ont préféré masquer le problème en changeant leur façon d’utiliser le Product Backlog et disant « on va faire un peu des 2 ». Le problème est toujours présent … mais comme on le voit moins, certaines personnes pensent qu’il est résolu (qui a dit que les managers croyaient en la Magie ?).
  3. Le micro management s’est traduit par un contrôle journalier de l’équipe sur la réalisation de tâches unitaires suivant un processus par étapes remis à l’ordre du jour (abandon du concept de sprint et surtout de ‘done’ en fin de sprint).
  4. Contrairement à la volonté de l’équipe, les ressources sont affectés à des tâches précises et chacun est responsable de sa partie. Fini l’engagement de l’équipe à délivrer itérativement quelque chose qui marche, voilà le retour de la justification individuelle !
  5. La plus grande partie du reporting actuel consiste à expliquer pourquoi l’avancement du projet n’est pas conforme à la roadmap définie initialement par … quelqu’un … sans implication de l’équipe. La seule question posée actuellement est « pour quand ce sera prêt ? » plutôt que « comment je peux t’aider à résoudre tes problèmes ? ».

Attention, mon propos n’est pas de dire que la méthode utilisée (Waterfall couplée à du micro-management) est mauvaise car je suis convaincu que l’équipe va délivrer les fonctionnalités demandées (j’ai moi-même utilisée cette méthode avec succès dans le passé). Mais comme pour la plupart des projets dans ce mode, ce sera avec du retard et avec un niveau de qualité non optimal (et cela devient déjà visible sur ce projet).

Mais je suis également convaincu qu’une approche Agile avec Scrum aurait permis de délivrer plus vite un produit de meilleure qualité. Car une équipe motivée, travaillant par petits incréments avec des objectifs clairs et partagés, est la plus grande chance de réussite d’un projet. Donc plutôt que de se concentrer sur le ‘pourquoi ca n’a pas marché’ il est plus important de se focaliser sur le ‘que reste-t-il à faire pour finir’.

Comme axe d’amélioration personnel, j’en retire qu’un coaching au niveau de hiérarchie supérieure aurait peut-être permis d’utiliser Scrum suffisamment longtemps pour prouver son efficacité et convaincre cette hiérarchie.

On apprend beaucoup de ses erreurs et puis il n’est pas dit que ce projet ne puisse pas revenir à l’agilité d’ici quelques mois, restons optimistes !