Scrum dans une PME,qui tient les rôles quand l'équipe est petite

Quelqu'un vous propose de passer à Scrum, et vous regardez votre équipe : quatre personnes, dont une qui répond aussi aux clients et une autre qui fait le support le vendredi. Scrum en PME, est-ce que ça tient quand personne n'a un seul métier ?

Je suis certifié Scrum Master et Product Owner, avec une limite que je préfère écrire tout de suite : je travaille seul, et je n'ai aucun chiffre de transformation à vous montrer. Je peux vous montrer les mécanismes de Scrum que j'ai gardés dans mes propres outils, et ce que je regarde avant de dire oui. Vous trouverez ici de quoi décider si la méthode vous convient, qui peut tenir les rôles, et comment lancer un premier sprint de deux semaines sans réorganiser l'entreprise.

01Ce que le Scrum Guide demande, et ce qu'il laisse ouvert

Le Scrum Guide est court et gratuit, et je vous conseille de le lire avant toute formation. Il demande peu de choses, mais il les demande fermement :

• une équipe avec un Scrum Master, un Product Owner et des Developers, en général 10 personnes ou moins ;
• des sprints de durée fixe, d'un mois au plus ;
• un objectif de sprint, un Daily de 15 minutes, une revue et une rétrospective ;
• une définition de « terminé » que tout le monde respecte.

Le reste est libre : l'outil, le format du Daily, la façon d'estimer. Le Guide ne parle ni de story points ni de logiciel. Il parle de responsabilités, et je n'y lis pas une obligation de créer trois postes.

Il est aussi très net sur un point : on peut appliquer une partie de Scrum, mais le résultat n'est plus du Scrum. Je ne le prends pas comme un reproche. Si vous gardez deux pratiques qui vous aident, gardez-les, et appelez-les autrement. Vous éviterez de conclure que « Scrum ne marche pas » après un essai qui n'en était pas un.

Le mot PME demande aussi une précaution. Pour l'Insee, une PME occupe moins de 250 personnes, et les microentreprises de moins de 10 personnes en font partie. Une entreprise de 200 personnes et une de 6 n'ont pas le même problème. Le Guide raisonne par équipe : la bonne question porte sur l'équipe qui ferait le sprint, pas sur la taille de la société.

02Trois questions à poser avant le premier sprint

Votre travail peut-il attendre deux semaines ?

Un sprint suppose qu'on protège une liste de travail pendant sa durée. Si la moitié de vos journées part en urgences clients, le sprint sera faux dès le mardi. Nielsen Norman Group a interrogé huit professionnels qui travaillent en agile, et l'une des plaintes revient à ceci : les demandes qui arrivent hors du processus cassent la planification (Doing UX in an Agile World). L'échantillon est petit et l'article date de 2014, mais je reconnais cette plainte.

Une personne peut-elle trancher ?

Le Guide le dit en peu de mots : le Product Owner est une personne, pas un comité. Dans une PME, le risque ressemble souvent à ceci : le fondateur, le commercial et le responsable technique priorisent chacun de leur côté. Tant que personne ne peut dire non aux deux autres, le carnet de travail n'est qu'une liste de souhaits.

La direction accepte-t-elle de ne plus interrompre ?

Christiaan Verwijs et Daniel Russo ont validé un modèle sur environ 5 000 développeurs et 2 000 équipes Scrum, et le soutien du management y figure parmi les cinq grands facteurs d'efficacité, avec la réactivité, l'attention aux parties prenantes, l'amélioration continue et l'autonomie de l'équipe (A Theory of Scrum Team Effectiveness). L'étude ne porte pas spécialement sur des PME, et j'en ai lu le résumé. Je retiens une conséquence pratique : si la personne qui dirige continue d'appeler directement un développeur pour « un petit truc », le reste ne tiendra pas.

03Tenir les rôles avec une petite équipe

Le Product Owner

Il vous faut quelqu'un de disponible, qui connaît les clients et qui a vraiment le droit de décider. Le fondateur convient s'il répond aux questions dans la journée. S'il est en rendez-vous toute la semaine, l'équipe attendra, ou décidera sans lui.

Le plus dur dans ce rôle tient en un mot. Henrik Kniberg prend un exemple simple dans Agile Product Ownership in a Nutshell : on demande dix sujets par semaine à une équipe qui en livre quatre à six, et la file ne cesse de s'allonger. Il n'y voit qu'une issue, le mot « non », qu'il présente comme le plus important pour un Product Owner. Il explique aussi que la capacité se mesure simplement, en comptant ce qui sort chaque semaine.

Le Scrum Master

Dans une équipe de cinq, personne n'y consacrera ses journées, et le Guide n'en fait pas une condition. Un membre de l'équipe peut le tenir à côté de son travail. Le Guide prévoit d'ailleurs que le Scrum Master et le Product Owner participent comme Developers s'ils travaillent sur le sprint. Un des témoins de Nielsen Norman Group résume bien le minimum : un Scrum Master dédié si vous le pouvez, sinon des rôles clairs.

Ce qui suit est mon avis, et le Guide ne l'impose pas : je ne donnerais pas les deux rôles à la même personne. L'un pousse pour faire entrer du travail, l'autre protège le sprint. Une seule personne perdra cet arbitrage contre elle-même.

Les Developers

Le mot gêne souvent hors de la technique. Le Guide appelle ainsi toute personne engagée à créer une partie de ce qui est livré, donc aussi le design ou le contenu si la livraison en dépend. Le design pose une difficulté connue : les personnes interrogées par Nielsen Norman Group conseillent d'avoir au moins une étape d'avance sur le sprint. Je passe volontiers par un prototype cliquable pour cela.

04La définition de « terminé », ce que je garde partout

C'est le mécanisme que je reprends même quand je ne fais pas de Scrum. Dans le Guide, un élément qui ne respecte pas la définition de « terminé » ne peut pas être présenté en revue et retourne dans le carnet.

J'ai construit ma machine de contenu sur la même idée. Un article n'est terminé que si un contrôle automatique ne trouve aucun rouge, que l'image a été regardée, que la version anglaise existe et que la page publique a été vérifiée. Trois autres choses ressemblent à du Scrum : un calendrier qui tient lieu de carnet, un verrou qui impose un seul article en cours, et des retours de relecture qui deviennent des règles écrites plutôt que des corrections à la main.

Ce n'est pas du Scrum pour autant. Je n'ai ni équipe, ni sprint, ni revue avec des parties prenantes. Mais en le faisant, j'ai cessé de croire les « c'est fait » : je demande la preuve. Pour votre équipe, une première version peut tenir en cinq lignes :

• le travail est en ligne ou livrable, sur l'environnement que le client voit ;
• une autre personne l'a relu ou testé ;
• la spécification ou la documentation correspond à ce qui existe ;
• la personne qui l'a demandé peut le voir sans qu'on le lui explique ;
• rien de connu ne reste cassé.

Le troisième point vient d'une mission, sur une intégration entre un ERP et un site marchand : la spécification a bougé presque à chaque réunion, et je l'ai versionnée pour que tout le monde parle du même document.

05Un premier sprint de deux semaines

Ce plan décrit ce que je ferais, et n'est pas le compte rendu d'un cas réel. Le Guide ne fixe pas deux semaines ; je les choisis parce qu'un mois laisse trop de temps pour se tromper sans le voir.

1. La veille : le Product Owner classe le travail par ordre d'importance, et l'équipe écrit sa définition de « terminé ».
2. Jour 1 : la planification. Écrivez l'objectif du sprint en une phrase, puis choisissez ce qui y contribue. Le Guide plafonne ce temps à huit heures pour un mois ; pour deux semaines, je viserais bien moins.
3. Chaque jour : le Daily, 15 minutes, à la même heure et au même endroit. Nielsen Norman Group rapporte des réunions de plus de 30 minutes qui se rapprochent de 15 avec la pratique, alors ne vous inquiétez pas si les premières débordent.
4. Pendant le sprint : toute nouvelle demande passe par le Product Owner, et l'équipe note chaque interruption. Une panne se traite tout de suite, le reste attend le sprint suivant.
5. Jour 10, la revue : montrez ce qui marche à ceux qui l'ont demandé, sans diapositives.
6. Jour 10, la rétrospective : choisissez un seul changement et écrivez-le comme une règle.

Après ce sprint, regardez deux chiffres : le nombre d'éléments terminés et le nombre d'interruptions. Un seul sprint ne prouve rien. Attendez-en trois ou quatre avant de parler de capacité.

Le sprint ne remplace pas non plus les décisions de budget ou de calendrier. Pour celles-là, un rapport mensuel qui part seul et un comité qui décide m'ont paru plus utiles qu'un tableau que personne ne lit.

06Quand je ne le conseillerais pas

Scrum a un coût que l'on compte rarement. Sur deux semaines, le Daily seul prend deux heures et demie par personne, sans compter la planification, la revue et la rétrospective. Dans une équipe de cinq où chacun porte aussi autre chose, ce temps se prend quelque part.

Je ne le conseillerais pas dans ces cas :

• le travail est surtout un flux de tickets ou de support, et un simple tableau avec une limite de sujets en cours sera plus honnête ;
• l'équipe compte une ou deux personnes, comme moi : une liste classée et une définition de « terminé » suffisent ;
• les personnes changent d'une semaine à l'autre, une difficulté que décrit aussi Nielsen Norman Group ;
• le projet n'est pas cadré, et les sprints vous feront avancer vite sans savoir vers quoi : commencez par cadrer le projet ;
• personne n'a le droit de dire non.

07Par où commencer lundi

Si vous hésitez encore, faites ceci avant d'acheter une formation ou un logiciel :

1. Lisez le Scrum Guide en entier.
2. Comptez les interruptions de l'équipe pendant une semaine.
3. Demandez qui tranche quand deux demandes s'opposent, et écrivez le nom.
4. Écrivez votre définition de « terminé » en cinq lignes.
5. Si les trois questions du début ont une réponse, lancez un sprint de deux semaines sur un seul sujet.

Si le résultat ne vous convainc pas, vous aurez perdu deux semaines et gardé une définition de « terminé », ce qui n'est pas si mal. Si vous voulez un regard extérieur sur votre projet, la page services dit comment je travaille ; on peut en parler.