(ancien article de 2012 revu)
N’en avez vous jamais eu assez de la manière dont sont gérées nos chères entreprises ? Moi, si…
A part exception, j’ai toujours eu le sentiment de servir les intérêts d’un seul ou de quelques uns seulement. Est ce normal ? Oui me répondront certains, car ils sont persuadés que seule une minorité dispose de capacité de leadership. Je dis que c’est faux ! Il existe d’autres moyens de créer une entreprise, de la diriger et que chaque élément de ce tout, soit récompensé à sa juste valeur.
Et pourtant je vais être actionnaire unique de la structure que je créée (une EURL pour être exact)… Suis -je stupide au point de faire ce que je dis qu’il ne faut pas faire ? Que neni. Pour imposer une nouvelle façon de faire, le seul moyen est de pouvoir le décider.
Si on laisse une entreprise s’organiser elle-même, sans aucun contrôle, je suis persuadé que l’on retombe bien vite dans les travers d’une organisation hiérarchique (chef, sous-chef, sous-sous-chef, …, et puis finalement ceux qui produisent) pour satisfaire la soif de pouvoir de certains.
C’est pour cela que je conserverai le pouvoir de décision mais plus comme le capitaine d’un navire qui tiens la barre mais ne peux rien faire sans ces matelots.
Pour le reste, je vais m’inspirer de ce que j’ai pu vivre sur l’un de mes derniers projets.
Connaissez vous les méthodes agiles ? Non ? Alors laissez vous vous éclairer sur le sujet.
Pour la définition de ce type de méthodes, allez faire un tour sur la page wikipedia qui est assez bien concise mais précise. Contrairement à ce que laisse penser la plupart des définitions que vous trouverez, elles ne se limitent pas aux projets informatiques bien au contraire.
Les pratiques agiles se doivent de répondre au manifeste agile qui, à mon sens, est plein de bon sens…
Scrum, celle que je connais le mieux, est un cadre de fonctionnement d’un projet qui peut-être utilisé dans tout type de projet (y compris ce projet de création d’entreprise qui vous tiens à cœur !).
Je vais essayer de vous expliquer simplement le fonctionnement et si cela vous semble intéressant, je vous enjoins à plus vous documenter, éventuellement à vous former, puis ensuite à appliquer cette méthode dans vos entreprises. Le bénéfice que chacun en retirera sera incroyable.
L’organisation : dans Scrum (mêlée au rugby), on va raccourcir les canaux de communication et le nombre d’intermédiaires. Ainsi, les intervenants d’un projet seront, une équipe, un ScrumMaster (le maître de mêlée) et un ProductOwner (le responsable du produit) qui peut être le client lui même lorsque l’on mène un projet pour un client.
L’équipe est composée des personnes qui vont mener à bien le projet (cela peut être les associés ou les salariés d’une entreprise par exemple pour une création d’entreprise).
Le rôle de ScrumMaster peut être tenu par une personne à temps plein ou par un membre de l’équipe si un temps plein n’est pas justifié. Son travail consiste à protéger les membres de l’équipe des perturbations extérieures comme les appels du client, la pression hiérarchique (si elle existe …), les autres équipes… mais aussi et surtout à traiter les « impediments » qui sont les problèmes qui ralentissent ou bloquent le travail de l’équipe (l’absence d’une machine à café à l’étage par exemple… ou un réseau informatique très lent).
Le « ProductOwner » gère son produit, définit les besoins sous la forme de users-stories, réponds aux questions de l’équipe et valide (accepte) le travail réalisé par l’équipe lors de chaque sprint (cf ci-dessous).
Quand on démarre seul une activité, il est difficile de mettre en place cette méthode. Mais on peut commencer au moins à en appliquer les principes. Dans notre cas, le responsable produit…. c’est moi !
Le backlog de produit : Il s’agit d’une liste des différentes « choses » à faire (des fonctionnalités voulues pour un projet informatique par exemple) comme « rédiger mes conditions générales de ventes » ou « préparer la formation LibreOffice ». Ces items, les user-stories, sont ensuite priorisés par le responsable de produit. Une estimation de la complexité/temps nécessaire à leur réalisation sera faite par l’équipe (et oui, ce sont les gens qui font qui estiment le temps dont ils auront besoin et pas un manager quelconque qui ne connaît rien du sujet à part le coût jour/homme !).
Le sprint : il s’agit d’un laps de temps plutôt court (2 à 4 semaines tout au plus) au cours duquel on va réaliser un certain nombre de user-stories. A la fin de chaque sprint, le produit sera « livrable » au responsable produit ou au client. Les sprints se succèdent pour construire au bout du compte le produit final.
Les « cérémonies » Scrum : C’est le cadre de réunions qui donne corps à cette méthode et que l’on doit absolument respecter. Le reste, c’est l’auto-organisation de l’équipe qui fera sont œuvre.
L’ « estimation meeting » que l’on peut placer en début de sprint, est l’occasion pour l’équipe d’estimer les users-stories qui viennent d’être ajoutées par le responsable produit dans son backlog (ce qui permet une flexibilité du besoin du client). Si l’équipe n’arrive pas à estimer une « storie » malgré les explications du responsable de produit et l’intervention des différents membres de l’équipe, alors celle-ci doit être retravaillée afin qu’elle puisse être estimée (donc l’équipe à le pouvoir de rejeter une tâche mal définie !).
Le « sprint planning » est placé en début de sprint. Elle va permettre de choisir les items du backlog de produit que l’on va injecter dans le backlog de sprint et réaliser au cours de celui-ci. En règles général, on prend dans l’ordre des priorités jusqu’à atteindre la capacité de l’équipe (ceci est flou au premier sprint mais s’affine au fur et à mesure).
La « daily scrum » est une réunion quotidienne de 15 minutes que l’équipe tiens debout le matin et chaque membre se pose seulement trois questions :
- qu’ai-je fait hier ?
- que vais-je faire aujourd’hui ?
- Ai-je rencontré un problème ?
On ne doit surtout pas s’étendre sur les problèmes et les gérer ensuite. Attention aux dérives car cela ne doit pas être prétexte au lynchage de ceux qui ont des problèmes mais un lieu ou l’on détecte ceux-ci pour les régler ensemble ensuite. C’est l’équipe qui est mise à l’honneur dans Scrum et l’on ne doit jamais l’oublier (en ne mettant pas d’objectifs individuels qui risque de casser l’entraide au sein de l’équipe par exemple).
Le « demo meeting » va permettre à chaque membre de l’équipe de présenter son travail au responsable de produit qui devra l’accepter ou le rejeter en fonction des critères d’acceptances définis au préalable. Une storie acceptée sera « done » et retirée du backlog de sprint. Une storie rejetée sera remise dans le backlog de sprint afin d’être reprise et terminée le sprint suivant.
La rétrospective est peut-être la plus importante réunion. On va tous ensemble analyser ce qui s’est bien passé (et donc que l’on doit conserver) et ce qui c’est mal passé (et que l’on doit changer…). Le secret est donc dans l’auto-organisation et amélioration que l’équipe va faire au cours des sprints.
Si je vous ai convaincu de l’intérêt de cette méthode et que vous souhaitez approfondir, alors lisez excellent livre de Claude Aubry : Scrum – 6e éd.: Un outil convivial pour une agilité radicale. Vous pouvez aussi vous rapprocher des « scrum users groups » qui existent dans quelques villes de France (je participe parfois au Sug de bordeaux et j’adore). Enfin, l’entreprise que je crée sur Bordeaux, Aplose, propose dès la rentrée, des formations courtes mais efficaces sur plusieurs aspects de la méthode Scrum.