Comment en finir avec le KEEP DROP START ou comment varier les formats de rétrospectives?

A vous, Scrum Master qui passez du temps à chercher des formats novateurs de rétrospectives à la fin de chaque Sprint ! A vous, facilitateurs divers et variés qui souhaitez donner un second souffle à vos projets tout en utilisant des méthodes ludiques pour vos ateliers ! A vous tous, qui en avez assez du simple KEEP DROP START : vous êtes au bon endroit !!!

Petit 1 : pourquoi en finir avec le Keep Drop Start pour vos rétrospectives ?

C’est en effet la première question à se poser.

Une rétrospective, rappelons-le, a pour objectif de favoriser l’amélioration continue au sein d’une équipe grâce à une introspection. Autrement dit, de faire un bilan de tout ce qui fonctionne bien et qui est à garder (le KEEP), de tout ce qui ne fonctionne pas bien et qu’il faut arrêter (le DROP) et de tout ce que l’on peut mettre en place au cours de la prochaine itération (le START). On pourra y faire référence à des flux de travail, à des interactions entre collègues, aux outils utilisés, aux rôles et responsabilités de chacun etc.

Pour atteindre cet objectif, il est alors important de mettre à l’aise l’équipe, de se dire les choses, de veiller à ce que cela puisse se faire dans la bienveillance et, au passage, de passer un bon moment tous ensemble !

Si nous en restons au format Keep Drop Start à chaque rétrospective, nous pouvons provoquer le même effet que si nous leur donnions la même chose à manger à chaque fois : de la lassitude, de la démotivation et la possibilité que ce moment privilégié soit finalement bâclé.

Avoir un format ludique et créatif est d’autant plus important dans le contexte d’un changement organisationnel et de mise en place de nouvelles méthodes de travail. Les travaux de Kurt Lewin ont d’ailleurs montré que l’appartenance à un groupe favorise un processus d’apprentissage et l’adoption de nouvelles attitudes. Quel meilleur moment que la rétrospective pour favoriser cette dynamique ?

 

Conclusion : finissons-en avec le Keep Drop Start !!!

Ou plutôt, utilisons le cadre “Keep drop start” de manière différentes pour stimuler la créativité et la motivation de vos équipes !

 

Petit 2 : OK super, mais on fait comment ?

Les possibilités qui vont suivre peuvent se combiner et se substituer. Ceci n’est pas une liste exhaustive mais quelques petites choses que j’ai pu tester.

Possibilité #1 : Utiliser des métaphores et les associations d’idées

Avec cette possibilité, nous avons une variété infinie de rétrospectives dans le creux de nos mains ! Il existe déjà différents formats de rétrospective qui passent par la métaphore comme le “Speed Boat”, “Comme une fleur”, la rétrospective “Star Wars”…

Vous pouvez vous amuser à créer vos propres formats !

Vous pouvez par exemple utiliser des thèmes liés à l’actualité, au cinéma, à la culture, au voyage

Cela élargira le champs des possibles pour les participants qui vont se faire leur propre image mentale de la consigne pour aller plus loin dans la réflexion.

Possibilité #2 : Ajouter des étapes

Les équipes ont quelquefois du mal à passer de l’étape du “bilan” à l’étape de “trouver des idées d’actions”. Laissez-leur le temps de générer des idées, de discuter, de se perdre dans leur discussion d’origine pour avoir de nouvelles idées !

Possibilité #3 : Ne pas passer du tout par les étapes KEEP/DROP/START

Autrement dit, autorisez-vous à profiter de ce moment privilégié pour approfondir certains points avec l’équipe. La rétrospective, c’est l’occasion pour l’équipe pour travailler ensemble sur un sujet particulier, par exemple :

  • définir les règles de vie de l’équipe
  • approfondir une notion agile ensemble qui est encore confuse (l’estimation / les rôles du PO – Scrum Master – équipe réalisatrice / la vision produit …)
  • permettre un tour de table pour une discussion ouverte de l’équipe

 

Petit 3 : le mot de la fin

La rétrospective est donc un moment d’échange pour lequel il ne faut pas hésiter à user de créativité ! Utiliser des métaphores pour générer des nouveaux formats, rajouter des étapes pour laisser le temps aux équipes de détailler les idées d’actions ou même, casser la routine de la rétrospective sont autant de moyens pour aider vos équipes à avancer ensemble.

A vous de rajouter de nouvelles possibilités !

 

Cyrielle EUDELINE

Shu Ha Ri

 

Le Shu Ha Ri est, à l’origine, un concept provenant des arts martiaux utilisé lors de l’étude des katas. Cela passe par 3 étapes comportementales, dans un premier temps l’imitation : puis la compréhension et enfin l’intériorisation ou l’adaptation.

 

  • Shu : Suivre les règles. Le disciple rentre par cette phase dans l’apprentissage. Il suit aveuglément les règles dictées par le maître.
  • Ha : Comprendre les règles. Le disciple questionne les règles, il peut faire le lien avec d’autres pratiques et commencer à en voir les limites.
  • Ri : Adapter les règles. Le disciple se détache des règles. Les techniques sont maîtrisées et utilisées de manière appropriées. Il peut maintenant les transcender et les adapter. Il devient son propre guide.

 

Ce concept est transposable à l’apprentissage de n’importe quelle discipline. On peut prendre, comme autre exemple, un musicien qui travaille ses gammes en les répétant en boucle, phase du Shu, afin de mieux comprendre leurs constructions, phase du Ha et enfin pourquoi pas composer ses propres musiques , phase du Ri.

 

Dans notre métier d’accompagnement vers de nouvelles façons de travailler, il peut s’avérer très utile de s’aider du Shu Ha Ri pour mettre en place certaines pratiques. Par exemple, lors d’animation de formation, commencer par un rappel des trois phases, en expliquant que nous sommes actuellement dans le Shu (et non pas dans les choux ^^) peut être pertinent pour bien commencer.

 

Anthony Coulon

Le rôle du PO est de gérer le backlog et c’est tout !

Aujourd’hui il y a beaucoup de discussions autour du rôle de product owner (PO); sur ses objectifs mais aussi sur ses outils, notamment le backlog. Il est souvent vu comme réducteur de résumer le travail du PO à la tenue du backlog. Il m’est même arrivé de voir des PO refuser cette tâche et l’attribuer au rôle ajouté de proxy PO (PPO).

Et si je vous disais que le seul et unique objectif du PO est de gérer le backlog ? Mais cela n’a rien de réducteur au contraire. C’est pour clarifier cette pensée que je me propose d’établir une liste non exhaustive du travail qu’il y a derrière « gérer un backlog ».

 

 

Comprendre le besoin

D’abord soyons clair, le backlog est une liste de besoins, et non de solutions. Afin d’apporter de la valeur au produit il est important d’avoir une pensée orientée besoins.

Pour y arriver, dès les premiers instants de la construction du backlog et tout au long de sa durée de vie, le PO doit travailler étroitement avec les futurs utilisateurs et les parties prenantes du projet (sponsors, experts, management…)  Selon le nombre de parties prenantes, il faut également réussir à aligner les contraintes et les besoins pour construire un produit cohérent.

Il s’agit déjà là d’une tâche très compliquée puisque nous avons tendance à réfléchir à des solutions et non des besoins. Et pourtant, le PO n’est pas au bout de ses peines puisque remplir le backlog de besoins n’est que le premier pas.

 

Imaginer une solution

Le PO a besoin de  travailler avec l’équipe de réalisation pour imaginer la meilleure solution possible afin de répondre au besoin de l’utilisateur. C’est-à-dire une solution fonctionnelle qui va apporter de la valeur à l’utilisateur sans dégrader le reste du produit.

Encore une fois, le PO doit aligner les différentes contraintes afin de permettre au produit de correspondre à la vision générale tout en gardant une bonne conception (visuelle, ergonomique et technique).

Le besoin et sa solution doivent être suffisamment explicites et clairs pour que tous les acteurs parlent le même langage et que le produit réalisé corresponde bien à ce qui a été travaillé.

 

Maximiser la valeur ajoutée/apportée

Ne l’oublions pas, l’un des objectifs du product owner est de maximiser la valeur produite, c’est-à-dire le retour sur investissement. Pour cela il a encore 2 missions.

Le PO doit prioriser le backlog de produit suivant divers critères. Cela peut nécessiter de travailler avec les parties prenantes ainsi que l’équipe de réalisation pour comprendre la valeur réelle apportée par la réponse au besoin, ainsi que la difficulté de réalisation de la solution proposée. Au delà de la valeur vécue par l’utilisateur, il y a là la notion de retour sur investissement qui entre en jeu. Dans certains cas les solutions peuvent être revues et dégradées afin de répondre au mieux et au plus vite au besoin.  

Suivre et monitorer l’avancement du produit

Enfin, une dernière tâche souvent attribuée au PO, et qui peut nécessiter une bonne tenue du backlog, est le monitoring sur l’avancement du produit. Il est donc souvent nécessaire d’ajouter des données aux items de backlog et d’avoir une avance suffisamment confortable pour voir arriver les problématiques. Il faut donc effectuer toutes ces tâches avec un peu d’anticipation pour pouvoir s’assurer que la direction que prend le produit est la bonne.

Il est également nécessaire de découper les besoins finement afin de réduire la marge d’erreur et d’assurer un apport de valeur à chaque itération, quelque soit sa durée.

 

Conclusion

Pour « seulement » remplir le backlog, le PO doit donc :

  • aligner les différents acteurs,
  • comprendre les besoins,
  • les découper,
  • imaginer une solution fonctionnelle,
  • et le tout avec une avance permettant de suivre la vision du produit.

Bien entendu aucune de ces tâches ne se fait en une fois et nécessite de nombreux aller-retour et dialogue avec les différentes parties.

Alors, pensez-vous toujours que gérer le backlog soit un travail simple à déléguer à d’autres ? Est-ce réducteur de penser qu’il s’agit de la priorité du PO ?

 

Marc Bougeret

Nous lançons nos premières Sketchnights !

Mardi 31 Juillet 2018, nous avons tenu notre première Sketchnight !

Une vingtaine de consultants Zenika, de leurs clients, et de coaches Agiles, débutants comme confirmés en sketchnoting, se sont retrouvés pendant deux heures pour échanger et apprendre à mieux pratiquer, ensemble.

L’idée de la rencontre est de produire des sketchnotes en un temps limité, sur des thèmes liés à l’Agilité (ou pas 😉 ).

Nous ré-ouvrirons nos portes à tout curieux ou enthousiaste du sketchnoting courant Septembre 2018, où ils seront les bienvenus ! Nous vous informerons plus précisément à ce sujet d’ici quelques semaines.

En attendant, quelques photos de notre soirée !

Nous commençons à donner des certifications Management 3.0 !

Notre pôle Agile (KAI) est depuis quelques mois habilité à former et certifier en Management 3.0.

En 2011, Jurgen Appelo publiait la première édition du Management 3.0, qui allait donner un cadre théorique et pratique à un nouveau type de management, des interactions entre personnes plutôt que des personnes elles-mêmes.

Le manager 3.0 aura pour tâche :

  1. de stimuler ses collègues
  2. de les responsabiliser et les rendre autonomes
  3. d’aligner les contraintes et objectifs
  4. de développer les compétences de ses collègues
  5. de faire croître la structure qu’ils forment
  6. et de cherche l’amélioration en permanence

Aujourd’hui, les pratiques liées au management 3.0 ont évolué. Nous vous proposons une formation d’actualité donnée par des personnes qui vivent cette approche au quotidien.

Notre approche ? Nous mêlons notre passion du développement personnel, des thérapies brèves et systémiques avec les approches du Management 3.0 pour vous offrir ce dont vous aurez besoin pour transformer votre activité et vos équipes, dans votre contexte !

Intéressés par l’aventure ? Contactez-nous !

 

Sketchnote Challenge @KAI

Du 4 au 8 juin derniers, afin de faire connaître le sketchnoting by Zenika, de s’améliorer (et tout simplement de pratiquer), les membres de KAI se sont donnés un challenge : un sketchnote par jour, chaque jour sur un thème différent.
Cette semaine, les thèmes étaient les suivants :

  • Lundi : La compréhension partagée
  • Mardi : L’inconfort génère le changement
  • Mercredi : Les réunions pourries
  • Jeudi : C’est quoi un coach Agile ?
  • Vendredi : L’importance du non-verbal dans la communication

Les règles du jeu ? Chaque jour, à 17h, nous postions nos oeuvres sur les réseaux sociaux et notre RSE.

On peut dire que notre chat a été particulièrement actif ! Chacun d’entre nous a pu faire montre de son propre style et de sa propre vision. Nous sommes tous heureux des résultats, du partage que nous avons pu avoir entre nous ou ailleurs, et de ce que nous avons pu apprendre de l’expérience, que nous renouvellerons bientôt !

Si vous êtes intéressés à l’idée d’en connaître plus sur les mondes vastes du sketchnoting, du scribing et de la facilitation graphique, venez vivre notre formation dédiée !

Quelques photos…

Merci à Nicole Nguyen, Céline Swierkowski, Séverine Luzeau,  Hicham Amraoui, Marc Bougeret, Anthony Coulon, Olivier Damour, Pierre Faure, Yoan Lureault, Caroline Sapt et Alain Sibous pour leur participation !

Jour 1 : la compréhension partagée

Jour 2 : L’inconfort génère le changement

Jour 3 : Réunions Pourries

Jour 4 : C’est quoi un coach Agile

Jour 5 : L’importance du non verbal dans la communication