Le 4 novembre 2013, j’ai été invité par le French Scrum User Group à présenter dans les nouveaux locaux parisiens de Google, « le rôle du coach Agile et son apport pour le projet ». C’était ma première présentation Agile ouverte au grand public. Jusqu’alors, je n’étais intervenu qu’en entreprise.
Pourquoi un tel sujet ? Parce que bien trop souvent, on ne sait pas vraiment ce que peut apporter un coach Agile pour un projet et on est freiné par son coût (qui est plus cher qu’un développeur mais pas plus qu’un consultant). Et pourtant, le coach Agile peut être décisif dans la réussite du projet car il va s’attaquer aux sujets qui coûtent le plus aux projets. Il va même dans certains cas sortir le projet d’un échec garanti.
Le but de cette présentation est de sensibiliser sur ce rôle et cette valeur ajoutée qu’il apporte pour le projet. La présentation étant limitée dans la durée, le sujet est loin d’être entièrement couvert et l’amplitude du rôle du coach Agile est bien plus vaste. Mais c’est un bon début.
En espérant que les slides, très imagés pour assurer une présentation vivante vous suffiront sans la bande son qui est toute aussi importante. Une captation vidéo a eu lieu. Elle est disponible sur Youtube.
Ci-dessous, les slides disponibles sur Slideshare. Vous pouvez également télécharger les versions pdf, ppsx (diaporama) et pptx (présentation). Tous mes articles sur l’agilité sont disponibles sur coachAgile.fr ou le mot-clé Agile dans le nuage de tags situés sur la droite de cette page.
Franck Beulé
Coach Agile, expert des technologies de l’Internet et en ergonomie du Web
Les jeux agiles permettent de mettre en valeur un point particulier à travers un niveau d’abstraction qu’est le jeu. C’est en général avec des activités ludiques que les notions sont les mieux acquises. Et c’est tout à fait professionnel.
Il est bien difficile de prioriser ses activités. Ça l’est encore plus lorsqu’il est nécessaire d’avoir un consensus de groupe. C’est ce que ce jeu agile de priorisation tente de mettre en valeur. Je n’étais pas présent lors de ce dixième agile playground où ce jeu a été organisé, mais Arnaud Villenave a écrit un excellent compte rendu que je vous invite à lire. Et n’hésitez pas à organiser ce jeu au bureau !
Beaucoup de réunions sont inutiles et vous y perdez votre temps ? Il est temps d’agir et d’y mettre un peu d’agilité…
Cela commence dès l’envoi de l’invitation. Toute invitation sans objet, salle et ordre du jour doit automatiquement être refusée avec le motif du refus. De même, une réunion jugée sans intérêt doit également être refusée avec le motif du refus.
La réunion doit commencer à l’heure et être limitée dans sa durée. L’ordre du jour, la durée et les objectifs visés doivent être rappelés en début de réunion. Bien entendu, il ne doit y avoir qu’une seule conversation à la fois. En fin de réunion, un rappel des décisions prises est fait. Les actions sont affectées et ont un objectif de date. Une réunion doit idéalement se terminer par un ROTI (retour sur le temps investi).
Il existe bien d’autres éléments à cadrer lors d’une réunion. Pour en savoir plus, je vous invite à lire l’excellent article de Jean-Claude Grosjean sur le hacking des réunions.
La conférence Agile France 2013 est la huitième édition organisée par Agile France. Pendant deux jours, des conférences, retours d’expériences, live coding, ateliers et jeux agiles se sont enchainés simultanément dans six salles. Cet événement a eu lieu les 23 et 24 mai 2013. Le principe et l’organisation sont similaires au Scrum day qui a eu lieu un mois plus tôt mais qui était concentré sur une seule journée. Vous pouvez lire mon compte-rendu du Scrum day ou visiter le site de la conférence Agile.
Voici mon retour d’expérience sur ces deux journées où il a fallu que je choisisse certaines conférences au détriment d’autres qui avaient lieu au même moment. Quelques regrets donc, mais globalement deux journées très enrichissantes. En fin d’article, vous trouverez la liste, je l’espère exhaustive, de tous les comptes rendus et slides publiés sur la toile. Compte-rendu. Lire la suite
Estimer la durée d’un projet ou la durée d’un artefact de développement, qu’il s’appelle histoire, composant, fonctionnalité ou autrement, voila un exercice bien difficile ! Longtemps confiné au rôle de chef de projet, l’agilité a délégué ce rôle à l’équipe. Et bien oui, qui mieux que l’équipe est à même d’estimer une tâche puisque c’est elle-même qui va la réaliser ? Oui, mais voila. L’équipe ne sait pas bien le faire. Et en se retournant vers le chef de projet, elle découvre que ce n’est pas mieux pour lui, hormis avec la technique du doigt mouillé, c’est à dire un chiffrage basé sur le sens du vent au moment même du chiffrage. Un moyen comme un autre…
Estimer, c’est aussi compliqué car le quoi à réaliser est plus ou moins vaste selon les points de vues. Le chef de projet est celui qui verra la version la plus simple du besoin alors que le responsable de la sécurité y verra une charge énorme, les développeurs se positionnant souvent un peu entre les deux, à savoir entre un mois et un an, à peu près…
A tel point qu’il existe même un mouvement de pensée pour la suppression totale des estimations. Selon eux, estimer est une perte de temps pour aboutir à un résultat de toutes manières aléatoire. Ils ont raison à un certain point. De mon humble avis, la seule estimation possible est comparativement à une autre situation similaire : avec une équipe à peu près équivalente et une fonctionnalité à peu près semblable.
Pour les personnes qui ne comprennent pas pourquoi estimer est aussi compliqué, je vous propose de lire un article de Michael Dubakov, malheureusement uniquement en anglais, expliquant toute la problématique de cette complexité. A lire avec attention, même si vous n’allez pas jusqu’au bout…
Charles Mayer est un étudiant qui réalise un mémoire de Master sur le thème de l’agilité. Il a fait un appel public pour participer à un questionnaire sur les pratiques Agiles en entreprise. Son questionnaire est intéressant car chaque question pointe les différents apports des méthodes Agiles ainsi que les différents freins à son adoption. L’ensemble de ces questions correspond donc à des affirmations vraies, ou du moins qui sont censées l’être et qui, si elles ne le sont pas, le devraient.
Son travail sur le questionnaire montre déjà qu’il pointe les bonnes choses. Je suis impatient d’en connaître les résultats. D’ici là, n’hésitez pas à lui donner un coup de pouce en répondant vous aussi à son questionnaire.
Voici les questions relatives à l’apport des méthodes Agiles : Lire la suite
Le Scrumday est un événement annuel organisé par l’association French Scrum User Group. Ce 11 avril 2013 avait lieu la troisième édition de cet événement à renommée nationale. Pendant une journée, 500 Agilistes se réunissent, échangent et partagent autour du thème de l’Agilité.
Certes, il existe des outils pour gérer ses projets Agile comme Jira / Greenhoper, Mingle ou VersionOne. Mais aucun n’est réellement ergonomique ni ne sort du lot. Au point que, oh horreur, Excel ou un peu mieux Google Spreadsheet sont utilisés en lieu et place d’outils spécialisés. Une solution du pauvre car ces outils ne gèrent pas de workflow. Beaucoup utilisent exclusivement des post its sur un tableau. On trace de traits et hop, on a directement l’interface que l’on veut et si l’on souhaite la changer, un coup d’effaceur et hop c’est reparti. Il ne reste qu’à déplacer les post its.
Il manque un outil qui offre la même représentation visuelle que ce que l’on cherche à avoir sur un tableau physique et qui soit aussi simple à manipuler que des post its sur un tableau physique.
Eidos est un nouvel outil, disponible en beta pour l’instant, qui semble enfin traiter l’aspect ergonomique des choses. Il était temps ! Je ne l’ai pas encore testé, mais il mérite qu’on y jette un coup d’oeil. Il n’est malheureusement pas Open Source. Un outil à suivre qui sera commercialisé fin juin 2013. D’ici là, vous pouvez participer au beta test dès aujourd’hui.
En octobre 2012, les équipes de Spotify ont présenté leur organisation agile composée de Tribes, Squads, Chapter et Guilds.
Les squads sont des équipes chargées de la réalisation d’une fonctionnalité.
Les tribes sont des regroupements d’équipes afin de favoriser les échanges entre elles.
Les chapters sont des entités transverses inter-équipes qui sont chargées de la cohérence des réalisations entre équipes.
Les guilds sont des groupes de personnes transverses chargées d’améliorer les pratiques.
Ce document présente une organisation à la fois verticale et horizontale afin d’optimiser les échanges entre personnes
tout en évitant le temps perdu. Une approche intéressante à découvrir.
À l’occasion de la première rencontre organisée lundi 3 décembre 2012 par l’association Agile .Net dans les locaux de Microsoft, j’ai eu la chance de rencontrer pour la première fois Jeff Sutherland, le fondateur de la méthodologie Scrum. L’occasion pour lui de faire le point sur la situation de Scrum dans le monde et plus particulièrement aux États-Unis. Qu’a-t-il dit ? Compte-rendu.
Mes conférences en vidéo
Mots clés : 
