Le But de l’itération

Tout d’abord un grand merci à Guillaume, Bruno, Emmanuel et Christophe pour leur traduction du livre de Henrik Kniberg : « Scrum and XP from the Trenches ».

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

Lire la suite »

Ca c’est du KANBAN

Pour ceux qui sont intéressés par le Lean et en particulier la mise en place d’un système KANBAN pour le développement logiciel, je vous recommande très fortement la lecture de cet excellent article de Clinton Keith (en anglais) sur la transition d’une méthode Scrum vers un système Kanban dans un contexte de développement de jeux vidéo.

L’article est plutôt long ou je dirais plutôt très complet, alors prenez votre temps

L’auteur explique de façon très pédagogique les apports de la méthode Scrum et ses limites dans le contexte du jeu vidéo. Il explique ensuite la manière dont l’équipe a mis en place puis surtout amélioré son système Kanban et révèle les gains de productivité associé (56%). Il détaille et argumente chaque changement en se référant aux 7 concepts du Lean Software Development.

Bref, pour moi qui suit un fana du Lean, c’était un pur moment de plaisir que de lire cet article, j’espère qu’il en sera de même pour vous, bonne lecture.

Scrum chez ATOS

Une des vocations du CARA (Club Agile Rhone Alpes) est de promouvoir l’agilité dans la région. Hier cela s’est traduit par une présentation chez ATOS ORIGIN sur le temps de pause du midi. La salle de réunion Innovallée était vraiment bondée avec plus de 60 personnes pour écouter Georges Allemand (membre du CARA) faire une présentation générale de l’agilité, puis moi-même présenter Scrum et Lean. Lire la suite »

Du bon usage de la vélocité

J’ai eu une discussion animée hier avec un ami qui cherche à convaincre une société de basculer dans une mode agile. Le point sur lequel nous avons loguement discuté était l’utilisation de la vélocité comme une mesure de performance de l’équipe et comme critère de maintient en poste ou pas d’une équipe de sous-traitants.

De mon point de vue, la vélocité est une mesure de capacité de production qui est lié à une équipe et une seule dans le contexte spécifique d’un projet. Au grand damme des managers classiques, il n’est malheureusement pas possible de comparer les vélocités entre équipes pour savoir si l’une est meilleure que l’autre et si un sous-traitant travaille mieux qu’un autre.

Lorsque la vélocité est calculée, et je recommande fortement de le faire, je l’utilise principalement de 3 façons différentes (liste non exhaustive bien entendu) : Lire la suite »

Scrum For 2 … 5 itérations plus tard

Il y a 5 semaines, j’avais évoqué mes incertitudes sur l’application de Scrum pour une équipe de 2 personnes et je suis maintenant en mesure de faire un premier retour.

Scrum est parfaitement adapté à une équipe de 2 personnes et voici comment nous avons pratiqué:

• Le Product Backlog est consitué uniquement de Post-IT sur un mur proche de mon bureau (de temps en temps je remets à jour le Wiki avec les éléments identifiés sur les Post-IT)
• L’itération dure 1 semaine. Démarrage et Fin tous les Vendredis après-midi.
• Le Daily Stand-Up est formel et nous nous réunissons tous les matins vers 9h pendant 10 mn environ devant le mur de Post-IT
• Les critères d’acceptation de chaque item sont clairement définis et affiché sur le mur.
• Les tâches ne sont pas pré-affectées et il nous est arrivé plusieurs fois de prendre une tâche qui semblait « mieux » adaptée à l’autre Lire la suite »

Agile à l’international

Une de mes activités professionnelles consiste à promouvoir la méthode Scrum comme alternative aux méthodes traditionnelles en France et dans plusieurs autres régions du monde (Europe, Asie, Inde, Canada). J’ai appris beaucoup des succès et difficultés rencontrés, et en particulier l’importance de la culture propre à chaque pays sur la façon d’aborder l’Agilité.

Ce petit article ne se veut pas être une liste de vérités absolues mais simplement ma perception de la situation dans les différents pays régulièrement visités. De plus, il est important de limiter mes propos au périmètre de mon entreprise (les personnes avec qui je travaille) et ne pas généraliser à l’ensemble du pays.

FR : Une bonne implication des équipes techniques, mais une forte résistance du management dû à la crainte d’une perte de pouvoir, une volonté de micro management et globalement la satisfaction des méthodes traditionnelles (on échoue mais on sait pourquoi, donc tout va bien et on ne change rien).

UK : Une démarche purement individuelle basée sur l’atteinte des objectifs définis par le top management qui empêche la mise en place d’un vrai sentiment d’équipe. Un certain manque de maturité sur l’importance de la qualité logiciel (et les bonnes pratiques associées) et la satisfaction réelle à être le héros que tout le monde admire. Lire la suite »

Avoir le réflexe Agile

Lors de la préparation de l’AT2008 (le 9 octobre à Grenoble), nous avons identifié une liste de tâches à faire avant le début de la manifestation (mise en place de tables pour l’accueil et le buffet, organisation des salles, affichage des posters …). Pour nous organiser au mieux, nous avons donc lister les tâches sur notre Wiki et de demander à des volontaires du CARA d’inscrire leur nom en face de chacune des tâches. Comme disent les anglais : « Cela fait du sens ».

Lors de notre dernière réunion de préparation, j’ai challengé cette approche car je ne la trouvais pas vraiment Agile. En effet, elle nécessite la présence d’un coordinateur (qui a dit un chef de projet ?) pour gérer les dépendances entre tâches et les impacts liés aux éventuels retards.

Nous avons donc décidé de nous organiser de la façon suivante :

• L’équipe organisatrice identifiera l’ensemble des tâches, le nombre de personnes nécessaires pour la mener à bien et les classera par priorité (Product Owner)
• Chacune des tâches sera écrite sur un Post-It qui sera affiché sur le mur de la salle de conférence (Scrum Master)
• Les volontaires se retrouveront devant le mur de Post-It, prendront le premier Post-It disponible, réaliseront l’action et reviendront chercher une nouvelle tâche etc … (Team)

De cette façon nous pouvons démarrer dès que suffisamment de volontaires sont disponibles pour réaliser la première tâche, pas besoin d’attendre que tout le monde soit là, si un volontaire arrive en retard il ne pénalise pas le projet, nul besoin de coordination (pas de ‘muda’) car l’équipe s’auto-organise, et si une tâche prend plus de temps que prévu ce n’est pas un problème en soi.

Il n’y a pas que les projets informatique qui se prêtent à l’Agilité et avoir le réflexe Agile permet souvent de trouver des solutions plus efficaces que celles auxquelles nous pensons en premier lieu.

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« 

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 !