Travaillez-vous avec Scrum ou eXtreme Go Horse (XGH)?
Parfois, nous sentons que nous travaillons avec autre chose que Scrum.

Je suppose que si vous avez travaillé avec Scrum, à un moment donné, vous vous êtes demandé: «Est-ce ce Scrum? « . J’ai connu de nombreux malentendus à propos de Scrum, et autant d’anti-patterns, qui ont empêché les équipes d’obtenir les avantages que Scrum peut apporter. Malheureusement, de nombreuses organisations sont déçues et abandonnent Scrum; mais travaillent-ils avec Scrum ou eXtreme Go Horse?
La méthodologie agile eXtreme Go Horse est une satire de cadres agiles mis en œuvre inadéquats; pourtant, j’ai vu de telles situations avec de nombreuses équipes Scrum. Les cas auxquels je fais référence sont:
- Bugs sans fin et dette technique.
- Blâmer les développeurs lorsque les choses tournent mal.
- Pas de hiérarchisation claire.
- Pas de propriété.
Bugs sans fin et dettes techniques
J’ai travaillé avec plusieurs équipes Scrum, à un moment donné, j’avais l’impression que nous étions dans une spirale négative; plus nous travaillions, plus nous créions de bugs et de dettes techniques. Très probablement, vous avez vécu quelque chose de similaire à cela si vous avez travaillé avec Scrum. La cause première de ce problème peut varier considérablement, par exemple, de mauvaises définitions de fait, un processus de développement médiocre, une pression élevée, etc.
Si nous regardons l’eXtreme Go Horse, il indique que pour chaque problème résolu, sept autres sont créés. J’ai vécu exactement cela avec certaines équipes Scrum. Au lieu de maximiser la quantité de travail non effectuée, avec XGH, nous faisons toujours plus.
3. Vous devrez toujours faire de plus en plus de XGH. Pour chaque problème résolu en utilisant XGH 7, d’autres sont créés. Et tous seront résolus en utilisant XGH. Par conséquent, XGH tend vers l’infini.
– Daniel Alonso, Méthodologie eXtreme Go Horse (XGH)
Comment éviter cela dans Scrum? Nous ne savons pas tout d’avance, c’est pourquoi il est essentiel d’inspecter et d’adapter. L’inspection peut avoir lieu à tout moment, mais il y a un moment précis où l’équipe s’arrête, et l’accent est mis sur l’inspection du Sprint et l’adaptation pour être meilleure; c’est la Rétrospective. Chaque Sprint, la Scrum Team devrait devenir une meilleure version d’elle-même, ce qui signifie que nous apprenons de nos échecs et nous améliorons.
Le Scrum Master encourage l’équipe Scrum à améliorer, dans le cadre du processus Scrum, son processus de développement et ses pratiques pour le rendre plus efficace et agréable pour le prochain Sprint. Au cours de chaque rétrospective Sprint, l’équipe Scrum prévoit des moyens d’améliorer la qualité des produits en améliorant les processus de travail ou en adaptant la définition de «Terminé», le cas échéant et sans entrer en conflit avec les normes de produit ou d’organisation.
Blâmer les développeurs uniques
Dans les équipes Scrum, la responsabilité ne revient jamais à une seule personne, ce qui signifie que toute l’équipe est toujours responsable. Malheureusement, j’ai vécu dans de nombreux scénarios où les développeurs s’accusent les uns les autres une fois que les bogues apparaissent.
Si vous entendez des phrases des développeurs comme « Je n’ai pas développé ça, « « J’ai dit que ça ne marcherait pas « , « Je n’ai rien à voir avec ça, « alors vous vivez ce scénario.
Les membres individuels de l’équipe de développement peuvent avoir des compétences spécialisées et des domaines de concentration, mais la responsabilité appartient à l’équipe de développement dans son ensemble.
Les développeurs qui se blâment font également partie de XGH. Bien que dans les équipes Scrum, cela ne devrait jamais se produire car la responsabilité appartient à l’équipe, j’ai rencontré de tels scénarios plusieurs fois. Comment éviter ce piège? Une fois que l’équipe de développement établit et accepte la définition de Terminé, les développeurs ont tendance à cesser de se blâmer.
8. Soyez prêt à sauter lorsque le bateau commence à couler. Ou blâmer quelqu’un d’autre.
Pour les personnes utilisant XGH un jour, le bateau coule. Au fil du temps, le système devient un monstre plus gros. Vous feriez mieux d’avoir votre curriculum vitae prêt lorsque la chose tombera. Ou avoir quelqu’un d’autre à blâmer.
– Daniel Alonso, Méthodologie eXtreme Go Horse (XGH)
La définition de Terminé est essentielle pour l’équipe de développement, ne sous-estimez pas cela, aidez l’équipe à l’établir et à vous mettre d’accord. Une fois que cela se produit, l’engagement et l’engagement augmenteront.
Pas de hiérarchisation claire
Lors de ma première expérience en tant que Product Owner, tout était une priorité. Je me souviens que nous ne pouvions nous concentrer sur rien, car à chaque fois nous devions changer de direction. Nous avions un Project Manager Officer (PMO), alors je lui ai demandé quelle était notre priorité, il a répondu: «Nous avons 50 projets, nous devons tous les terminer, ce sont tous des priorités ». Nous avons donc trouvé notre façon de définir la priorité:
La personne qui crie le plus fort obtient la priorité de la demande.
Pour sûr, ce n’était pas durable. Nous devions nous adapter et trouver un meilleur moyen. Malheureusement, ce scénario sans priorité claire a duré des mois. Après avoir lu l’eXtreme Go Horse, j’étais sûr que nous le suivions au lieu de Scrum.
11. XGH est anarchique. Pas besoin de chef de projet. Il n’y a pas de propriétaire et chacun fait ce qu’il veut lorsque les problèmes et les exigences apparaissent.
– Daniel Alonso, Méthodologie eXtreme Go Horse (XGH)
Dans Scrum, le Product Owner est responsable de la définition quoi une priorité est et quoi n’est pas. Pour que cela soit possible, l’organisation doit respecter la décision des propriétaires de produits. Une fois que les entreprises commencent à utiliser Scrum, la priorisation peut nécessiter une attention particulière car elle implique plusieurs parties de l’organisation.
Le Product Owner est une personne, pas un comité. Le Product Owner peut représenter les désirs d’un comité dans le Product Backlog, mais ceux qui souhaitent modifier la priorité d’un élément du Product Backlog doivent s’adresser au Product Owner.
Pour que le Product Owner réussisse, toute l’organisation doit respecter ses décisions. Les décisions du Product Owner sont visibles dans le contenu et la commande du Product Backlog. Personne ne peut forcer l’équipe de développement à travailler à partir d’un ensemble d’exigences différent.
Aucune propriété
J’ai été dans des scénarios où les développeurs ont refusé de résoudre les problèmes parce qu’ils n’y travaillaient pas. Cela s’est produit une fois lorsque le développeur qui a développé une partie spécifique du produit n’était pas présent, puis un problème est apparu et personne ne voulait y travailler.
Si vous entendez des phrases comme «Je ne peux pas y travailler « , « Nous devons attendre qu’il revienne » « J’ai peur de toucher cette partie du code », etc. Je crains que les développeurs ne soient propriétaires du produit ou que vous travailliez avec eXtreme Go Horse au lieu de Scrum.
22. Le problème ne vous appartient que lorsque votre nom figure sur les documents de code.
– Daniel Alonso, Méthodologie eXtreme Go Horse (XGH)
Dans Scrum, les équipes doivent être transparentes, ce qui signifie que tous les artefacts sont transparents. L’équipe de développement est propriétaire du processus de développement, ce qui signifie qu’en cas de problème, elle en est responsable. L’équipe de développement doit être en mesure de résoudre un problème, quelle que soit la personne qui y ait travaillé auparavant.
Le Scrum Master doit travailler avec le propriétaire du produit, l’équipe de développement et les autres parties impliquées pour comprendre si les artefacts sont complètement transparents. Il existe des pratiques pour faire face à une transparence incomplète; le Scrum Master doit aider chacun à appliquer les pratiques les plus appropriées en l’absence de transparence totale. Un Scrum Master peut détecter une transparence incomplète en inspectant les artefacts, en détectant les modèles, en écoutant attentivement ce qui est dit et en détectant les différences entre les résultats attendus et réels.
Le travail du Scrum Master est de travailler avec l’équipe Scrum et l’organisation pour augmenter la transparence des artefacts. Ce travail implique généralement l’apprentissage, la conviction et le changement. La transparence ne se produit pas du jour au lendemain, mais est un chemin.
Emballer
Scrum est un cadre robuste. Cependant, de nombreuses équipes ne parviennent pas à l’implémenter correctement, avant d’abandonner, d’inspecter et d’adapter. Assurez-vous que vous n’utilisez pas eXtreme Go Horse au lieu de Scrum.
- Scrum est empirique. Plus nous en faisons, plus nous en apprenons. Inspectez et adaptez chaque fois que cela est possible. Faites des rétrospectives à la fin de chaque sprint.
- Il n’y a pas une seule personne responsable au sein des développeurs; au lieu de cela, toute l’équipe de développement est responsable du travail effectué.
- Assurez-vous que le Product Owner fait respecter ses décisions.
- Ne tombez pas dans le piège de multiples priorités; il n’y a qu’une seule priorité.
Voulez-vous écrire pour Serious Scrum ou discuter sérieusement de Scrum?