Je me questionne beaucoup sur la valeur de la prédictibilité. L’article de Dave Rooney « Is Predictability Really What We Want ? » m’a donné un certain éclairage que je vais essayer de traduire ici.
La prédictibilité peut résonner comme l’une des principales caractéristiques pour créer la parfaite relation client. Je m’engage, je livre dans les temps, le client est content. En scrum, la prédictibilité se construit à l’aide de la vélocité. Plus cette vélocité est stable, plus les dates de livraison de vos user stories seront prédictibles. On aura tendance à attendre d’une équipe Scrum qu’elle atteigne une certaine maturité de vélocité afin de tenir les engagements du Sprint. Je ne suis pas à l’aise avec cette notion d’engagement de sprint, d’une part à cause des dérives quelle peut entraîner (l’équipe se sent obligée de terminer à tout prix le lot sur lequel est s’est engagée, quitte à y passer la nuit ou le week-end) et d’autre part, en raison de son éloignement de l’objectif premier « la satisfaction client », dont il existe certainement de meilleurs chemins pour y arriver.
Rendre le système prédictible?
Quel l’on soit en Scrum ou en Kanban, on cherchera à minimiser les perturbations du système afin d’obtenir une vélocité et une prédictibilité pertinentes. La réduction de ces perturbations passera par exemple par un investissement sur des environnements de tests efficaces, une formation aux pratiques Craftmanship pour limiter la dette technique, la mise en place d’une solide stratégie de test, etc. Il est important de garder à l’esprit que malgré tout, le système ne sera pas protégé de toutes les perturbations (maladie, panne informatique, etc.).
En Scrum, la vélocité aide l’équipe à se projeter sur le nombre de points d’effort qu’elle est capable de réaliser sur une période donnée (le sprint). L’équipe donne un nombre de points d’effort à chaque user stories du backlog, ce qui lui permet d’identifier celles qu’elle pourra faire « rentrer » dans le sprint (la somme des points d’effort est inférieure ou égale à la vélocité). Il est à noter qu’en scrum, bien que le découpage de user stories soit encouragé, il est fréquent d’avoir un backlog de sprint contenant des user stories de tailles assez différentes.
En Kanban, on s’intéressera plus au temps de parcours de chaque user story, de sa création, jusqu’à sa résolution.
Afin que cette mesure soit pertinente, il est important que toutes les user stories aient approximativement la même taille et que cette dernière soit petite (de un à deux jours hommes ou d’un à trois points de vélocité par exemple).
La prédictibilité de quoi?
La prédictibilité concerne des éléments fonctionnels assez fins : les user stories. Elle perd son sens au niveau des fonctionnalités, car celles-ci se déclinent en user stories à prioriser.
Par exemple, si vous avez définit six user stories à partir d’une fonctionnalité, peut être prioriserez vous trois d’entre elles au prochain sprint, en placerez deux au sprint suivant et déciderez, à un moment donné, de jeter aux oubliettes la dernière qui n’apporte que très peu de valeur. La prédictibilité de la fonctionnalité ne veut pas dire grand-chose : elle serait associée à la prédictibilité d’un lot de user stories, tout en sachant que le nombre de user stories de ce lot peut augmenter (découpage de user stories en fonction de l’effort de développement) ou diminuer (décision de supprimer des user stories avec peu de valeur). Il est important d’apporter cette précision à votre client.
La prédictibilité, nécessaire dans les échanges avec le client ?
Mais au fait, est-il nécessaire d’installer la prédictibilité dans les discussions avec le client ? De lui parler de votre débit de user stories et des dates de fin estimées de chacune d’elles ? Ne peut-on pas de contenter de collaborer étroitement avec le client sur les sujets qui ont le plus de valeur pour lui ? Comme l’auteur de l’article, j’ai eu la chance d’expérimenter ce type de relation sur quelques projets. Sur l’un d’eux, je m’étais installé à proximité du client pour développer son application. Je pouvais le rencontrer régulièrement pour obtenir du feedback. Nous discutions des petits éléments fonctionnels à développer, sans s’attarder sur le temps que cela pouvait prendre. Nous insistions pour qu’ils soient petits et ordonnés par valeur. Le client voyait que les choses avançaient dans le bon sens. Il avait confiance et ne ressentait pas le besoin de s’attarder sur la prédictibilité, elle était implicite.
La confiance avant tout
Vous pouvez donner confiance à votre client en lui montrant que vous respectez vos engagements, le contrat en terme de livrable. Vous vous rencontrez chaque mois, voire toutes les deux semaines pour faire la revue des user stories sur lesquelles vous vous êtes engagés. L’équipe y est vraiment allée cool, ou bien a peut être trimé tous les jours jusqu’à 21h pour rendre la livraison possible. Le client a confiance en l’équipe, car elle est capable de livrer dans les temps.
Vous pouvez aussi créer la confiance en apportant très régulièrement de la valeur à votre client. Cette valeur peut prendre plusieurs formes :
- Des éléments fonctionnels testables ou utilisables en production
- De l’information : l’équipe et le client se sont mis d’accord sur ce qu’ils souhaitaient apprendre d’un développement exploratoire par exemple.
- De la transparence pour travailler sur les éléments non fonctionnels comme la maintenabilité et l’évolutivité.
- Etc.
Dans le deuxième exemple, l’équipe n’a pas besoin d’utiliser la prédictibilité dans ses échanges avec le client. Ce dernier s’est habitué à ce que l’équipe lui livre fréquemment de la valeur.
Ça y est, la confiance est là, vous vous êtes employés à la construire avec votre client. Vous n’avez pas eu besoin de donner une importance particulière à la prédictibilité. L’équipe ne s’inquiète pas lorsque le client change d’avis sur un sujet, car elle a confiance en lui et donc dans ce choix. Le client a également confiance dans la capacité de l’équipe à intégrer ce changement. Le client ne s’inquiète pas si la dernière user story du sprint n’est pas terminée, il sait que l’équipe a travaillé sur les bons sujets. Les préoccupations de l’équipe et du client sont de donner le meilleur d’eux-mêmes, car ce contexte est favorable pour accomplir de grandes choses.
A lire également « Réflexions sur l’estimation des User Story« .
