Post-it Art for Scrum

Comment apprendre à distance Scrum? Quels outils pour simuler l’ensemble du cycle de vie de Scrum?

On retrouve différents outils pour simuler Scrum : lego4Scrum, minecreft4Scrum, BusinessValueGame… Mais l’ensemble de ces jeux ne se prête pas toujours bien à une formation à distance.

J’ai souhaité réaliser une simulation de Scrum pour des cours à distance : et quoi de mieux que d’utiliser des post-it. D’où l’idée de faire du post-it Art (inspiré de https://illustrarium.com/play de mon bon ami Sergey) :

Photo de Francesco Ungaro sur Pexels.com

Objectif du jeu

Ce jeu peut donc se dérouler en ligne en utilisant des outils comme Klaxoon. Personnellement, j’utilise Miro.

Le jeu va permettre de voir l’ensemble des cérémonies scrum et de réaliser un projet. Cela permettra aux apprenants de simuler un projet dans sa globalité.

Règles du jeu

Durée : 120 minutes

Taille du groupe : 3 à 10 personnes

Matériel : avoir accès à un outils type Miro, Klaxoon, etc.

Description du jeu :

Le jeu consiste en une simulation de Scrum avec comme objectif la réalisation avec des post-it d’une maison de face (pixel art). Ce jeu peut être adapté à tout type de méthodologie itérative.

« Vous avez été recruté pour construire une maison. Le projet est complexe et nous avons considéré que la taille de votre équipe permet de réaliser cette maison dans les délais. Nous allons construire de façon itérative cette maison pour nous adapter au besoin du client. »

L’animateur jouera le rôle de coach pour la partie explication du jeu, debriefing et le rôle du client pour la revue.

Dans le jeu, on considère que :

1 post-it = 0,5 mètre
1 point = 1 fenêtre
N’utiliser que des post-it de même taille
Respecter l’ordre de construction classique d’une maison.

Avant de début, nous aurons une présentation du backlog (qui aura été préparé en amont) à l’équipe. Une phase d’estimation. Et une phase de planification de release.

Le jeu se déroule en 4 sprint de 5 minutes. Chaque sprint étant constitué de :

une phase de planification (sprint planning)
Réalisation. Un jour = Une minute.
une démonstration
une rétrospective

Aperçu

Pour plus d’informations, je vous invite à télécharger le document décrivant ce jeu Agile : Agile Pixel Game .

Remerciements

Merci à Agile Toulouse et Pewem pour les feed back sur ce jeu.

juillet 31, 2021 2

Citations sur la gestion de projet Agile

Quelques citations pour illustrer la gestion de projet agile.

La gestion du changement

« Face au monde qui change, il vaut mieux penser le changement que changer le pansement. » Francis Blanche

« L’intelligence c’est la capacité de s’adapter au changement. » Stephen Hawking

« Le futur a été créé pour être changé. » Paolo Coelho

L’équipe

« Ça n’a pas de sens d’embaucher des gens intelligents puis de leur dire quoi faire. Nous embauchons des gens intelligents afin qu’ils puissent nous dire ce qu’il faut faire. » Steve Jobs

« Les meilleures choses qui arrivent dans le monde de l’entreprise ne sont pas le résultat du travail d’un seul homme. C’est le travail de toute une équipe. » Steve Jobs

« Seul, on va plus vite. Ensemble on va plus loin. » proverbe africain

« Se réunir est un début, rester ensemble est un progrès, travailler ensemble est la réussite. » Henry Ford

« Les performances individuelles, ce n’est pas le plus important. On gagne et on perd en équipe. » Zinedine Zidane

Le planning

« Attendre d’en savoir assez pour agir, c’est se condamner à l’inaction. » Jean Rostand

« Plans are nothing; planning is everything. » Dwight D. Eisenhower

« Vous n’avez pas besoin de voir tout l’escalier, empruntez juste la première marche. » Martin Luther King

« La route ? Là où on va, on n’a pas besoin de route ! » Retour vers le futur, Dr. Emmett Brown et Marty

« Si tout semble sous contrôle, c’est que vous n’allez pas assez vite. » Mario Andretti (pilote de F1)

« Prévoir consiste à projeter dans l’avenir ce qu’on a perçu dans le passé. » Henri Bergson

« Pour réussir il ne suffit pas de prévoir, il faut aussi savoir improviser. » Isaac Asimov

« L’avenir ne se prévoit pas, il se prépare. », Maurice Blondel

La priorisation

« La clé dans tout ce que l’on fait, c’est de prioriser. C’est-à-dire de cerner les points importants à traiter pour nous, et de s’y tenir. » Mark Zuckerberg

« Choisir, c’est renoncer » André Gide

« L’important n’est pas de tout faire, mais de faire le plus important. » François Gamonet

L’estimation

« Estimer le temps pour réaliser quelque chose qui n’a jamais été fait auparavant est quelque chose de difficile. Et, par nature, nous sommes souvent des animaux optimistes… » Jeff Patton

« Méthode d’estimation du temps : tout travail tend à se dilater pour remplir le temps disponible. » Cyril Northcote Parkinson

La mesure

« Tout ce qui est mesuré et observé, s’améliore. » Bob Parsons

« Mesurer, c’est savoir. » William Thomson

L’amélioration

« L’amélioration continue vaut mieux que la perfection retardée. » Mark Twain

« Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s’adaptent le mieux aux changements. » Charles Darwin

« La folie, c’est de faire toujours la même chose et de s’attendre à un résultat différent. » Albert Einstein

« La connaissance s’acquiert par l’expérience, tout le reste n’est que de l’information. » Albert Einstein

« Une personne qui n’a jamais commis d’erreurs n’a jamais tenté d’innover. » Albert Einstein

Et vous quelles sont les citations que vous appréciez pour illustrer la gestion de projet agile?

juin 5, 2021 0

Product Owner : quelques ressources

Un ami me demandait récemment des ressources pour monter en compétence sur un poste de Product Owner. Je partage avec vous, une petite liste de sites que je recommande!

Si il n’y avait qu’une vidéo, je pense que celle-ci est un bon début :

My Agile Partner propose une bonne série de vidéos :

PSPO – préparer sa certification product owner

Évidemment, l’excellente chaine Scrum Life :

https://www.youtube.com/channel/UCMCnZGIOeLVO65-LBxkkHyQ

Éventuellement, comme la question est autours du Product Owner :

En dehors des vidéos, il y a les tests gratuits :

https://www.scrum.org/open-assessments/product-owner-open

PSPO I™ Preparation Quiz – Learning Mode

Le blog de Claude Aubry vous apportera un peu de lecture :

https://www.aubryconseil.com/product-owner/

Et vous quelles lectures conseillez sur le sujet?

Mai 17, 2021 0

Definition of Done

Qu’est ce que la Definition of Done (DoD)?

Qu’est ce qui vous permet de définir que votre développement est terminé? Il est intéressant au sein d’une équipe de partager une vision des critères qui définissent qu’une fonctionnalité est terminée.

« La Definition of Done (Définition de Fini) est une description formelle de l’état de l’Increment lorsqu’il satisfait les mesures de qualité requises pour le produit. » Scrum Guide 2020

Comment construire sa Definition of Done?

En Scrum, c’est l’équipe qui va définir ces critères. L’équipe va définir les critères minimum qui permettront de définir qu’un développement est terminé. Cela permettra un alignement de la qualité au niveau de l’équipe. Si plusieurs équipes travaillent sur un même produit, elles doivent partager une même Definition of Done.

Ce document définissant la liste des critères de cette DoD peut donc être rédigé lors d’un brainstorming. Mais vous pouvez aussi utiliser des outils pour vous aider à la définir. Je vous conseille l’excellent deck de carte, DoD Karts : https://coach-agile.com/2017/11/decouvrez-dod-kards-definition-of-done/

Ce deck de carte est composé de différentes cartes représentant des critères pouvant être ajoutés à votre DoD. Les cartes seront tirées à tour de rôle et l’équipe devra définir pour chaque carte :

si elle va rentrer dans leur Definition of Done : colonne »Oui ».
si elle rentrera plus tard dans cette DoD (le critère est intéressant, mais l’équipe n’est pas encore assez mature pour le prendre en compte) : colonne « Plus tard ».
ou si elle ne le prendra pas en compte (critère non pertinent ou non réaliste) : colonne « Non ».

Cet outil permet de créer une DoD ou d’échanger sur une DoD existante et ainsi permet à l’équipe de s’approprier ces critères.

En distanciel, le deck de carte peut facilement être converti avec un outils de type tableau blanc virtuel (miro, metroretro, klaxoon…). Je vous partage mon modèle: https://metroretro.io/board/LBGYTIGW8MPO

Que va contenir votre DoD?

La DoD va contenir:

des contraintes métiers ou fonctionnelles (critères d’acceptances …)
des prérequis non fonctionnels (maintenabilité, performance, sécurité …)
des contraintes de qualité (pair revue, TDD, coverage, technical debt …)

Definition of Done d’une User Story ou d’une Epic?

Pour commencer, il me semble important d’avoir une Definition of Done au niveau de vos User Story. Et il est intéressant d’en définir une autre pour vos Epic. Peut-être que lorsque vous livrez une Epic Story, cela aura un impact sur les environnements nécessaires au déploiement, sur la documentation?

Et après?

On est Agile? Partons d’une Definition of Done simple et améliorons la en fonction de notre expérience! Je vous invite à revoir régulièrement votre DoD en équipe. La rétrospective peut être l’occasion d’échanger sur cette Definition of Done.

Pour compléter, une bonne pratique dans votre management visuel, sera de rendre visible cette DoD : la mettre dans votre Wiki, Confluence, et idéalement de l’afficher dans vos bureaux.

Pour aller plus loin

Quelques liens :

Découvrez DoD Kards !

avril 24, 2021 0

Rétrospective du changement

Dans cet article, je vais vous présenter une rétrospective qui peut être utile dans un contexte de changement d’équipe : dissolution de l’équipe ou transfert de l’équipe.

Le modèle de Tuckman

Mais avant de commencer, il me semble intéressant de présenter le modèle de Tuckman. Dans la vie d’une équipe, on retrouve classiquement 4 étapes qui ont été décrites par le modèle de Tuckman :

🏁Forming (formation) : le groupe se découvre et est motivé pour démarrer une nouvelle aventure ensemble sur un sujet qui est encore nouveau.
⚡Storming (tension) : les différents équipiers cherchent leur place dans l’équipe. Le projet avance et l’équipe va dans le vif du sujet quitte à avoir quelques tensions.
🏭Norming (normalisation) : l’équipe met en place ces normes, ces protocoles. La confiance se met en place.
🚀Performing (performance) : l’équipe est pleinement opérationnelle sur son sujet. La productivité va augmenter au fur et à mesure.

On peut représenter ces différentes phases par ce schéma :

inspire.ehe.osu.edu/files/2016/05/Bruce-Tuckman...

Ce modèle a été créé par Bruce Wayne Tuckman (psycho-sociologue américain) en 1965.

Une dernière étape Adjourning (dissolution) a été ajoutée au modèle en 1977.

Sans aller jusqu’à la dissolution, on constate souvent une baisse de productivité lors de changements concernant les membres de l’équipe. Si un membre est remplacé, on repassera par une phase de storming/norming, le temps que le nouveau membre s’aligne et que l’équipe évolue. Si l’équipe est délocalisée on repassera d’autant plus par ces différentes phases. L’objectif sera alors de minimiser la baisse de productivité en accompagnant le changement pour revenir rapidement sur la phase performing.

La rétrospective du changement

Pour aider lors d’un changement majeur d’une équipe (remplacement d’équipier, délocalisation, etc), je vous propose un template miro pour la rétrospective :

Je me suis inspiré de l’article de Jean-Pierre Lambert :

https://jp-lambert.me/la-r%C3%A9tro-de-d%C3%A9part-tirer-parti-du-d%C3%A9part-dun-collaborateur-pour-faire-grandir-l-%C3%A9quipe-mod-3b632fe7efb2

L’idée est de récupérer du feedback sur :

L’équipe actuelle. Cela permet aux équipiers de voir ce qu’ils ont apprécié et moins apprécié dans l’équipe actuelle. Ce feedback pourra aider les personnes à mieux s’adapter à leur nouvelle équipe.
Le produit. L’idée ici est que l’équipe prenne du recul et puisse aider la nouvelle équipe à connaitre les forces et les points d’amélioration du produit.
Le changement. Regardons ensemble les points positifs et négatifs de ce changement. Pour les personnes qui changent d’équipe, il y a certainement de nouveaux défis à relever : nouveaux domaines fonctionnels, nouvelles technologies? Peut-être un peu de regrets de ce départ. Faisons le point pour accompagner dans ce changement.

Je vous passe le lien du template miro dont vous pouvez vous inspirer : https://metroretro.io/board/LBQ9WWTP3H5T

Faire le bilan lors d’un changement majeur dans l’équipe doit permettre ici de garder l’équipe performante, accompagner les personnes dans leurs nouvelles équipes. Ce bilan permettra de prendre aussi en compte le facteur humain et d’aider les personnes à faire le deuil de l’équipe actuelle.

Pour aller plus loin, je vous conseille deux articles :

https://blog.trello.com/fr/modele-de-tuckman

Modèle de Tuckman : la cohésion d’équipe

« Le changement c’est maintenant!. »

— François Hollande

janvier 29, 2021 0

Scrum Guide 2020

L’histoire

En 1995, Ken Schwaber présenta dans un communiqué les fondements de Scrum. Nous fêtons donc en 2020 les 25 ans de Scrum. Le Scrum Guide quand à lui a eu sa première édition en 2011.

A l’occasion de ses 25 ans, une nouvelle version est proposée : le Scrum Guide 2020 et avec lui son lot de nouveautés!

Les nouveautés

Sans rebalayer tout le document avec vous, je pense qu’il est intéressant de noter les évolutions suivantes :

un cadre toujours léger (13 pages) : le document a été allégé pour être moins normatif.
une équipe soudée autours d’un produit :
- la notion d’équipe de développement au sein de l’équipe scrum n’est plus évoquée. On retrouve une équipe Scrum avec toujours les trois responsabilités : les développeurs, le Product Owner et le Scrum Master.
- On parle maintenant d’équipe auto-gérée (qui fait quoi, quand et comment) et plus auto-organisée.
- L’équipe doit rester focus sur l’objectif produit. On parle maintenant d’équipes concentrées sur un seul produit.
le notion d’objectif produit est introduite. L’ensemble du travail réalisé doit tendre vers cet objectif produit. Cela permet d’amener un objectif à plus long terme qui unit l’équipe autour de ce produit.
un sujet a été ajouté à la planification de sprint: « Quelle est la valeur ajoutée de ce Sprint? ». Cette partie met en valeur l’objectif du sprint qui était déjà présent.
l’engagement (commit, commitment and accountable) a été évoqué de façon plus intensive dans ce document par rapport à la version 2017.
le mot « lean thinking » a été ajouté à ce guide. Il est intéressant de noter dans cette méthode Agile qu’est Scrum, l’ajout de ce terme « lean thinking ». Le lean a précédé les méthodes Agile et ces deux méthodes sont complémentaires. Le lean est une méthode très utilisée de nos jours : on le retrouve entre autre dans SAFe. Le lean est évoqué pour deux points : la partie focus et l’élimination des gaspillages. Ce sont deux points qui à mon sens existaient déjà en Agilité, mais qui ont été clarifiés par l’ajout de ce terme.

Pour aller plus loin

Je vous conseille de vous faire votre avis en allant lire le document de référence : https://www.scrumguides.org/scrum-guide.html et son historique : https://www.scrumguides.org/revisions.html

Et pour voir ou revoir l’événement :

novembre 20, 2020 0

Rétrospective d’Halloween

🎃 En cette période d’Halloween 🕷, je vous conseille « La rétrospective dont vous êtes le héros » proposé par Octo :
https://lnkd.in/d2PKEDk

💻 Je vous propose un board Metro Retro que vous pouvez copier comme template en cette période :
https://lnkd.in/dhrQZY9

👩‍⚕️ Pour rester dans le thème et pour savoir si votre team est infectée, vous pouvez vérifier votre niveau de Zombie Scrum :
https://lnkd.in/dirpGpa

🧟 Pour vous changer en zombie, vous pouvez utiliser ce site : https://makemeazombie.com/

Bonne fête d’Halloween à tous! 🎃🕸🕷

octobre 29, 2020 0

Comment inclure les personnes en vacances dans les rétrospectives?

La rétrospective est un événement important en Agilité: c’est l’occasion pour l’équipe d’inspecter ce qui vient de se passer dans le sprint et de travailler ensemble sur un plan d’amélioration (Kaizen). Tous les domaines peuvent être abordés en rétrospective (en restant positif et constructif) : humain, organisationnel, pratiques, processus, outillage, qualité de vie au travail, conflits, interactions avec le métier.

Après avoir travaillé ensemble pendant le sprint, un équipier a souvent des éléments à échanger avec l’équipe. Si cette personne est absente (en cette période de vacances par exemple) pour la rétrospective, comment lui permettre de s’exprimer dans cette cérémonie (si elle le souhaite)?

La solution simple est un retour par mail

Dans les équipes avec lesquelles j’ai travaillé, le plus fréquemment, les personnes souhaitant remonter des informations en rétrospective envoient un mail à l’équipe avant de partir.

Une solution originale

J’ai souhaité proposer un template plus original pour permettre aux absents de profiter des différentes phases de la rétrospective (à remplir avant de partir en vacances) :

Il y a donc 5 colonnes, correspondants aux 5 phases que nous proposons dans les retrocards :

Contexte : dans cette phase de la rétrospective, le facilitateur présente quelques éléments permettant de situer le contexte du sprint (ce qui a été réalisé, le burndown par exemple). On pourra placer un post-it sur des remarques générales concernant le contexte.
Actions précédentes : en général dans cette phase, on fait le point sur les actions pour lesquelles l’équipe s’était engagée. On pourra placer des post-it sur ces actions.
Etat d’esprit : dans mon équipe, les personnes indiquent une note entre 1 et 5 pour préciser leur humeur (1 si le sprint s’est mal passé pour eux et 5 si c’était parfait)
Génération d’idée : cela correspond à la phase dans la rétrospective où le facilitateur va choisir un format de rétrospective (par exemple speed boat). L’équipe va échanger sur le sprint et ce qu’on pourrait améliorer. L’idée ici avant de partir en vacances est d’indiquer les points positifs et négatifs du sprint.
Actions à faire : normalement les actions seront définies par l’ensemble de l’équipe présente à la réunion. Mais les personnes absentes, peuvent suggérer à l’équipe des idées qu’elles aimeraient voir dans le prochain sprint.

Si ce template vous intéresse, je le partage avec vous : https://metroretro.io/board/Sy1bqZY-v

Il faudra remplir le template sans masquer les post-it. Le facilitateur présentera les différentes colonnes au fur et à mesure de la rétrospective.

D’autres solutions existent : faire une boite à idées par exemple.

Et vous?

Et vous dans vos équipes, les personnes absentes à la rétrospective ont-elle des astuces pour partager leurs idées d’amélioration et remonter leurs idées à cette réunion?

août 6, 2020 0

Google cloud – retour d’expérience

Je me suis lancé récemment dans un projet nodeJs. Souhaitant pouvoir tester rapidement une version déployée de mon application, j’ai décidé d’utiliser Google Cloud : Google offre une plateforme assez complète et vous offre 300$ pour démarrer en toute tranquillité : https://cloud.google.com/free?hl=fr

Différents types d’hébergement dans le cloud

Google cloud propose 3 solutions différentes pour déployer votre application nodeJs :

Utilisation d’un serveur virtuel (Compute engine) : https://cloud.google.com/compute/docs/instances?hl=fr

Je n’ai pas testé cette solution. Je pense qu’elle nécessite plus d’administration.

soit une architecture basée sur kubernets: https://cloud.google.com/kubernetes-engine?hl=fr

J’étais parti initialement sur cette solution. L' »autoDevops » de Gitlab doit permettre de déployer automatiquement des images docker sur Google Cloud. J’ai rencontré quelques difficultés sur le paramétrage que j’aurais pu résoudre. Mais j’ai préféré migrer vers App Engine qui semblait mieux répondre à mon besoin :

soit un service d’hébergement d’application (App Engine) :

https://glaforge.appspot.com/article/building-and-deploying-microservices-with-app-engine-and-cloud-functions

App Engine propose d’ailleurs deux modes de fonctionnement : le mode standard et le mode flexible. Le mode flexible permet de mieux s’adapter au trafic, les applications sont lancées dans des conteneurs dockers, etc: https://cloud.google.com/appengine/docs/the-appengine-environments?hl=fr

Mode flexible vs Mode Standard

Souhaitant démarrer rapidement, j’ai suivi un tuto (sans comparer les deux modes) qui m’a orienté vers le mode flexible. Je me suis rendu compte les jours suivants que mes crédits offerts par Google diminuaient à vue d’œil (près de 8€ consommés par jour):

Le mode flexible est facturé à l’heure sous la ligne de facturation « Flex Instance Core Hours EMEA » que vous utilisiez le service ou non, les coûts s’accumulent…

Le mode flexible n’est clairement pas adapté pour une application en cours de démarrage comme la mienne et dont il n’y a pas de contrainte de performance. Je vous conseille si vous souhaitez démarrer sans frais le mode standard qui m’a permis de revenir sur un coût de 0€ par jour.

Un petit aperçu du cloud Google

Pour résumer, vous retrouverez les différentes parties que je viens d’évoquer dans la partie « Compute » de cette illustration :

juillet 11, 2020 1

Rétrospective KISS

En tant que Scrum Master, j’essaie de proposer une rétrospective en fonction du contexte de l’équipe.

Dans les conditions actuelles, il y a de nombreux outils pour animer des rétrospectives en ligne. Je vous conseille metroretro. Cet outil gratuit propose différents formats de rétrospective de base et permet de créer ses propres formats de rétrospective.

Lors de la création de l’équipe, notre système architecte nous avait présenté le principe KISS : « Keep it simple, stupid ». Ce principe préconise la simplicité. Il est important en informatique : toute complexité du code ramènera un surcout à la maintenance. Je vous conseille ce très bon article qui présente ce principe dans le domaine de l’informatique : https://blog.myagilepartner.fr/index.php/2017/01/26/la-philosophie-du-developpement-kiss/

J’ai souhaité réaliser une rétrospective sur ce thème pour que l’équipe reste focus sur le MVP et la simplicité du code. Dans notre cas, l’application devant passer en production d’ici peu, j’ai aussi profité de cette rétrospective pour voir comment l’équipe appréhendait le sujet.

Les phases de l’animation

J’ai animé cette rétrospective de façon assez classique :

J’ai présenté les différentes colonnes où les membres de l’équipe devaient préparer leur post-it.
Ils ont eu 10 minutes pour préparer leur post-it.
Chacun son tour, les membres de l’équipe ont présenté leur post-it.
En fonction des post-it, nous nous sommes mis d’accord sur les actions à mettre en œuvre pour le prochain sprint.

Les 5 colonnes

Le tableau était donc découpé en 5 colonnes :

« K » : Keep. Ce que l’équipe souhaite conserver : bonne pratique, ce qui a fonctionné.
« I » : It (management). Notre application va passer en production. Est-ce que l’équipe est prête? Quels sont les éléments dont l’équipe aura besoin pour ce passage en production?
« S »: Simple. Que peut-on simplifier? Penser au MVP et à la maintenabilité de l’application.
« S »: Stupid. Quelles sont les difficultés dans l’équipe?
Et je me suis permis d’ajouter une case en haut à droite pour les remerciements.

Comment copier mon template

Si vous souhaitez recopier ce format de rétrospective, vous pouvez :

Cliquer sur ce lien : https://metroretro.io/board/SJLf09aYL
Revenir sur votre tableau de bord metreoretro : https://metroretro.io/
Et cliquer sur « Start as template » sur la retrospective que je vous propose :

Mai 12, 2020 0