Scrum et XP depuis les Tranchées

Les équipes doivent connaître les bases de Scrum. Comment est-ce que vous créez et estimez un backlog de produit ? Comment le transformez-vous en backlog d'itération ? Comment gérez-vous une courbe du reste à faire et calculez la vélocité de l'équipe ? Le livre d'Henrik est un kit de démarrage avec les pratiques de base qui aident les équipes à passer d'un essai de Scrum à une bonne implémentation de Scrum.

Une bonne implémentation de Scrum devient plus importante pour les équipes qui cherchent des investissements financiers. En tant que coach Agile pour un groupe investissant en capital-risque, je les aide à investir seulement dans les entreprises agiles qui appliquent bien les pratiques agiles.

L'associé principal du groupe a demandé à toutes les sociétés au sein de son portefeuille si elles connaissent la vélocité de leurs équipes. Elles ont des difficultés à répondre à la question tout de suite. Les futures opportunités d'investissement vont obliger les équipes à comprendre leur vélocité de développement logiciel.

Pourquoi est-ce si important? Si les équipes ne connaissent pas leur vélocité, le Directeur de produit ne peut créer de feuille de route pour le produit avec des échéances crédibles. Sans des échéances fiables, l'entreprise peut échouer et les investisseurs peuvent perdre leur argent !

Ce problème touche les grandes sociétés comme les petites, nouvelles ou anciennes, financée ou non. Lors d'une discussion récente sur l'implémentation de Scrum de Google à une conférence londonienne, j'ai demandé à une audience de 135 personnes combien appliquaient Scrum et 30 ont répondu positivement. Je leur ai ensuite demandé s'ils faisaient du développement itératif selon les standards de Nokia. Le développement itératif est fondamental dans le Manifeste Agile - délivrer tôt et fréquemment du logiciel qui marche. Après des années de rétrospectives avec des centaines d'équipes Scrum, Nokia a développé des exigences de base pour le développement itératif :

• Les itérations doivent être de durée fixe et inférieure à six semaines.
• Le code à la fin de l'itération doit être testé par le AQ et doit fonctionner correctement

Sur les 30 personnes qui prétendaient appliquer Scrum, seulement la moitié affirmait se conformer au premier principe du Manifeste Agile sur les standards Nokia. J'ai ensuite demandé s'ils suivaient les standards Nokia pour Scrum :

• Une équipe Scrum doit avoir un Directeur de produit et doit savoir qui c'est.
• Le Directeur de produit doit gérer un Backlog de produit avec des estimations fournies par l'équipe.
• L'équipe doit avoir une Courbe du reste à faire et doit connaître sa vélocité.
• Aucune personne extérieure ne doit interférer avec l'équipe durant le Sprint.

L'apport du livre d'Henrik est que, si vous suivez les pratiques décrites, vous aurez un Directeur de produit, des estimations pour votre Backlog de produit, une Courbe du reste à faire, et vous connaîtrez la vélocité de votre équipe ainsi que de nombreuses autres pratiques essentielles pour un Scrum dangereusement opérationnel. Vous passerez le test Nokia pour Scrum et serez digne de l'investissement dans votre travail. Si vous êtes une startup, vous pouvez même bénéficier du financement d'une société capital-risque. Vous serez peut-être le futur du développement logiciel et le créateur d'une nouvelle génération d'éminents logiciels.

Jeff Sutherland,
Ph.D., Co-Créateur de Scrum

Scrum et Extreme Programming (XP) demandent tous deux aux équipes de finir certains éléments tangibles et livrables de leur travail à la fin de chaque itération. Ces itérations sont conçues pour être courtes et à durée finie. L'accent mis sur le fait de livrer du code qui marche au bout d'une courte période de temps signifie que les équipes Scrum et XP n'ont pas de temps pour faire de la théorie. Elles ne s'évertuent pas à dessiner le modèle UML parfait dans leur outil de modélisation, à écrire des cahiers des charges parfaits, ou à écrire du code qui pourra s'adapter à tous les changements futurs imaginables. A la place, les équipes Scrum et XP se concentrent pour que les choses soient terminées. Ces équipes acceptent qu'elles puissent faire des erreurs en chemin, mais elles réalisent aussi que le meilleur moyen pour trouver ces erreurs est d'arrêter de penser au logiciel au niveau théorique de l'analyse et de la conception, mais plutôt de se lancer, de se salir les mains, et de commencer à construire le produit.

C'est par cette focalisation sur le « faire » plutôt que le « théoriser » que se distingue ce livre. Il est facile de s'apercevoir que Henrik Kniberg l'a bien compris dès le début. Il ne fait pas de longs discours sur ce qu'est Scrum ; pour ça, il se réfère à des sites faciles à comprendre. Au lieu de cela, Henrik entre dans le vif du sujet et commence directement à décrire comment son équipe gère et travaille son carnet de produit. A partir de là, il parcourt tous les autres éléments et les pratiques d'un projet agile bien-portant. Pas de théorie. Pas de référence. Pas de note de bas de page. Aucun besoin de cela. Le livre d'Henrik n'est pas un exposé philosophique expliquant pourquoi Scrum marche ou pourquoi vous voudriez utiliser ceci ou cela. Il s'agit d'une description sur comment une certaine équipe agile efficace travaille.

C'est pour cette raison que le sous-titre du livre, « Comment nous appliquons Scrum », est si approprié. Ce n'est peut-être pas la façon dont vous appliquez Scrum, c'est comment l'équipe d'Henrik applique Scrum. Il se peut que vous vous demandiez pourquoi vous devriez vous intéresser à la façon dont une autre équipe applique Scrum. Vous devriez vous y intéresser car nous pouvons tous apprendre à améliorer notre pratique de Scrum en tirant partie des expériences des autres, spécialement lorsqu'ils le font bien. Il n'y a pas et il n'y aura jamais de liste des « meilleures pratiques Scrum » car le contexte de l'équipe et du projet prévaut sur toute autre considération. A la place, ce que nous avons besoin de savoir, ce sont les bonnes pratiques et les contextes dans lesquels elles ont réussi. Lisez assez de témoignages d'équipes qui réussissent et comment elles se sont débrouillées et vous serez préparé pour affronter les obstacles survenus sur votre chemin durant votre mise en oeuvre de Scrum et XP.

Henrik fournit une multitude de bonnes pratiques ainsi que l'indispensable contexte pour nous aider à mieux comprendre comment appliquer Scrum et XP dans les tranchées de nos propres projets.

Mike Cohn
Auteur de Agile Estimating and Planning et User Stories Applied for Agile Software Development.

Scrum ca marche ! Au moins pour nous (c'est-à-dire mon client actuel à Stockholm, dont je n'ai pas l'intention de mentionner le nom ici). J'espère qu'il marchera pour vous aussi ! Peut-être que ce papier vous aidera au long du chemin.

C'est la première fois que j'ai vu une méthodologie de développement (désolé Ken, un cadre) marcher exactement comme dans le bouquin. Plug'n play. Nous sommes tous heureux avec lui - développeurs, testeurs, managers. Il nous a aidés à nous sortir d'une situation difficile, et nous a permis de maintenir une focalisation et un élan malgré de sévères turbulences du marché et des réductions de personnel.

Je ne devrais pas dire que j'ai été surpris, mais, eh bien oui, je l'ai été. Après avoir initialement digéré quelques livres sur le sujet Scrum semblait bien, mais près trop bien pour être vrai (et nous connaissons tous le proverbe « quand quelque chose semble trop beau pour être vrai... »). Donc j'étais légitimement un peu sceptique. Mais après avoir appliqué Scrum pendant un an je suis suffisamment impressionné (et la plupart des gens dans les équipes aussi) pour que je continue probablement à utiliser Scrum par défaut dans les nouveaux projets chaque fois qu'il n'y a pas une très bonne raison de faire autrement.