How Spotify Builds Products

J’avais posté il y a quelques temps un lien vers l’article d’Henrik Kniberg à propos du scaling chez Spotify. Cet article expose la manière “lean startup” dont les produits sont pensés et évoluent :

  • Think it : on a une idée !
  • Build it : on construit un MVP.
  • Ship it : On le met en production.
  • Tweak it : Puis on l’améliore continuellement.

C’est même un Kanban au niveau de la société qui permet de visualiser la totalité des projets et leur état d’avancement.

Think it

Lorsque quelqu’un arrive avec une nouvelle idée, il peut former une petite “squad” (typiquement 3 personnes) s’il a le feu vert de la direction afin de développer celle-ci, typiquement sous forme de prototype. Il s’agit de répondre aux questions : pourquoi devons-nous construire ce produit et pour qui ? Quel va être la mesure du succès ? Bref, une vraie démarche Lean Startup dans l’esprit !

La partie la plus importante est un narratif qui est développé avant que le produit soit développé. De nombreuses maquettes (papier ou non) sont souvent élaborés en parallèle.

Le “done” est accompli lorsque le management décide que le produit vaut le coup. Cela est fait de manière subjective, sans épauler cela de chiffres ou d’études de marché. Cela viendra plus tard, dans le “ship it” !

Build it !

C’est la construction du produit, conduit en agile (Scrum, XP, Kanban) avec un squad plus étoffé. Parfois même plusieurs squad. L’objectif est la création du MVP.

Le MVP est un équilibre délicat entre un proto qualifié d’embarrassant, en tout cas pas assez abouti pour être mis dans les mains des utilisateurs et un produit standard, bien trop coûteux pour un premier jet. Pour Spotify, MVP signifie Minimum Loveable Product, qui soit “narrative complete”, plutôt que “feature complete”.

Le “done” est atteint quand le squad et le management pensent que le produit est assez bon pour passer en production.

Ship it

Il s’agit de déployer progressivement le produit vers 100% des utilisateurs. On commence par le déployer vers un petit échantillon d’utilisateurs, et c’est là que l’on commence à vérifier nos hypothèses initiales. Le processus standard est d’effectuer des itérations pour opérer des ajustements.

Le “done” est atteint lorsque le produit est déployé vers 100% des utilisateurs.

Tweak it

C’est la phase la plus importante. Le produit peut être amélioré de nombreuses façon. Le squad opère des évolutions via de l’A/B testing et le suivi des métriques d’utilisation. A un certain point le produit atteint un optimum local et les nouvelles fonctionnalités n’ajoutent guère de valeur au produit. Soit le squad passe progressivement vers un nouveau projet, soit l’on rentre dans une phase de “re-think” pour changer dramatiquement le produit.

Publicités

L’essence de l’agilité

Cette présentation a été fait par Henrik Kniberg en 2010 à Kiev. Elle reprend les points essentiels de l’approche agile et fait le tour d’horizon des principales méthodes qui en sont issues (XP, Scrum, Kanban), avec toutefois un focus particulier sur Kanban.

Stoos Satellite Paris en Janvier

Le nombre ne fait pas forcément la qualité (il est vrai que l’inverse ne se vérifie pas non plus), nous n’étions que 3 pour ce premier déjeuner Stoos de 2014 !

Passer un moment intéressant ensemble, avec des personnes que j’apprécie, avec lesquelles je vais pouvoir échanger des idées et qui me feront reflechir est déjà une bonne motivation pour moi. Yannick et Christine font sans aucun doute partie de ces personnes.

image

La co-création de valeur

Christine nous avait fait rencontrer Manfred Mack l’an dernier, ce dernier nous avait parlé de co-création de valeur et de son expérience en cette direction chez Spi-Batignolles. Ils semblent tous deux très motivés pour enclencher un évènement autour de cette question, peut-être une bonne occasion d’impliquer le groupe et enfin faire quelque chose de concret.

Par contre, il reste à déterminer quelle forme donner à cela. Car si des témoignages sont intéressant, cette approche se vit plus qu’elle ne s’expose. Nous avons donc encore du pain sur la planche.

Pour l’instant notre réflexion nous a conduit à explorer l’existence de cette co-création à différents niveaux stratégiques ou opérationnels. C’est peut-être une voie à explorer pour une thématique du genre “la co-création de valeur aux différents niveaux de l’entreprise” ?

Les tests d’acceptance sont de la co-création

Il semble que Yannick et moi partageons la même expérience sur ce sujet : Ecrire des tests d’acceptance en faisant travailler côte à côte les différents métiers impliqués dans un projet nous apporte une plus value à de nombreux niveaux :

  • Créer une convergence de point de vue et de compréhension du problème.
  • Etablir un langage commun.
  • Valoriser la complémentarité de points de vue et de savoir-faire des intervenants.

Le motif récurrent semble être le “langage commun” d’une part et l’effacement de la frontière entre le “nous” et le “eux” qui nous est si chère, à nous autres agilistes.

Communautés et équipes opérationnelles

Effacer les frontières entre les métiers pour réaliser des projets en mettant les personnes nécessaires dans une même équipe, c’est bien. C’est même indispensable. Mais c’est aussi détruire une citadelle pour en construire une autre !

En effet, le partitionnement organisationnel en métiers induit une friction dommageable au fonctionnement des projets, souvent coûteux, parfois fatal. Par contre il favorise la transmission d’information transversal et permet (ou plutôt devrait permettre) l’amélioration des savoirs-faire.

Les unités projets pluri-disciplinaires réduisent cette friction et améliorent l’efficacité de manière très importante. Mais elle créent de nouvelles barrières pour permettre la communication transversale et l’apprentissage au sein d’un même corps métier. C’est là qu’interviennent les principes de communauté et de guildes comme l’évangélise Jurgen Appelo ou que l’applique Henrik Kniberg chez Spotify. La difficulté étant de maintenir et entretenir ces communautés. C’est parfois fait via un “20% de management opérationnel”. Je vais tenter quelque chose en ce sens dans les mois qui viennent, j’aurais peut-être un retour à faire d’ici quelque temps…

Effectuation

Voilà plusieurs fois que j’entend revenir ce néologisme. Cette fois, c’est Yannick qui nous en parle ! Apparemment, il s’agit d’une logique d’expertise entrepreneuriale qui va à l’inverse de la logique causale, mais qui part plutôt de l’effet que l’on cherche à obtenir, si j’ai bien compris. Elle se rapprocherais ainsi de la logique de pensée du coaching orienté solution, si je peux me permettre cette association osée…

La vidéo de la conférence TED que m’a envoyé Yannick est un peu longue, mais Saras Sarasvathy est la chercheuse qui a identifié et formalisé ce concept, il est donc juste d’en donner le lien.

A bientôt pour un prochain déjeuner Stoos ou des nouvelles de l’évènement sur la co-création de valeur !

L’agilité à grande échelle chez Spotify, par Henrik Kniberg & Anders Ivarsson

Dans cet article, les auteurs décrivent la façon dont Spotify est parvenu à maintenir une dynamique agile malgré une montée en taille importante et rapide sur les 6 dernières années. Elle s’appuie sur un petit nombre de concepts organisationnels

Les squads

A mi-chemin entre la Scrum Team et la Feature Team, le squad est doté d’une mission sur le long terme, possède un espace de travail en propre et regroupe toutes les compétences nécessaires à sa mission. Son mode de travail s’inspire du Lean Startup, mais ici on appelle cela “think it, build it, ship it, tweak it”. Les squads bénéficient aussi des 10% hack days inspirés des 20% ou des exploration days de Jurgen Appelo (c’est la même chose).

L’objectif, sinon la clé est d’avoir des squads autonomes.

Les tribus

Les squads sont nombreux : il y en a 30 chez Spotify. Ils sont regroupés en tribus. Une tribu est focalisée sur une problématique métier particulière est fonctionne un peu en “incubateur de startup”. Elles sont de taille variées mais ne dépassent pas 100 personnes.

Les tribus organisent leur propres rassemblements et partagent outils, idées, etc… 

Les chapitres

Ce sont des regroupements “transverses” de personnes de même domaine d’expertise. Ils se rencontrent régulièrement pour partager outils, expérience, challenges, etc.. Chaque chapitre est géré par un manager qui est de fait le responsable hiérarchique de ses membres … mais est lui-même membre d’un squad avec des responsabilités opérationnelles ! Les chapitres sont locaux aux tribus.

Les guildes

Ce sont des communautés d’intérêt, plus informelles que les chapitres. Elles sont transversales à l’entreprise et regroupent souvent les chapitres correspondant des différentes tribus. L’animateur d’une guilde l’est à temps plein. 

Là aussi, la lecture du Management Workout de Jurgen Appelo peut être instructive…

L’organisation dans son ensemble

Elle est en quelque sorte matricielle. La dimension dominante est celle du “quoi”, l’axe opérationnel, donc les squads et les tribus. Il y a une seconde dimension, celle du “comment” qui correspond aux chapitres et aux guildes.

Et bien d’autres choses…

Voilà, il s’agit juste de l’apéritif pour vous encourager à lire cet article par ailleurs fort bien écrit et illustré. Il y a de nombreux éléments que j’ai passé sous silence, comme la gestion des dépendances entre les squads.

Spotify est une entreprise dont la structure dominante est tournée vers l’opérationnel. Elle rompt avec les structures traditionnelles orientées compétences qui fragmentent l’organisation en silos, obligeant les projets à franchir les obstacles entre ces silos, consommant temps et énergie et souvent aussi hélas, vidant les projets de leur substance !

Note de lecture : Scrum and XP from the Trenches, par Henrik Kniberg

Note : 9 ; Du vécu, rien que du vécu ! Book of the Year 2009 !

Le titre à lui seul résume la direction du livre : « comment nous pratiquons Scrum ». Pas de descriptif de Scrum ici (l’auteur renvoie pour cela à d’autres références), ni de longue dissertation sur la théorie. Sur chaque pratique l’auteur décrit de la manière la plus concise possible la façon dont il pratique cela dans son équipe et le bénéfice qui en est retiré. La concision et la valeur du texte sont tout simplement impressionnantes ! Que n’ai-je lu ce livre avant ! D’ailleurs, avec un petit format, une quantité honorable d’illustrations et seulement 130 pages, il se lit très rapidement. Une seule journée m’a suffit.

Le livre compte quand même 15 chapitres, donc forcément très courts, ce qui est un plus. On couvre ici toutes les pratiques : Le product backlog, le sprint planning, la communication, le sprint backlog, l’organisation de l’espace, le sily scrum, démos et rétrospectives. Les pratiques XP combinées à Scrum ne sont pas oubliées : Scrum et XP et TDD ont droit à leur chapitres ! L’auteur s’offre même le luxe d’aborder les sujets « avancés » : les contrats au forfait, les équipes géographiquement dispersées et laa pratique de Scrum sur plusieurs équipes.

Le livre existe en version reliée, mais aussi en PDF librement téléchargeable qui offre l’avantage d’avoir les illustrations en couleur ! Si vous pratiquez Scrum ou vous y interessez, il n’y a vraiment aucune raison de ne pas lire cet ouvrage !

scrum-from-trenches

Référence complète : Scrum and XP from the Trenches, how we do Scrum – Henrik Kniberg – InfoQ 2007 – ISBN : 978 1 4303 2264 1

Scrum and XP from the Trenches

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

Note de lecture : Kanban and Scrum, making the most of both – Henrik Kniberg & Mathias Skarin

Note : 7 ; L’une des meilleures références pour comprendre le Kanban, pour les praticiens de Scrum

La lecture de ce bref ouvrage avait deux objectifs pour moi : étrenner mon Kindle DX (mais je n’en parlerais pas ici) et rédiger une note de lecture sur la version française pour le French SUG.

Ouvrir un nouveau texte signé Henrik Kniberg était forcément pour moi un moment fort attendu, tellement le livre précédent était excellent. Mon premier réflexe est de voir la taille du livre : 128 pages d’une couverture à l’autre pour la version française, contre 122 pour la version originale. Ça va. Cette fois, Henrik s’est associé à Mathias Skarin, également consultant chez Crisp. La table des matières montre une répartition remarquablement symétrique : 50 pages nous viennent d’Henrik Kniberg et traitent de la comparaison de Kanban et de Scrum sur 16 chapitres. La seconde partie, rédigée par Mathias Skarin, est une étude de cas. Elle couvre également 50 pages sur 16 chapitres. On aura bien sûr compris que ces chapitres sont très courts, chacun couvrant 3 pages en moyenne !

Kanban et Scrum, s’ils peuvent être complémentaires, se distinguent fortement l’un de l’autre. Scrum se focalise sur l’itération, lui donnant un périmètre au départ et s’organisant de façon à ce que celle-ci aboutisse positivement en suivant l’avancement des tâches et en acquièrant du fedback à la fois au cours de l’itération et à sa fin. Kanban en revanche ignore pratiquement le concept d’itération, et se focalise sur le flux des tâches, sur les limites d’accumulation de celles-ci aux différents stades d’avancement et en organisant le travail des différents membres de l’équipe en fonction des goulots d’étranglements pouvant apparaître.

Lire la suite

Note de lecture : Lean from the Trenches, managing large-scale projets with Kanban, par Henrik Kniberg

Note : 10 ; Efficace, pertinent, intelligent !

J’ai acheté ce livre avec de grosses attentes. Non pas sur le contenu, car je ne me suis même pas préoccupé d’en connaître la teneur en l’achetant, mais simplement de par la connaissance des autres écrits d’Henrik Kniberg.

Henrik Kniberg aime faire court. Une tendance qui s’agrave avec l’âge : ce texte fait 150 pages. Et encore la partie principale (celle qui vient des tranchées) n’en compte que 100. A l’arnaque me direz-vous ? Il n’en est rien. L’auteur boucle en 100 pages ce qui en demande 250 à d’autres ! Ca tombe bien : notre temps est précieux, quand l’auteur va droit au but et fait que chaque ligne compte et donne de l’information, cela fait vraiment la différence. A ce jeux, Henrik Kniberg est le meilleur.

A l’image de Scrum from the trenches, l’auteur nous livre un retour d’expérience. Il nous livre ce qu’il a fait, ce qui a marché et ce qui n’a pas marché, comment son équipe en est arrivé là et qu’est-ce qui reste imparfait. Le texte est un modèle de clarté, de pertinence et d’honnêteté. Il est éclairant de par ses bonnes idées, par la démarche et l’analyse fine qui sous-tend cela. Mais que recèle donc ce texte ?

En fait les 16 (oui, 16 chapitres sur 100 pages !) tournent autour du tableau Kanban : la façon dont il est construit, comment a-t-il évolué, quelles sont les dynamiques de travail qui gravitent autour, quelles métriques en sont extraites. Bien sûr le texte est naturellement illustré par des photos (parfois auxquelles des indications sont supperposées) du Kanban ou de l’équipe. L’auteur n’a pas essayé de décrire de manière approfondie la façon de travailler de l’équipe (à la façon de ce qu’il avait fait dans « Scrum from the Trenches »), mais plutôt de se focaliser sur les dynamiques de l’équipe et du projet.

La seconde partie consacre 4 chapitres sur 50 pages pour évoquer certains aspects plus informatifs auxquels le texte principal se rapporte : ce qu’il y a dans XP, Scrum, Lean et Kanban ; l’automatisation des tests ; le planning poker et les diagrammes de cause-effets. Chaque chapitre est un modèle de pertinence et de concision.

Je ne vais pas passer du temps à décrire ce que contient le livre : il vous faut simplement le lire vous-même. Si vous êtes agiliste, débutant ou expert, il n’y a simplement aucune raison, aucune excuse pour ne pas consacrer du temps à vous plonger dedans !

lean-from-trenches-pragprog

Référence complète : Lean from the Trenches, managing large-scale projets with Kanban – Henrik Kniberg – Pragmatic Bookshelf 2011 – ISBN : 978-1-934356-85-2

Lean from the Trenches: Managing Large-Scale Projects with Kanban


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