Auteur : Fabio Panzavolta

Lectures

J’ai raté mon évaluation PSM I

Posted on by Fabio Panzavolta in Evaluations Scrum.org

L’évaluation en ligne Professional Scrum Master I de la Scrum.org démontre votre connaissance de Scrum tel qu’il est décrit dans le Scrum Guide par leur créateurs : Ken Schwaber et Jeff Sutherland.

Il arrive, parfois, que certains de mes stagiaires soient déçus car ils n’arrivent pas à passer du premier coup l’évaluation Professional Scrum Master I.

Chaque participant à un cours officiel scrum.org que nous délivrons reçoit un voucher avec deux tentatives pour l’évaluation en ligne.

Le premier tentatif doit être fait dans le 14 jours qui suivent la fin de la formation. S’il ne réussit pas, le deuxième tentatif est disponible sans échéance particulière. Cette manière de faire permet aux stagiaires d’inspecter leur connaissance de Scrum et de l’adapter pour mieux comprendre Scrum.

Je comprends la frustration et l’énervement des stagiaires qui ratent l’évaluation, car j’y suis passé avant. Parfois cette expérience est vécue comme un échec et cela nous rappelle les mauvaises expériences (scolaires ou autre). J’ai appris (en plus de Scrum) à exploiter l’échec comme une opportunité de devenir meilleur, pas comme un drame et j’aide mes stagiaires à passer ce cap, vous n’êtes pas seuls !

Voici l’email que j’envoie aux personnes qui me contactent après avoir raté l’évaluation PSM I, en espérant que cela vous soit utile.

« Je comprend la frustration et l’énervement pour ce résultat. Cependant je te félicite pour avoir essayé et obtenu des indications importantes qui te permettrons de renforcer les parties de Scrum que tu dois approfondir. Cette indication tu la trouves dans l’email de feedback envoyée pas scrum.org. »

« Voici mes conseils pour adapter ta connaissance :

  • Repère les « subject areas » dans lesquelles tu as obtenu le score le plus faible.
  • Révise sur le support de formation les chapitres correspondants
  • Choisi un des livres conseillés en fin de chapitre, cela pourrait être intéressant d’en lire plusieurs
  • Utilise le scrum master learning path pour améliorer tes connaissances à travers des articles de blog, des vidéos, etc.
  • Lis encore le scrum guide en anglais
  • Répète les open assessments et, éventuellement, essaye aussi le Product Owner Open Assessment (cela élargi le panel de questions, certaines seront plus orienté PO, ne soit pas étonné si certaines questions sont plus difficiles, car elle font un focus sur le PO)
  • Note toutes tes questions, à la fin je suis à ta disposition pour une demi-heure de rétrospective avant la deuxième tentative
  • Tu n’est pas très loin du but, à la fin du parcours tu auras une connaissance accrue (et pas superficielle) de Scrum, cela vaut le coup, crois moi »

Scrum On!

Du bon réglage d’une « Definition Of Ready »

Posted on by Fabio Panzavolta in Agile

La notion de « Definition Of Done » (DOD) fait partie des éléments constitutifs du cadre Scrum. (Cf. https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done )
La DOD est un élément nécessaire à plusieurs titres pour accroître la transparence du système. En particulier elle permet à l’équipe :
• de calibrer la quantité de travail pour l’itération qui débute
• de comprendre et partager le niveau de qualité du produit attendu et sur lequel l’équipe s’engage
• de comprendre la teneur des différents travaux techniques à entreprendre, en particulier sur les « exigences non fonctionnelles »

De manière générale, on s’attend à ce que la DOD du produit se durcisse avec le temps afin de faire croître la qualité du travail, réduisant ainsi la dette technique et le coût total d’acquisition, ce qui est un gage d’adaptabilité du produit.

En revanche, la « Definition Of Ready » (DOR) n’est pas un élément de Scrum mais une pratique complémentaire fréquemment utilisée par les équipes. Scrum suggère uniquement que l’équipe soit en mesure de déclarer si un item du « Product Backlog » est « prêt », dans le sens qu’il peut être sélectionné pour être réalisé dans un prochain sprint.

Attention, la DOR ne doit JAMAIS être utilisée comme une barrière stricte en recréant des silos entre le PO et l’équipe de développement, mais au contraire la DOR doit être un support pour faciliter une réelle collaboration entre le PO et l’équipe de développement.

Cf. https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog

Dans la pratique, l’équilibre parfait est très subtil à atteindre et encore plus à conserver. Ainsi la DOR d’une équipe va être soit trop laxe soit trop stricte.
Le problème est d’arriver à avoir une mesure objective qui permette à l’équipe de savoir dans quel sens faire évoluer la DOR.
Si la DOR est trop laxe, l’équipe va constater fréquemment que malgré sa bonne volonté à bien vouloir s’attaquer à tout ce qu’on lui demande, elle est souvent bloquée après avoir commencé à implémenter les items du « Sprint Backlog » : l’équipe commence les travaux d’implémentation mais doit s’arrêter fréquemment pour aller chercher des informations importantes manquantes pour poursuivre le développement de l’item en cours.

Chaque arrêt génère un gaspillage de temps, d’énergie et de perte de focalisation important. Un point de mesure simple mais naïf serait par exemple le temps de blocage cumulé pendant le sprint.

Si la DOR est trop stricte, l’équipe va constater qu’elle n’est quasiment jamais bloquée, ce qui semble intéressant. En effet, le temps de blocage cumulé pendant le sprint devrait être proche de zéro. Cela se traduit généralement par une vélocité « importante » car l’équipe n’est jamais bloquée et a l’impression de travailler sans gaspillage de temps, en livrant ainsi fréquemment un logiciel opérationnel (Cf. http://agilemanifesto.org/iso/fr/principles.html principe #3).
Malheureusement, la DOR utilisée ici comme bouclier protecteur pour l’équipe l’empêche alors d’être en mesure de prendre en charge rapidement des nouvelles idées et d’accueillir les changements de besoins, même tard dans le projet (Cf. http://agilemanifesto.org/iso/fr/principles.html principe #2). En effet, ces nouvelles idées devront passer par de nombreux ateliers, avec de nombreux acteurs avant que l’équipe ne considère que l’idée est enfin raisonnablement réalisable dans un prochain sprint.
Nous avons ici un excellent exemple de cas d’une optimisation locale au détriment de l’optimisation globale du système.

Le temps de cycle est une mesure intéressante qui permet à l’équipe d’apporter un niveau élevé de transparence, pour lui permettre d’inspecter l’efficacité de ses outils (tel que la DOR) et de guider les éventuelles adaptations à apporter au système.
Il est également très parlant pour mesurer si l’équipe arrive à accueillir les changements de besoins, indépendamment de sa cadence de livraison.
Enfin, si le temps de cycle englobe l’ensemble des travaux de l’équipe de «  développement » et pas seulement les travaux de « codage », il permet bien de mesurer l’efficacité globale de la chaîne de production de valeur, c’est à dire jusqu’à la la création d’un incrément de produit potentiellement livrable en production avant la fin du Sprint.

En synthèse, si la DOR est trop laxe, le temps de cycle sera détérioré par les nombreux blocages et si la DOR est trop stricte, le temps de cycle sera détérioré par des travaux préparatoires trop longs.

Dans tous les cas, la réduction recherchée du temps de cycle ne peut se faire qu’avec un travail collaboratif en équipe et avec le « Product Owner ».
Casser les silos permet de limiter les files d’attente et de lever rapidement les blocages en partageant rapidement l’information entre les différents acteurs.

Pour en savoir plus sur le temps de cycle : http://referentiel.institut-agile.fr/leadtime.html

Scrum on !