2007, l'essor de Scrum

Matthieu se demande, à propos des membres d’une équipe qui suit un processus Agile :

Si ceux-ci ne s’engagent pas sur leurs estimations, à quoi s’engagent-ils ?

Je prépare ma présentation de Scrum pour les séminaires Telelogic de mars.

Sur l’Agilité à grande échelle qui est le titre de ces séminaires, j’ai un peu de pratique et quelques idées tirées de mon expérience sur de grands projets.

Dans un billet précédent, je notais que la ré-actualisation en heures du reste à faire pendant un sprint était difficile à obtenir des équipes. Suite à la lecture de When is Scrum not Scrum, j’ai décidé d’essayer la technique proposée pour le suivi du sprint. Je la résume ci-dessous, en mettant en évidence les différences avec la pratique Scrum standard.

Pour obtenir la certification Scrum actuelle, il suffit de suivre un cours de 2 jours. Cela ne garantit pas que vous êtes devenu un maître de Scrum.

Je suis ScrumMaster certifié depuis 2005. J’apparais dans la liste des 10888 CSM[1] de la ScrumAlliance. J’y suis même 2 fois, ce qui me fait douter de la précision du chiffre et de la bonne gestion de la ScrumAlliance.

Ca m’a beaucoup amusé au début, plus d’être ScrumMaster (le côté rugby) que d’être certifié il est vrai. Pour cela, il m’a suffi d’assister aux 2 jours de cours dans une cave de Gentilly. En arrivant en retard. C’était la première formation Scrum en France et à l’époque l’aspect certifiant n’était pas du tout mis en avant.

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.

Scrum fournit un cadre léger qui facilite le passage à l’Agilité. Les évolutions de Scrum (voir mon précédent billet) empruntent à XP (comme le fait remarquer Ervin). Cela s’amplifie encore dès qu’on ajoute à ce cadre de nouvelles pratiques d’ingénierie (TDD, binômage…). On peut considérer que beaucoup d’utilisations sont hybrides au sens qu’elles combinent du Scrum et de l’XP.

J’étudie actuellement DSDM et j’ai lu pas mal d’articles sur Lean. J’ai aussi parcouru des présentations de FDD et Crystal.

De nombreuses organisations utilisent intensivement ces acronymes. Personnellement je trouve que c’est de façon abusive, surtout quand on les utilise au sein d’une seule organisation ou pour des rôles alors que, historiquement, ces notions s’adressent à des personnes morales.

Mais l’essentiel n’est pas dans le nom. L’utilisation de MOA et MOE tend à créer une séparation très nette entre 2 groupes. Cela contribue aux problèmes suivants :

Les titres auxquels vous avez échappé :

• lettre à release
• release tailor

Suite aux commentaires sur le billet release à date fixée, je reviens sur la notion de release.

La confusion vient de ce que j’utilise release pour désigner à la fois ce qui est produit et la période de temps nécessaire pour le produire.

Pour ceux qui ont lu mon billet sur la certification Scrum, le débat continue, dans le même sens, sur InfoQ qui se demande si la certification ScrumMaster est bonne pour la communauté Agile.

Dans les séminaires ou dans les réunions, quand je présente l’agilité je montre les différences -généralement les bienfaits- par rapport à une approche… pas agile.

Cela revient à séparer le monde des processus en 2 parties[1], ce qui est très schématique… De plus comment qualifier la partie non agile ?

C’est la responsabilité de l’équipe Agile de passer ces tests, pas question de laisser ce travail à une équipe de testeurs indépendante qui attendrait la production d’une release pour commencer.

Les histoires d’utilisateurs doivent être finies à la fin de chaque sprint et a fortiori à la fin d’une release. Une histoire d’utilisateur est considérée comme finie quand elle a passé avec succès les tests d’acceptation qui l’accompagnent.

Classification des processus selon une enquête de Forrester.

Comme le font remarquer avec pertinence Camille et Matthieu dans leurs commentaires, il n’existe pas un processus traditionnel standard, traditionnel pris ici par opposition à Agile.

J’ai eu 13 retours sur les 42 personnes qui ont assisté au Sigmat2 (deuxième Séminaire d’Information Gratuit sur les Méthodes Agiles de Toulouse) du 16 mars.

A noter que les personnes qui ont assisté à ce Sigmat2 n’avaient pas assisté au premier Sigmat pour la plupart, seules 20% environ ont assisté aux 2 (et 4 parmi les 13 qui m’ont fait des retours). Il serait intéressant de savoir pourquoi ceux qui ont assisté au premier ne sont pas revenus. En tout cas ceux qui ont répondu ont l’intention de revenir. Je vous livre les retours :

Pour respecter le manifeste agile.

La présentation de Scrum que j’ai faite pour les séminaires Développez Agile à plus Grande Echelle de Telelogic à Toulouse, Paris et Bruxelles est disponible sur le site de Telelogic France.

BMUF

Après le BRUF, le BDUF, Scott Ambler s’attaque, dans un article du DDJ, à la grosse modélisation au début d’un projet, le BMUF.

Comme lui j’ai pratiqué la modélisation depuis très longtemps sur de nombreux projets et j’ai constaté qu’il y avait beaucoup de modèles trop détaillés faits au début et qui ne servaient à rien.

Je reviens d’une semaine de déplacements dans le nord[1], ce qui fait que je n’ai pas alimenté le blog pendant cette période. Je ne pensais pas rester aussi longtemps, mais pour rester agile, j’ai adapté mon emploi du temps aux besoins de mes clients et partenaires.

J’ai fait la semaine dernière une présentation de Scrum à des personnes qui n’avaient jamais entendu parler des méthodes agiles. Ce n’est pas ce que je fais d’habitude et c’est à éviter pour des novices complets sur le sujet.

C’est qu’avec Scrum on utilise un langage particulier : sprint, scrumMaster, backlog, product owner, scrum daily meeting, etc.

jc de QualityStreet présente les différences entre les cas d’utilisation et les histoires d’utilisateur. Son étude présente bien ce que sont ces 2 techniques, mais sa comparaison s’inscrit dans le cadre de techniques de spécifications des exigences fonctionnelles. Or les histoires d’utilisateur ne sont pas vraiment une technique de spécification.

Les différences exposées dans son billet entre ces 2 techniques sont donc à replacer à l’aune de cette distinction.

Il est impossible de connaître toutes les exigences[1] dès le début d’un projet. Depuis 20 ans j’ai participé à de nombreuses définitions et spécifications d’exigences dans différents domaines et il en a toujours été ainsi. En réfléchissant longtemps et en essayant d’imaginer les situations dans lesquelles se trouveront les utilisateurs, on peut bien sûr découvrir un bon nombre d’exigences significatives, mais il existera toujours des exigences que, même en se mettant dans la peau des utilisateurs, on ne pourra pas spécifier voire identifier à l’avance.