D’un grand groupe à une Start-Up, De Scrum à Shape-Up - Agence de conseil en Product Management

Au sommaire de cet article :

Introduction

Le besoin
🏆 Moment clé
🔎 C’est quoi Shape up?
👩‍💻 L’équipe dans Shape up
🗂 Les phases de Shape up
📈 Comment suivre l’avancement
🛡 Shape up vs Scrum, Quelles sont les différences
🏃 Pour aller plus loin

Introduction

Un plan de carrière peut prendre des formes très diverses. Passer d’un grand groupe à une start-up – ou inversement – est une évolution possible.

Après 5 ans au sein d’un grand groupe automobile, le choix était de sortir de ma zone de confort, et découvrir de nouvelles façons de travailler. J’étais habitué aux process, aux boucles de validation souvent trop longues, des équipes aux 4 coins du monde… Je voulais travailler en mode projet, pousser les bords de ma fiche de poste et voir ce que j’étais capable d’entreprendre dans une structure moins pesante. Être un product owner dans un manque de moyens face à la concurrence me parait challengeant. Être un product owner dans une startup me parait excitant.

Le besoin

Dans une startup, on a besoin d’un Product Owner qui prend des décisions stratégiques sur le produit. Ce produit doit impérativement permettre la croissance. Ton produit désigne le futur de la startup et l’équipe produit est le moteur de cette évolution.

L’équipe produit passe beaucoup de temps dans les tâches logistiques (crée un backlog, produit/sprint, gère des tableaux, crée des événements, suit la progression du développement, teste les tickets, ouvre des bugs..). Elle ne trouve pas le temps de réfléchir plus profondément et stratégiquement aux problématiques autour du produit et de l’utilisateur pour concevoir les bonnes solutions. Notre CEO a commencé de réfléchir à intégrer une nouvelle méthodologie de travail qui remplacera Scrum afin de donner un nouveau degré de liberté à l’équipe produit pour se concentrer davantage sur l’étude de la concurrence et l’évolution de notre produit.

Moment clé

La décision vient de s’annoncer, on basculera de Scrum à Shape up. J’ai eu l’occasion de travailler avec notre PM pour amener cette transformation au sein de la startup. Une transformation qui arrive dans un moment clé, dans une phase d’accélération. Il faut trouver la bonne formule pour la team product, les développeurs, les designers, le département marketing…pour tout le monde. Là j’ai commencé mes premiers pas dans Shape up. Là j’ai senti la rupture avec Scrum. Ce framework agile qui m’a accompagné pendant plusieurs années. On commence à réfléchir aux heures passées dans la planification du sprint, le daily le matin ou la rétrospective.

Le premier point qui t’attire est que Shape up fonctionne sans Product backlog. Si quelqu’un veut garder une trace d‘une idée, il doit s’en occuper lui-même. Comment fonctionne Shape up dans ce cas?

C’est quoi Shape up?

La méthode Shape up est une approche de développement de produits conçue pour aider les équipes à “shaper” et à construire des produits à un niveau plus élevé grâce à une définition et une priorisation claires.

Cette méthode a été créée par Basecamp, l’outil de gestion de projet et de communication d ‘équipe bien connu. Cette méthode a été présentée au monde dans le livre “Shape Up : Stop Running in Circles and Ship Work that Matters” rédigé par Ryan Singer en 2019.

La méthode Shape Up aide les équipes produit à réfléchir plus en profondeur aux bons problèmes beaucoup plus tôt dans le processus de développement et à commencer à livrer des produits significatifs à temps.

Les chefs de produit Shape – ou définissent – un projet suffisamment concrètement pour que l’équipe avance dans la bonne direction. Cependant, ils doivent travailler de manière suffisamment abstraite pour que l’équipe conserve son autonomie pour développer ses propres solutions.

L’équipe dans Shape up

Chaque équipe dans Shape up est assez restreinte. En effet, Cette équipe doit avoir toutes les compétences pour mener ce projet à son terme, et elle ne contient souvent qu’un seul acteur par domaine (par exemple 1 développeur frontend, 1 développeur backend, 1 designer). Il est de la responsabilité de cette équipe de mener à bien ce projet. Cela comprend la finalisation du design, les choix d’architecture logiciel, l’implémentation, les tests fonctionnels et automatisés, etc… L’intérêt d’assigner un projet complet à des personnes, c’est qu’elles sont davantage responsabilisées et impliquées dans le produit (les développeurs ne sont pas là uniquement pour dépiler des tickets).

Les phases de Shape up

Chaque cycle commence généralement par un problème à résoudre et mène les équipes jusqu’à une solution satisfaisante. Les équipes réfléchiront à ce qu’elles ont appris à la fin d’un cycle et reconnaîtront comment ces nouvelles techniques/compétences/capacités de résolution de problèmes peuvent être appliquées efficacement à de futurs projets.

Les équipes comprennent des designers et des développeurs, et elles disposent d’une plus grande autonomie qu’elles ne le sont par le biais d’autres méthodes de développement de produits. Ils sont entièrement responsables de la gestion des tâches, de la définition des objectifs et de leur réalisation avec succès.

Alors, que font les product owner pendant les cycles de six semaines ? Ils travaillent à shaper des pitchs destinés à devenir de nouveaux projets à l’avenir, sans responsabilités de microgestion distrayantes. Ils peuvent se concentrer sur la création de projets qui offrent une réelle valeur ajoutée à l’entreprise/startup et aux clients/utilisateurs cibles.

L’approche Shape Up se compose de trois grandes étapes :

1) Shaping – 6 semaines

C’est la phase de conception et de planification, au cours de laquelle l’équipe produit définit le(s) problème(s) à résoudre et la(les) solution(s) à livrer avec la bonne quantité de détails qui permet à l’équipe de développement d’atteindre les objectifs sans revenir à équipe produit, dans un délai prédéfini.

L’équipe produit élimine au maximum les risques et les inconnues, tout en laissant à l’équipe DEV un maximum de liberté dans sa mise en œuvre.

Cette phase présente un processus. On y déroule 4 étapes :

Set boundaries

C’est la toute première étape qui marque l’émergence d’une idée, avant qu’elle ne devienne un projet. Il s’agit ici de définir “ The Appetite” que l’on souhaite se donner sur un sujet donné. Cet appetite est conditionné à la dimension de l’équipe (1 à 2 développeurs + 1 designer) et à la dimension temporelle du batch (6 semaines). A partir de là, il est donc possible pour les personnes réalisant le shaping, de déterminer ce qui est envisageable ou non de réaliser avec ces contraintes.

L’ appetite est complètement différent d’une estimation. Les estimations commencent par un design et se terminent par un nombre. Les appetites commencent par un chiffre et se terminent par un design.

Rough out the elements

A cette étape, la méthode tend à trouver un équilibre entre donner un maximum de détails afin qu’il n’y ait pas de confusion possible sur le besoin et le résultat attendu, le « quoi », mais sans pour autant orienter de manière trop précise le « comment », afin de laisser une marge de manœuvre maximale à ceux qui réaliseront l’implémentation.

Address risks and rabbit holes

L’objectif de cette phase est de faire en sorte d’être le plus serein possible lorsque le pitch sera rédigé, réduire le risque au maximum, afin de garantir que ce qui est proposé est raisonnablement réalisable. Ainsi, le risque de faire totalement échouer le batch est très réduit. on regarde un peu plus en profondeur notre solution pour détecter tous les risques (cas aux limites, etc…).

Write the pitch

The pitch : A la fin de cette phase, un bref « pitch » doit être rédigé. On regroupe tous les éléments ci-dessus dans un pitch (spécification + schéma) qui permettra de le prioriser et de l’implémenter. Ce pitch doit prendre la forme d’un document facile à lire. A cet effet, il peut embarquer les breadboards réalisés, les dessins au feutre, éventuellement des maquettes très sommaires. Il doit donner envie. Il est important de noter qu’il n’est pas l’équivalent d’une spécification, l’esprit de Shape Up étant de laisser un maximum de place aux équipes de réalisation pour décider de leur implémentation (tant sur le côté UI/UX que technique).

2) Gap : Betting / Cool down – 2 semaines

Au cours de cette phase, l’équipe produit identifie les prochains sujets (in the betting table) qui peuvent shaper dans le prochain cycle.

En parallèle, cette phase peut s’appeler : retour au calme pour l’équipe DEV pendant laquelle l’équipe peut respirer. Il peut être affecté à :se former, affiner le code, corriger les bugs, faire du support, des réunions…

3) Building – 6 semaines

Durant cette phase, l’équipe DEV entre en mode ininterrompu pour concevoir et développer la solution, en mettant en œuvre tous les moyens à sa disposition pour atteindre les objectifs identifiés dans la phase de mise en forme.

Le cycle de travail de six semaines de Shape Up donne aux équipes suffisamment de temps pour construire un produit du début à la fin. Puisque la possibilité de repousser une échéance ne fait pas partie de l’approche Shape Up, l’équipe doit travailler efficacement dans les délais impartis.

Comment suivre l’avancement ?

Plutôt qu’un diagramme de Gantt, un projet laissant place à l’inconnu peut se représenter par une colline : dans une première phase on gravit la colline quand on détermine la façon dont on va traiter le sujet, puis on la descend quand on réalise effectivement les tâches.

Basecamp étend cette analogie et ce visuel à son produit afin que les parties prenantes puissent obtenir des rapports d’état sans déranger l’équipe de projet.

On laisse l’équipe faire le tour du projet, lister les tâches concrètes, les regrouper en sujets, et commencer le projet. Chaque sujet est traité séparément, en fonction de sa to-do list. Le plus logique est de commencer par le plus dur, ou le moins clair dans le temps qu’il va falloir pour le réaliser : il s’agit de réduire les risques et les inconnues.

il y a donc trois niveaux, du plus global au plus spécifique Projet>Chantier>Sujet

Projet = Σ(chantiers); Chantier = Σ (sujets)

Dans l’exemple ci-dessus, le projet avait 3 « scopes » (des morceaux de travail), représentés par les 3 points sur la colline. Il est clair que l’équipe est toujours en train de déterminer l’expérience utilisateur des modifications d’application future, les événements récurrents mondiaux sont presque terminés et les permas par occurrence sont en cours. Le cercle en haut à gauche montre que le pari ne comprend que ces trois morceaux de travail (c’est-à-dire qu’il n’y a plus rien à faire une fois que ces 3 sont terminés).

Shape up vs Scrum, Quelles différences ?

Qu’est-ce qu’ils ont en commun?

Approche temporelle de la livraison “Time boxed”.
Le scope est flexible pendant le time-box. Cependant, il y a des limites à cette flexibilité. Tant qu’elle atteint l’objectif visé du “Bet” ou du Sprint, la flexibilité est autorisée.
Le “Refinement” est nécessaire pour être prêt à travailler.
L’équipe a un contrôle total sur la façon de diviser le travail en tâches et sur la façon dont le travail est effectué.

Quelles sont les différences?

Shape Up n’a pas de Product Backlog.
Shape Up suit un processus agile à double axes de découverte et de production.
Le “Refinement” Shape Up (Shaping) est effectué par des membres seniors en dehors de l’équipe et est remis à l’équipe qui l’exécutera. Dans Scrum, le “Refinement” est effectué par l’équipe qui effectuera le travail.
Shape Up est une boîte à outils, Scrum est un cadre de processus. Shape Up ne vous aidera pas à découvrir de meilleures façons de travailler ou de créer de la valeur.
Shape Up n’offre aucune approche normative pour évoluer avec de nombreuses équipes. Scrum non plus, mais au moins il existe de nombreux Scrum scaling frameworks disponibles. La façon dont vous faites fonctionner Shape Up sur des produits compliqués avec de nombreuses équipes n’est pas encore claire.

Conclusion

Du point de vue personnel, j’ai énormément apprécié travailler avec cette méthodologie : elle laisse plus de place à l’autonomie. Pour autant, elle est très complexe à bien appliquer.

Après le premier cycle avec Shape up, on peut voir clairement que l’équipe de développement a le plein pouvoir sur le scope du cycle de six semaines. Cela améliore l’auto-organisation à un autre niveau.

Puisque les équipes sont minuscules, cela signifie que la collaboration devient plus facile. Cela pourrait également être un problème pour les produits qui sont plus compliqués d’avoir plusieurs petites équipes.

On a beaucoup apprécié également les Cycles de “Cool down” à la fin de six semaines. Scrum peut être implacable et laisser peu d’espace pour respirer. Cela donne également l’opportunité aux membres de l’équipe de passer du temps sur les choses sur lesquelles ils aimeraient travailler et de les récompenser pour leurs efforts. Il offre un espace d’apprentissage, d’expérimentation, de réflexion et de pensée divergente.

A mon avis, les techniques de Shape up peuvent être combinées avec d’autres méthodologies de développement ou cadres de processus. J’ai proposé dèjà à notre CEO d’avoir notre propre méthodologie qui match avec nos besoins et le nos produits à la fois. Un mix Scrum – Shape up !