Note de lecture : Software in 30 days, par Ken Schwaber & Jeff Sutherland

Note : 3 ; Déçu, déçu, déçu et anachronique !

Jurgen Apello a qualifié ce livre de « poorly writen marketing brochure ». Je dois avouer que cela résume bien le livre. Pourtant, je me réjouissais d’avoir enfin un texte co-écrit par les 2 créateurs de la méthode, mes attentes étaient donc élevées, c’est certain. Voyons ce qu’il en est.

Le livre est bref : 125 pages (rajoutons les 3 très volumineuses annexes qui comptent tout de même 60 pages), sur 10 chapitres rassemblées en 2 sections. C’est du John Wiley, le papier est dégueulasse, c’est une habitude chez cet éditeur. En fait, ça commence même mal dès la couverture : qui fait encore du Scrum sur 30 jours ? Les auteurs sont restés campés sur leur position vieille de 20 ans (pour être précis). Le monde a changé entre temps, ils ont choisi de décider que le monde avait tord et que la Vérité promulguée il y a 2 décennies était inaltérable. En tout cas, cela ressemble à ça.

Long d’un peu plus de 50 pages et fort de 4 chapitres, la première section défends l’idée que toutes les organisations peuvent produire du logiciel… en 30 jours (encore !). Les 13 pages du 1er chapitre introduisent la « crise du logiciel ». C’est l’introduction classique à l’agilité. L’intérêt ici, c’est de s’appuyer sur des études datant de 2011 au lieu de la classique étude du Standish group de 2002 !

Au chapitre 2, on s’intéresse à l’essence de Scrum : l’empirisme. Un propos que j’ai l’impression d’avoir déjà lu il y a 10 ans dans les ouvrages précédents de Ken Schwaber. Plus pathétique encore : comparer cette approche au Waterfall. Sans doute il y a-t-il encore un peu de Waterfall sur des projets dans des coins, mais que diable, nous sommes en 2013 !

Après l’introduction, la mise en œuvre. Le chapitre 3 nous propose de choisir un projet pilote pour mettre en œuvre Scrum. C’est à mon avis un anachronisme de plus, car si ce concept pouvait exister il y a 10 ans, aujourd’hui les projets qui ne sont pas critiques ne sont simplement pas faits. Seule bonne nouvelle : le chapitre est court.

Cette première partie s’achève sur un court chapitre de 8 pages qui pose et investigue la question : quelle est la prochaine étape ? C’est une introduction à la seconde partie.

Cette seconde partie, justement, compte 70 pages sur 6 chapitre. Elle débute par le chapitre 5 qui présente les grandes lignes du framework Scrum. Le grand moment de rigolade de ce chapitre, c’est quand les auteurs prétendent que la majorité des mises en œuvre de Scrum se font avec des durées de 30 jours et que la réduction de cette durée à 2 semaines n’affecte que de façon très marginale les durées des meetings de début et fin d’itération. C’est ce qu’on appelle être bien à côté de ses pompes !

Le chapitre 7 nous présente le « studio Scrum ». C’est peut-être le chapitre le plus intéressant du livre, sans qu’il soit non plus transcendant. Mais au moins on parle un peu sérieusement de la « definition of done », par exemple.

Les chapitres 8 et 9 évoquent Scrum au niveau de l’entreprise. Cela reste dans la même veine que l’Enterprise Scrum de Ken Schwaber, rien de nouveau et c’est nettement plus superficiel.

Enfin le chapitre 10 nous parle de cycles d’amélioration de Scrum. Là encore un propos qui fait double emploi avec la prose de Agile Project Management with Scrum de Ken Schwaber.

Le Scrum Guide de l’annexe B est celui disponible en ligne. OK, cela occupe au moins un peu de place. Le « playbook » de l’annexe 3 est plus originel, quoiqu’il date de 2005 !

Ce livre est une grosse déception à de nombreux niveaux. Clairement j’attendais mieux des créateurs de la méthode. Le propos est très superficiel, et même carrément marketing. Je m’attendais à y voir les tripes des auteurs, y sentir des choses profondément ancrées : rien. Le seul intérêt que je peux voir est l’usage exclusif des termes et concepts originaux de Scrum. Ainsi on y parle exclusivement de « product backlog items (PBIs) », là où il semble admis un peu partout de parler de user stories… le retour aux fondamentaux n’est pas nécessairement un mal partout.

S’il n’y a pas de raison à bouleverser le framework Scrum, le propos n’a pas non plus changé d’un iota. Un certain nombre de points souvent dogmatiques sont toujours là et présentés comme indiscutables. Pourtant ils peuvent l’être ou être anachroniques, tel la durée des sprints sur 30 jours (ce que je n’ai ni pratiqué, ni jamais vu pratiqué). Un livre que je déconseille très fortement à tout le monde. Les bons livres sur Scrum existent. Ailleurs.

Référence complète : Software in 30 days – Ken Schwaber & Jeff Sutherland – John Wiley & sons 2012 – ISBN : 978-1-118-20666-9

Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust

https://www.goodreads.com/book/add_to_books_widget_frame/1118206665?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s