Rapport de mise à jour : essai de la méthodologie « Shape Up » de Basecamp

L'année dernière, j'ai tenté de faire passer mon équipe produit de l'approche SCRUM classique à la méthodologie Shape Up de Basecamp. Ce fut une expérience incroyable; J'en ai beaucoup appris et j'ai pensé partager certaines de mes découvertes avec vous.

Si vous l'avez expérimenté vous-même, j'aimerais savoir comment cela s'est passé. Si ce n’est pas le cas, j’aimerais savoir pourquoi vous êtes resté à l’écart.

Partie 1 : Pourquoi Shape Up ?

Mon équipe fonctionnait sur SCRUM depuis toujours. À l'époque de notre startup, nous vivions les cycles technologiques classiques : travailler vite, expédier et ne pas trop penser aux processus. Ensuite, nous avons été acquis.

Une fois que j'ai eu un peu plus de temps pour réfléchir à nos options de méthodologie produit, j'ai décidé d'essayer Shape Up. Il y avait plusieurs raisons :

1. Jusque-là, nous essayions des sprints de 2 semaines et échouions systématiquement à les terminer. Chaque semaine ressemblait à un tapis roulant de billets que nous n'aurions jamais vraiment terminé.

   
   

2. L’équipe se sentait comme des singes codés. Choisissez un billet. Billet de travail. Livrer le billet.

   
   

3. Parce que nous n'avons jamais terminé le sprint, les tâches se répercutaient toujours sur la suivante. Finalement, le barrage se brise.

   
   

4. Nous avons tous manqué de concentration. Chaque sprint était un choix et un mélange de choses sur lesquelles travailler sur l'ensemble de la base de code.

   
   

5. Très peu de travail d'équipe. Chaque développeur travaillerait sur sa petite part du gâteau, laissant peu de place à l’apprentissage mutuel et, franchement, à un sentiment de communauté.

   
   

6. Presque aucune compréhension du client. Les développeurs récupéraient les tickets attribués, les faisaient et n'avaient aucune idée de pourquoi/qui/quoi.

Après avoir relu Forme du camp de base , j'ai pensé essayer car il prétendait résoudre la plupart de ces problèmes.

Partie 2 : Pitching en interne

L’une des parties les plus difficiles du passage à Shape Up a été de présenter l’idée en interne.

J'ai passé plus de temps à internaliser la plupart des concepts de Shape Up pour m'assurer d'être prêt à répondre à toutes les questions. Sans surprise, les développeurs ont adoré l'idée de cette nouvelle approche (plus de temps, plus de concentration, plus de collaboration ; pourquoi pas !).

Sans surprise également, la hiérarchie s’est montrée plus réticente. Finalement, j'ai réussi à les convaincre en :

1. Assurant que ce n’était qu’un essai. Si les choses ne fonctionnaient pas, nous reviendrions à la « normale ».

   
   

2. M'assurer que j'allais rester aussi disponible que jamais pour les aider. Les développeurs seraient concentrés et ininterrompus, mais pas moi.

   
   

3. Mettre en avant Shape Up nous permet de résoudre des problèmes plus importants, ce qui signifie de plus grandes opportunités.

   
   

4. Insister sur la douleur que le produit ressent actuellement et sur la manière dont elle affecte chaque équipe.

J'ai préparé un diaporama très clair et l'ai présenté à chaque chef de département (service client, ventes et C-suite).

Partie 3 : Peurs et inquiétudes

Mon expérience en tant que fondateur, spécialiste du marketing et chef de produit m'a appris qu'il vaut toujours la peine de noter ses préoccupations avant de commencer une expérience. J'en ai eu quelques-uns avec Shape Up :

• Comment gérer les distractions ? Je sais que je suis censé « dire non ». 'Étaient occupés.' « Au prochain cycle, nous pourrons examiner cela. » C'est la théorie, et cela fonctionne si l'ensemble de l'entreprise adhère à cette méthodologie. Lors de mon premier essai de cycle, j’avais peur qu’une urgence surgisse.

• Des arriérés ? Shape Up recommande de ne pas accumuler de retards (chapitre 7). Puisque nous essayions juste cela, je ne suis évidemment pas allé cmd+a+supprimer notre retard, mais quand même. Si nous devions adopter cette méthodologie, je me sentirais un peu perdu sans arriéré.

• 'Presque fini.' Celui-ci m'a vraiment fait peur. Que se passe-t-il si nous atteignons la fin du cycle de 6 semaines et que nous y sommes provisoirement, mais pas tout à fait ? Basecamp dit « recommencez » (sauf si vous êtes si proche). J'avais peur que nous manquions la cible dans la fourchette ennuyeuse de 20 à 30 %.

En fin de compte, aucune de ces craintes/inquiétudes n’a pu m’empêcher de poursuivre le procès. Mais cela valait la peine de les garder à l’esprit.

Partie 4 : Le cycle

Et c'est parti !

J'ai lancé le premier cycle un lundi matin, après six semaines de concentration intense et de travail d'équipe. Voici un résumé de ce qui s'est passé chaque semaine :

• Semaine 1 : Coup d'envoi et... silence. Laisser l'équipe tranquille, la laisser faire des recherches et se plonger dans le code à son rythme sont tous des éléments majeurs de cette méthodologie. C'était incroyablement difficile pour moi de lâcher prise pendant cette première semaine et de ne pas demander de mises à jour. J'ai tenu bon !

• Semaine 2 : L'équipe est enfin sortie de sa coquille. Communication reprise. Le design du travail a commencé à apparaître, j'ai pu donner mon avis et travailler ensemble.

• Semaine 3 : En théorie, la semaine 3 devrait être le sommet de la courbe du cycle. À la fin, l’équipe devrait avoir une très bonne idée de la manière dont elle va construire ce qui doit être construit. Nous avons créé un canal Slack spécifique au cycle alors que la communication commençait à s'intensifier correctement. À la fin de cette semaine, nous avons vu des prototypes, des conceptions, des extraits de code et bien plus encore. Nous étions sur la bonne voie !

• Semaine 4 : Calme à nouveau. Tous les allers-retours de la semaine 3 ont produit une semaine 4 concentrée pendant laquelle chacun a mis en œuvre son travail. Nous avons lancé un « show & tell » vendredi.

• Semaine 5 : Semaine Curveball. L’un des oscilloscopes a commencé à générer pas mal de discussions. Il est vite devenu évident que le champ d’application n’était pas suffisamment clair. Je n'avais pas été assez précis dans mes exigences et ce qui semblait simple et agréable au départ s'est avéré complexe. J'ai dû prendre la décision difficile de réduire cette portée.

• Semaine 6 : Les scopes restants se déroulaient bien. L'intensité a considérablement augmenté au cours de la semaine 6 alors que je faisais du contrôle qualité partout, et les développeurs répétaient mes commentaires incroyablement rapidement ; nous étions tous unis pour atteindre l’objectif.

  
  

Au final, nous avons atteint la cible. Nous l'avons créé! C'était super intense et j'étais dévasté de devoir couper l'un des télescopes, mais nous y sommes parvenus.

Le lundi suivant à 10 heures, nous sommes entrés en production.

Partie 5 : Quelques leçons

Sans ordre particulier, voici quelques leçons et recommandations :

1. La mise en forme est difficile . Je pensais avoir fait un travail décent en façonnant la plupart des parties effrayantes du cycle. Il s’avère que j’ai raté quelque chose d’évident qui a presque fait dérailler tout le cycle.

   
   

2. Incluez votre équipe lors du façonnage . Je l'ai façonné principalement seul, et parfois, avec le chef de mon équipe de développement. Il aurait été utile pour moi d'inclure d'autres développeurs.

   
   

3. Si vous vous retrouvez à discuter ou à façonner le milieu du cycle, quelque chose ne va pas . Arrêtez tout. Votre priorité est de comprendre cette chose avant qu’elle ne fasse dérailler complètement tout le reste.

   
   

4. L'intensité n'est pas uniformément répartie . Que ce soit entre les membres de l’équipe ou tout au long du cycle, l’intensité du travail va grandement varier. En tant que PM, votre rôle est de repérer ces poches d'intensité et de porter une attention particulière aux individus qui les traversent.

   
   

5. Créez une chaîne Slack distincte . Cela a rendu la communication beaucoup plus facile mais aussi beaucoup plus amusante. L’équipe du cycle a rapidement développé un langage commun, des mèmes liés au travail sur lequel nous travaillions, etc. C’était essentiellement comme être une startup au sein de l’équipe.

   
   

6. Mettez en œuvre des réunions show & tell à partir de la semaine 1 . Nous avons attendu trop longtemps pour le faire. Il devrait y avoir de quoi montrer ou discuter dès la fin de la semaine 1. C'est aussi l'occasion de se retrouver, de discuter, d'apprendre, etc.

   
   

7. La période de recharge s'est avérée beaucoup plus difficile que le cycle lui-même . Tous les « autres travaux » s'étaient accumulés pendant 6 semaines ; c'était comme revenir directement à SCRUM. C’est quelque chose que je travaille encore à améliorer.

Comme vous pouvez probablement le constater, j'ai été vendu par cet essai.

Mettre en œuvre Shape Up et adopter ses bizarreries ne se fait certainement pas du jour au lendemain. Je pense que ce sera un long processus d'apprentissage. J’ai particulièrement apprécié le changement de mentalité que cet essai nous a permis. Nous (et les autres équipes, je l'espère) avons appris à voir le travail pour ce qu'il est : un défi passionnant que nous relèverons ensemble.

Si vous avez essayé cela (ou non), j'aimerais lire des histoires ou des commentaires !

Si vous avez apprécié cet article, vous apprécierez peut-être ma newsletter . J'écris sur la gestion de produits, je partage des informations exploitables et je relève des défis de produits réels pour le plaisir (je sais, n'est-ce pas ?).