« Comment j’ai lu le Scrum Guide » par Mike Burrows

Traduction

1. Le bon : les choses que le Scrum Guide renforce et qui peuvent facilement se perdre

Mon plus grand « Aha! » pour Scrum fut lorsque j’ai réalisé qu’il ne s’agissait pas de story points, de vélocité, de nombres de Fibonacci, et semblables. Bien que des outils comme ceux-ci semblent marcher suffisamment bien pour certaines personnes, d’autres les considèrent comme une recette pour (i) de la perte de temps ou (ii) pour préparer les équipes pour une déception régulière, les rendant une cible populaire pour être snipée. A juste titre, il n’y a aucune mention d’eux dans le guide.

Le guide parle à la place du backlog de sprint comme à la fois un set d’éléments sélectionnés pour le sprint, et – crucialement – un plan pour les produire. Et comprenez : le backlog de sprint est subordonné à autre chose, l’objectif de sprint :

Pendant que l’Équipe de Developpement travaille, elle garde l’Objectif de Sprint en tête. Afin de satisfaire l’Objectif de Sprint, elle implémente de la fonctionnalité et de la technologie. Si le travail s’avère être différent de ce que l’Équipe de Développement attendait, elle collabore avec le Product Owner pour négocier le périmètre du Backlog de Sprint au sein du Sprint.

Imaginez que vous travaillez dans une organisation qui prend typiquement des mois ou même des années pour livrer quoique ce soit de notable (je n’exagère pas). Maintenant donnez aux personnes une chance de travailler ensemble sur l’achèvement d’un but significatif en l’espace de quelques jours. Et encore. Et encore. C’est puissant. Est-ce que cela pourrait être fait sans Scrum ? Est-ce que cela arrive sans Scrum ? Bien sûr que cela pourrait être fait sans et bien sûr que cela arrive sans, mais Scrum est souvent un véhicule par lequel les personnes expérimentent cela pour la première fois, et c’est quelque chose à célébrer.

Je dois égaIement donner crédit à Ken et Jeff pour avoir été explicites sur l’applicabilité de Scrum :

Scrum (n): Un framework dans lequel les personnes peuvent adresser de problèmes adaptatifs complexes, tout en livrant de manière productive et créative des produits de la plus grande valeur possible.

Je n’emphase pas cette citation comme une sorte de compliment désinvolte, une manière de remettre Scrum dans sa boite. Le domaine décrit ici est énorme ! Et c’est important pour des raisons que nous explorons dans le chapitre 5 du livre Agendashift. Pour mettre en oeuvre un processus Lean, Agile, ou Lean-Agile digne de ce nom, vous devez embrasser l’idée que le travail souvent challengeant, parfois désordonné, et toujours nécessaire pour aider une organisation à changer doit être traité comme un véritable travail, pas juste aux côtés du travail de production, mais intégral en lui-même. La partie « complexe adaptatif » de cette citation paraît non nécessairement jargonneuse mais elle se réfère à l’incapacité d’un plan linéaire à délivrer ce type de changement vital efficacement (voir ma keynote “Change in the 21st century”)

En rassemblant ces éléments, un Scrum fonctionnant correctement signifie :

1. Des objectifs significatifs atteints régulièrement
2. Le système – l’équipe et bien au-delà – évoluant proportionnellement

Cela plus dûr à réussir et même plus dûr à maintenir qu’il n’y paraît, et le guide est honnête au sujet du niveau de challenge impliqué. Ce qu’il omet de dire est que dès que Scrum en vient à signifier labourer dans le backlog, ces bénéfices deviennent de plus en plus difficiles à maintenir. C’est pourquoi on trouve du soutien dans des outils complémentaires tels que Kanban, le Lean Startup, et maintenant Agendashift [1] lorsque les retours de Scrum en lui-même commencent à diminuer.

2. Le vilain : les choses que ne devraient pas être acceptées telles quelles

Le Scrum Master est responsable de la promotion et du support de Scrum comme défini dans le Scrum Guide. Les Scrum Masters font cela en aidant tout le monde à comprendre la théorie, les pratiques, les règles et les valeurs de Scrum.

Le Scrum Master est un leader serviteur pour l’Équipe Scrum. Le Scrum Master aide ceux en dehors de l’Équipe Scrum à comprendre lesquelles de leurs interactions avec l’Équipe Scrum sont utiles et celles qui ne le sont pas. Le Scrum Master aide tout le monde à changer ces interactions pour maximiser la valeur créée par l’Équipe Scrum.

Il y aurait eu tellement de meilleures manières d’introduire le rôle de Scrum Master, et il est inconcevable que cette section ait pu être éditée (encore une fois) dans l’édition 2017 et laissée comme cela. Après un vilain paragraphe facilement construit comme ‘votre première responsabilité est envers Scrum’, on voit une sorte de leadership serviteur limité avec grande précaution qui sera sûrement lu à la lumière de ce qui le précède. Il y a des interprétations plus charitables, mais elles dépendent de suppositions qui ne sont pas rendues explicites.

Pour être un véritable leader serviteur, votre responsabilité est envers vos collègues, votre organisation, vos clients, d’autres parties prenantes, même envers la société. Où Scrum à la lettre vous aide dans ces responsabilités, fantastique. Où il se met en travers, il semble être temps de faire quelque chose non à la lettre. Un véritable maître de Scrum pourrait trouver ces situations rares, mais ayez pitié du débutant en doute ! Même si seulement dans le contexte de ces phrases, si cela ne vous dérange pas que les Scrum Masters soient certifiés après juste 2 jours de formation, cela devrait.

Si l’on veut que notre industrie fasse mieux, il nous faut regarder ses systèmes, prêts à challenger un statut-quo qui tend à se préserver lui-même. Scrum est dans le coin depuis suffisamment longtemps pour se qualifier à ce genre d’examen et quelque soit leur véritable intention, ces phrases largement lues sont trop ouvertes à une interprétation cynique et intéressée.

En réponse à mon tweet hier matin, Neil Killick fut rapide avec cette bien meilleure alternative :

[Traduction des Tweets]

Mike Burrows

Neil Killick

Avec tout le respect que je dois à Neil, ce n’était pas si dûr, n’est-ce pas ?

3. Mon approche

Je pars de la perspective que Scrum décrit des solutions pragmatiques à des problèmes communs. Est-ce que vous avez plusieurs clients, loin de l’équipe ? Alors vous trouverez utile d’avoir un Product Owner grandement disponible. Est-ce que vous avez besoin de quelqu’un pour modeler et faciliter des pratiques et comportements appropriés ? Alors embarquez un Scrum Master. Est-ce que vos boucles de feedback sont trop lentes par rapport au rythme de changement environnemental ? Alors planifiez votre travail afin de remplir de petites timeboxes et réunissez vous quotidiennement.

Réciproquement, si vous n’avez pas tous ces problèmes, vous pourriez ne pas avoir besoin de Scrum. Tout du moins, agissez prudemment :

• Ne placez pas d’obstacles entre une équipe et ses clients s’ils collaborent déjà (yay, les valeurs de manifeste !)
• N’ajoutez pas de couches de process et de cérémonies alors que l’équipe s’auto-organise déjà efficacement
• Ne laissez pas les timeboxes de Scrum entraver le chemin d’un flux rapide et d’un changement rapide – ils n’en ont pas besoin [2], c’est pourquoi je ne les présente pas comme une objection technique à Scrum

Ce sont des problèmes sympas à avoir, vous pourriez me dire. Et à vrai dire, c’est pourquoi je suis bien plus pro Scrum qu’anti. Mais je ne laisse pas mon expérience, mes connaissances ou ma curiosité à la porte. Là où je vois des conflits entre approches, j’approfondis, en m’attendant totalement à trouver un accord, et suis généralement récompensé largement.

Pour la plus grande partie, vous pouvez laisser de côté les éléments intéressés (j’ai appris à les filtrer). Si vous aidez à emmener de la clarté et de l’entente autour d’une finalité et des objectifs (choses sur lesquelles Agendashift et le guide s’entendent totalement), et si vous commencez par les besoins, recherchez l’accord sur les résultats, et ainsi de suite [3], il est probable que vous approchiez les choses de la bonne manière. Avec le temps, vous trouverez que les choses ressembleront de moins en moins à ce que vous avez entendu en classe, mais ne laissez personne vous couvrir de honte pour cela. Expert ou débutant (et oui, agissez en conséquence), vous êtes responsables. Vous êtes un leader !

[1] A propos d’Agendashift
[2] Scrum et Kanban revisités
[3] Agendashift en 5 principes

Je suis reconnaissant à Olivier My, Neil Killick, Johan Nordin, et Karen Beck pour leur feedback précieux sur les prémisses de cet article.