Après les cycles en V, en cascade ou en escargot, voici venu la gestion en ballon ovale : scrum (ou mêlée de ce côté-ci de la Manche).
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 ?
- 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.
Le lien Wikipédia du jour :
Scrum
).
Deux heures après mon appli était « en prod » : hébergée par zoho, multi-utilisateur, je pouvais saisir mes contextes, projets, tâches, et avoir sur mon onglet d’accueil un calendrier auto des deadlines à venir et des tâches urgentes. 
