Comment le Scrum Product Owner peut définir la date d’une livraison(release) d’un nouveau produit ?


Lors de la création d’un nouveau produit, en tant que Product owner, la question qui revient tout le temps de la part des stakeholders (sponsors) est la suivante:
Quand est-ce que l’on release, quand est-ce que le produit sera prêt ?

Habitués par les projets waterfall, les sponsors s’attendent à une date de livraison incluant tout ce qu’ils peuvent avoir en tête que cela soit ou non dans les dossiers de spécifications.
Ils ont aussi en tête les nombreux dépassements de date, et les désaccords sur ce qui sera livré.

Alors, en tant que Product Owner, quelle date doit on leur donner et quelles clarifications devront nous faire ?

La première chose que nous devons expliquer est qu’il s’agira d’un livraison initiale, qu’en aucun cas nous attendrons que le produit soit « terminé » pour livrer.
Cette livraison initiale proposera un set de fonctionnalités suffisant pour permettre l’évaluation de la livraison et l’orientation du développement futur.
Pour ce qui concerne la date de cette livraison initiale, en fait nous avons deux choix : Une livraison à date fixée ou une livraison à périmetre fixé.
Ces deux options ne peuvent être combinées, sinon on revient au waterfall…

Voyons ces deux options en détail :

La livraison à périmètre fixé :
Le perimetre est un ensemble de fonctionnalités sur lequel le product owner et le sponsor s’entendent pour les définir comme etant le contenu de cette première livraison, la date de livraison ne peut donc être fixée.
Dans cette option le PO doit tout faire pour, avec le sponsor, déterminer un périmètre initial raisonnable, et non pas un périmètre gigantesque qui va repousser la première release trop loin et nous replacer dans une situation waterfall.
C’est le périmetre qui définit le moment de la livraison, elle dépendra donc de l’ampleur du périmetre et de la capacité de l’équipe.
Au fil de l’avancement du développement deux éléments se précisent :

  • le backlog de produit devient de plus en plus complet permettant ainsi de connaitre l’effort qu’il reste à fournir
  • La vélocité moyenne de l’équipe se raffine ( à condition de ne pas porter de changements à l’équipe)

Avec ces deux informations le Product Owner va être de plus en plus en mesure d’estimer un intervalle de sprints restants et donc la période de livraison.

Attention : Cette livraison ne doit pas forcement aller sur le marché, elle peut servir pour des beta testeurs.

La livraison à date fixée :
Le sponsor établit la date à laquelle il désire que la livraison initiale intervienne, ce sont souvent des contraintes soient opérationnelles soient marketing qui dictent cette date.
Le Product Owner aura alors pour objectif de maximiser la valeur livrée à cette date.
Évidemment le bon sens doit être de mise, cette livraison initiale comporte forcement un périmètre minimum, sans lequel la valeur livrée sera insuffisante.
C’est le rôle du product owner de faire comprendre ceci et de s’assurer que cette date fixée assure d’atteindre ce périmètre minimal.
Il est important que la première livraison soit relativement rapide étant donné qu’elle apporte la valeur initiale, permet le feedback des sponsors et des premiers utilisateurs, et peut même permettre le début du ROI en étant commercialiser.

Laquelle des deux options choisir ?
Je préfère de loin une livraison a date fixée, dans ce type de gestion le product owner aura une grande responsabilité : celle de maximiser la valeur. Dans l’autre option aussi mais les fonctionnalités à developper son beaucoup plus clairement établies.
Aussi la gestion par périmètre, n’ayant pas de date fixe, elle a de plus grands risques de laisser place à du développement superflu.
À l’opposé une livraison à date fixe oblige toute l’équipe à s’en tenir à ce qui minimalement repond au besoin story apres story et génère un produit pkus « lean ».

Selon moi, les livraisons par périmètre ne devraient avoir lieu que lorsque ce perimetre est dicté par des inmperatifs technologiques. Par exemple un produit qui s’appuie sur plusieurs éléments interdépendants et que si un seul de ces éléments est manquant, tout le produit est non fonctionnel. La valeur livrée reste nulle tant que le périmetre n’est pas atteind.

Dans le cas d’un produit destiné à la revente, la date fixe est l’option la plus recommandée puisqu’elle permet de synchroniser le plan marketing, la formation des vendeurs et la préparation du support technique. La poursuite de livraisons à échéances courtes et fixées donne une vie au produit, onserve l’interêt du client et permet la création de « buzz » autour du produit.

Bonne livraison et bon projet à tous.

Durée des sprints : deux, trois ou quatre semaines ?


Je vois souvent des équipes qui se demandent quelle devrait être la durée de leurs sprints ? Deux, trois ou quatre semaines ?
En fait pour répondre à cette question, il faut d’abord comprendre quelles sont les differentes variables qui influencent ce choix.

Première variable : la taille de l’équipe.
On le sait, les équipes scrum doivent être constituées de 3 à 9 membres. On parle tout de même d’un ratio du simple au triple.
Des équipes de 3 personnes ont évidemment une capacité de développement moindre, partant de cette idée, des sprints courts ne permettront pas suffisament d’ajout de valeur, les sponsors (stakeholders) risquent de perdre interet pour les sprint review.
À l’opposé, de grosses équipes utilisant des sprints longs, vont produire beaucoup de valeur à chaque sprint et necessiter beaucoup de travail de plannification en amont des sprints. Il permettrons aussi moins de changements à faible coût.

Deuxième variable : l’experience de l’équipe
Si il s’agit d’une équipe qui a peu d’experience tant au niveau de l’approche agile qu’au niveau du travail collectif, des sprints plus courts entraineront une plus grande fréquence des sprint retrospective. Plus une équipe est jeune, plus les retrospectives, si elles sont bien conduites et si on applique les pistes d’améliorations que l’on y découvre, sont importantes. Elles sont l’élément principal de l’amélioration continue de l’équipe.
Pour une équipe plus aguerrie, le besoin d’amélioration est moins présent on peut donc se permettre d’étirer un peu les sprints.

Troisième variable : la disponibilité du Product Owner
Plus les sprints sont courts, plus les meetings de sprint planning, sprint review et sprint retrospective sont fréquents, bien qu’ils soient de durées proportionnelles au sprint, plus ils sont fréquents plus c’est demandant pour le po.
Un Product owner qui gererait plusieurs projets ou équipes aurait beaucoup de difficulté à tenir le rythme.
À l’opposé un po qui ne gère qu’une seule équipe pourrait trouver des sprints de 4 semaines beaucoup trop longs et manquant d’interaction.

Quatrième variable : le besoin de changement, de réactivité
Lorsque le projet nécessite une plus grande réactivité dûe à une compétition plus féroce, un domaine jeune en plein évolution, des sprints courts offriront au Product Owner la souplesse nécessaire pour assurer une grande compétitivité.

Sachant qu’il est peu recommandé de changer la durée des sprints en cours de release, avant de définir celle-ci, verifiez ces variables pour vous assurer le bon choix.

Scrum outil d’amélioration continue


Un des objectifs de scrum est d’encourager l’amélioration continue de l’équipe.

Qu’entend on par amélioration  continue ?
La philosophie japonaise du kaizen ( http://fr.wikipedia.org/wiki/Kaizen) présente l’amelioration continue comme une démarche quotidienne basée sur une participation volontaire de chacun qui engendre des progrès réels et peu onéreux.

Toute la philosophie du Kaizen réside dans ces phrases : « Fais-le mieux, rends-le meilleur, améliore-le même s’il n’est pas cassé, parce que si nous ne le faisons pas, nous ne pouvons pas concurrencer ceux qui le font. » « Mieux qu’hier, moins bien que demain. »


Quels sont les outils mis à notre disposition par Scrum pour permettre cette amélioration ?

L’outil principal proposé par Scrum pour atteindre cet objectif est bien entendu le Sprint Retrospective, meeting qui intervient à la fin de chaque sprint après la review.

Lors de la rétrospective on identifiera en équipe ce qui fonctionne bien, ce qui fonctionne moins bien et comment l’améliorer.
Dans cet article : https://sebastienboyer.wordpress.com/2012/02/14/scrum-sprint-retrospective-la-magie-des-post-its/ je partage certains trucs pour réussir ses rétrospectives.

Évidemment ce meeting n’a lieu qu’à tous les 2 à 4 semaines dépendant de la durée de vos sprints, on ne parle pas d’une démarche quotidienne.
Néanmoins une équipe qui cherche de façon proactive et volontaire à s’améliorer à ce rythme là est déjà un gage de succés.


Que cherche t on a ameliorer exactement ?

La réponse est en fait simple : absolument tout ce qui peut l’être ! Dans la mesure du raisonnable, tant au niveau de l’effort à fournir que des moyens financiers à déployer.
Concrètement on parle souvent, de l’équipe, de ses interactions, des outils, des processus scrum, des méthodes, de l’implication etc…

Les pieges pour une jeune équipe agile : la perte de focus, l’écart à la définition de fini


Lorsqu’une compagnie décide de prendre le virage de l’agilité, ses équipes de developpement font face à de nombreux pièges.
Bien sur l’ajout de scrum master experimentés aiderait grandement à prévenir l’équipe face à ces pièges, la réalité est que dans la plupart des cas l’entreprise va vouloir effectuer cette transition avec les effectifs déjà en place.
Dans cette optique il est impératif de former des employés à certains des rôles importants d’une équipe scrum.

1: un Product Owner, il faudra déjà identifier la bonne personne, quelqu’un qui connait le metier, les attentes du marché. Une personne qui allie à la fois des compétences techniques et commerciales serait idéale.

2: Des scrum master, il faudra prevoir deux scrum master par équipe afin qu’ils puissent se valider et se surveiller l’un l’autre pour s’assurer que celui qui jouera le role pendant le sprint n’oublie rien et ne devie pas du processus. On leur donnera le rôle en alternance de 2 ou 3 sprints.

Dans notre cas, j’ai suivi les deux formations, je joue donc le role de PO mais aussi celui de facilitateur et de coach agile auprès de l’équipe et des scrum masters.
C’est ce qui me permet de déceler les pièges dont je vais vous parler.

Le premier que je vous présente est la perte de focus.
Il faut se rappeler qu’un des objectifs du processus scrum est de maximiser la valeur de ce qui est créé en éliminant le superflus.
Pour les programmeurs qui ont une longue experience de développement waterfall, l’élimination du superflus n’est pas du tout une habitude.
Et dans le pire cas cela risque de se présenter comme suit :
Votre Product Owner va construire un backlog priorisé allant à l’essentiel.
L’équipe selectionnera ce qu’elle peut réaliser dans le prochain sprint en respectant les priorités du po.
Le sprint commence l’équipe ajoute des tâches reliées aux stories mais certaines de ces taches vont au dela de ce que decrivent les stories, elle en vient a fabriquer un marteau pneumatique pour écraser une mouche.
Elle anticipe sur ce qu’elle pense que le po priorisera pour les prochains sprints.
Et puis l’équipe identifiera des taches « urgentes » pour répondre à des besoins technologiques et réalisera ces tâches au dépend de celles nécessaires aux stories.

Le deuxième est l’écart à la définition de fini :
L’équipe oublie de se referer à la définition de fini pour valider que les stories qu’elle considère terminées le sont bel et bien.
Unvou plusieurs des éléments ne correspondent pas. Par exemple on oublie de valider un des browsers sélectionnés.

Résultat : peu ou pas de stories sont considerées finies.
Est-ce-que ce sprint est un echec ? Absolument pas, il est une source d’enseignements considérable !

Maintenant que l’on a identifié ces pièges, on peut trouver des pistes de solutions.
1- lors de chaque création de tâche reliée à une story, relire la story ET la définition de fini et se poser la question suivante « Comment cette tâche m’aide-t-elle à terminer cette story ?  »
Si la réponse n’est pas évidente, pourquoi réaliser cette tâche ? Plutôt se reposer la question « Comment finir cette story ou comment la finir mieux ou différemment ?

2- lors de l’ajout de tâches « urgentes » non reliées directement à une story, se poser la question suivante « Quel obstacle qui bloque la réalisation de stories de ce sprint cette tâche va-t-elle permettre d’éliminer et comment pourrais je le faire sans cette tâche ou avec une meilleure approche? »
Si la tâche demeure la meilleure option … go for it !
Sinon il faut se poser la question suivante  » Comment cette tâche va me permettre de réaliser les stories plus rapidement et m’assurer de les finir dans ce sprint et comment pourrais je faire autrement ou mieux ? »

Si la tâche ne demeure pas un réel levier dès ce sprint, bien qu’elle puisse être justifiée elle n’est pas urgente et devrait etre réevaluée et repriorisée avec le PO.

3- En tout temps chercher le chemin de moindre résistance permettant de créer la valeur ajoutée attendue par la story en éliminant le superflu.

4- Imprimer la définition de fini et la mettre très visible dans un lieu de passage ou bien exposée sur chaque cubicule afin qu’on s’en impreigne.

5- Se faire de mini démos en cours de sprint entre les membres de l’équipe pour valider l’aspect fini de chaque story terminée.

Réussir ses Sprint Rétrospective : La magie des post-its


J’agis à la fois en tant que Product Owner et facilitateur Agile au sein de ma compagnie ; nous avons pris ce virage depuis peu et je remarque une certaine difficulté lors de la rétrospective.

Dans tout le processus Scrum,  la rétrospective est le meeting le moins mécanique et par conséquent aussi le meeting ou les membres de l’équipe ont le plus de difficulté à s’exprimer.

J’ai donc cherché les raisons de cette difficulté et j’en arrive à ces conclusions.
il s,agit surement d’une certaine forme de gêne dans des équipes qui ne sont pas habituées à :

  • S’interroger sur leurs interactions
  • S’interroger sur leur façon de collaborer
  • Se confronter respectueusement.

J’ai donc essayé différentes pistes.
Dans un premier temps je leur exposais simplement les 2 premieres questions : Qu’est-ce qui à bien fonctionner dans ce sprint ? Qu’est ce qui aurait pu mieux fonctionner ?
Résultat, quand un parle les autres n’osent pas exprimer d’avis contraire. Ils ont beaucoup plus de misère à exprimer ce qui aurait pu être  mieux. On arrive rapidement au silence, les rétrospectives sont donc peu productives.

J’avais pensé que lors du sprint suivant ,j,aborderai les questions une par une et ne permettrai à chaque personne de n’exprimer qu’une opinion à la fois. Finalement j’ai opté pour une autre approche que je vous présente ici.

On commence donc avec la première question que l’on écrit au tableau : Qu’est-ce qui, lors de ce sprint, a selon vous été une réussite ?
On ecrit ensuite les thėmes pour lesquels on veut répondre à la question, dans notre cas ce sont les suivants :

  • la technologie & les outils
  • l’équipe (Scrum dev + Scum master + Product owner)
  • l’équipe étendue (équipe + experts externes)
  • le processus Scrum
  • les actions du Scrum master
  • les actions du Product Owner

On part un timebox de 15 minutes, chaque membre de l’équipe doit ecrire une opinion/fait par post-it en spécifiant le thème.
En quelques minutes les opinions évidentes sont notées, le reste du timebox force les participants à identifier les éléments moins marquants.

On ramasse les post-it et on les place sous les thèmes correspondants.
On commence par remarquer les thèmes qui récoltent le plus et le moins de post-it, donc les zones de pus grands succès sur lesquels on va pouvoir se reposer pour perpetuer le succès.

Par thème, On les lit à haute voix et ensemble on les regroupe par idée.
Cet exercice permet à chacun de se situer par rapport à l’équipe, voir si ils partagent une vision commune.


image





















On répète le même exercice pour la question deux : Qu’est-ce qui, lors de ce sprint, aurait selon vous pu être mieux réussi ?
Ensuite en équipe on trouve des pistes d’amélioration des points de la question 2.

Voilà, bonne rétrospective !