Si vous cherchez de l’inspiration pour convaincre votre hiĂ©rarchie de passer Ă  l’approche Scrum de la gestion de projet, une prĂ©sentation “Explaining Scrum to your Management Team” est disponible sur Agile Alliance. La prĂ©sentation est assez synthĂ©tique et efficace , mais en anglais seulement .

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…

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.