Scrum2.0 ?

Le Scrum enseigné dans les cours officiels et présenté dans les livres est un peu dépassé.

Tobias Mayer, dans son billet When Scrum is not Scrum?, présente les adaptations qu'il apporte au Scrum de base et se demande s'il s'agit encore de Scrum. Si c'est intéressant, je ne trouve pas ça complètement nouveau : la plupart de ses propositions sont déjà pratiquées dans la communauté Scrum et j'ai déjà parlé de certaines dans mon blog. Sur les 8 points évoqués, je mets en pratique certains régulièrement, comme :

  • le directeur produit fait partie de l'équipe
  • les itérations font moins de 4 semaines
  • utilisation de tableau de tâches
  • les backlogs collés au mur
  • les réunions d'estimation
  • les pratiques d'ingénierie

Et je suis en train d'essayer les tâches ne sont pas estimées en heures.

De mon point de vue, ces évolutions restent dans l'esprit, elles ne remettent pas en cause la mécanique de Scrum. Le dernier des 8 points, c'est "pas besoin de ScrumMaster dans une équipe", c'est plus sujet à polémique.

Mais si ce billet retient surtout l'attention, c'est parce que le Tobias s'est fait virer de la ScrumAlliance. D'après ce que je comprends pas pour les adaptations présentées ci-dessus, mais parce qu'il aurait mis en cause la transparence et l'intégrité de la direction. On applique le centralisme démocratique dans la ScrumAlliance ?

Commentaires

1. Le mardi 27 février 2007, 12:00 par ervin

C'est peut-être un problème de mono-culture chez moi, mais on dirait que cela revient à "redécouvrir l'eXtreme Programming"... En effet, initialement Kent Beck ne s'intéressait pas à la partie purement planification et il a pour une bonne part repris Scrum lorsqu'il a eu ce besoin.

Si à cela on ajoute les points que vous évoquez pour adapter Scrum:

- "le directeur produit fait partie de l'équipe", c'est un des principes forts en XP (même si on parle de "client" plutôt de "directeur produit", j'ai quand même une préférence pour la terminologie Scrum ici);

- "les itérations font moins de 4 semaines", or XP pousse à faire des itérations courtes deux ou trois semaines maximum;

- "utilisation de tableau de tâches";

- "les backlogs collés au mur", à regrouper avec le point précédent je pense, cela peut alors être mis en parallèle avec l'utilisation préconisée dans XP de "fiches A5" pour gérer les histoires utilisateurs;

- "les réunions d'estimation", là je ne suis pas sûr de bien comprendre... comment une méthode dite agile pourrait fonctionner sans réunions d'estimation?;

- "les pratiques d'ingénierie", et là c'est vraiment le "coeur de métier" de l'eXtreme Programming, avant de devenir réellement public il s'agissait uniquement d'un recueil de pratiques d'ingénierie.

Loin de moi l'idée de faire de la querelle de clocher, je remarque simplement une certaine convergence (en fait c'est le titre "Scrum 2.0" qui m'a fait utiliser le terme de "redécouverte"). Cela dit, certaines des propositions sont intéressantes notamment sur la gestion des backlogs.

2. Le mardi 27 février 2007, 14:17 par Camille Bloch

Personnellement je sépare Scrum d'XP pour la principal raison qu'ils n'ont pas la même portée à mon avis.

Scrum est orienté gestion de l'équipe et du travil, alors qu'XP est plus orienté développement.

Chacun apporte sa pierre à l'édifice pour les deux aspects, mais pour moi, Scrum et XP sont avant tout complémentaires.

Nous utilisons Scrum pour l'aspect gestion et XP pour les bonnes pratiques de développement.

Je suis d'accord, les deux se rejoignent sur certain point, mais ils offrent néanmoins une approche d'un même problème sous deux angles différents...

Enfin, ce n'est que mon avis...

3. Le lundi 05 mars 2007, 06:42 par Benjamin MULLER

Pour moi scrum est un meta modele de gestion de projet. Il fournit des grands principes et a chacun de les mettre en pratique à sa facon.

Les pratiques evoquées plus haut sont pour moi des facons d'implementer les principes de scrum et non pas des regles absolues à integrer à SCrum.

Ainsi chaque equipe pour chaque projet peut juger interessant de partir des principes de bases de scrum et de les adapter, completer ...

Cela reste pour moi de l'agilité basée sur scrum.

Vouloir enfermer Scrum dans une definition precise et parler de version est selon moi contraire à la philosophie de l'agilité.


4. Le lundi 05 mars 2007, 09:29 par Camille Bloch

Je suis d'accord sur le fait que le principe de l'agilité, c'est de prendre ce dont on a besoin, mais je ne pense pas que cela soit antinomique avec l'évolution d'une pratique, par exemple Scrum 2.0.

Il faut considérer que c'est juste un ajout de bonne pratiques "possibles". On a maintenant plus de choix possibles.

Par contre, je ne pense pas que Scrum soit un meta modèle. Pour moi, Scrum est bien concret, même si on n'applique pas forcement tous les principes.

Mais contrairement à XP, je pense qu'on peut facilement appliquer la majoritée des principes Scrum.

5. Le lundi 05 mars 2007, 16:08 par Stéphane Boisson

Personnellement je suis contre l'incorporation de pratiques d'ingénieurie dans Scrum..
Il faut à mon avis que Scrum reste général et qu'on puisse appliquer à d'autres activités de production que le developpement de logiciels..

6. Le mardi 06 mars 2007, 09:30 par Camille Bloch

oui, je suis aussi d'accord avec ca.

Le gros avantage de Scrum, c'est qu'en effet, on peux choisir ses propres regles d'ingéniérie.

7. Le jeudi 08 mars 2007, 19:02 par claude aubry

Le qualificatif qui me semble le plus adapté pour Scrum est que c'est un framework (cadre) de processus. Quand on implémente Scrum sur un projet, on applique très concrètement ce qui constitue ce cadre (les réunions, les backlogs, les rôles) et on y intègre les activités d'ingénierie spécifiques du projet.