Par le pouvoir du Scrum Master, transforme-nous !

En continuité avec l’article de ma collègue de Xebia sur la thématique du Scrum Master en pratique, je vous propose de découvrir aujourd’hui une proposition de mise en place incrémentale du Scrum dans une équipe.

Mise en place de Scrum en « sous marin »

Que faire si votre équipe ne fait pas du Scrum ? Comment faire pour migrer une équipe vers une logique Agile de manière incrémentale ?

Pour ce genre de situation, nous vous proposons une liste d’étapes à suivre pour vous aider à faire glisser votre équipe vers une démarche Scrum. Ceci ne reste qu’une proposition et n’est en rien la solution parfaite.

Priorisation des tâches

Afin de vous proposer ce modèle, nous avons estimé les éléments qui composent le Scrum et nous avons cherché à les prioriser par rapport à leur retour sur investissement (ROI).

Le ROI dans un contexte financier est calculé par la formule suivante :

Dans l’univers Agile, le gain correspond à la valeur ajoutée d’une fonctionnalité et le coût est la complexité pour la réaliser. Ces deux valeurs étant souvent estimées sur deux unités de mesure différentes, la formule appliquée est alors simplifiée :

En règle générale, cette formule est d’une grande aide lorsque l’on souhaite prioriser les tâches à faire. Il sera alors beaucoup plus facile d’identifier celles qui vous apporterons le plus au moindre coût. Il est donc très fortement conseillé d’utiliser cette formule lorsque vous cherchez à prioriser un backlog.

Dans notre application de cette formule, nous avons considéré que la valeur ajoutée était l’amélioration du cadre de travail de l’équipe de développement et nous avons choisi comme complexité les problèmes techniques et logistiques.

Cette explication étant faite, lançons dans notre mise en place du Scrum !

Visibilité et communication

Les éléments du Scrum qui apportent sans doute le plus de gains avec un effort réduit sont les deux cérémonies centrées sur l’équipe : Le daily stand up et la rétrospective !

Ces deux cérémonies sont très importantes car elles sont récurrentes et permettent aux développeurs de parler de leurs obstacles.

Durant le daily stand up, le développeur signale entre autres ce qui le bloque pour avancer dans son travail au jour le jour.

Durant la rétrospective, on demande à l’équipe de prendre du recul sur ce qui a été fait pour ensuite prendre des décisions afin d’améliorer le mode de fonctionnement.

La valeur ajoutée de ces cérémonies est donc très importante et elles ne sont pas complexes à mettre en place. Il suffit de disposer d’un espace de travail et d’un laps de temps dédié pour se réunir régulièrement.

Il est évident qu’il faudra réussir à délier les langues et à organiser des débats constructifs où tout le monde peut donner son opinion. Or cela fait justement partie du quotidien du Scrum Master (voir le quotidien du Scrum Master).

L’excellence technique

La seconde étape possède une très forte valeur ajoutée mais est aussi d’une très forte complexité dans sa mise en place : Instaurer un processus de qualité au niveau des développements !

Le Scrum stipule qu’il faut livrer régulière du logiciel de qualité proche de la production, mais ne nous explique pas comment faire.

Nous parlons ici d’un sujet non explicitement inclus dans Scrum mais qui est vital dans toute méthode Agile : l’excellence technique, l’un des 12 principes sous jacents du manifeste agile !

Ma vision sur ce sujet ne cesse d’évoluer au fil du temps :

La première méthode Agile que j’ai connu qui traite le mieux la majorité de ces problématiques était l’eXtreme Programming (XP).

Dans l’univers de Microsoft, nous parlons souvent de l’ALM (Application Lifecycle Management) mais la vraie communauté émergente qui est naît et qui n’est dépendante d’aucun langage est le mouvement du Software Craftsmanship qui propose un manifeste en complétude du manifeste Agile.

Il est capital d’investir du temps et de l’argent dans cette étape car la négliger risquerait de mettre à mal les belles promesses de l’agilité :

• La maîtrise de dette technique ;
• La capacité au changement ;
• Un produit opérationnel répondant au besoin ;
• La non-régression ;
• Etc.

Les méthodes Agiles embrassent le changement mais si nous ne possédons aucun moyen d’en contrôler et tracer les impacts, le produit sera alors instable et donc inexploitable. De ce fait,iIl est impératif de compléter le Scrum avec des bonnes pratiques d’artisanat logiciel.

eXtreme Programming

L’élément capital venant de l’XP qu’il faut absolument inclure dans sa structure est la gestion des tests automatisés. Tout le monde vous le dira : Pour qu’un projet Scrum fonctionne bien, il faut tester, tester, tester !

La recette est toujours une période difficile et trop coûteuse. La meilleure stratégie pour remédier à cela est d’automatiser au maximum vos tests. Une bonne pratique du développement dirigé par les tests (TDD) vous aidera à détecter plus rapidement les problèmes de régression. C’est est l’un des moyens les plus sûrs pour s’assurer de la qualité de son produit. Plus votre couverture du code par les tests sera importante et plus vous pourrez réduire la durée de la recette manuelle.

L’élément complémentaire aux tests automatisés est l’intégration continue dans un build. Par cette pratique, la santé et la compilation de votre solution seront contrôlées régulièrement.

Enfin, il ne faut pas hésiter à compléter d’un maximum de pratiques XP : la revue de code ou le Pair Programming pour maintenir le partage du savoir, le refactoring pour garantir un code propre, la normalisation du code pour limiter la dette technique et faciliter la compréhension du code, etc.

Les plus grands succès connus sont des projets où le Scrum a été complété par XP et ceci n’est pas dû au hasard !

Software Craftsmanship / Application Lifecycle Management

En plus de ces pratiques XP, il faut penser à l’univers de l’artisanat logiciel afin d’offrir une meilleure solution d’ingénierie :

• La gestion d’un Build ;
• La traçabilité des développements
• le contrôle de la couverture du code par les tests ;
• le développement par branches ;
• l’industrialisation des développements ;
• le déploiement automatisé;
• …

Petit aparté : ALM ou Software craftsmanship ?

A mes yeux, le mouvement qu’il est intéressant de suivre est celui du Software Craftsmanship. Il est le chaînons manquant au Scrum pour permettre d’atteindre l’excellence technique !

Dans l’univers de Microsoft, nous parlons par contre d’ALM…  (Malgré le fait que l’ALM et le Software Craftsmanship ne soient pas la même chose, je me permet de prendre ce raccourci aujourd’hui car les bonnes pratiques précédemment cités sont communes aux deux)

L’ALM est un sujet capital aux yeux de Microsoft qui est mis en avant depuis la version 2012 de leurs produits et qui continue d’être mis en avant dans la version 2013 disponible en preview.

Autant être honnête, je présente ce besoin comme un prérequis du Scrum, mais en fait il est essentiel pour tout type de gestion de projet.

Ce qu’il faut retenir

Toutes ces pratiques sont là pour améliorer la qualité du produit et accélérer le feedback. Compléter votre processus de développement avec ces bonnes pratiques vous fournira donc une quantité importante d’information pour surveiller et améliorer la qualité de vos applications.

De plus, il est toujours intéressant de pouvoir gagner du temps sur toutes les tâches répétitives et chronophages comme le déploiement ou le lancement des tests par exemple.

Il est sûr que toutes les technologies ne permettent pas cette mise en place. Il est possible de faire du Scrum sans automatisation en ayant uniquement des plateformes de tests adéquats ou des mécanismes de test régulier.

Le challenge de l’excellence technique peut représenter un coût important surtout au début mais son gain est d’autant plus important que le temps passe et que la solution grossit.

Si vous négligez cette étape, il y a peu de chance que votre expérience Scrum puisse être un réel succès.

Mise en place des autres pratiques Scrum

Arrivé à ce niveau là, si votre équipe vise l’excellence technique et que vous arrivez à échanger durant vos cérémonies, vous ne devriez plus rencontrer énormément de freins techniques pour mettre en place ce nouveau mode de fonctionnement au sein de votre équipe.

Le cœur de cette dernière est déjà en place : Qualité et communication au sein de l’équipe.

Maintenant vous pouvez compléter vos pratiques avec le reste des éléments qui composent le Scrum :

• Introduisez le concept du backlog de produit (en attendant d’avoir un Product Owner) ;
• Traduisez les fonctionnalités qu’on vous fournie en User Stories (US) ;
• Définissez une unité de mesure pour estimer la complexité des users stories avec votre équipe (taille de T-shirt, suite de Fibonacci,…) ;
• Sensibilisez votre équipe sur l’importance des tests d’acceptation ;
• Commencez à découper le temps en sprints ;
• Réfléchissez avec votre équipe sur les pré-recquis nécessaires pour qu’une US soit prête à être réaliser (READY) ;
• Déterminez aussi les exigences pour qu’une US soit terminée tout en respectant les objectifs de qualité que vous vous êtes fixé lors de l’étape précédente (DONE) ;
• Commencez à mesurer votre vélocité Mettez en place le planning poker et les autres cérémonies restantes ;
• Etc.

N’essayez pas de tout mettre en place en même temps, au risque de vous dispersez et casser votre belle dynamique. N’oubliez donc pas d’y aller petit à petit (cf. baby steps) et de ne pas vous éparpillez sur trop de chantier en parallèle, cela est le plus souvent contre-productif.

Maintenant ce sont les pratiques qui touchent l’extérieur de l’équipe qu’il faut mettre en place.

Identifier le Product Owner

Vous y êtes presque ! Vous avez une équipe opérationnelle. Votre environnement est prêt. Il ne vous reste plus qu’à identifier la personne côté métier qui va vous permettre d’alimenter votre équipe avec des fonctionnalités exprimées en Users Stories: Le Product Owner (PO) !

Dans une mise en place en « sous-marin », avoir un Product Owner sera une tâche très ardue. Malgré le fait que vous avez pu modifier le mode de fonctionnement de votre équipe, ici il est question de nouveaux individus qui ne font pas parties de l’équipe directement. Il faudra donc trouver une sorte de sponsor au sein de la maîtrise d’ouvrage qui acceptera de jouer le jeu avec vous.

Vous allez donc entreprendre un partie de « Qui est ce ? » au sein de l’entreprise.

• Sera t il capable de nous expliquer les fonctionnalités clairement ?
• Est-il capable de nous aider à déterminer les critères d’acceptation ?
• Sera-t-il capable de se rendre disponible pour valider le travail de l’équipe ?
• Pourra t il accepter de négocier avec nous les moyens de réaliser son besoin avec l’équipe ?
• …

Lorsque vous avez trouvé votre candidat, commencez à extraire des fonctionnalités qu’il vous fourni les Users Stories afin de les lister dans le product backlog. Vous pourrez lui présenter ce nouveau format et la notion de priorisation des US. Ainsi, petit à petit vous l’accompagnerez pour qu’il glisse lui aussi dans une démarche Agile dans l’expression des besoins qui alimentera votre équipe.

Pour que cela puisse bien fonctionner, Il serait idéal que le PO connaisse parfaitement le produit et la cible métier et il qu’il puisse posséder le poids nécessaire au sein de l’entreprise pour vendre les décisions qui seront prises lors de la réalisation incrémentale du logiciel.

Vous l’aurez compris le PO est crucial pour le projet. Si vous demandez à un coach Agile le problème le plus récurrent sur les projets Agile, il répondra souvent : « Avoir un bon PO ! ».

Faites donc votre possible pour accompagner et motiver les personnes qui pourraient jouer ce rôle afin de vous donner tous les chances que votre défi d’introduire de l’agilité pour votre équipe soit un grand succès.

Si vous réussissez à atteindre ce niveau, Bravo vous faites du Scrum ! Il y a encore à faire et il est toujours possible de s’améliorer mais courage ! En maintenant le cap, votre équipe progressera et Il y a fort à parier que cette nouvelle approche intrigue tous les intervenants extérieurs qui collaborent avec votre équipe.

Conclusion

A présent, vous en savez plus sur le Scrum Master mais il serait prétentieux de dire que nous vous avons tout dit sur le sujet.

La plus grande épreuve lorsque l’on souhaite introduire des pratiques Agiles ne sont pas la méthode en elle-même mais surtout le choc des mentalités lorsqu’on essaye de changer les choses. Si vous arrivez à surpasser ces épreuves relationnelles alors vous découvrirez les bienfaits de Scrum et offrirez à votre équipe un meilleur cadre de travail.

Finalement, Le Scrum Master a pour vocation de transformer une équipe en un groupe auto-organisé et pouvoir considérer que cette tâche est terminée est la plus grande victoire que peut viser un Scrum Master !

A ce niveau de maturité, un Scrum Master dédié pourrait être remplacé par un Scrum Master intégré car ce rôle deviendra une responsabilité partagée parmi les membres de l’équipe. Il ne faut jamais perdre de vue cet objectif ! Scrum prônant l’amélioration continue, il y aura toujours des actions à mettre en place pour viser plus haut mais une fois l’équipe autonome elle aura la maturité pour affronter ses obstacles.