Transition rapide et radicale

C'est le moment de passer à la vitesse supérieure.

Jeff Sutherland rappelait jeudi soir, lors du lancement du SUG français, qu'à peine un tiers des équipes proclamant faire du Scrum passaient avec succès le test Nokia. Ce n'est pas beaucoup. Ce n'est pas assez et j'espère qu'en France nous allons obtenir de meilleurs résultats.

Trop de chipotages, de tergiversations, de demi-mesures sous prétexte d'adaptation au contexte, il est temps de passer à des transitions plus radicales. Plus rapides aussi.

La situation a changé. C'est le moment d'entreprendre des changements importants plus vite parce que la crise est là. C'est le moment parce que les autres approches ont montré leurs limites. C'est devenu possible parce que la culture agile est maintenant diffusée et qu'il existe en France plein de consultants de bon niveau prêts à vous aider.

Dans ma présentation de Marseille mardi dernier, j'ai mis en avant une liste de pratiques dont l'apport est reconnu pour chacune d'entre elles :

  1. Cycles courts et timeboxés
  2. Equipe complète + Management laissant l'équipe s'organiser (ScrumMaster)
  3. Représentant des clients dans l'équipe (Product Owner)
  4. Backlog avec priorités
  5. Planification à 2 niveaux
  6. Intégration continue
  7. Scrum meeting
  8. Rétrospective
  9. Pilotage par les tests
  10. Binômage

Pour une transition efficace à l'agilité, il vaut mieux les mettre en œuvre toutes. Avec le cadre Scrum, cela donne un tout cohérent. Adapter au contexte ce n'est pas piocher dans la liste 2 ou 3 pratiques, c'est définir de quelle façon seront appliquées ces pratiques. Pour donner quelques exemples :

  • définir la durée des itérations. Le choix est vaste entre 0 jour et un mois, voire un mois et demi dans certains contextes
  • décider de l'heure et de la forme du scrum meeting. Là aussi, il existe de nombreuses possibilités, pour tenir compte de la répartition géographique de l'équipe
  • définir la notion de fini pour l'équipe. Ce que signifie fini peut varier beaucoup selon le contexte[1].

L'amélioration continue mise en avant à travers les rétrospectives ne doit pas non plus être un prétexte à un démarrage en agile canada dry (comme dirait Thierry). Certes la rétrospective permet de définir des axes d'amélioration mais, ayant lieu pendant que le projet se déroule, elle est plus efficace pour du tuning que pour introduire des changements importants.

Les changements importants il vaut mieux les faire rapidement et au début plutôt que les faire progressivement ce qui peut durer pendant des mois. C'est plus efficace pour changer les mentalités.

L'exemple le plus connu d'un big-bang agile reste Salesforce.

Notes

[1] Nous aurons d'ailleurs vendredi, lors du SigmaT9, un retour d'expérience présenté par Atchik, qui montrera comment l'équipe a adapté cette notion de fini à son contexte.

Par claude le lundi 23 mars 2009, 12:13 - L'agilité en France - Lien permanent

Commentaires

1. Le lundi 23 mars 2009, 16:08 par Jean-Baptiste DUSSEEAUT

Je me sens d'un coup moins seul dans le camps des "radicaux", et vous en remercie.

Maintenant j'aimerai avoir la réputation qui permet de tenir ce genre de propos sans se voir taxer d'extrêmiste utopiste :)

Radicaux et rapides parce que si le changement ne se fait pas vite, il risque de ne pas se faire du tout.
2. Le lundi 23 mars 2009, 20:14 par david

tu n'es pas seul, ca non.
Maintenant, qu'en est-il alors de la méthode "transition douce" suggérée dans la prez "Agilité en situation" (avant dernier slide) si une transition big bang n'est pas possible ?
n'est-elle pas un peu irréaliste du coup ?

La situation a évolué. Avec le constat que ceux qui essaient la transition en douceur tout seuls en se croyant agiles échouent le plus souvent, il est temps de tenter la transition rapide et radicale. La transition rara !
3. Le mardi 24 mars 2009, 09:26 par Bruno Orsier

j'ai eu la chance de vivre une transition radicale à Scrum il y a 4 ans, et je le referai si besoin. Avec le recul, il aurait fallu :
- être plus intransigeant sur le "terminé". Tout laxisme ici fausse tout doucement Scrum.
- être plus flexible sur la manière d'obtenir ce "terminé", pour favoriser l'auto-organisation.
- se faire plus accompagner dans la gestion du changement. Passer à Scrum implique pour tout le monde de faire le deuil de certaines choses, attitudes, confort de pensée, etc. Gérer ce deuil n'est pas évident pour des managers pas formés sur la question.

Sur la définition de terminé (fini fini), je suis d'accord,je considère maintenant cette pratique comme essentielle, alors que je la trouvais mineure dans mes débuts scrumesques. Sur l'accompagnement, oui je pense qu'il est indispensable dans la plupart des contextes.
4. Le mercredi 25 mars 2009, 20:01 par Thierry CROS

bonjour Claude
je partage parfaitement ce point de vue, qui me fait penser tout de même à "Shu Ha Ri". Je suis persuadé effectivement qu'être agile c'est "virer sa cutie" : c'est un "saut quantique" dans la perception de l'appli et des rôles de chacun. Je suis au passage heureux de trouver des pratiques telles que TDD ou intégration continue dans ta liste :-)
Cela pose effectivement la question des résultats de l'agilité. Ce qui serait terrible c'est un bilan négatif porté sur l'agile alors qu'en réalité ce qui avait été fait n'était pas de l'agilité. C'est ce que l'on rencontre fréquemment "je ne fais pas de doc donc je fais de l'XP" ou bien "je fais de l'itératif court donc je suis agile".
Je rejoins la note de Bruno : "faire le deuil", car en fait, l'Agile ne concerne pas que les pratiques mais aussi les convictions de chacun. D'où l'importance en coaching d'accompagner, en particulier le management, dans cette conduite de changement.
(au niveau des itérations, je dirais entre 1 jour et 1 mois ;-)

Je n'aime pas trop employer le japonais (sauf obeya à la place de War room), mais s'il le fallait pour la transition rapide et radicale, ce serait le kaikaku plutôt que le shu ha ri. Pour les itérations, 0 c'était pour évoquer le flot continu du Lean.