A moins que vous n’ayez envie comme un des trois petits cochons de construire votre maison en collant des spaghetti, l’intérêt est bien sûr ailleurs que dans l’assemblage lui-même. En comparant les performances de différentes équipes en fonction de leur composition et de leur façon de travailler, on apprend beaucoup de choses, y compris sur la conduite de projet agile…

Mais je ne veux pas trop en dévoiler, le mieux est de regarder l’excellente présentation ci-dessous (les sous-titres en français sont accessibles en cliquant dans le lien « View subtitles » juste sous la vidéo).

(suivez ce lien si votre lecteur de flux n’affiche pas la video : http://www.ted.com/talks/view/id/837)

Si l’expérience vous tente, vous trouverez toutes les instructions nécessaires pour organiser un tel défi sur http://www.marshmallowchallenge.com/.

Vidéo-Bonus : Ne mangez pas le marshmallow !

Enfin, pas tout de suite.

(suivez ce lien si votre lecteur de flux n’affiche pas la video : http://www.ted.com/talks/view/id/553)

La fillette qui sniffe son marshmallow est franchement géniale.

Et si vos collègues vous parlent de passer plutôt à l’eXtreme Programming, lisez ce billet (en anglais toujours) qui explique que ces deux méthodes agiles ne sont pas concurrentes mais complémentaires.

A la mi-temps : un poker

Une suggestion d’outil pour vous aider dans votre implémentation de Scrum : le planning poker, gentiment présenté en français sur le touilleur express.

Vu que je suis fana de webware (devrais-je dire webiciels ? toiliciels ? hmmm ) je vous propose d’utiliser un outil en ligne gratuit pour organiser vos parties de poker planning : http://www.planningpoker.com/

L’éditeur de ce site propose également des présentations autour de Scrum (devinez quoi : en anglais encore et toujours )

Bonne lecture…

Scrum (vu de super-loin)

Scrum est une méthode « agile », légère, adaptative, itérative – je suis à court d’adjectifs – plutôt pour les petites équipes et les projets de taille modérée.

Résumé des règles du jeu (vu de loin)

Une particularité de Scrum est une gestion très légère. Les quelques grandes lignes exposées ici constituent 80% de la méthode. L’art de scrum insiste sur la bonne conduite de réunions, qui vont rythmer le projet.

Le démarrage de sprint

Scrum est une méthode itérative, dans laquelle chaque itération, de longueur fixe et plutôt courte (30 jours par exemple), est appelée un sprint. Le but d’un sprint est de produire un ensemble de fonctions démontrables et livrables à la fin du sprint.

La réunion de démarrage de sprint permet de choisir parmi la liste des développements souhaités ceux qui seront réalisés lors du prochain sprint. Une fois ce choix effectué, on essaiera dans la mesure du possible de « protéger » l’équipe de réalisation des aléas de planning et avant-ventes, et on ne tiendra compte des changements de priorités que lors du démarrage du prochain sprint.

Le daily scrum (mêlée quotidienne)

Les développements prévus pour ce sprint sont découpés par l’équipe de réalisation en tâches, à la granularité de moins d’une journée, sans entrer dans le micro-détail de la demi-heure. Chaque jour, toute l’équipe se réunit pour une réunion de coordination très courte (par exemple 20 minutes maximum, montre en main) : la mêlée quotidienne. Chacun doit répondre à ces trois questions :

• Ce que j’ai réalisé depuis la dernière mêlée :!:
• Ce que je projette de faire jusqu’à la prochaine mêlée
• Les difficultés potentielles pour cette tâche, que la hiérarchie ou l’équipe doit essayer de lever

Fin de sprint et rétrospective

A la fin du sprint, l’équipe organise une séance de démonstration interne et surtout externe (hiérarchie, support, commerciaux, end-users…) des fonctions ajoutées ou modifiées lors du sprint. L’équipe procède ensuite, éventuellement à une auto-congratulation et un restau buffet-à-volonté, mais surtout à une rétrospective :

• Qu’est-ce qui a bien fonctionné lors de ce sprint ? 8)
• Qu’est-ce que l’on pourrait améliorer pour les prochains sprints ?

La méthode est un guide, pas un carcan : les équipes vont adapter la méthode et optimiser leur processus de sprint en sprint.

Glop

• prise en main rapide et ludique de la méthode par les gens impliqués
• insiste sur l’importance de la conduite de réunion
• prévoit des démonstrations et des livrables afin de limiter l’effet tunnel lors du sprint

Pas glop

• Difficile à mettre en place dans des environnements bureaucratiques
• Demande beaucoup d’autonomie de chaque membre de l’équipe…
• … et de l’équipe dans son ensemble
• Demande à ce que l’on laisse de l’autonomie à l’équipe

Verdict

Cette méthode n’est sûrement pas applicable à tous les environnements ni une bonne méthode pour gérer de la production intensive bien balisée.

Scrum est une très bonne méthode pour gérer des projets plutôt R&D, de prototypage par exemple, ou de développement XP de taille modérée. Elle permet à une équipe expérimentée de s’auto-organiser en souplesse. Les démonstrations de fin de sprint sont très importantes (des fois vitales ) particulièrement dans une optique de R&D mais souhaitables dans tout environnement.

Une richesse méconnue de scrum est la possibilité de gérer un projet très transverse, de créer une organisation de projet ad-hoc virtuelle. Prenons l’exemple de la mise en place d’un intranet, le scrum pourra permettre aux différents acteurs de coordonner leurs efforts, sans pour autant qu’il y ait de hiérarchie bien définie entre les acteurs du projet. Etant légère, la gestion scrum ne vient pas exagérément alourdir la gestion de projet existante de chacun. C’est dans cet optique qu’un prochain billet montrera comment on peut créer une infrastructure ad-hoc de projet scrum légère et efficace, en se basant sur l’offre d’applications en ligne google apps. Bref, Scrum en SaaS, c’est pour bientôt (et buzzword-compliant ).

Restez à l’écoute.