Je profite de l’occasion du Scrum Day pour partager mon expérience sur un projet sur lequel je travaille depuis 6 mois. Ce projet est intéressant pour deux raisons. Premièrement, il démarre de rien et j’ai eu la chance de le lancer et de le faire évoluer. Deuxièmement, il a été désigné comme projet pilote pour la mise en place de l’agilité au sein de la DSI.
Le changement est toujours compliqué, surtout après des années de modèle prédictif, et ces 6 mois ont été riches en enseignement. Je pense refaire un billet pour faire le point sur le passage à l’agilité pour toute la DSI et analyser si l’objectif affiché est atteint (et à quel prix). Pour le moment, je me contenterai de réaliser un billet sur la vision d’un membre d’une team scrum, des quelques pièges que j’ai pu rencontrer et dans lesquels j’espère ne plus tomber.
- Le Product owner tu écouteras et tu motiveras
On ne le répétera jamais assez mais scrum ne rime pas avec : “aucune spécification”. C’est même une composante importante. Tout ce que scrum dit c’est qu’il n’existe aucun format imposé et qu’elles ne doivent pas impérativement être complètes ni définitives avant le lancement du développement.
Notre projet couvre un besoin nouveau pour le client et nécessite un travail important de conception. Le product owner (PO) n’a ni le recul ni le temps nécessaires pour nous donner des spécifications claires et complètes pour démarrer. Après coup, cette situation n’est pas insurmontable et l’important est de rendre au PO ce qui appartient au PO. Il ne faut pas que l’équipe prenne la responsabilité des spécifications d’une fonctionnalité, ce n’est pas notre application et nos décisions seront forcément incomprises voire critiquées. Et sans l’appui du PO, les dérives peuvent être nombreuses.
Il est important de remettre le PO au centre des décisions, cela lui redonne de la confiance et ressoude l’équipe, augmentant ainsi les chances de réussite du projet.
- Avec le Scrum master, la communication tu développeras
Scrum met l’accent sur la communication au sein de l’équipe et la définit comme composante principale de réussite du projet. Le daily scrum meeting est là pour rendre compte des tâches en cours, réalisées ou restantes à faire et participe à cette communication.
Dans notre cas, le scrum master (SCM) n’est pas staffé à 100% sur le projet et gère plusieurs autres projets en même temps. Dans cette configuration, il est important que l’équipe remonte au SCM les alertes potentielles du sprint et en particulier les tâches incertaines pouvant dériver. Ce sont par exemple des tâches nouvelles pour l’équipe, jamais réalisées par celle-ci. Ou encore une tâche d’une durée importante, supérieure à une journée. Ces tâches peuvent être sous-estimées et l’augmentation peut entraîner la dérive du Sprint. On peut l’observer facilement sur un Sprint Burndown Chart, avec une courbe qui stagne et ne décroit plus.
Pour les repérer facilement, nous les affichons sur le whiteboard avec des post-it de taille plus importante permettant au SCM de les suivre facilement. Augmenter la communication avec le SCM lui permet de suivre sereinement le projet et de pouvoir réaliser correctement son rôle de protection de l’équipe.
- Les incertitudes, tu élimineras
On l’a vu, les incertitudes sont une composante importante dans la probabilité de dérive d’un sprint. Il faut pouvoir les estimer et pour cela, il faut définir ce qui est une tâche incertaine et ce qui ne l’est pas.
Tout d’abord, Il est important de faire évoluer l’évaluation de ses tâches pendant le déroulement des sprints. Une tâche réalisée en 2h la première fois prendra nettement moins de temps la seconde fois. Tenir ainsi ses tâches à jour permet de garder une évaluation la plus juste possible et une estimation de sprint cohérente.
Les tâches incertaines ne peuvent être évaluées aisément. Elles peuvent être reconnaissables quand une évaluation ne fait pas le consensus de l’équipe ou quand une tâche ne peut tout simplement pas être évaluée. Ce sont souvent des tâches jamais réalisées par l’équipe ou mal spécifiées. Dans le deuxième cas, je déconseille fortement de les prendre dans le sprint. Engager son équipe sur quelque chose qu’elle ne maîtrise pas est le meilleur moyen de rater le sprint et de perdre en confiance dans le PO.
Dans le cas des tâches inconnues, elles doivent être évaluées au possible, prises en compte dans le sprint et suivies de près par l’équipe. Une fois réalisées, elles sortiront de leur statut incertain, pourront être évaluées, réévaluées et traitées plus sereinement.
Une fois estimées, vient le moment de les réaliser. On peut suivre deux méthodes pour éffectuer ces tâches. Les résoudre en fin de sprint, après avoir fini l’ensemble des tâches simples ou en tout début de sprint.
Je conseille fortement de les éliminer le plus tôt possible, ne pas remettre au lendemain ce que l’on peut réaliser tout de suite ! Une tâche incertaine peut fortement dériver et mettre en péril le sprint. Les réaliser tôt permet de conserver du temps dans le cas où elle échappe à l’équipe et ainsi permet de garder la possibilité de prendre les décisions nécessaires pour boucler le sprint (retirer une user story, modifier la priorité …). Un deuxième point à ne pas négliger est le stress généré par une tâche qui dérive. Il est beaucoup plus simple de gérer ce genre de tâche en début de sprint que deux jours avant la démo, quand rien ne fonctionne.
Plus tôt elles sont résolues et plus sereine est l’équipe.
- En continu, tu t’amélioreras et pour cela à 100% tu ne te chargeras pas
La gestion des incertitudes demande une certaine souplesse dans le sprint et une partie de celui-ci peut être conservée pour encaisser une dérive éventuelle. Mais conserver du temps pour les tâches incertaines ne doit pas être la principale priorité.
Scrum prône une constante remise en cause de l’équipe, notamment grâce au sprint review. Une bonne pratique d’amélioration continue consiste à conserver pour chaque sprint une partie du temps alloué à des tâches non dépendantes d’une user story. Ce temps peut être utilisé pour du refactoring, pour améliorer la couverture de test d’une fonctionnalité ou un process de travail. Nous, nous conservons 10% de notre temps (par développeur) à améliorer constamment notre environnement de travail. Dernièrement, nous avons dépensé ce temps à passer de feuilles Excel partagées à Jira pour la gestion du projet. Excel nous convenait pour la gestion d’un sprint mais le passage à Jira nous a permis d’améliorer le travail collaboratif et le bug tracking.
Nous dépensons aussi ce temps pour améliorer nos build maven, notre couverture de tests, nos montées de versions …
Le chemin vers Scrum est semé d’embûches surtout dans un environnement non préparé pour cette méthode. Le PO est une pièce clef du processus et doit rester maître de l’application. Ne pas prendre de décision à sa place et ne pas hésiter à lui renvoyer tous vos questionnements est une bonne démarche pour conserver le PO dans son rôle.
La communication au sein de l’équipe est importante et le SCM doit être tenu au fait des avancées de l’équipe. On pourra ainsi utiliser tout ce qui est à notre disposition pour qu’il puisse suivre très facilement le bon déroulé du sprint.
L’incertitude au sein du sprint doit être maîtrisée pour plus de sérénité au sein de l’équipe. Conserver une estimation cohérente de ses tâches permet de cibler rapidement ce qui pourrait poser problème. Les résoudre en début de sprint permet d’éviter beaucoup de stress inutile.
Et ne jamais perdre de vue que scrum prône une perpétuelle amélioration de ses processus de travail et qu’il est important de conserver du temps pour les réaliser. Garder 10 % de son temps à réaliser des tâches annexes permet d’augmenter la qualité du projet.
Scrum propose une méthodologie de travail pragmatique qui apporte plus de sérénité au sein de l’équipe. L’équipe ne porte plus seule la responsabilité de l’ensemble des tâches de réalisation d‘un projet et l’environnement de travail est beaucoup plus serein. On peut enfin se recentrer sur ce qu’on fait le mieux, développer, et trouver les meilleures solutions techniques pour que le projet réussisse.
