Agile, Lean, Scrum et informations diverses
Hier, alors que je faisais une présentation de la méthode Scrum, nous avons eu une discussion plutôt intéressante sur la gestion des risques en méthode Scrum comparé aux méthodes de gestion de projet traditionnelle et voici ce qu’il en est ressorti.
Pour un produit donné, il existe 2 grandes classes de risques:
Continuer la lecture de « Gestion des Risques : Les risques Business »
S’il y a consensus pour ce qui est d’estimer les « User Story » en « Story Points » et non en jours ou heures (Cf. dernier article de Claude Aubry et les très bons livres de Mike Cohn), il semble que le chiffrage des tâches issues de la planification des User Story ouvre la porte à quelques discussions.
En résumé, et désolé pour cette simplification extrême, il y a 2 grandes façons de chiffrer les tâches:
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 :
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.
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. Continuer la lecture de « Scrum chez ATOS »
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) : Continuer la lecture de « Du bon usage de la vélocité »
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é:
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. Continuer la lecture de « Agile à l’international »
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 :
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.
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é.