Note de lecture : Team of Teams, par Stanley McChrystal

Note : 10 ; Une vue holistique inspirante de l’agilité à grande échelle !

Le Général McChrystal fut le commandant en chef des forces américaines en Irak et en Afghanistan à partir de 2003. Ce livre nous raconte comment et pourquoi il a été amené à repenser la structure de fonctionnement de ce détachement militaire face à un ennemi (Al Quaïda en Irak) qui était tout simplement en train de gagner. Mais il ne s’agit pas simplement d’une histoire militaire, en fait il s’agit même assez peu de cela. Il s’agit avant tout de comprendre ce que signifie « s’adapter » au 21ème siècle, pourquoi cela est devenu indispensable, ce que cela signifie et quelles en sont les implications.

Car en réalité, ce que nous appelons « adapter » est souvent au mieux « aménager », car notre façon de pensée est largement imprégnée du réductionnisme direct descendant du Taylorisme, grand vainqueur du 20ème siècle. Le texte de McChrystal tisse de nombreux liens entre le fonctionnement des troupes au moyen-orient et des histoires du passé qui mettent en exergue sous différents angles les limites (voir les dangers) de la pensée réductionniste : le « better, faster cheaper » de la NASA, la gestion holistique des situations d’urgence ou encore les nouveaux entrainements des pilotes de l’aviation civile mettant l’accent sur la collaboration. Il y a encore beaucoup d’autres histoires qui y sont racontées. Car l’ouvrage est avant tout un grand story-telling. Plutôt que de passer les chapitres en revue, je préfère énumérer quelques uns des sujets qui sont évoqués, ce qui ne sera malheureusement pas exhaustif :

Lire la suite

Publicité

Note de lecture : Agile Software Development with Distributed Teams, par Jutta Eckstein

Note : 3 ; Très loin de ce que j’espérais…

Sans jamais avoir lu aucun de ses livres, mais en ayant croisé son nom à de multiples reprises, j’avais mis beaucoup d’espoirs dans le texte de Jutta Eckstein. La caution « Dorset House » ajoutant encore un peu à cela. Une attente d’autant plus importante que la fameuse mode du « scaling agile » ne donne rien de réellement convainquant, la plupart des approches misant sur le processus plus que sur le savoir-être agile.

Hélas, ici encore, c’est surtout de processus qu’il est question ! Le corps du texte tient en 220 pages, constitué en 10 chapitres. On ouvre le bal avec « getting started » qui campe la structure du livre en 5 pages. Passons. Au chapitre 2 « assessing agility and distributed projects », l’auteur nous présente sur une quinzaine de pages des généralités sur les différentes catégories (structures) de développement distribué d’une part et les bases de l’agilité d’autre part. Certainement utile et bien écrit pour des débutants mais je n’y ai rien appris.

Le 3ème chapitre « building team » est plus conséquent avec 25 pages. On y fait la différence entre la feature team (équipe pluridisciplinaire à un seul endroit) et l’équipe dispersée où les compétences nécessaires à une réalisation sont réparties sur plusieurs localisations. Si l’auteur insiste à juste titre sur la nécessité de se connaître sur le plan individuel, j’ai été plus déçu par le focus important donné aux rôles qui occupe la dernière partie du chapitre.

Lire la suite

Note de lecture : Re-Engineering Legacy Software, par Chris Birchall

Note : 3 ; Une expérience vécue solide pour l’auteur, mais un peu léger voir naïf pour un livre !

Dans l’ensemble, l’auteur s’est contenté d’évoquer ses quelques expériences (surtout une en fait) de travail sur du code Legacy. Certes, l’expérience est assez solide, mais présente aussi d’importantes lacunes dont je parlerai, je pense surtout aux tests.

L’ouvrage en lui-même n’est pas un jour sans fin : il compte 200 pages, réparties en 3 parties qui totalisent 10 chapitres. La première partie « getting started » comprend 2 chapitres qui comptent pour 45 pages. Au premier d’entre-eux, « understanding the challenges of legacy projects », on fait le point sur une douzaines de pages sur les problèmes rencontrés sur du legacy. Des problèmes que l’on connaît fort bien, ce ne sont donc pas des découvertes, le sujet est même traité un peu façon « tarte à la crème » !

Avec une trentaine de pages, le second chapitre « finding your starting point » est plus conséquent. La stratégie apparaît quand même étonnante et même peu pertinente : on y évoque de l’exploratory refactoring (donc du refactoring sans filet ) et l’usage des outils de métrique comme PMD. Mais point encore de tests qui justement me semble le bon point de départ !

Lire la suite

Note de lecture : Startup Growth Engines, par Sean Ellis & Morgan Brown

Note : 5 ; Il ne dit pas tout…

Sean Ellis est à l’origine du terme « growth hacker ». Cet ouvrage s’inscrit dans la continuité de cette approche. Ou plutôt, elle en est la déclinaison pratique par l’exemple : ce sont 10 entreprise dont les facteurs de croissance spectaculaire sont analysés, décortiqués ici. C’est en reconstituant l’histoire de ces startups que l’auteur nous montre précisément le ou les facteurs qui n’ont pas donnés les résultats escomptés et les changements qui ont provoqué le décollage et pourquoi.

On commence avec Yelp! Pour les auteurs, le site de recommandation a su démarrer au niveau local pour assurer son assise dans la baie de San Francisco jusqu’à y devenir incontournable. Yelp! A aussi su éviter la dérive pub : le focus a toujours été l’utilisateur, ne pas biaiser les avis en fonction des annonceurs, récompenser les bons comportements et promouvoir les « Yelp Elite » qui tractent le site par la qualité et la quantité de leurs notations. Un moment important fut le pivot des recommandations d’amis vers le partage de revues, en 2005. Yelp! A gagné son pari d’influer les commerces plutôt que l’inverse, mais s’est aussi embarqué très tôt sur la vague mobile.

Github a été créé en 2008, et est devenu depuis le Mammouth de l’open-source (provoquant même la disparition de certains acteurs historiques). Au départ, Github se veut une solution au problème de collaboration que Git adresse mal. Il devient une plateforme de choix pour cloner des repo, proposer des évolutions, bref collaborer, justement. Grâce à cela, Github a très tôt formé une communauté d’ingénieurs chevronnés, noyau d’un « effet réseau ». L’un des facteurs déterminant fut le modèle « freemium » qui n’a pas cannibalisé le modèle payant. Au final, le produit devient très addictif et les utilisateurs fidèles.

Lire la suite