Je vous propose la traduction en Français de l’article « Scrum doesn’t do anything » de Tobias Mayer après avoir reçu son accord. L’article original pour ceux qui préfèrent la version en Anglais et pour suivre les commentaires se trouve sur le blog de Tobias. Merci à Tobias de m’avoir autorisé à traduire son article et merci à Sébastien Douche pour m’avoir indiqué l’article original sur Twitter.
This article is a French Translation of the original « Scrum doesn’t do anything » wrote by Tobias Mayer. Published with his agreements, thanks again to Tobias for this very good article. Please see : http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/
Tobias Mayer:
« Faire du Scrum » est aussi vide de sens (et impossible) que de créer une instance d’une classe abstraite. Scrum est un cadre pour mettre en avant les dysfonctionnements d’une organisation. Ce n’est pas un processus et il n’est pas prescriptif. Le cadre de base de Scrum, tel que décrit (par exemple) ici et ici, ne fait pas en effet grand chose. Il est, en quelque sorte, un contrat que nous mettons en place entre ceux qui recherchent de la Valeur et ceux qui la construisent. Mais un contrat ne produit rien. Une interface est passive. Il nous faut une implémentation.
Scrum commence à fonctionner quand les gens le comprennent suffisamment pour en créer une mise en application concrète, pour ensuite faire émerger un processus qui leur est propre. Comprendre et respecter Scrum ainsi que l’ensemble des règles permet de s’aligner avec les autres et d’avoir un ensemble commun de valeurs et de principes à partir duquel travailler.
Scrum lui-même peut être considéré comme analogue à un ensemble de règles de jeux. Pensez aux échecs, pensez au football. Les règles sont faciles à apprendre, et les connaitres vous permet de jouer avec les autres. Les règles sont donc les liens qui nous unissent. Mais bien que vous connaissez les règles, ce n’est pas pour autant que vous tirez du plaisir de la partie [d’échec ou de foot]. Vous aurez besoin de jouer pour être impliqué. C’est donc jouer, et pas simplement connaître la règle qui apportera un résultat. D’ailleurs pour bien jouer, vous devez élaborer une stratégie, et dans les jeux d’équipe dont vous avez besoin de développer une relation de confiance et de partage avec les autres.
Dans n’importe quel jeu, dès lors que vous commencez à ne plus suivre les règles, tout s’écroule, et plus personne ne voudra alors jouer avec vous. Et bien c’est exactement la même chose avec Scrum.
Respecter le contrat, les règles, ou dans le langage des logiciels, respecter l’interface, vous permet de créer un processus qui convient à votre contexte – et votre contexte est beaucoup de choses: les gens, l’industrie, des entreprises, une place du marché, un produit, une localisation, une langue, l’environnement physique, la culture, les gens, etc. Il commence et se termine avec les gens. Scrum en fait ne fait rien, ce sont les gens qui font des choses. Le processus Scrum émèrge à travers l’interaction entre les gens, et il sera différent pour chaque organisation et chaque équipe. Et c’est là que les gens trébuchent, trop nombreux à penser que la création de leur propre processus commence par briser les règles. C’est faux ! Faire cela, et vous aurez échoué avant de commencer. (Note de Nicolas : avant d’adapter Scrum, suivez simplement ses principes, votre équipe évoluera ensuite)
La mise en place initiale de Scrum doit s’effectuer avec des paramètres convenus, elle doit être délimitée par des règles. Toutes les méthodes de la Classe abstraite doivent être implémentées, ou la classe ne se compilera pas et ne sera pas exécutée. Si vous essayez de déplacer votre Fou dans un jeu d’échec en ligne droite, alors votre adversaire quittera la table. Si vous voulez ramasser le ballon de football avec les mains sur le terrain et le jeter, vous prendrez un carton rouge.
Le cadre de Scrum est un mécanisme puissant pour mettre en avant les dysfonctionnements d’une organisation et d’une équipe. C’est ce pouvoir même qui pousse les gens à essayer de contourner les règles et à prendre des raccourcis. Ils ne veulent souvent pas regarder. Mais ne pas chercher la cause d’un problème ne fait pas disparaître celui-ci, ou ne réparent pas ce qui est cassé, cela retarde simplement le moment où l’on échouera de manière inévitable. Nous nous en remettons pas pour rien à la valeur de Courage dans Scrum.
Essayer de comparer Scrum à des pratiques d’implémentations comme XP ou de l’artisanat logiciel apporte peu de sens. Chacun de ces mouvements offre par ailleurs d’excellents outils pour mettre en place une pratique solide de Scrum, pour rendre concret l’abstrait. Scrum offre un cadre solide et un rythme implacable pour secouer la poussière des années [sur un projet].
Vous ne pouvez pas « faire du Scrum » mais vous pouvez certainement vous y embarquer, et le plus courageusement vous le faites, plus fort sera votre processus émergeant. »
FIN DE LA TRADUCTION
Nicolas, thanks for taking the time to translate this article and make it available to your readership. I am glad the spirit of the article hit a chord with you.
Je suis assez fan d’analogies alors cet article m’a beaucoup parlé! La traduction est fluide et agréable à lire. Sur le fond, cet article nous rappelle que SCRUM est un révélateur de problèmes, pas un ensemble de solutions. Il est important de le rappeler grâce à des billets comme celui-ci car trop nombreux sont ceux qui ne profitent pas de la puissance de SCRUM en adaptant trop vite les règles du jeu. Je pense à « Terminé », « IPPS »… ;o)
Analogies intéressantes. Cet article aurait certainement pu être résumé en une ou deux phrase, mais la multiplicité des analogies permet de saisir clairement le message.