Quand je serai grand, je serai ScrumMaster!

Lors des rétrospectives, la technique classique pour pouvoir filtrer les sujets à discuter est le dot voting . On donne 3 voix (+/-) à chaque membre de l'équipe et il vote pour le sujet qui lui tiens à coeur. Ce principe a un gros problème dans mon équipe actuel: il y'a 5 développeurs, 2 testeurs, 1 PO et 1 UX/Designer. Je n'ai pas besoin de faire un dessin pour vous montrer que les sujets choisis sont toujours les sujets qui concernent les développeurs car ils sont en majorité. L’équipe de recette et le PO peuvent avoir des points communs mais je vous garantit que l'UX n'a aucune chance de pouvoir avoir du poids dans le vote. C'est souvent très frustrant pour eux ! J'ai trouvé une alternative à ceci: la devinette . Le jeu fait partie de l'agilité non ? Je prépare 3, 4 ou 5 devinettes avant la rétrospective: des questions de rapidité, de calcul mental ou de culture/actualité, voir des questions "agile". Celui qui répond correctement en prem

Ci dessous une représentation d'un organigramme "idéal" pour que l'agilité puisse s'exprimer à plein régime. Cette image me parle beaucoup ! J'ai extrait ces images d'un article de Ron Jeffries, je vous résume l'idée majeur qui m'a plu. Pour que les idées agiles puissent fonctionner à plein régime, l'entreprise doit être pensée sous la forme d'un arbre: le tronc (i.e le grand chef!) et toutes les branches du management sont la pour supporter les feuilles qui représentent la où le produit/la production est réalisé. Ceci est également vrai en dehors de l'agilité,  dans n'importe quel forme de management moderne. Malheureusement, quand le support du management n'est pas suffisant ou si les équipes de développement n'arrivent pas à fonctionner en agile, les feuilles ne sont pas en bonne santé. Elles se fanent et tombent... Je pense que l'image est suffisamment parlante pour ne pas av

Je suis tombé sur un format de rétrospective dont j'adore le concept: "Turn the tables" Pour décrire en une phrase ce que j'ai compris et apprecié: Une autre personne que vous explique les post-its que vous écrivez. On voit ainsi si l'équipe se connait, un facteur clé de succès ! http://retrospectives-agiles.fr/post/46705782065/la-r%C3%A9trospective-turn-the-tables

Une métaphore sur la différence entre un cycle itératif tel qu'on pourrait se l'imaginer et un mode itératif réussi basé sur la notion de MVP L'explication détaillé du raisonnement "MVP" derrière ce dessin: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

Si vos retrospectives ressemblent à ca, c'est qu'il y'a des chefs un peu trop influent dans vos équipes (ou des chefs tout court ?). En agile, c'est l’équipe qui décide et s'auto-organise ! Petit manque de mise a jour récemment car j'ai été débordé par les vacances, ci dessus un sujet léger pour s'y remettre...

J'ai débuté une nouvelle mission dans une équipe qui ne travaille pas en Sprint mais uniquement avec un Kanban. Il m'est assez vite apparu qu'une partie des membres de l'équipe utilise le Kanban parce qu'on leur a demandé et pas parce qu'il est utile pour leur travail quotidien. Après quelques jours d'observation, j'ai donc essayer de dérouler un jeu qui me semblait adéquat:  http://tastycupcakes.org/2009/06/were-having-a-party/ Le jeu consiste à réaliser une invitation pour une fête en découpant en taches multiples la réalisation de l'invitation: on réalise 2 fois le process de 2 manières différentes (batch&queue puis single piece flow). Cette forme la est très simple et rapide, il existe des variations plus complète sur le même principe, tel que ici:  http://www.netobjectives.com/resources/articles/the-dot-game L'objectif est de faire prendre conscience aux participants qu'il est plus productif pour l'équipe de finir une user st