J'ai récemment décidé de revisiter un classique. Publié il y a plus de 12 ans, le Lean Startup n'a pas déçu.
On y trouve bien les notions de MVP et de "feedback loop" qui sont devenus des lieux communs aujourd'hui. Mais il reste aussi quelques pépites qui valent la peine d'être relevées.
Après avoir lu leur livre sur la gestion du changement, j'étais curieux de savoir ce que les frères Heath avaient à dire sur un sujet encore plus fondamental: la communication.
Leur livre précédent et portant sur la question, 'Made to stick', a parfaitement répondu à cette attente, y comprit en prenant un tour surprenant dans son dernier chapitre.
par Annabelle Gawer, Michael A. Cusumano et al.
Il y a bien longtemps un ami m'avait recommandé ce livre Platform Leadership (EN) qui faisait partie des références de son cursus d'étude.
Le livre m'avait impressionné par la façon claire et précise avec laquelle il analysait les deux grands phénomènes qui avaient conditionné le "monde de l'informatique" dans lequel on vivait à ce moment là. Se concentrant surtout sur les initiatives d'Intel qui permirent à l'industrie du PC de croître et s'imposer, le livre comparait aussi cette stratégie avec l'approche radicalement différente utilisée par Microsoft pour faire croître "Windows".
Depuis, le monde a évolué et l'industrie de l'informatique avec. Je me suis donc plus récemment mis à espérer que le livre soit "mis à jour" à la lumière de ces changements, et en le cherchant, ce n'est pas une mise à jour mais un livre entier et tout neuf que j'ai finalement trouvé: Business of Platforms (EN)
Tout aussi impressionnant, et je vous dis ce qui m'a marqué.
Switch, sous titré "osez le changement" dans sa traduction française, propose une façon de réfléchir à comment changer quelque chose (une habitude, une méthode etc), à l'impact sur nous autres humains d'un tel changement et à comment le rendre plus facile pour nous tous.
Le livre est facile à lire (dans sa version anglaise en tout cas) avec un bon équilibre entre des exemples issus de cas réels, des cas d'études simplifiés et une très courte sélection de recettes qui leurs sont associées.
Résumé ici ses principales leçons serait sans doute injuste tant les auteurs ont eux même fait de grands efforts de synthèse à la fin du livre. Je me contenterai donc ici de partager les grandes idées ainsi que le cheminement de pensée tel que je l'ai compris.
L'essentiel du livre suit la "Task Force" de l'armée US en Iraq alors qu'elle doit s'adapter à une guerilla d'AQI (Al Qaeda en Irak).
Les auteurs développent leur proposition d'organisation d'une équipe d'équipes ("team of teams") progressivement, à travers une succession de compte-rendus de missions militaires de cette campagne.
Ils complètent leur raisonnement d'illustrations venant du monde civil pour démontrer comment le type d'organisation qu'ils mettent en avant peut s'appliquer dans un domaine plus large. De façon intéressante, cela les amènes à déconstruire certaines idoles du monde entrepreneurial telles qu'Adam Smith et Taylor et leur opposer d'autres idoles parfois plus inattendues sur ce sujet telles que Tocqueville, l'amiral Nelson, George Mueller de la NASA et un ancien maire de New-York, Bloomberg.
Dans les tous derniers chapitres les auteurs donnent aussi quelques exemples d'initiatives qui ont contribué à changer l'organisation de la "Task Force". Ces exemples sont intéressants mais c'est aussi la partie que j'aurais aimé voir plus détaillée.
Voyons donc ce qu'est une équipe d'équipe pour ces auteurs.
Ce printemps a été assez chargé pour mon projet personnel WaterOnMars.
En effet, en voulant y rajouter une fonctionalité (une première depuis longtemps, mais qui fera peut-être l'objet d'un autre billet), j'ai reçu une salve de "warning" à chaque push et deployement pointant du doigt des éléments essentiels du projet. Car oui ce projet utilisait alors des versions largement obsolètes de Python et Django.
Donc merci aux développeurs de Python et Github de générer ces warnings qui m'ont motivé pour mettre à jour l'application en passant de Python2 à Python3 et passer de Django1.4 à Django2.2.
Les quelques détails et remarques sur cette grosse migration étant purement techniques, ils se liront mieux sur la version anglaise de ce billet.
Dans mon précédent billet j'annonçais la migration de Wordpress vers Nikola.
Mais après avoir profité de Wordpress pendant toutes ces années, j'ai le sentiment que je dois bien quelques explications à la communauté.
Le reste de ce billet résume certains points de mon experience (très bonne !) avec Wordpress, un peu de celle avec zenPhoto et de ce qui fait la différence avec Nikola.
Ça y est, c'est fait ! Le premier billet de ce blog écrit avec Nikola et, encore mieux, tout mon site tibonihoo.net est désormais constitué de page statiques.
Après 12 ans de bons et loyaux services, Wordpress (merci à Automattic et sa communauté) ne "propulsera" donc plus ce site qui consumera donc moins de ressources et me demandera marginalement moins de maintenance.
Le nouveau logiciel que j'utilise pour le remplacer s'appelle Nikola (un grand merci à Roberto Alsina, Chris Warrick et aux autres contributeurs) et génère la totalité du site sous forme de pages html statiques une bonne fois pour toute.
La flexibilité de Nikola m'a permis de maintenir l'essentiel de l'organisation du blog avec étonnamment peu de changements d'adresses pour le contenu mais quand même avec un minimum d'effort décrit dans la suite du billet.
Et, pour le plus important, on retrouve les billets de blog et les photos aux mêmes endroits.
Après trois ans un peu loin du projet j'ai enfin eu le temps de faire une livraison de Yapsy, avec le regret de ne pas avoir fait honneur aux contributions qui ont pourtant sympathiquement amélioré la librairie.
Les améliorations les plus notables sont la résolution de problèmes de compatibilités avec Python3.6 et d'un gros bug qui rendait la gestion parallèle des plugins impossible sous Windows (changelog ci-dessous).
C'est parti pour une revue de Peopleware: Productive Projects and Teams, 2013 (1ère édition en 1987) par Tom DeMarco et Tim Lister. Encore une revue très en retard puisque j'ai eu le temps de le lire deux fois depuis que j'ai décidé d'en faire la revue.
C'est un livre à propos des équipes de développeurs, de ce qui leur permet de créer des logiciels exceptionnels et de comment (pour les managers) ne pas les en empêcher. De mon point de vue c'est aussi la suite logique du Mythical Man Month.
L'idée centrale c'est que le développement logiciel est un travail essentiellement intellectuel (de communication et de réflexion) dans un environnement (le marché et la technologie) qui change rapidement.
Je grouperais les autres idées dans les trois catégories suivantes:
