En startup, la destinée de l’entreprise et son/ses produit(s) sont intimement liés. L’application des méthodes agiles fondées sur une vision produit permet d’obtenir des cycles courts, des livraisons régulières et des retours d’insights fréquents qui sont nécessaires au bon développement de chaque projet.

Afin de mettre en place de l’agilité, différents frameworks existent (SCRUM, KANBAN, XP, Lean development etc.). Ils peuvent se combiner pour trouver les méthodes qui s’adaptent le mieux au développement produit que vous souhaitez mettre en place.

Chaque start-up ayant ses méthodes et outils, j’ai donc décidé dans cet article de partager mon retour d’expérience de ce que nous avons mis en place chez Partoo.

Comment organiser son équipe en feature teams ?

L’objectif de l’équipe est d’aborder chaque problème rencontré afin de le transformer en opportunité, des équipes sont organisées (généralement de 3 à 9 personnes) afin de rassembler toutes les compétences nécessaires pour mener à bien le projet. Ces équipes sont généralement appelées feature teams ou squads (modèle Spotify). Chez Partoo, nous avons décidé d’appliquer la culture de Rick & Morty à l’équipe tech en renommant nos 5 feature teams par l’identité d’un personnage de la série (Rick, Morty, Bird Person, Jaguar et Summer). Cette étape vise à améliorer la cohésion d’équipe et le sentiment d’appartenance à un groupe.

Les équipes sont autonomes et entièrement responsables de leurs réalisations. Elles se composent dans la plupart des cas d’un Product Owner, d’un SCRUM Master et de développeurs.

Product Owner (PO)

Il est le responsable de la définition et de la conception d’un produit. Son role est de faire le lien entre la partie métier et la partie technique du projet. Il est l’interface entre l’utilisateur, le Scrum Master et les équipes chargées du développement.

Beaucoup de startups font une différenciation entre Product Owner et Product Manager mais dans la culture produit, le PO et le PM sont la même personne et effectuent le même travail.

SCRUM Master (SM):

Il a un rôle de coach et son objectif est de faire sortir le meilleur de la part de chaque membre de l’équipe de développement. Le role de SCRUM Master peut être un role tournant comme c’est le cas chez Partoo.

Développeurs :

On ne les présentent plus, ils sont une ressource rare que les startups s’arrachent. Le lead developer a des compétences managériales et techniques. En effet, il doit être capable de former ses équipes, d’encadrer et de motiver les développeurs qu’il manage. En tant que leader, il définit le rythme du développement du projet. Il garantit son bon déroulement grâce à ses solides compétences techniques, et il a une forte proximité métier avec ses équipes.

A titre d’exemple, chez Partoo, nos features teams se composent d’un Product Manager, d’un Lead Developer et de deux à trois développeurs.

SCRUM – KANBAN un combo qui fonctionne

SCRUM est un cadre méthodologique simple, pragmatique, transparent et empirique. C’est le cadre le plus utilisé parmi les méthodes agiles existantes. KANBAN est un framework permettant de montrer en toute transparence le travail effectué et accentue la communication en temps réel. Mixer ces deux frameworks permet de faciliter le travail d’équipe dans l’objectif d’être toujours plus efficace.

La méthode Kanban, un processus évolutif

Introduite chez Toyota dans les années 50, la méthode Kanban visait à améliorer la production via des processus évolutifs. Tout le fonctionnement est basé sur les étiquettes, qui sont destinées à optimiser la production et la collaboration entre les équipes. Une étiquette (Kanban, en japonais) voit le jour dès lors qu’une commande est passée. Elle indique une tâche à réaliser (une fonctionnalité à développer sur un back-office par exemple). Les tâches sont réparties dans un tableau en fonction de leur état et peuvent passer d’une colonne à l’autre au fur et à mesure du processus : par exemple à l’étude, à faire, en cours, fait. Chaque membre de l’équipe sait ainsi ce qu’il a à faire et où en est le travail des autres.

Outre une meilleure communication, cette technique permet de visualiser de manière claire l’ensemble de la chaîne de production et l’avancement des tâches, ce qui permet de repérer facilement les blocages et les urgences.

Des outils tels que Trello, JIRA, Monday etc. permettent d’appliquer cette méthodologie aux projets modernes. Dans le cadre de Partoo, nous avons suivi pendant quelques années nos sprints sur Trello mais face au grossissement de l’équipe technique, nous avons opté pour JIRA afin d’améliorer nos performances.

Create A Board | Getting Started with Trello
Kanban Trello

La méthode SCRUM : Comment découper une fonctionnalité ?

La gestion d’un projet en suivant la méthodologie Scrum se fait en mode itératif en effectuant des sprints de quelques semaines. Le découpage d’une fonctionnalité est une étape essentielle à la réussite d’un projet. Il permet de livrer plus rapidement des fonctionnalités tout en limitant le risque technique. En effet, il est plus simple de tester de petites fonctionnalités que de gros ensembles.

Lorsque nous abordons le découpage des fonctionnalités, les termes « EPIC », « User Story » et « Tasks » reviennent régulièrement. Ils recouvrent des concepts différents, liés aux spécifications fonctionnelles, et donc particulièrement structurants pour le projet.

  • EPIC
    Selon Mike Cohn, inventeur de l’EPIC agile, celui-ci représente une brique fonctionnelle de haut niveau. Un EPIC est une fonctionnalité conséquente. Un découpage en user stories est nécessaire car il ne peut être développé en un seul sprint (plus de détails sur ce qu’est un Sprint dans la partie suivante).
  • User Story
    Rédigée par le Product Owner, son objectif est de spécifier le développement d’une fonctionnalité afin d’apporter de la valeur au produit.

    Différents formats existent mais le plus commun est celui-ci :

    En tant que <qui>, je veux <quoi> afin de <pourquoi>

    Le qui représente l’utilisateur concerné par le produit (il n’est pas forcément l’utilisateur final). Le quoi représente le besoin exprimé par l’utilisateur. Enfin, le pourquoi représente la valeur de la fonctionnalité pour l’utilisateur.
  • Task et Sub-Task
    Une task représente un ensemble de travaux d’ingénierie qui ne sont pas directement liés à une à story mais nécessaires à la réalisation de l’EPIC.

    Les sub-tasks, quant à elles, représentent les tâches de développement nécessaires à la réalisation d’une User Story. Généralement le temps de développement d’une Sub-Task n’excède pas une journée.
EPIC_Split
Découpage d’un EPIC

Un quotidien rythmé par les rituels

Chez Partoo comme dans de nombreuses startups, de nombreux rituels indispensables à la conception de nouvelles fonctionnalités rythment nos semaines :

  • Sprint : généralement chiffré à deux semaines. Le temps des sprints est à définir par la startup afin de garantir ses objectifs. Chez Partoo, nous avons trouvé notre rythme en fonctionnant avec des sprints d’une semaine.
  • Stand-up meeting (coffee meeting) : réalisé debout afin de garder les personnes concentrées. Il permet de communiquer sur le travail effectué la veille et sur le travail prévu du jour. C’est un rendez-vous quotidien indispensable pour la communication et la rectification des sprints en cas de dérive. C’est un parti pris qui exige beaucoup de rigueur et d’efficacité de la part de chacune des feature teams.
  • Retrospective : se fait après chaque sprint afin de faire un point sur les succès du sprint précédent mais également de faire remonter les axes d’améliorations dans l’objectif de prendre des actions pour les sprints futurs. Assigner et dater les actions permet de faciliter la validation de celles-ci.
  • Sprint planning : se fait avant de démarrer le sprint de manière à imaginer ce qu’il sera possible d’intégrer (en terme de user stories et tasks) pendant la durée de celui-ci. Chez Partoo nous utilisons la méthode poker planning qui s’effectue en utilisant la suite de Fibonacci et permet de donner des estimations “à la marge” car des estimations précises sont difficilement quantifiables. L’avantage principal du poker planning est de permettre à tous de s’exprimer librement. L’estimation est meilleure car la validation se fait par tous les membres de la feature team qui ont des niveaux d’expérience et d’expertise différents.
Poker Planning
  • Backlog refinement (Grooming) : se fait la semaine précédent chaque nouveau sprint. L’objectif de cette cérémonie est de préparer le prochain sprint planning en faisant une revue des développements prévus (User stories et Tasks) et en définissant la stratégie technique qui sera mise en place pour concevoir ceux-ci.
  • Demo : se fait une fois le sprint terminé afin de communiquer sur le travail effectué.
Retrospective_Sprint
Cycle

* * * * * * * * *

Si répondre aux besoins des utilisateurs est nécessaire lors de la conception produit, ce travail n’en reste pas moins difficile. Implémenter SCRUM et KANBAN dans votre startup vous permettra de gagner en efficacité et d’appréhender plus légèrement les problèmes.