Scrum Update : WTF ? | Genba

Scrum Update : WTF ?

Ecrit par
Catégorie : Agile 

« Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint ». Voici l’une des précisions qu’apportent la mise à jour du Scrum Guide que l’on peut lire sur le site de Ken Schwaber : http://bit.ly/nPVHl3.

J’avoue avoir eu l’impression que le temps s’était arrêté pendant quelques instants… Et j’avoue avoir ressenti à la première lecture de cette phrase une certaine forme d’incompréhension, et même plutôt de vide sous mes pieds : « je n’ai finalement RIEN compris à Scrum » !!

Un mot clé central : l’engagement

Le terme « commit », qui signifie « engagement » en français, est présent 7 fois dans le Scrum Guide (avant cette dernière version). Le Scrum Guide fait même référence à la petite fable du cochon et de la poule qui veulent monter un restaurant, pour (parfaitement) bien illustrer la différence entre l’engagement et l’implication.

L’engagement est donc central dans Scrum, et on le retrouve à tous les étages :

  • le PO s’engage auprès de sa hiérarchie, de ses actionnaires, et/ou de ses clients vis-à-vis du contenu du produit, des conditions de sa réalisation (respect d’une date ou d’un budget);
  • le PO s’engage auprès de l’équipe à lui fournir tous les éléments et tout le temps nécessaire pour permettre à l’équipe de ne pas être bloqué;
  • l’équipe s’engage auprès du PO, entre autres, à livrer avec toujours le même niveau de qualité…

Un virage à 180° ?

Si on prend donc la première phrase de ma citation au sens strict, c’est terminé l’équipe ne s’engage plus : elle devient un poulet ! Je me rappelle de ma formation ou lors de conférences ou l’on parlait de « chasse aux poulets », en veillant à éviter que des membres du Scrum ne fassent que s’impliquer. Voilà donc l’objet de mon étonnement.

Si on lit la suite, on ne parle donc plus d’engagement mais de « prévisions » (forecast en anglais). D’ailleurs, le terme commit n’apparait plus que 3 fois dans la nouvelle version du Scrum Guide (et encore, sous la forme commitee…). La fable aussi a été supprimée…

Que faut-il comprendre ?

Après une bonne heure de débat avec moi-même, j’en viens à une analyse toute personnelle. Je me rappelle des discussions que j’ai eues avec l’un de mes anciens managers (merci Eric !) qui m’a permis de bien comprendre la notion d’engagement telle que Scrum l’entendait. Notre discussion portait sur le fait que, à cette époque, je considérais que l’équipe ne s’engageait pas lors des Sprint Planning (tiens, ça me rappelle quelque chose), ce qui faisait bondir mon manager sur sa chaise !

En fait, dans mon discours, je voulais faire apparaître une nuance entre l’engagement de Scrum, et l’engagement que peut avoir une SSII lorsqu’elle contractualise un forfait avec son client. Dans le dernier cas, il faut bien comprendre que quelque soit les difficultés techniques ou de compréhension du métier rencontrées par la SSII, quelque soit le manque d’implication du client pour aider la SSII à bien cadrer ce qu’elle a à faire, si elle est en retard pour livrer tout le produit en temps voulu, elle n’aura pas d’autre choix que de terminer (bâcler ?) le boulot à temps, et ainsi faire venir ses développeurs nuits et jours, soirs et week-ends.

Dans Scrum, tel que je le comprenais jusqu’à ce matin, et après convergence dans la discussion avec mon manager, l’équipe s’engage de manière très forte, à la différence près que si elle n’a pas fini, elle s’arrête. Un peu comme un sablier qui s’écoule lors d’un examen, elle pose son stylo (principe de la timebox). C’est cette nuance très subtile qui fait que Scrum et le forfait sont parfaitement incompatibles.

Pour en revenir à notre sujet d’origine, je pense donc, après cet intense moment de réflexion, que si Ken et Jeff ont apporté ces modifications, c’est justement pour éviter une mauvaise interprétation de la notion d’engagement, telle que la culture du forfait nous l’a imposée. Ils ont donc, toujours selon moi, voulu marquer cette différence en parlant de « prévision ».

Une fausse bonne idée

Dans tous les cas, je trouve cela dommage. J’aime cette notion d’engagement, à tel point que je la pousse parfois jusque dans les daily scrum. J’essaye de savoir si chaque membre peut s’engager sur la tache qu’il a en cours, et si l’équipe peut s’engager à finir la User Story la plus importante, pour la forcer à trouver la bonne organisation et concentrer l’effort là où il faut. L’idée est de comprendre ensuite pourquoi l’engagement n’a pas été tenu, sans jugement de valeur, et en essayant de trouver à nouveau la bonne organisation pour avancer. C’est cela que j’appelle la pression positive.

J’ai peur que cette notion de « prévision » ne soit considérée comme un relâchement de pression total, induisant l’apparition de poulets au détriment des cochons, suivi d’une baisse de la vélocité, de la confiance mutuelle entre équipe et PO, de l’abandon de la qualité, des difficultés énormes dans le projet, et à terme de la perte de l’intérêt de l’agile pour ceux qui sponsorisent cette approche.

Ce tableau un peu noir que je dresse ici ne demande qu’à s’éclaircir, notamment lorsque les principaux protagonistes auront expliqué ce qu’ils avaient derrière la tête.

Comments

4 Comments on Scrum Update : WTF ?

  1. Jérôme Avoustin on lun, 25th juil 2011 14 h 07 min
  2. Un billet de blog préalable à l’update a été posté par Ken à cet endroit :
    http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/.

    La raison semble celle évoquée dans mon billet : l’engagement était un terme trop marqué, et trop pris au pied de la lettre. Cela ne reste qu’une affaire d’emploi de termes et non une modification structurelle.

    Les commentaires qui suivent montrent un équilibre entre ceux qui approuvent le changement pour l’emploi du terme « forecast », et ceux qui préfèrent continuer à conserver le terme « commit ».

    Pour ma part, je reste sur ma position initiale, expliquée dans ce billet de blog. le problème va être maintenant d’expliquer ce changement, sans que ça ne soit perçu comme une baisse de pression, et donc potentiellement d’efficacité…

  3. Oaz on jeu, 1st sept 2011 16 h 10 min
  4. « baisse de la vélocité »
    Ces quelques mots dans la conclusion montrent à quel point on peut avoir une vision biaisée des méthodes agiles.

    La vélocité baisse ? Et alors ?
    La vélocité n’est qu’un indicateur (très imparfait d’ailleurs) pour essayer de planifier les développements futurs. Avoir peur d’une baisse de vélocité, c’est la considérer comme une mesure de productivité, ce qu’elle n’est pas.

    De plus, les hausses de vélocité peuvent être bien pires.
    Que dire d’une équipe qui tient toujours ses « engagements » en terminant toujours en avance, avec des utilisateurs satisfaits par le résultat produit et avec une vélocité croissante sur plusieurs mois ?
    Dit comme ça, c’est plutôt sympa, non ?
    Que dire alors si cette même équipe, après avoir livré le produit part sous d’autres cieux et laisse les personnes en charge de la maintenance avec un machin prêt à exploser tellement il a été codé à la va-vite pour respecter les « engagements », tout en sachant que ceux-ci n’auraient pas besoin de durer très longtemps ?

  5. Jérôme on dim, 23rd oct 2011 22 h 04 min
  6. Salut Olivier,

    Bien loin de moi de faire l’apologie de la chasse à la vélocité.
    En revanche, je suis plus sensible à sa stabilité, ce qui est bien différent.
    Et je suis bien d’accord avec toi qu’une augmentation brutale peut cacher bien des choses…

    Peu importe son niveau finalement, mais pour un manager, je comprends qu’il souhaite se projeter, en diminuant progressivement l’incertitude.
    Et pour la réduire, et donc avancer dans le cône d’incertitude, il faut que la vélocité soit stable.

  7. Xavier NOPRE on dim, 28th oct 2012 11 h 32 min
  8. Salut Jérôme,

    Suite à nos échanges du jour, je viens de lire ton article.

    Je ne suis pas choqué, le terme « engagement » peut porter à confusion, surtout pour ceux qui veulent bloquer cout-temps-contenu et se rassurer.

    Pour moi, l’engagement de l’équipe est en lien direct avec une sorte de « Give me five », c’est-à-dire finalement : est-ce que l’équipe y croit ? Est-ce qu’elle croit que la charge prévue pour l’itération à venir est réaliste et réalisable ? Donc, êtes-vous prêts à vous engager sur ça ?

    Mais bien sûr, la meilleure mesure est lorsque le résultat est produit. En début d’itération, on se base sur des estimations qui n’excluent pas des écarts, des imprévus. Cet engagement est signe de confiance, de croyance (on y croit) mais pas un engagement dur sur le résultat !

N'hésitez pas à me faire vos retours...
et n'oubliez pas de créer votre gravatar!





*

Smartview, Conseil et Formation