Sources Scrum

On me demande souvent mes sources Scrum, s'il n'y a qu'un livre à lire, lequel? par où commencer? Scrum pour les nuls, ça existe? c'est quoi, un bon scrum master? etc ... j'avais écrit une page à cet effet, mais j'ai l'impression que rares sont mes lecteurs qui s'aventurent sur la rubrique Articles. Alors voilà, je redonne toutes mes sources.

Bien sûr, le manifeste Agile, c'est la première étape. Le lire, le comprendre, l'imprimer sur du papier A3, l'afficher au mur, en discuter avec son équipe, avec d'autres collègues, avec ses managers les plus proches, puis un jour, se décider, quand on a atteint la maturité nécessaire, le signer. La signature du manifeste Agile est un sacré engagement, et cela vous change votre vie professionnelle de développeur. Plus rien n'est comme avant. La vision devient différente.

Puis le livre Agile Project Management with Scrum, de Ken Schwaber. Le lire. Le comprendre. Ce sont les bases de la méthode, d'un côté, mais aussi, de nombreuses histoires de projets de développement, sur les quels Ken est intervenu. A la fin de la lecture, on sait ce que c'est que la méthode Scrum. On sait aussi comment l'implémenter. On croit savoir. Mais cela ne suffit pas. C'est là tout le truc de Scrum. C'est très facile. Les concepts sont très simples. Les trois rôles : le responsable produit ou Product Owner, le Scrum Master, et l'équipe. La notion de Sprint : période de temps limité (15 jours, un mois, par exemple, mais pas plus) pendant laquelle l'équipe met tout en oeuvre pour développer les user stories sur lesquelles elle s'est engagée de manière collective. Les différentes réunions qui rythment les projets Scrum : les Scrums ou points quotidiens où chaque membre de l'équipe expose aux autres ce qu'il a fait la veille, ce qu'il fera aujourd'hui, et les éventuels obstacles qu'il a rencontré, charge au Scrum master de les régler. Les Sprint Reviews, lors desquels l'équipe exposent aux commanditaires, et toutes autres personnes de l'entreprise, d'ailleurs, les développements terminés lors du Sprint. Les Sprint Planning, pendant lesquels le responsable produit expose à l'équipe les user stories priorisées en attente. L'équipe estime et s'engage sur un certain nombre de user stories. Mais la vrai compréhension intervient petit à petit, dans la pratique de tous les jours.

Ensuite, c'est le livre Agile Estimating and Planning, de Mike Cohn. Le lire. Je conseille d'ailleurs de lire en même temps le livre de Ken et celui de Mike. Cet ouvrage de Mike Cohn se lit comme un roman. On apprend comment écrire une user story. Comment estimer de manière retlative une user story en user story point avec un planning poker. On comprend les différentes "peaux d'oignon" de la planification : la planification sur l'horizon de la journée lors du scrum quotidien, la planification sur l'horizon du sprint, puis les releases, puis la roadmap produit, et enfin la planification à horizon stratégique.

Une fois tout ceci dans la tête, il est indispensable de s'abonner au groupe de discussions du développement Scrum sur Yahoo, une mine d'or. Mike et Ken y participent régulièrement. Certain fil de discussion sont passionnant. AU début, l'oeil du débutant y fait un tri naturel. On ne comprend pas tout. Puis, petit à petit, à force d'avancée dans les projets, on s'aperçoit que d'autres, à travaers le monde, rencontrent les mêmes interrogation que soi-même, posent des questions que l'on se pose aussi, ou exposent comment eux, dans leur cas, ont résolu un problème de cette manière-là. Une source d'inspiration inépuisable.

Puis installer un framework de gestion de projet Scrum. Comme nous sommes en .net et que nous utilisons Team Foudation Server, j'avais deux options possibles : eScrum et Scrum for Team System de Cochango. J'ai choisi ce dernier, qui s'installe en 1 clic! Il faut en lire le Process Guidance, une ressource excellente de Scrum, avec quelques vidéos de Ken Schwaber.

Sans oublier THE French Blog about Scrum tenu par Claude Aubry, consultant de son état (le Jeff Sutherland français?), qui a mis à disposition une remarquable documentation de la méthode au format EPF.

Après la lecture de toutes ces ressources, il faut plonger. Evangéliser son équipe. Evangéliser son boss. Evangéliser le boss de son boss. Evangéliser le boss du boss de son boss, par l'intermédiaire de son boss... Evangéliser ses partenaires transverses à l'intérieur de la structure. Expliquer, avec agilité. En effet, il faut savoir être agile dans son discours, quand on prône l'agilité!

Lire. Evangéliser. Puis pratiquer. C'est là où l'on s'aperçoit que l'on est loin d'avoir tout compris. Chaque jour se poser la question du pourquoi de ses erreurs. S'améliorer. Feedback permanent avec l'équipe.

Comments

[Rédigé par: Fefal]

Merci pour tous ses sources...Je me suis empréssé d'acheter "Agile Estimating and Planning" qui va me permettre d'améliorer la visibilité sur le projet en cours...ou pour le prochain.
Actuellement, je remarque bcp d'erreur sur le projet pour lequel je travail:
- une estimation qui n'a pas bougé depuis le debut du projet
- une prioritization des "features" jamais réalisées
- Pas d'itération (juste en fin de projet)
- Une équipe de 4 sans coordination
- un Scrum-meeting qui dure plus 30-45 min, sur divers problémes...
- un projet de 250 jrs qui va certainement couter le double...

[Rédigé par: Claude Aubry]

Très bonnes sources ! Et merci beaucoup pour la citation.
Je viens d'écrire un petit billet en corrélation et je voulais faire un trackback, mais ça marche pas.