SCRUM is the vehicle, not the destination

http://scrumology.com/guest-post-scrum-is-the-vehicle-not-the-destination/ par Chris Sterling, VP d’Ingénierie à AgileEVM.com et auteur du blog http://www.gettingagile.com/

Avez-vous jamais entendu ou prononcé l’une de ces expressions ?

• Nous allons implémenter la méthodologie Scrum.
• Nous appliquons un Scrum modifié.
• Nos développeurs utilisent un processus Scrum.

Ces déclarations peuvent sembler inoffensives mais elles sont les indicateurs d’interprétation erronée potentielle de comment Scrum est le mieux utilisé. Scrum n’est pas un processus de développement complet (bien que presque quoi que ce soit qui a des étapes puisse être considéré comme un processus) et ce n’est pas une méthodologie. Scrum ne vous dit pas comment implémenter le logiciel. C’est une structure simple qui aidera un groupe qui développe des produits à comprendre ce qui ne fonctionne pas bien et comment y remédier.

La Structure de Scrum

Au début, les personnes et équipes implémentant Scrum se concentrent sur le processus sans comprendre pourquoi et comment réaliser chaque partie efficacement. Nous croyons que nous « ferons du Scrum » et en gagnerons tous les bénéfices, simplement :

• En maintenant d’une liste de travail à faire (l’Arriéré de Produit)
• En l’assignant à l’équipe pendant une réunion de Planification de Sprint
• En réalisant ce travail pendant la durée du Sprint

Ce focus sur comment passer à travers les étapes peut être dangereux et irritant pour les individus, équipes et managers. Scrum n’est pas UNE SOLUTION MIRACLE! Aucun processus, pratiques, ou des techniques ne le sont. Au lieu de vous concentrer sur le processus, les pratiques et les techniques de Scrum, je suggère aux personnes, équipes et au management de se concentrer sur les enseignements qui peuvent être produits par une équipe faisant du Scrum et agir sur ceux-ci.

Scrum est un processus empirique de contrôle. L’idée est que vous planifiez et réalisez ensuite quelque chose, inspectez ce que vous avez fait et adaptez ensuite votre comportement pour vous améliorer. C’est une structure apprenante pour des équipes de développement de produits. On se réfère à ce cycle d’étude comme « inspecter et s’adapter ». Les 3 rôles de Scrum sont impliqués dans cet apprentissage : le Propriétaire de Produit, le ScrumMaster et les Développeurs (quand je dis Développeurs je veux dire toute personne dont on a besoin pour construire le produit, pas seulement des programmeurs).

Dans Scrum, Il y a 3 cycles spécifiques « Inspecter et Adapter » :

• La rencontre Scrum Quotidienne (Daily Scrum) permet à l’équipe de se concentrer sur ses engagements pour le Sprint actuel et vérifier s’ils sont toujours en piste pour livrer par rapport à cet engagement. S’ils ne peuvent pas respecter l’engagement, alors on leur demande d’ajuster le Sprint, s’adaptant ainsi à la situation.
• La réunion de Revue de Sprint (Sprint Review) permet aux clients de voir un incrément de produit potentiellement utilisable créé par l’Équipe et de leur fournir un retour d’information qui ajuste le contenu de l’Arriéré de Produit et les priorités. Nous inspectons le produit et nous nous adaptons à une nouvelle compréhension du produit.
• La Rétrospective de Sprint permet à l’Équipe d’améliorer le processus qu’ils utilisent pour délivrer du logiciel à chaque Sprint. On s’attend à ce que l’équipe inspecte son processus honnêtement et à fond pour comprendre comment ils peuvent s’adapter pour que leur capacité collective de livraison soit améliorée dans le prochain Sprint.

Si vous lisez souvent mon blog, vous pourriez reconnaître ici un billet précédent appelé « Kaizen Mentalité » qui contient de bonnes informations sur la façon d’utiliser les leçons apprises et gérez les obstacles autour de celles-ci.

Scrum est plus un outil qu’une méthodologie.

Scrum rendra visible ce qui ne va pas aussi bien qu’il pourrait être. C’est alors aux personnes dans l’équipe et l’organisation e faire des changements pour s’améliorer. Avec chaque amélioration progressive, l’équipe de développement accomplira beaucoup plus efficacement son travail. Plutôt que de vous concentrer sur atteindre la perfection sur chaque étape dans la structure de Scrum, découvrez ce qui peut être amélioré dans votre processus de livraison et adaptez-le en conséquence. Si une partie de la structure de Scrum est difficile à faire ou semble être une perte de temps alors, au lieu d’éliminer cette partie, découvrez pourquoi c’est difficile ou gaspilleur dans son adoption. Il y a d’habitude un obstacle caché derrière ces difficultés et perceptions qui si il est éliminé permettra à l’équipe de développement de produits d’être plus efficace.

Scrum n’est pas une destination.

C’est plutôt un outil qu’une équipe de développement de produits utilise pour continuellement inspecter et adapter leur façon de délivrer pour la rendre plus effective. La destination devrait être votre business et vos objectifs d’efficacité d’équipe de développement. Comment pouvons-nous livrer davantage ? Comment pouvons-nous réduire le temps entre le commencement et la livraison du projet? Comment pouvons-nous délivrer plus souvent à plus bas coût pour stabiliser les sorties de produits ? Comment pouvons-nous réduire le risque dans notre processus de livraison de projet et dans notre portefeuille de projets ?

La destination devrait être substantielle et attractive. Scrum est seulement le véhicule pour vous aider à vous y rendre.