Scrum est une méthode Agile de développement fortement anglo-saxonne. Par certains aspects, je me demande si les processus de Scrum sont adaptés à notre culture. Dans cet article, je déconnecte complétement votre subjectivité en vous proposant une nouvelle méthode virtuelle : la méthode Resto. Alors à table, il est temps de changer votre vision sur Scrum.
Je me pose pas mal de questions sur Scrum.
Une grosse partie de la méthode Scrum a révolutionné ma vision sur le développement informatique. A un point tel que j’ai vraiment du mal avec les méthodes classiques de gestion de projet. D’un autre côté la maîtrise de Scrum demande des efforts qui vont au delà d’une simple formation.
Après quelques mois et un peu plus de recul, je commence à croire qu’il faudrait adapter et revoir culturellement la méthode avant de l’appliquer en France telle quelle. On peut reprocher à Scrum son cérémonial rigide. En effet malgré le peu de cérémonies, celles-ci sont des rendez-vous important pour que le processus fonctionne. La cérémonie qui fonctionnait le moins bien pour nous (chez Reuters) était la Sprint Review Meeting. Je demandais à l’équipe de lister les points qui s’étaient bien déroulés et les points à améliorer. Et finalement tout tournait autour de Scrum. Je sais que Scrum met en avant les points délicats dans la gestion d’un projet, que c’est l’un de ses effets. Cependant l’équipe n’arrivait pas à passer à l’étape suivant et à voir un intérêt à ces événements.
Alors réfléchissons à une autre méthode, la méthode RESTO (copyright Le Touilleur Express).
Les bases de cette méthode : cycle itératif court et limité dans le temps, une liste de fonctionnalités à implémenter, aucunes cérémonies, la capacité pour chaque développeur de prendre n’importe quand n’importe quel élément d’un tableau. Techniquement il vous faut des post-it, des marqueurs de couleur, un « paper board » et un peu d’organisation. Ensuite j’y ajoute des rôles tournants afin de pouvoir palier aux soucis venant de l’exterieur. Il me faudra un barman, des cuisiniers et des serveuses. A noter que si votre équipe est trop petite, vous pouvez cumuler les rôles.
Faire le Menu de votre RESTO
Tout d’abord la première étape est de regrouper dans un fichier Excel toutes les demandes de vos clients, les bugs et les demandes de changement. Pour chaque élément, vous allez identifier par une phrase comment le client testera la fonction.
Par exemple : « j’ouvre mon navigateur, je me connecte sur l’adresse de la prod, je vois une page d’authentification. Je mets mon login et mon mot de passe et je peux alors entrer dans l’application. Sur la page d’accueil je peux cocher une fonction ‘Se souvenir de moi’ et c’est tout »
Ce fichier doit être mis à jour en permanence selon les demandes des clients. C’est ce que j’appelle le Menu, et c’est ni plus ni moins un Product Backlog.
Les Serveurs auront pour mission durant la durée de la Mission de mettre à jour le contenu de ce fichier en y insérant les demandes des Clients. Les Cuisiniers seront chargés de donner le Prix à payer pour chaque élément, en respectant mes explications sur ce qu’est une Estimation dans le cadre du développement d’un logiciel.
Un peu de réunionite
Ensuite je verrai bien une première réunion à laquelle j’inviterai un client avec l’équipe. L’idée est qu’avant de commencer à développer, le client est présent afin d’expliquer en détail et de clarifier les points qui seraient mal expliqué. Appelons cela la Commande. Une fois la Commande passée aux Serveurs, le Client doit attendre tranquillement que son plat soit préparé.
Le Barman : mister Cocktail
Le Barman est là pour le faire patienter. Il peut venir l’aider ponctuellement afin de l’aider à corriger un problème urgent. C’est la personne en charge de la production en quelques sortes. Il est disponible pour travailler avec le Client pendant que le reste de l’équipe bosse. L’idée par rapport à Scrum serait d’avoir une personne disponible et allouée afin de traiter les problèmes du Client en dehors du cycle de production. En fait le Barman se charge de faire boire le client pour le faire patienter. Je piquie cette idée à ce que nous faisons actuellement sur la plateforme de Prime Brokerage : l’un de nous est en charge de la production pour 5 jours et durant cette durée, ne participe pas aux développements de l’équipe.
La batterie de Cuisine
Les Cuisiniers ne voient pas le client, ce qui est peut-être une faiblesse par rapport à Scrum. D’un autre côté ils peuvent travailler en permanence sans devoir être présent à des réunions, ou être obligé de participer à des cérémonies comme pour Scrum. J’imagine ainsi accélérer la productivité en n’impliquant qu’une partie de l’équipe dans la relation client< ->équipe.
Il est important de ne rien faire une fois par semaine
Enfin j’y ajoute un concept qui vient de mon expérience chez Reuters : le vendredi c’est ravioli.
Derrière cette phrase magique, l’idée est de dire à toute l’équipe qu’une journée de la semaine est consacrée à faire autre chose que le boulot habituel. Durant cette journée, chacun fait ce qu’il veut tant que cela reste en rapport avec son travail. Je reprends une idée appliquée chez Google.
Aurélien mon petit-frère a travaillé 2 ans chez Google en Irlande. Il m’expliquait ainsi qu’une partie de leur évaluation et donc de leur bonus est calculé sur leurs initiatives pour la communauté. Mon frère a ainsi monté un groupe de rock/folk et il a participé à une œuvre caritative, en plus de son travail, ce qui lui a valu des points en retour par son management. Évidemment cela ne rapporte rien, si ce n’est un esprit, une ambiance et quelque chose que les autres compagnies n’ont pas.
Je pense que la personne qui a l’idée d’un nouvel outil pour améliorer la productivité, ou qui a l’idée d’apporter un panier de basket pour que l’équipe se détende, devrait être récompensé. Attention je ne vois pas un système anglo-saxon basé sur la performance, plutôt un système bien français basé sur la bon humeur.
Nous pourrions imaginer qu’à la fin de chaque Mission, tout le monde donne un point à une personne de son choix. Celui qui a le plus de point est alors proclamé Grand Manitou, et il peut alors affecter une tâche rébarbative dont il a la charge à un de ses collègues. Le Grand Manitou a le droit de refuser une Commande d’un client pour la prochaine Mission. A chaque fin de Mission on élit alors un nouveau Grand Manitou et ainsi de suite.
Oui cela vous choque… pourtant j’ai entendu cette semaine le cas d’un grand cabinet de consultant qui a offert un iPhone à deux de ses collaborateurs les plus méritants, qui, par leurs contributions sur le blog de l’entreprise, ont contribué à améliorer la visibilité et la réputation de cette entreprise.
Prenons ensuite une spécificité franco-française que nos voisins Belges ou Suisses nous envient (peut-être) c’est la fin d’une mission. Après 2 semaines de développement, le dernier vendredi de ces 2 semaines sera une journée Ravioli, avec l’obligation de fêter la fin de la Mission. Pour cela vous pouvez apporter des croissants et faire un petit-déjeuner, vous pouvez faire un restaurant le midi ou même organiser un apéritif après le travail dans un bar à côté de votre travail… L’objectif est de FETER la fin de la Mission.
Dans le bâtiment lorsqu’une équipe termine un chantier, les ouvriers, l’architecte et les conducteurs de travaux se retrouvent afin de faire un grand repas pour fêter la fin du chantier. Je pense que nous devrions faire la même chose et formaliser cela dans la méthode RESTO.
Voilà un billet bien décalé qui nous sort de la morosité ambiante, qui nous permet d’envisager un processus adapté à nos habitudes, et qui je l’espère, vous donnera de l’inspiration pour vous épanouir et vous faire plaisir en travaillant. Je sais qu’au final derrière ce que je viens d’expliquer, ça sent le Scrum.
Bonnes fêtes.
0 no like
Un billet ‘bien décalé’ comme on les aime 🙂
J’ajouterais volontiers quelques ingrédients à la méthode RESTO:
– lors de la composition du menu, n’oubliez pas de demander au client dans quel ordre il veut qu’on lui serve les plats. Si vous lui collez les profiteroles avant la ratatouille, ça va être moche, c’est l’indigestion assurée (il faut prioriser!)
– Mister Cocktail c’est une très bonne idée, mais bon, ce serait tout de même sympa que tout le monde ait droit aux jolies filles du market qui viennent remonter leurs problèmes de prod. Chacun son tour, on change de Tom Cruise à chaque itération (il faut motiver!)
– les cuisiniers, là aussi, ils vont finir par être frustrés de ne pas participer aux réunions avec le client. Passer ses journées le nez dans les casseroles, ça finit par démotiver. Chacun son tour les planning pokers!
– dites donc les cuisiniers, ce serait tout de même pas mal de tester vos plats avant de les envoyer en salle… non?
– arrêtons les plats à moitié préparés, c’est du gâchis. Et ne préparez plus les plats avant qu’un client ne les commande, la moitié va terminer à la poubelle!
Par rapport à mes expériences projet, moi je trouve ca plutôt très pragmatique comme méthode.
(ah dommage qu’une saleté de crève m’ai laissé au lit, j’aurais bien discuté de cette méthode au javacamp2 .. on verra pour le 3).
Je la retravaillerai bien dans un article de mon blog (avec un schéma sans doute)