Romain Chauny » Scrum http://www.rchauny.fr Web-Marketing & e-Commerce @ Grenoble Mon, 06 Feb 2012 12:47:49 +0000 en hourly 1 http://wordpress.org/?v=3.0.3 Jeux Agile Scrum : Artists & Specifiers http://www.rchauny.fr/jeux-agile-scrum-artists-specifiers/scrum-agile/ http://www.rchauny.fr/jeux-agile-scrum-artists-specifiers/scrum-agile/#comments Mon, 25 Jul 2011 08:44:21 +0000 Romain Chauny http://www.rchauny.fr/?p=1076

La méthodologie SCRUM – et plus généralement l’agilité – est un concept qui se veux entrainant et motivant pour l’équipe. Il a le mérite de placer l’humain au centre du débat (comme Google?) en tant que developpeurs, de clients, mais surtout au final, en tant qu’équipe ! Dans ce sens, de nombreuses sociétés tentent de faire la bascule vers ces nouvelles méthodologies de travail.
L’une des méthodes permettant de découvrir les concepts de l’agilité est le jeux! Oui, simplement de jouer…

En effet, cela permet de donner tout d’abord un aspect ludique à la formation : On apprend en s’amusant, c’est moins rébarbatif que de voir défiler les slides powerpoint, et c’est bien evidemment un moyen de se focaliser plus simplement sur un sujet nouveau. Cela permet également de sortir d’un contexte professionnel connu, parfois un peu « rébarbatif », et s’affranchir ainsi de nos « casquettes » (le responsable de projet peut prendre le rôle d’un développeur et inversement). On peut aussi eviter ansi des « à prioris » vis-à-vis des différents corps de métier…
Mais le jeu a pour principal attrait de mettre en avant, de manière simple mais claire, les avantages certains de la méthodologie face au problématiques quotidiennes du travail en équipe. Ainsi, en transposant les situations dans des contextes professionnels concret et familier, on réalise souvent à quel point la problématique qui faisait sourire dans dans le jeux, et un problème bien réel et nuisible pour l’équipe.

Il existe ainsi des dizaines de jeux « Agile » et beaucoup de « coach » proposent leur cuvée « maison ». Le jeu que je souhaite vous présenter dans cet article est appelé « Artists & Designers ». Ce jeux a été crée initialement par Allistair Cockburn (the Draw – This drawing game), guru de l’agilité. Bien qu’ayant eu l’opportunité de participer à une formation avec Allistair, c’est avec Alexandre Boutin et Agilex que j’ai eu l’occasion de pratiquer ce jeux, d’abord en tant que participant, puis en tant qu’organisateur lors de mon rôle de « coach Agile ». Encore un grand merci à Alexandre donc pour la démonstration magistrale de bonne approche avec ce jeux.

Ce jeu a l’avantage d’être simple à mettre en place et necessite un minimum de matériel. Il permet de mettre en evidence de manière ludique l’importance des principes de bases de l’agilité (feedback continu, itération courte, etc). Vous êtes prets, alors c’est parti :
  • Le principe de base consiste à réunir une équipe composée de dessinateur (artist) et de client (designer).
  • Ainsi les dessinateurs doivent reproduire un dessin sans l’avoir vu, par les simples explications de leur client.
  • Tout d’abord, commencez par créer vos equipes et à les nommer (pour des raisons pratiques)
  • Prévoir 5 minutes pour réunir des equipes pouvant aller entre 5 et 7 personnes.
  • Idéalement repartir de la manière suivante : 2 Designers et 4 artistes par équipe
  • Expliquer simplement, clairement, mais aussi succinctement le principe du jeux.
  • Les artistes sont dans une salle qui représente leurs locaux d’entreprise.
  • Les designers, qui vont transmettre leur demande aux artistes, ne peuvent pas emmener le modèle à retranscrir dans ces « locaux ». Le modèle reste à l’exterieur
  • Les designers doivent ainsi transmettre l’information aux dessinateurs afin que ces derniers reproduisent un modèle exact du dessin d’origine.
  • Détail notable, les echanges d’informations doivent etre fait uniquement par écrit (oui, les specs sont souvent ecrites, par mail, etc…)
  • L’itération est de 10 minutes, c’est à dire qu’on demandera après 10min la récupération de la copie.
C’est tout pour le moment comme dirait la fameuse voix, on laisse volontairement certains « flous » autour de la gestion (on precise le temps d’itération total, mais pas celui de specification ou de production). 3 itérations sont necessaires pour mettre en exergue les problématiques…

Itération 1
C’est parti ! Les designers prennent des notes à l’exterieur de la salle, puis les transmettent à leurs equipes d’artiste pour reproduction. Il est bon de cadencer cette première itération en rappelant de décompte du chronomètre, afin d’aider un peu. Il est également interessant de noter le temps où la première spec arrive chez l’equipe de dessinateur… souvent révélateur d’un certain soucis d’organisation. La première itération est souvent assez folklorique et les dessins ramenés plutot etranges par rapport au modèle d’origine !

Rétrospective de l’itération 1
On propose 5minutes chronométrées aux equipes afin d’organiser une retrospective. On peut leur proposer un modèle classique de la rétrospective afin de les encadrer un peu dans cette procédure : Noter les pratiques à conserver, celles qui posent problèmes, et enfin, les solution à essayer.

Rétrospective commune
La retrospective commune a pour objectif d’aider les equipes, de partager les idées et d’orienter un peu les solutions. On peut alors mettre en avant une solution particulière à tester qui servira d’exemple positif pour appuyer une théorie, où au contraire de contre exemple. Un point important à ce moment là, s’il ne vient pas des équipes, et d’orienter vers un fonctionnement itératif…

Itération 2
C’est reparti! On note souvent la mise en place d’une méthode de travail – certes plus où moins efficaces – mais les choses s’organisent. Des aspect les plus importants à mettre en avant sont :
  • Orienter sur l’itératif : L’idée est de montrer qu’il est plus simple de fournir des specifications volontairement moins complète, afin de se focaliser sur une forme, plutot que sur un tableau global.
  • Aspect incrémental du travail: valider forme par forme et pas les formes les unes par rapport aux autres. On fait en sorte de ne passer à une forme suivante que lorsque la précédente est parfaitement terminée.
  • Client embarqué : Plutôt que de quitter la salle pour laisser les artistes à leur pauvre sort, les designers sont « encourager » à rester sur place, et meme s’il ne peuvent communiquer que par écrit, il peuvent répondre à des questions importantes pour l’équipes.
A noter : les artistes ne peuvent pas sortir de leur salles! (et oui, on ne s’invite pas chez le client). Ils peuvent donc « ecrire un mail », post-it qui passe par l’organisateur sous la forme d’un papier, mais qui bien souvent n’aboutie pas… ou pas dans les temps.
Les idées les plus originales s’organisent, par exemple, on peut ecrire des informations (plus gros, plus à droite, plus bas) et pointer du doigts pour accelerer la compréhension. On evitera par contre les petits malins qui veulent prendre des photos avec leur téléphone mobile ! Les équipes les plus organisées passent sur un mode 100% itératifs, les designers se relaient, l’un explique aux artistes pendant que l’autre prepare la description de la forme suivante…
La gestion des priorités est egalement mise en avant dans cette exercice, la oomplexité des formes etant très variée, il est important d’attaquer par le bon bout !

Retrospective de l’itération 2
On propose à nouveau 5 minutes chronométrées aux equipes afin d’organiser une retrospective.

Retrospective commune
On met en avant les bonnes pratiques (agiles notées ci-dessus) et alors que l’équipe est prete à tout exploser ! On corse un peu le jeux…
On echange une contrainte (qui s’oriente sur l’interdication de la parole) contre une reproduction plus hardue… Le dessin à reproduire n’est plus constitué de formes géométriques mais devient une veritable photographie, bien complexe! Pour visualiser cette photo, on passe à un seul specifier (pour eviter trop d’intervenants autour de l’ecran) On sera surpris par la qualité des resultats si les equipes suivent leurs procedure etablie dans les itérations precedentes.

C’est partie pour l’itération 3 et finale !
Voilà, en esperant que cela vous donnera envie de jouer. Encore, je me dois de remercier Agilex, et plus directement Alexandre Boutin, pour cette démonstration majistrale du jeux Agile ! Vous pourrez trouver plus de jeux à ces adresses :
]]> http://www.rchauny.fr/jeux-agile-scrum-artists-specifiers/scrum-agile/feed/ 0 I am a Certified Scrum Product Owner (CSPO) http://www.rchauny.fr/certified-scrum-product-owner-cspo/news-perso/ http://www.rchauny.fr/certified-scrum-product-owner-cspo/news-perso/#comments Mon, 13 Sep 2010 10:09:01 +0000 Romain Chauny http://www.rchauny.fr/?p=910

Comme j’ai pu en parler dans ces articles sur la méthodologie AGILE ou encore sur la gestion de projet SCRUM, le monde du projet (informatique entre autres) prend un virage important dans l’optimisation de ses methodes de travail.

J’ai eu la chance de prendre ce virage avec la société Kelkoo / Yahoo et de pouvoir ainsi pratiquer ces methodes de manière poussée, dans un contexte propice au bon exercice ! J’ai ainsi experimenté à différents niveaux (technique, coordination, définition) la gestion Scrum et XP. Après avoir dans ce cadre bénéficié d’une formation de Scrum Master, de plusieurs jours de coaching Agile par la société Agilex, et en tant que Program Manager, animé durant une période de 6 mois les debats sur l’agilité dans la société, j’ai passé recemment 2 etapes marquantes.

La première est la Certification officielle de Product Owner. Suite à une formation de 2 jours j’ai obtenu la certification (Certified Scrum Product Owner Agreement) validée par l’internationale Scrum Alliance. Rien d’exceptionnel ici car comme toujours l’experience prime sur les diplomes, cela dit, cela symbolise pour moi une certaine validation d’acquis.

Le second mon nouveau job de International Development Product Owner. Après une dizaine d’années dans le monde technique, des débuts de webmaster HTML et Flash chez Hewlett Packard, jusqu’à la gestion d’une équipe de developpeur web à Kelkoo, je passe du coté produit en tant que « Product Owner International ». Mon role est donc d’assurer le succès des deploiements du site Kelkoo au sein des nouveaux marchés. Un travail large mais passionnant !

]]> http://www.rchauny.fr/certified-scrum-product-owner-cspo/news-perso/feed/ 1 Méthodologie Scrum : L’équipe http://www.rchauny.fr/methodologie-scrum-lequipe/scrum-agile/ http://www.rchauny.fr/methodologie-scrum-lequipe/scrum-agile/#comments Mon, 15 Feb 2010 06:48:51 +0000 Romain Chauny http://www.rchauny.fr/?p=833

Scrum est une méthodologie AGILE et reprend donc ses principes fondamentaux:
  • Communication accrue
  • Fonctionnalité avant tout
  • Collaboration du client
  • Réactivité au changement
On rentre par contre ici dans le détails du processus avec l’application d’un vocabulaire « scrum » tout à fait propre à cette méthode. Nous allons tout d’abord tenter de cerner l’équipe Scrum. (NB: le scrum ne se pratique pas nécessairement nu).

Le Product Owner (PO)

Le product owner represente à la fois le client du projet et les utilisateurs. C’est donc lui qui définit les attentes et les besoins du projet. Ainsi, son rôle est de définir les taches qui permettront de répondre à ces besoins et mettra en place leur priorisation. Il assume donc la responsabilité d’eventuels changements importants dans le déroulement du projet. Le product owner n’inclut pas un niveau hiérarchique, mais un niveau decisionnel en terme de priorisation. Tout comme le veut l’ensemble de la méthodologie, le product owner doit etre disponible et assurer une communication accrue avec l’equipe en donnant une transparence parfaite sur les objectifs définis.

Le Scrum Master (SM)

Le scrum master est là pour assurer globalement le bon déroulement du programmes et protéger l’équipe de tout problème extérieur. Il garantie qu’aucuns éléments perturbateur ne viennent handicaper l’equipe dans son travail, ou si besoin il est chargé de les resoudre. Si l’équipe et le product owner sont focalisés sur le developpement et la bonne définition des besoin, le Scrum Master gére tout ces éléments extérieurs qui peuvent interagir sur le bon déroulement du projet, et l’expérience prouve qu’ils sont nombreux. C’est lui qui également assure l’organisation des réunions et la bonne application de la méthode AGILE de par ce biais.

L’équipe
La team ne comporte pas d’élément particulier si ce n’est son auto-gestion. La communication et le partage entre les différents developpeur est fréquente (quotidienne) et l’equipe s’adresse directement au product owner pour la comprehension des objectifs. Son auto-gestion doit lui permettre de s’alimenter en tache, résoudre ses défis techniques, prendre des décisions, contrairement aux méthodes classiques qui centralisent ces besoins autour d’un chef de projet.

Voilà pour le moment, la suite à suivre…

]]> http://www.rchauny.fr/methodologie-scrum-lequipe/scrum-agile/feed/ 2 Méthode AGILE http://www.rchauny.fr/methode-agile/scrum-agile/ http://www.rchauny.fr/methode-agile/scrum-agile/#comments Sat, 13 Feb 2010 10:47:23 +0000 Romain Chauny http://www.rchauny.fr/?p=816
Suite à l’application exponentielle de la méthodologie AGILE dans le monde de l’entreprise et plus précisement dans celui du developpement web, je me suis penché sur le sujet cette semaine. « Ce que l’on concoit bien s’énnonce clairement » ! C’est donc pour pousser ma compréhension que je vous propose de partager ma vision simplifiée, destinée aux auditeurs qui comme moi souhaitent se familiariser avec ce concept.

AGILE est une procédure de projet informatique apparue durant les années 1990. Par opposition à la technique classique dites en cascade (ou waterfall), la technique AGILE met l’accent sur la réactivité en repondant de manière pragmatique et le plus directement possible au besoin d’un client qui lui même se doit d’être impliqué dans le suivi du projet. Si AGILE est une technique, il s’y applique des méthodes qui detaillent plus en particulier la procédure d’implementation. Les méthodologies AGILE les plus connues en France sont la méthode Scrum et la méthode XP (pour Extreme programming).


La méthodologie AGILE repose sur 4 piliers: L’équipe, L’application, La collaboration, Le changement. Pour condenser ces valeurs, je dirai que le bon fonctionnement de la méthode repose tout d’abord sur une équipe solide, soudée et communicante. L’objectif est de délivrer une application fonctionnelle, tout le reste est secondaire y compris la documentation qui peut etre sustentée par la communication. Le client doit collaborer tout au long du projet et fournir à l’équipe un feedback continu et une parfaite transparence de ses besoins. A ce titre, l’acceptation du changement est capital afin d’assurer un suivi aux besoins du client.


  • La communication
La communication au sein de l’équipe est une notion clé de la méthodologie AGILE, c’est à dire qu’elle met l’accent sur une communication accrue et fréquente dans l’équipe. Là où d’ancien processus favorisait les qualités individuelles, la technologie AGILE met l’accent sur l’esprit de groupe et la transparence dans le travail de chacun.

  • Accès sur le fonctionnement
La technologie AGILE met l’accent sur l’application. L’objectif est que le developpement fonctionne, tout le reste est secondaire. Biensur la flexibilité de cette méthode demande une documentation complète, cela dit, la priorité reste l’atteinte des objectifs fonctionnels.

  • Un Feedback continue
L’implication du client dans le suivi du projet est capitale. Contrairement au methodes plus ancienne le retour du marchand est continu tout au long du developpement du projet, permettant d’eviter les erreurs d’orientation et rectifier au plus vite si besoin.

  • Réactivité et Changement
Les changements de direction ou de priorité doivent etre gérable. Ils sont le pain quotidien (mais aussi la bete noire) des projets informatiques. La méthodologie AGILE permet de les gérer au mieux avec une re-evaluation continue des priorites.

Les 12 commandements partagés par l’ensemble des méthodes AGILEs

  • « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles »
  • « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ».
  • « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ».
  • « Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet »
  • « Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail ».
  • « La méthode la plus efficace pour transmettre l’information est une conversation en face à face »
  • « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet »
  • « Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment »
  • « Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité »
  • « La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle »
  • « Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent »
  • « À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens »

Et enfin pour finir, des mots clefs en vrac qui pour moi illustrent au mieux ce qu’est AGILE:
Pragmatisme, Implication, Equipe, Communication, Fonctionnel, Changement, Efficace, Direct, Transparence, Collaboration, Flexibilité…

Illustration Photos Li Wei

]]> http://www.rchauny.fr/methode-agile/scrum-agile/feed/ 2