SCRUM, c’est the mother of all agile frameworks. C’est la « méthodo » agile la plus simple, la plus immédiate et également la plus largement pratiquée. Pour agiliser un projet, un produit ou une organisation, ne cherchez pas plus loin.
En 2001, dix-sept ingénieurs se sont rassemblés pour rédiger le Manifeste Agile. Ils y formulèrent 4 principes essentiels:
- des gens (plutôt que des processus),
- des produits qui fonctionnent (plutôt que de la documentation),
- la collaboration (plutôt que la négociation),
- l’adaptabilité (plutôt que la conformité).
Ces postulats ont aujourd’hui largement dépassé le contexte des projets informatiques: on les retrouve également à la base du lean, du design thinking, des entreprises dites « libérées » et du Teal.
SCRUM, c’est tout simplement un cadre de travail (parmi d’autres) qui a été formalisé pour mettre ces principes en pratique. C’est le plus simple, le plus utilisé et le plus universel. Il est immédiatement applicable et pertinent dans tous les secteurs d’activité.
SCRUM s’articule autour de 3 dimensions très claires:
- les rôles (qui fait quoi?),
- les artefacts (que produit-on?)
- les réunions (quand et comment en discute-t-on?)
Les rôles
Les rôles sont au nombre de 3 : les gens qui se focalisent sur la compréhension des besoins (appelés product owners), les gens qui se focalisent sur la mise en œuvre des solutions (appelés team members) et celui/celle (ou ceux) qui aide(nt) ce petit monde à se questionner sur sa façon d’aborder les choses (appelés scrummasters).
C’est tout? Oui. Ne cherchez pas: il n’y a pas de manager. Ca marche vraiment? Parfois, oui. Parfois, non. Mais quand ça marche, c’est du petit lait. On touche alors du bout du doigt à une fluidité totalement nouvelle.
Les artefacts
Tout ce que vous pouvez voir ou toucher, c’est un artefact.
SCRUM en manipule toute une série, mais les 3 artefacts de base sont le product backlog (la liste des attentes et des besoins, compilée par les product owners), le sprint backlog (la liste des quelques besoins sur lesquelles nous allons travailler dans les quelques semaines qui viennent) et le product increment (le surcroît de valeur ajoutée résultant du fait que les besoins du sprint backlog ont reçu une réponse appropriée apportée par les team members).
Les réunions
SCRUM est rythmé par des sprints, qui correspondent en général des cycles de 2 à 4 semaines.
Au début de chaque sprint, une réunion de sprint planning (réunion numéro 1) permet d’identifier ce sur quoi nous choisissons de travailler dans les 2 semaines qui viennent. Durant le sprint, les team members se voient tous les jours, pendant 15 minutes, pour leur daily standup (réunion numéro 2), durant lequel ils se répartissent les tâches au quotidien. En fin de sprint, une grande présentation est organisée, le sprint review (réunion numéro 3), où sont présentés tous les avancements enregistrés pendant ces 2 semaines. Avant d’attaquer un nouveau sprint, les équipes se posent alors pour réfléchir à leur façon de travailler et pour ajuster leur mode de fonctionnement. C’est la sprint retrospective (réunion numéro 4). C’est peut-être lors de cette quatrième réunion que l’agilité se joue vraiment, d’ailleurs…
Et donc quoi?
C’est ça, SCRUM? Un ensemble de règles qui dictent la gouvernance d’un projet?
Oui et non.
Oui, ce pourrait n’être que cela : SCRUM fournit une trame, un cadre de travail prêt à l’emploi. A ce titre, c’est simplement un mode de fonctionnement à comprendre et à appliquer. Pas besoin de réfléchir pour pratiquer SCRUM. Cela semble peut-être sec et froid, mais c’est clairement expliqué. Just do it… On verra alors ce qui se passe.
Non, ce n’est pas que cela, parce que ce mode de fonctionnement n’a finalement qu’un seul objectif: vous mettre face à votre propre mode de pensée, et vous amener à le faire évoluer. Si l’on y réfléchit vraiment, vous n’appliquerez SCRUM qu’une seule fois: pendant le premier cycle (le premier sprint). Après, pour les sprints suivants, ce n’est déjà plus tout-à-fait le même SCRUM que celui avec lequel vous aviez démarré. A chaque cycle, vous en ajustez les règles pour les adapter à votre contexte et à vos enjeux. C’est là que l’effet magique et transformationnel de SCRUM jouera pleinement son rôle.
Comparons cela à un art martial. Vous pouvez en faire l’expérience avec des motivations très terre-à-terre, très rationnelles, très objectivables, comme par exemple améliorer votre force, vos capacités d’autodéfense, vos réflexes, etc. Ce sont des raisons parfaitement valables. Vous pouvez aussi pratiquer cette art martial pour ce qu’il a à vous apprendre sur vous-même (comme dans la démarche du Zen et du tir à l’arc, par exemple). Dans ce cas, le bénéfice est intérieur, non-objectivable : c’est votre vision du monde et votre manière de penser qui évoluent.
L’un n’empêche d’ailleurs pas l’autre. Tout bien réfléchi, l’un pourrait-il aller sans l’autre? SCRUM, on peut y venir pour l’efficacité, la flexibilité, la performance, etc. On peut aussi en vouloir pour découvrir ce que cette « gestion-de-projet-sans-gestionnaire-de-projet » peut induire comme changement culturel dans l’organisation. Des projets où chacun prend pleinement ses responsabilités au sein d’équipes auto-gérées, est-ce que cela mérite d’être essayé? Est-ce que cela pourrait avoir un impact personnel sur chacun? Est-ce que cela pourrait avoir un impact systémique sur l’organisation? On peut décider de faire confiance en cette possibilité.
D’ailleurs, quel serait le risque?
Jean-Paul Sartre disait: « faire, et en faisant, se faire« . C’est exactement ce que SCRUM propose.