Le Slack est une pratique utilisée dans les méthodes dites « agiles » comme le scrum ou le XP (eXtrem Programming)… Elle consiste à se donner une marge de manœuvre sur la gestion du timing pour éviter les retards de livraison (nous parlons ici de livraison de versions intermédiaires de développement produits et non de livraison de marchandises…) 🙂
Ah bon ? Mais pourquoi se laisser du mou ?
Le respect du délai sur le développement d’un produit (que ce soit un logiciel ou une nouvelle techno) est trop important (impact sur la satisfaction client, sur les coûts, le stress de l’équipe…) pour le négliger.
Par ailleurs, il faudrait être naïf (ou prétentieux) pour imaginer prévoir et anticiper tous les aléas possibles sur un projet… (Cf Mon chapitre sur les prévisions de mon « Antibible du Contrôle de Gestion« )
Bref, utiliser le Slack c’est intégrer de la flexibilité dans la conduite de notre projet, alors pourquoi devrait-on s’en priver !? 😉
Mais concrètement, comment faire ?
Concrètement il existe deux méthodes…
- La première consiste à s’accorder un stock tampon de temps. Si nous reprenons l’exemple d’un projet XP (eXtrem Programing) qui fonctionne par itération de 2 à 4 semaines, nous ne planifierons aucun scénario fonctionnel (story) à développer sur la dernière (ou les 2 dernières) journée de l’itération. Ainsi, si nous enregistrons des retards sur l’itération, il sera possible de la rattraper sur ce temps prévu pour. Et si aucun problème n’est rencontré, alors ce temps sera utilisé pour s’avancer sur le projet, ou pourquoi pas pour laisser un peu de repos à l’équipe pour recharger les batteries avec la prochaine itération.
- La deuxième façon de faire consiste définir certaines fonctionnalités comme « potentiellement reconductibles ». Nous obtenons un périmètre fonctionnel sur lequel nous nous ne pouvons pas déroger + d’un périmètre fonctionnel dont la réalisation dépendra de l’état d’avancement du projet sur la fin du jalon.
Un stock tampon que l’on retrouve par ailleurs dans les outils de Gorldratt…
Les fans de Goldratt reconnaitront dans cette pratique du Slack une similitude avec la notion de buffer présentée dans « The Critical Chain », roman d’initiation à l’usage de la théorie des contraintes dans le cadre de la gestion de projet.
Dans sa méthode de gestion de projet, Goldratt préconise l’utilisation de ce buffer pour préserver le chemin critique… Il s’agit là encore de préserver l’échéance de livraison du projet.
Je ne suis pas un assez fin connaisseur des méthodes agiles pour savoir si le Slack a une quelconque affiliation avec le buffer de la chaîne critique de Goldratt mais ce ne serait pas impossible, car celui-ci est cité dans chacun des ouvrages que j’ai pu consulter sur le sujet…
Du Buffer Slack au Creative Slack…
En approfondissant mes recherches sur le sujet, j’ai découvert avec intérêt que certaines équipes agiles pouvaient utiliser ce temps libre comme un temps dédié à la créativité. Ainsi à la fin d’une itération, si l’équipe est dans les temps ou en avance, il peut être prévu un temps de réflexion ou de prototypage des scénarii fonctionnels prévu sur la prochaine itération. Ce temps ainsi libéré pour la créativité peut par la suite déboucher sur des gains de productivité importants sur les développements à venir.
Cette pratique du Slack du fait de sa souplesse permet également une prise de risque (parfois source de valeur ou de productivité) qui ne serait pas envisageable sans ce temps disponible.
Attention, le Buffer Slack n’est pas le Slack Off…
Le Slack est une zone de liberté pour l’équipe qui lui permet d’avoir davantage de contrôle sur son projet. L’équipe comme le responsable du projet sont conscients de l’utilité de ce temps. Il est donc inutile de venir polluer l’état d’esprit de cette pratique par l’idée que l’équipe pourrait en profiter pour s’abandonner dans l’oisiveté.
De votre côté, quel outil utilisez-vous pour éviter les retards sur vos projets ? Que pensez-vous du Slack ? L’avez-vous testé pour pouvoir nous en faire un retour d’expérience ? 😉
Bonjour,
Dans un poste précédent, j’ai eu à gérer la planification et le suivi des projets de l’entreprise.
Lors de la planification, la direction souhaitait que les temps soient minimiser, les opérationnels souhaitaient que les temps soient allonger et pour ma part je souhaitais que les temps soient les plus prés de la réalité.
A plusieurs reprises, j’ai mis chacun face à ses contradictions :
La direction avec : « on ne respecte jamais les temps »
Les opérationnels avec : « on a prévu tant de temps, j’ai le temps »
Moi avec : « par rapport au projet se rapprochant le plus nous avions mis tant de temps »
Au final, j’ai proposé une solution qui ressemble à celle que vous présentez. J’ai proposé de prendre le temps moyen validé par chacun pour qu’il soit notre objectif commun et ce temps été planifié avec une marge.
Cette marge servait de tampon ou de temps pour faire des mises à jour, du développement, ou pour animer des ateliers de résolutions de problème.
Malheureusement, pris dans la cours à l’urgence ce système n’a pas survécu…
Je reste persuadé qu’il faut mieux réfléchir et s’organisé avec des méthodes comme celle que vous présentez que de faire le pompier toute la semaine.
Merci Tionebmada pour ce témoignage… Dommage que l’expérience n’ait pas réussit. 🙁
Un des facteurs clé il me semble est de considérer ce buffer et le chemin critique comme des points indispensables à suivre tout au long du projet.
Si nous n’en percevons pas l’intérêt c’est sûr que ça doit très vite passer à l’as…
Au plaisir.
Florent.
Tout a fait Florent,
Pour ma part j’ai sous estimé le pouvoir d’une bonne présentation des enjeux, des objectifs et de la méthode, à l’époque c’est une idée que j’ai développé avec mes connaissances du moment.
Le souci est que la direction n’avait pas cette sensibilité organisationnelle et que leur priorité « gérer les urgences » est passée avant le bon déroulement des projets pour ne pas avoir d’urgence.
C’est bien le problème de traiter les causes premières au lieu de traiter les causes racines !!!
Je profite de ce message, pour encore vous féliciter pour votre site et pour vos fiches outils.
Bonne continuation et a bientôt pour d’autre commentaires.
Benoit ADAM