Scrumification
Par Olivier Azeau le 13 janvier 2007, 02:23 - En français - Lien permanent
Dans le cadre de mon activité professionnelle, j'ai toujours appliqué une démarche de dissémination de pratiques agile dans un processus existant, ce qui produit en pratique des méthodes de travail un peu bricolées et spécifiques à un contexte donné.
En ce début d'année, je change un peu mon fusil d'épaule. Ce changement n'a rien de dogmatique et découle plutôt d'une démarche opportuniste. Il est des contextes où les changements que peuvent apporter de légères orientations un peu plus agiles obtiennent de très bon rendements. Il en est d'autres où les mêmes changements apportent moins que ce que l'on espérait : il faut alors savoir se poser les bonnes questions...
En ce début d'année, je change un peu mon fusil d'épaule. Ce changement n'a rien de dogmatique et découle plutôt d'une démarche opportuniste. Il est des contextes où les changements que peuvent apporter de légères orientations un peu plus agiles obtiennent de très bon rendements. Il en est d'autres où les mêmes changements apportent moins que ce que l'on espérait : il faut alors savoir se poser les bonnes questions...
Il serait prétentieux de ma part de définir précisément les contextes où il est plus opportun d'agir de telle ou telle manière. Peut être un jour avec le recul... Je crois que c'est avant tout une question d'expérience, au sens "essayer quelque chose" et non pas "avoir de la bouteille". Quand une méthode de travail existante rencontre certains blocages, il me semble moins risqué de tenter de résoudre les blocages au cas par cas en essayant certains changements incrémentaux. D'ailleurs, n'est ce pas le propre de l'agilité que de procéder à petits pas aisément maitrisables et testables ?
Quand ces expériences de donnent pas les résultats escomptés, il faut passer à autre chose. Pour l'heure je fais donc mon deuil (temporaire) de ces incréments méthodologiques au profit d'une mise en place de Scrum.
Le premier obstacle qui apparait devant moi découle de ce que je viens d'écrire. Lorsque l'on est fermement convaincu que du Big Design Up Front ne marche pas pour concevoir un logiciel, comment se persuader que l'on peut faire débarquer quelque part une méthode de travail qui sera, au moins dans un premier temps, livrée clef en mains prête à appliquer ?
Un terreau dans lequel enraciner cette plantation me semble essentiel. Dans le cas qui me concerne actuellement, il prend la forme d'un sentiment collectif, plus ou moins conscient, que quelque chose ne tourne pas tout à fait rond, que depuis plusieurs semaines le travail n'avance pas aussi bien qu'il le devrait. Ce contexte favorable étant acquis, il ne me restait plus qu'à déployer la démarche, en 2 temps.
Dans un premier temps, j'ai proposé à l'ensemble des membres de l'équipe de faire une présentation de Scrum dans l'absolu. Dans un deuxième temps j'affinerai la mise en place en tenant compte des diverses spécificité du contexte que l'on ne peut ignorer.
En ce qui concerne la présentation de Scrum, j'ai tout simplement suggéré de visionner la présentation de Claude Aubry sur valtech-tv "Scrum, l'esprit d'équipe comme au rugby" (on trouve ici la 1ère partie et là la 2ème) et de compléter par une petite séance de questions autour de la mécanique de Scrum (toujours par Claude Aubry, unique fournisseur de ressources francophones de qualité sur le sujet).
Cette approche se prêtait bien aux points qu'il me semblait important de mettre en avant : le backlog comme référentiel unique accessible à tous et les réunions ciblées pour instiller la communication nécessaire.
Etant donné que nous sommes à Toulouse, je n'ai pas échappé aux remarques concernant l'analogie avec le rugby : la mêlée est un élément de construction des phases de jeu à venir mais elle n'en reste pas moins un outil de destruction dont l'esprit n'a que peu de liens avec le développement logiciel. Je dois avouer que je trouve moi-même tout cela un peu capilotracté. Le maul pénétrant me semblerait quelquefois un peu plus représentatif...
Le décor étant planté, il ne me reste plus, dans les jours à venir, qu'à adapter la démarche au contexte. Au menu :
La mise en oeuvre de Scrum semble démarrer sur de bonnes bases. Comment cela continuera-t-il ? La suite des évènements fera peut-être l'objet d'un ou plusieurs autres billets dans les semaines à venir. S'il y a quelque chose d'intéressant à raconter...
Quand ces expériences de donnent pas les résultats escomptés, il faut passer à autre chose. Pour l'heure je fais donc mon deuil (temporaire) de ces incréments méthodologiques au profit d'une mise en place de Scrum.
Le premier obstacle qui apparait devant moi découle de ce que je viens d'écrire. Lorsque l'on est fermement convaincu que du Big Design Up Front ne marche pas pour concevoir un logiciel, comment se persuader que l'on peut faire débarquer quelque part une méthode de travail qui sera, au moins dans un premier temps, livrée clef en mains prête à appliquer ?
Un terreau dans lequel enraciner cette plantation me semble essentiel. Dans le cas qui me concerne actuellement, il prend la forme d'un sentiment collectif, plus ou moins conscient, que quelque chose ne tourne pas tout à fait rond, que depuis plusieurs semaines le travail n'avance pas aussi bien qu'il le devrait. Ce contexte favorable étant acquis, il ne me restait plus qu'à déployer la démarche, en 2 temps.
Dans un premier temps, j'ai proposé à l'ensemble des membres de l'équipe de faire une présentation de Scrum dans l'absolu. Dans un deuxième temps j'affinerai la mise en place en tenant compte des diverses spécificité du contexte que l'on ne peut ignorer.
En ce qui concerne la présentation de Scrum, j'ai tout simplement suggéré de visionner la présentation de Claude Aubry sur valtech-tv "Scrum, l'esprit d'équipe comme au rugby" (on trouve ici la 1ère partie et là la 2ème) et de compléter par une petite séance de questions autour de la mécanique de Scrum (toujours par Claude Aubry, unique fournisseur de ressources francophones de qualité sur le sujet).
Cette approche se prêtait bien aux points qu'il me semblait important de mettre en avant : le backlog comme référentiel unique accessible à tous et les réunions ciblées pour instiller la communication nécessaire.
Etant donné que nous sommes à Toulouse, je n'ai pas échappé aux remarques concernant l'analogie avec le rugby : la mêlée est un élément de construction des phases de jeu à venir mais elle n'en reste pas moins un outil de destruction dont l'esprit n'a que peu de liens avec le développement logiciel. Je dois avouer que je trouve moi-même tout cela un peu capilotracté. Le maul pénétrant me semblerait quelquefois un peu plus représentatif...
Le décor étant planté, il ne me reste plus, dans les jours à venir, qu'à adapter la démarche au contexte. Au menu :
- La distribution géographique des cochons implique une utilisation incontournable d'outils électroniques. Nous disposons d'un système de téléconférence relativement efficace qui, je l'espère, nous permettra de mener à bien certaines réunions de planification de sprint et certaines démonstrations et rétrospectives de fin de sprint.
- L'intégration dans un processus de production plus général et très orienté "production de documents" ne doit pas être un frein à la dynamique des tâches quotidiennes et à la progression du sprint.
- La non unicité du directeur de produit induit un niveau de concertation supplémentaire, tout particulièrement en ce qui concerne la gestion du backlog. Cette non unicité découle d'une organisation où plusieurs entités ont, légitimement, leur mot à dire sur le contenu. On y trouve le marketing produit qui décide de la stratégie et induit la démarche commerciale. On a aussi l'assurance qualité, représentant des utilisateurs dans un domaine médical fortement réglementé. On a enfin le support produit qui, en bout de chaîne, va assurer la bon fonctionnement du système chez les clients.
La mise en oeuvre de Scrum semble démarrer sur de bonnes bases. Comment cela continuera-t-il ? La suite des évènements fera peut-être l'objet d'un ou plusieurs autres billets dans les semaines à venir. S'il y a quelque chose d'intéressant à raconter...
Commentaires
Mais parlons Scrum. J'ai une réserve : avoir un comité de 3 personnes au lieu d'une seul directeur de produit ne me paraît pas une bonne idée, pour 2 raisons :
- il est préférable que l'équipe n'entende qu'une seule voix quand il s'agit d'avoir une réponse à une question
- un directeur de produit devrait être à plein temps ou presque sur le projet ce qui est probablement incompatible avec les fonctions évoquées
A mon avis, dans mon contexte (édition de produit logiciels pour plusieurs dizaines voire centaines de clients), un directeur de produit unique est une illusion si l'on considère le besoin d'interaction avec le terrain (les clients, les commerciaux, les field engineers, ...) que doit gérer une direction de produit pour faire ses choix.
Le 'client sur site' présenté comme personne unique était une des critiques majeures de XP à ses débuts et cette notion a d'ailleurs plus ou moins disparu dans XPE2E.
J'en arrive même à me demander si l'esprit de Scrum ne serait pas applicable à une activité de gestion de produit : plusieurs personnes collaborant sur un travail dont le but est de produire un 'backlog de produit'. Pourquoi ce que l'on considère possible pour du développement logiciel ne serait pas possible pour cela ?
J'arrête mon commentaire ici parce que cette boîte pour l'écrire est vraiment trop petite et avec des caractères minuscules !
Dire que les membres de l'équipe ne doivent entendre qu'une voix ne signifie pas forcément que cette voix soit celle d'une seule personne ! On peut considérer la situation symétrique : il est préférable que la direction de produit entende une seule voix quand il s'agit de donner un coût à une exigence (sans cela, impossible de prioritiser). Pourtant, cela n'implique pas qu'un seul membre de l'équipe soit habilité à estimer ce coût !
Euh, la police est toujours aussi minuscule.
Je voulais dire :
On fait une séance en groupe (Planning poker) pour estimer le coût avec un consensus de l'équipe et de façon symétrique on peut faire un workshop pour définir les priorités avec les différentes personnes intéressées par le produit (stakeholders).
- décider des priorités des diverses exigences ?
- connaître les besoins détaillés des utilisateurs ?
- connaître les contraintes techniques et organisationelles du terrain ?
- ....
Dans mon contexte actuel (et même ceux que j'ai connus dans le passé), une seule personne ne peut pas fournir l'ensemble des réponses dont ont besoin les membres de l'équipe au quotidien. Il en faut obligatoirement plusieurs. C'est la raison pour laquelle, d'une manière ou d'une autre, il faut que ces personnes qui constituent collectivement la "direction de produit" soient sur la même ligne de pensée.
Une solution serait de mettre une seule personne en point d'entrée unique sur la gestion de produit pour l'ensemble des membres de l'équipe de développement mais un tel choix me fait surtout penser à un goulot d'étranglement qui ne va pas du tout dans le sens "Individuals and interactions over processes and tools".
Merci pour la police !