De la souplesse dans Scrum avec les GASPs

La notion de GASPs

Mike Cohn introduit la notion de GASP, signifiant Generally Accepted Scrum Practice ou Pratique Scrum Généralement Acceptée. Une GASP se définit comme une activité pratiquée par un grand nombre d’équipes Scrum, mais pas par la totalité. Pour lui, une GASP est avant tout une bonne idée, connue de toute l’équipe, qu’il est généralement bon d’appliquer mais qui en aucun cas n’est obligatoire. Ce sera même un peu plus qu’une simple bonne idée étant donné qu’il faudra que les équipes Scrum connaissent les GASPs pour pouvoir décider ou non de les utiliser.

Différences entre une règle et une GASP

Il faut ici faire la distinction entre deux notions, à savoir les règles Scrum et les GASPs. Une “règle Scrum” est en fait une pratique nécessairement appliquée pour justifier l’appellation Scrum. Au final, chaque règle et GASPs est en soit une recommandation, mais sans certaines d’entre elles, il devient difficile de justifier le fait de dire “nous utilisons Scrum” comme il serait difficile d’appeler course automobile une compétition qui n’utiliserait pas de voiture. Par exemple nous définirons “Travailler en itérations courtes et limitées dans le temps” comme une règle. En revanche, la limitation du nombre de tâches en cours (principe emprunté à Kanban), sera une GASP, c’est-à-dire une bonne idée, généralement bonne à appliquer mais non obligatoire pour Scrum.

Souvent on observe dans les équipes passant d’une méthodologie en cascade à Scrum une amélioration de la qualité et de la vitesse. Cependant, il arrive que plus tard dans le temps Scrum devienne une contrainte dans le sens où l’application stricte de la méthodologie impose un certain nombre d’activités superflues.

Ainsi, ne serait-il pas intéressant de pouvoir se défaire de ces activités tout en restant agile ? C’est ce que représente les GASPs. Le point réellement important est de pouvoir justifier pourquoi l’une de ces pratiques n’est pas nécessaire dans un contexte donné.

En effet, simplement ne pas appliquer une GASP parce qu’elle semble alourdir un processus ou simplement parce que c’est une tâche répétitive n’est pas une bonne raison, ou en tout cas pas suffisante.

Démonstration par l’exemple

Prenons l’exemple du Release Planning. C’est une bonne pratique, pertinente et donc souvent utilisée. Cependant, dans un projet où on ferait de la livraison continue, quelle serait l’intérêt du Release Planning ? Est-ce, pour ce projet, pertinent d’utiliser cet outil ? Est-ce que ce contexte rend sa mise en œuvre difficile ? Autant de questions qui nous permettront de justifier son utilisation ou non, tout en gardant la casquette Scrum. Le fait qu’on puisse se poser ces questions au sujet du Release Planning en fait donc une GASP.

On peut également décider de ne pas appliquer une GASP simplement parce qu’on la remplace par quelque chose de “mieux”, “mieux” indiquant implicitement “fonctionnant mieux pour l’équipe dans le contexte actuel” et non pas comme qualitatif de la pratique en général. On prendra ici l’exemple des User Stories qui est aujourd’hui d’usage courant. Si l’ensemble de l’équipe se sent plus à l’aise avec une autre forme de définition, avec un niveau de granularité suffisant, ce sera au final un changement pertinent.

Ces réflexions de l’équipe pourront également servir d’indicateur sur sa maturité dans le sens où une justification claire et posée de ne pas appliquer une ou plusieurs GASPs fera toute la différence entre une équipe mature et une immature.

Voici quelques exemples de pratiques qui pourront être considérées comme des GASPs :

Pratiques techniques	Pratiques agiles
Intégration Continue	Standard de qualité “Zéro défauts”
Déploiement Continu	Indicateur de vélocité
Tests automatisés	Indicateur de valeur business
Test Driven Development	Session d’élargissement de Backlog
Behavior Driven Development	Vision du Produit
Build journalier	Maintenir les décisions prises durant la rétrospective
	Utilisation des User Stories

On pourra considérer la plupart des indicateurs et autres métriques étant des GASPs, simplement parce que tous les indicateurs n’ont pas toujours une pertinence suffisante pour mériter l’investissement de temps nécessaire à leur mise en place. Ces indicateurs, qui ne sont pas forcément triviaux à générer, pourraient ainsi alourdir le processus et résulter en une perte de productivité, effet contraire à celui recherché.

On pensera également au nombre idéal de membres pour une équipe Scrum. De nos jours, il existe quelques techniques, comme le Scrum de Scrum, qui permet de gérer de plus grandes équipes, transformant cette règle en GASP. De plus, une équipe de 11 personnes faisant du Scrum peut très bien fonctionner, bien que ce soit contre les indications de la méthodologie, en faisant également une GASP.

On notera donc qu’il existerait un grand nombre de GASPs, alors que les règles de Scrum restent en nombre limité. Bien entendu, la séparation des GASPs et des règles de Scrum est parfois difficile et il existera toujours des cas où la distinction entre l’un et l’autre sera impossible. Mike Cohn propose que, dans ces moments-là, on se réfère tout simplement au bon sens.

Concluons…

Le fait qu’une pratique soit catégorisée comme GASPs ne veut pas dire qu’elle n’est pas indispensable. Encore une fois tout dépendra du projet en question et du contexte dans lequel il se déroule. Il appartient à tout à chacun d’analyser ledit contexte et d’adapter l’outillage agile en fonction des besoins.