6 conseils pour mettre en place la méthode Scrum dans votre startup

J’en ai parlé déjà dans un article la semaine dernière, je vous conseille la lecture du blog du très bon Guillaume Potier, CTO de Balloon, et qui traite son quotidien sur I’m CTO, Bitch!.

Il se trouve qu’avec Guillaume, nous avons eu déjà pas mal de discussions sur les bonnes méthodes lean, moi plutôt sur les approches commerciales, lui sur la gestion de ses équipes de développeurs. Avec la même impérieuse nécessité : avancer le plus vite possible, avec des ressources limitées, parfois dans le brouillard et en tout cas en devant innover sans cesse…

Scrum quoi ?

 

 

Pour le business, nous avons une méthode « lean startup« , c’est le customer development. Côté équipes techniques, la méthode qui a le vent en poupe, c’est Scrum. Il n’en fallait pas plus pour nous donner envie, Guillaume et moi, de faire un premier post collaboratif, sur le sujet. Il devrait en préfigurer d’autres, qui seront au croisement des aspects business, management, et techniques, tantôt ici, tantôt de son côté. Parce qu’une startup web, c’est un tout, et que les équipes doivent avancer ensemble, à un rythme d’enfer…

Je suis donc très heureux de laisser pour les lignes suivantes la parole à Guillaume, qui nous explique ce que la méthode Scrum peut vous apporter et comment la mettre en place !

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Merci Guilhem et donc bonjour à toutes et tous ! J’ai en effet mis en place Scrum il y a quelques mois chez Balloon, et j’en suis vraiment satisfait. Voici donc 6 conseils pratiques pour mettre efficacement et rapidement en place du Scrum dans ses développement et en tirer profit :

  • Des post-it et un stylo suffisent: l’objectif de Scrum est d’améliorer la productivité d’une équipe, de limiter les temps morts et éviter les couacs projet.
    Fidèle à ce principe jusque dans sa mise en oeuvre, vous pouvez en 20 minutes chrono entamer votre premier Scrum: sur un pan de mur disponible, matérialisez 3 colonnes, avec de gauche à droite: tâches programmées en attente, tâches en cours de développement et tâches terminées.
    Vous avez ensuite besoin d’un gros feutre et d’un bon bloc de post-it. Découpez alors votre projet en tâches unitaires et notez-les sur ces derniers. Placez-les enfin dans la colonne de gauche par priorité décroissante. Vos développeurs ont alors une excellente vision de ce qu’ils ont à faire, et vous avez une excellente vision quotidienne de l’avancement des développements, en fonction de la quantité de post-it qui auront transité de gauche à droite 😉
  • Estimez les tâches et observez la vélocité de votre équipe: la première étape (organisationnelle) du scrum étant mise en place, vous pouvez désormais ajouter la gestion du temps de travail et de sa vitesse d’avancement en estimant la difficulté des différentes tâches écrites sur vos post-it.
    Deux méthodes pour cela : un système de points relatifs (cette tâche vaut 4 points donc celle-ci en comparaison en vaut 8 car deux fois plus complexe/longue, tandis que celle-là en vaut seulement 2) ou un système de temps (heures,/jours). Personnellement, je préfère la seconde méthode qui me permet de mieux estimer en heures ce que représente chaque tâche et qui ne nécessite pas un ou deux scrums de rodage pour connaitre le nombre de points que votre équipe est capable d’abattre chaque semaine.
    Désormais, au jour le jour vous avez une vision de l’avance ou du retard que votre équipe ainsi que chaque développeur a sur le projet: si à la fin de la journée vous avez passé 4 post-it valant un total 9h de travail dans la colonne de droite, vous avez raisonnablement pris quelques heures d’avance sur la journée de demain! A contrario, vous n’avez abattu aujourd’hui qu’une seule grosse tâche de 4h, vous avez donc pris du retard..
  • Ne pas toucher son scrum une fois lancé: ça fait partie des règles du jeu qui garantissent l’efficacité de cette méthode dans la réalisation et le maintien des délais. Au quotidien on est confronté à des demandes de la part de ses clients/users ou même ses propres commerciaux/associés. Ces dernières ne peuvent pas venir perturber le Scrum en cours, et devront trouver leur place dans le Scrum suivant, c’est la règle!
  • Effectuer des cycles très courts (une à deux semaines max): ce point découle naturellement des deux précédents. Plus vos cycles seront courts, moindre sera votre erreur de prévision, et plus rapidement vous pourrez itérer et intégrer les premiers retours clients dans les cycles à venir.
    Il est tout à fait possible d’effectuer des Scrums de Scrum. Chez Balloon par exemple, nous découpons nos cycles de releases en périodes de 2 mois: définition des features à venir, des améliorations à effectuer et du scope de développement pour les équipes qui ne sont pas en support (car il nous faut quand même bien être réactif pour certains clients / certaines demandes..).
    Ensuite, on tronçonne tout ça en Scrums d’une semaine. Ce n’est certainement pas un remède miracle, mais dans notre cas, cela fonctionne bien!
  • Préserver l’environnement de développement: il est nécessaire si vous voulez tenir le chiffrage estimé en début de cycle qu’une personne limite les perturbations extérieures des équipes de développement (téléphone, demandes commerciales, etc..).
    Si vous tablez sur 6h de développement intensif par jour, à vous de garantir à vos équipes 6h de sérénité et de calme pour qu’elles s’y mettent à fond! N’hypothéquez pas la pause déjeuner qui bien souvent permet de souffler et de partager autour d’un repas-détente les soucis et accomplissement de chacun sur son Scrum.
    Enfin, n’oubliez pas d’aller boire un verre tous ensemble au moins une fois par semaine pour se détendre et se féliciter sous peine de voir tout le monde au bout du rouleau après 4 cycles 😉
  • Esprit d’équipe et communication: régulièrement, faites le point sur les sprints quotidiens et sur chaque cycle. Communiquez avec vos développeurs, faites-leur valider les estimations de durées en début de cycle, ils ont leur mot à dire.
    Ne soyez pas un contremaître odieux qui essore jusqu’à la dernière goutte ce qu’il peut! Il vaut mieux prévoir un peu plus large plutôt que d’avoir une équipe à la traine tirant la langue et courant éperdument  après les deadlines. Assignez les tâches adéquates aux développeurs adéquats.
    Laissez-les ensuite s’échanger des tâches si l’un est en avance et l’autre en retard, ou s’il s’agit d’une question d’appétence personnelle.

Scrum est un outil simple mais redoutable d’efficacité lorsqu’il est bien utilisé et bien vécu dans sa startup en modèle Lean. Les cadences seront bien plus dynamiques et productives, on ne ressent quasiment jamais de flottement. Vous aurez par la même occasion moins de chances d’exploser vos délais et plus de latitude pour pivoter ou ré-orienter vos développements. Réciproquement, ne pilotez pas cela mécaniquement, discutez peu mais efficacement et régulièrement (un point de 5 minutes tous les jours avant ou après la journée suffit), récompensez et célébrez à la fin de chaque cycle, faite une petite analyse et améliorez les cycles suivants!

Enfin, pour aller plus loin avec de plus grosses équipes, utilisez une petite webApp qui va bien pour piloter vos Scrums, Scrumwise par exemple :)

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[A partir de là, c’est re-Guilhem qui parle]
Pour aller plus loin, je pense que l’on peut pousser l’esprit du Scrum à d’autres tâches que le développement du code. Dans ma nouvelle startup, et alors que nous ne sommes encore que 3, j’applique des « rythmes », ou « routines », proche de Scrum, évidemment de manière adaptée, et ce même pour les tâches commerciales.

Par exemple, la semaine débute par un tour de table de tout ce que chacun a fait, et ce qu’il compte faire dans la semaine. Cela oblige à plus de transparence et surtout à une bonne communication entre les équipes. Au-delà de ce point, cela me permet, à moi qui fait office de chef d’orchestre pour bien organiser tout le monde, de voir précisément là où l’on dévisse ou de reprioriser certaines tâches.

Toutes les réunions font l’objet d’un compte-rendu, histoire que l’on puisse suivre au fur et à mesure l’avancée de chacun et surtout mettre un peu d’ordre dans une vie de la startup plutôt floue sur tout un tas d’aspect.

Enfin, j’ai instauré un « plan mensuel », qui est la liste en 6 chantiers maximum, des objectifs du mois. Chaque chantier est constitué de 6 objectifs très concrets, que l’on doit s’efforcer de remplir avant la fin du mois, de manière presque mono-maniaque. Chacun dans l’équipe l’a sur son bureau ou sous son nez, et l’idée est de ne se focaliser que sur ces points, et de ne pas passer 1 minute sur autre chose (qui n’y figurerait pas).

Ce que je dois encore améliorer pour me rapprocher du Scrum (en tout cas pour tester quelques petits trucs) :

  • mettre à l’avance des allocations de temps sur les tâches
  • parfaire le système pour lorsque l’on sera 6, 10, 20 et plus seulement 3
  • utiliser la « frise chronologique » aimantée que j’ai peinte ce we au bureau, pour représenter ainsi en temps réel l’avancée des différents objectifs de notre plan mensuel

Bref, y’a encore de quoi faire !

Et en attendant, n’hésitez pas à partager vos propres réflexions ou expériences en la matière dans les commentaires, et bien sûr aller faire un lien chez Guillaume !

13

  1. Bonjour,
    Je suis ravi de voir que les bénéfices de Scrum soient arrivés jusqu’à vos oreilles.
    Faisant moi-même de la gestion de projet au moyen de méthodes agiles comme Scrum et Kanban depuis plusieurs années, je me permets d’apporter quelques précisions, et si vous le voulez bien, quelques recommandations.
    Scrum est un processus itératif dont les itérations d’une durée de 1 à 4 semaine sont appelées Sprints. Théoriquement, les fonctionnalités développées en cours de sprint ont atteint un niveau de qualité suffisante pour être déployées en production.
    Ensuite, la méthode Scrum est très peu rigide, mais comme elle est basée sur le bon sens, il est préférable d’essayer de l’appliquer dans son ensemble avant de la customiser. Ne passez donc pas à côté de ce que peuvent vous apporter les cinq réunions prescrites par la méthode, celles-ci ont pour but d’avoir une communication plus efficace et surtout de responsabiliser tous les membres de l’équipe.
    Ces réunions sont :
    – le daily meeting : tous les jours, pour une durée de 15 min, à heure fixe, toute l’équipe se réunit devant le tableau des tâches. C’est le moment de synchroniser les efforts de chacun.
    – le planning meeting : permet d’impliquer l’ensemble de l’équipe dans une vision à moyen terme sur le projet en développement. La liste des fonctionnalités doit impérativement être priorisée pour permettre à l’équipe technique de développer en premier ce qui apporte le plus de valeur. C’est également le moment où l’équipe technique estime les fonctionnalités à développer avec comme unité des points d’efforts. Pour rendre dynamique cette première phase d’estimation, on utilise généralement des cartes de planning poker.
    – le sprint planning meeting : une fois les fonctionnalités triées selon les priorités du métier et estimées par l’équipe technique, cette dernière peut s’engager sur un périmètre à réaliser au cours du prochain sprint. Ce périmètre doit être de l’ordre du faisable pour éviter le sentiment d’échec continuel.

    Les deux dernières réunions suivent également le rythme du sprint. Elles sont les moteurs de l’amélioration continue, à la fois pour le produit développé, mais également pour le process de développement.
    – la review de sprint est un atelier de travail où l’équipe fait la démo de ce qu’elle a réalisé au cours du sprint et invite le public (Métier, super-utilisateurs …) à faire des commentaires et proposer des améliorations qui pourront être prises en compte dans l’itération suivante.
    – la rétrospective permet de se retrouver entre membres de l’équipe pour discuter de l’amélioration du processus de développement. C’est un moment crucial où se joue la productivité accrue qui est « vendue » dans Scrum. Si l’on ne se pose pas pour analyser la manière dont on travaille, on ne peut s’améliorer.

    Je me rends compte que mon commentaire prend des allures de cours magistral, et j’en suis un peu désolé.Néanmoins, je ne voudrais pas finir ce commentaire sans vous recommander d’appliquer Scrum en vous nourrissant des valeurs et de l’état d’esprit qui vont avec.
    Avec Scrum, vous devez faire le pari d’abandonner le modèle Command&Control de la gestion de projet classique, en favorisant la collaboration et la responsabilisation de tous les acteurs de votre projet, en les faisant adhérer à votre cause en partageant avec eux votre vision.
    Perso, il n’y a pas une semaine sans que je relise les valeurs inscrites dans l’agile manifesto, et je terminerai donc en vous invitant à en prendre connaissance.

    • Pour compléter ce cours magistral 😉 une intro à Scrum en 10 minutes extrèmement bien faite. Un tout petit peu de pub à la fin pour un produit de pilotage de sprint que je n’ai pas testé :

      bit.ly/zpPYu6

  2. +1 pour les différentes réunions, c’est aussi le point que je voulais évoquer. Et +1 aussi pour l’Agile Manifesto.

    Pour ma part je ne suis pas pour une méthode en particulier (Scrum ou ses amies), surtout dans mon cadre actuel, mais plus pour la mise en avant des valeurs de l’Agile au sein d’une équipe.

  3. Bonjour,

    Je me joins à Yann_G, les remarques et précisions qu’il vous apporte sont essentielles!

    Il est très important de respecter le rythme de votre sprint et de réaliser l’ensemble des réunions définies par le framework (notamment la rétrospective qui est souvent le parent pauvre de Scrum).

    En fait actuellement vous faites du Scrum…But, c’est un peu le Canada Dry de Scrum 😉 Vous pouvez faire ce petit test pour vous en assurer http://antoine.vernois.net/scrumbut/?page=test&lang=fr et vous référez au site de la Scrum Alliance pour la définition officielle http://www.scrum.org/scrumbut

    Je vous encourage à lire l’excellent livre de Claude Aubry sur Scrum http://www.aubryconseil.com/pages/Livre-Scrum et d’en profiter pour faire un tour sur son blog et lire ses nombres billets sur le sujet

  4. L’application web Trello (gratuite) est aussi un bon support pour le sprint planning.

  5. Pierre Merlin

    12 mars 2012 at 23:24

    C’est toujours très enrichissant de voir l’application des méthodes dans le feu de l’action.

    Merci pour vos retour d’expérience.

    À propos des différents cycles et leurs durées je croyais que le scrum est la plus petite « Time-box » et qu’elle faisait une journée. Tandis que l’ensemble de 1 à 2 semaine constitue un « sprint ». Pourquoi n’utilisez vous pas cette terminologie ? Cela représente-t’il des différences concrètes ?

    • Bein moi je vais chez cupcakes and co. La bouuiqte fait reaver et ya pleins de choix.Apre8s c’est sfbr que e7a vaut pas ceux de New-York mais bon

  6. Pierre Merlin

    12 mars 2012 at 23:28

    Je n’avais pas vu le autres commentaires… Le lien est sans doute inopportun. Désolé.

  7. Je vous recommande sur le même principe une application du nom de CollabSpot http://www.collabspot.com/ édité par un Français WeMakeProjects.
    A noter l’énorme avantage c’est que l’application est complètement intégrée à Google Apps.

  8. Bonsoir,

    Je suis convaincu de cette méthodologie pour moi-même l’avoir utilisée dans le développement de mes projets.

    Cependant, aujourd’hui, en méthode Agile, je suis plutôt partisan pour ajouter Kanban et le concept même de la Lean Startup. Comment démarrer une entreprise sans prendre des risques inconsidérés dans le but de valider une idée business.

    J’en ai réalisé la chronique pour ceux que ça intéresserait : http://www.roadtoentrepreneur.com/the-lean-startup-methodologie-creer-business-succes

    Plus vite vous validez une idée, plus vite vous avancez vers la concrétisation et la rentabilité.

    Jérémy Goldyn

  9. Merci pour l’information. C’est précisément ce que je recherchais pour améliorer encore davantage nos process.

  10. +1 pour l’association du Lean Startup et de SCRUM

  11. Si vous cherchez un outil de gestion de projet Agile :

    1 – L’outil gratuit Ice Scrum, dont Claude Aubry (auteur d’un très bon bouquin sur scrum) est le Product Owner, peut également constituer une bonne alternative aux outils cités.

    2 – Le plugin Greenhopper permet aussi de faire du Scrum et/ou du Kanban dans Jira.

Les commentaires sont fermés.

© 2024 Création d'entreprise & startups !

Gulihem BertholetUp ↑