Ca Scrum !

Pour ceux qui ne le savent pas encore, j’ai quitté mon précédent employeur il y a maintenant 3 semaines. Cela faisait presque 10 ans que je travaillais dans ce groupe et c’était ma première experience significative. Ce départ est un départ positif : je pars heureux de ce que j’ai appris, de ce que j’ai pu apporter. J’ai chercher des conseils auprès de Jean-Claude Grosjean pour qu’il m’aide à faciliter ce départ. Après notre discussion, j’ai mieux compris l’importance de la « célébration » du départ. Ce n’est pas « naturel » de célébrer une séparation. Divorces, enterrements, licenciements ne sont pas en général des moments très festifs et joyeux. Et justement, une séparation n’est pas un moment triste. Certes, c’est la fin d’un parcours que l’on a fait ensemble, mais d’un parcours qui nous a emmené à des réussites (humaines avant tout). Alors il est important que ce dernier moment soit à l’image de ce que l’on a construit ensemble… (suite…)

Je ne suis pas facile.

Il faut le reconnaître, humblement, je ne suis pas facile à manager. Il faut dire que je n’aime pas sentir « tiens, là, on est entrain de me manager ». Je ne sais pas si certaines personnes aiment cela, ou si la plupart des gens trouvent ca normal. De mon côté, je fais partie des personnes qui se sentent sur la défensive dans ces moments là. Et comme je ne suis pas facile, je ne me laisse pas faire. Un exemple ? (suite…)

J’ai planté un chêne
Au bout de mon champ
Ce fut ma semaine
Perdrerai-je ma peine
J’ai planté un chêne
Au bout de mon champ
Perdrerai-je ma peine
Perdrerai-je mon temps…

Depuis 3 ans que je vais à Agile Grenoble, et cette année en plus à Agile Innovation, je me demande toujours ce que je vais découvrir … Et si je vais arriver à apprendre de nouvelles choses. Dans tous les cas, je me force chaque année à ne pas prendre de notes, afin de profiter du moment présent. La plupart des « speaker » mettant à disposition leur présentation, tout est mis en oeuvre pour que je puisse rester « connecter » avec l’évènement. (suite…)

Pour compléter l’article précédent, je vous invite à venir découvrir un « nouveau » jeu : La session dont vous êtes le héros.

J’aurai la chance d’animer cette session avec Emmanuel Etasse … Que j’avais rencontré il y a 2 ans lors d’une formation ScrumMaster. Il y a quelques mois, nous nous sommes lancé le défi d’inventer un nouveau jeu. Après 2 premières présentations au CARA ainsi que dans mon entreprise, nous espérons être à la hauteur le  jour J :)

Ce sera un moment important pour moi : ce sera ma première présentation à la communauté agile, la première occasion de « donner » à la communauté après avoir beaucoup appris pendant plusieurs années. Je suis d’autant plus heureux que ce soit sous la forme d’un jeu.

Je ne sais pas pour vous, mais il existe des moments où les galères s’accumulent. Tout avait pourtant bien commencé dans le Sprint précédent. On savait que le contenu du Sprint devrait absolument être mis en prod ce lundi car il contenait 2 fonctionnalités attendues pour l’ouverture de 10 nouvelles agences, dont la fonctionnalité « MAGAM ».

Bon, personne n’est alarmé plus que ca :

• On vient d’installer en prod la version précédente : nous n’avons pas de stock :)
• Le besoin métier est facile : l’équipe évalue les 2 fonctionnalités à 1 point chacun et nous produisons 60 points par itération.

On commence le Sprint par le plus prioritaire et après 4 jours (sur 15) on a une version stable contenant le minimum obligatoire. L’application est alors mise à disposition du P.O qui valide le fonctionnement. On continue alors le reste du Sprint. J-1, tout le contenu du Sprint est prêt. C’est le début des ennuis : (suite…)

Le projet Marguerite, le projet chardon, etc … Tous ces projets composent notre Système d’information. La plus grande contrainte dans le développement d’un S.I tient au fait qu’il n’existe pas de date de fin à la création du S.I. L’agilité nous propose différents outils permettant de revoir régulièrement nos priorités facilement, ce qui a été une révolution ! Il est cependant important pour l’équipe, le P.O mais aussi les stackholders d’avoir régulièrement une « vision » des prochaines étapes : le Release Plan.

Quel outil ? Comment construire / échanger / travailler cette définition du produit sur les mois à venir ?

L’idée toute simple m’a été soufflée par Jean Claude GROSJEAN, dans un article lu il y a quelques mois concerant son backlog D.E.E.P et physique.

(suite…)

The End

Il y a 7 mois, presque jour pour jour, j’ouvrai ce blog en évoquant combien celui de Frédéric Doillon avait été important dans ma découverte du métier de ScrumMaster. Mon objectif était le suivant :

« Mon objectif principal reste de me fournir un outil me permettant de prendre du recul et de garder une trace du fonctionnement de Scrum sur un projet : du début à la fin :) »

Je n’avais pas imaginé ce jour là combien l’écriture de ce blog allait aussi être une expérience humaine : découverte d’autres équipes, d’autres ScrumMaster, d’autres pratiques agiles … Merci à tous (@nmartignole , @CyrilleDeruel , @jcQualitystreet , @claudeaubry , @NAJard , @agilex ) pour vos commentaires, vos encouragements !

Ce jour, nous venons d’installer en production le projet Marguerite sur lequel l’équipe travaillait depuis début Janvier 2011 en 37 secondes.

Hommage à Frédéric Doillon

Nous venons de démarrer ce matin le dernier Sprint de la release 1 du projet Marguerite. Je voulais organiser un jeu/évènement afin que l’équipe reste focalisée sur la qualité du produit et qu’elle réflechisse à la gestion des risques. Ayant découvert récemment le jeu « Remember the Future« , je voulais organiser un jeu placant l’équipe 1 semaine après une mise en production « ratée » de notre produit et que l’on cherche les causes de cet échec.

Je partage cette idée avec notre « Super P.O » qui trouve cette approche « anxiogène » à quelques jours d’un évenement important. Je repars un peu frustré. Quelques jours plus tard, je tombe sur Alex qui se promenait dans notre entreprise et je lui raconte cette histoire.

Moi : « Ben, euh, il parait que c’est anxiogène comme idée, t’en penses quoi »

Alex : « Faut pas faire un Remember the Future, mais un Pré-Mortem ! »

(suite…)

Lors de notre dernière rétrospective, nous avons pas mal discuté de la gestion des « incidents de production ». En effet, en tant que client final, nous développons nos outils mais nous devons aussi en assurer le bon fonctionnement, parfois en temps réel (on ne peut pas attendre le prochain Sprint pour résoudre un problème).

Dans ce genre de cas, toute l’équipe n’est pas forcement mobilisée sur la résolution de l’incident de production !

L’équipe a donc proposé d’investir dans un nouvel outil de visualisation : le gyrophare, et le fonctionnement suivant : lorsqu’un membre de l’équipe est informé d’un incident de production, il allume le gyrophare et TOUTE l’équipe se réunit afin d’identifier et de trouver au plus vite la meilleure solution au problème.

Il ne nous reste plus qu’à trouver une solution pour ne pas perturber les équipes voisines :)

Cela fait maintenant plusieurs mois que je voulais faire cet article sur la rédaction des tests selenium (et en plus, c’était plutôt bien noté dans mon backlog :p). J’espère que les commentaires seront nombreux !

Voici un exemple de scénario que l’on peut facilement générer avec Sélénium et son IDE. C’est déjà chouette ! On a largement de quoi repenser notre manière d’organiser les projets ; comme mettre en place du Développement Piloté par le Comportement (BDD).

Après quelques projets, quelques points négatifs demeurent :

1 – Peut-on dire que la lisibilité est suffisante ? Peut-on échanger avec un P.O ou des fonctionnels sur la pertinence de tel ou tel scénario ?

2 – Lorsque l’application évolue, il faut reprendre beaucoup de tests : il n’y a aucune factorisation du « code » des tests.

Je vous propose donc un exemple d’organisation des tests Selenium. Pour cela, je vous propose de « tester » la vente en ligne du site fnac.com (J’ai choisi ce site pour sa célébrité et sa « complexité » ergonomique) (suite…)

Début de semaine dernière, on discute de l’avancement du projet avec le P.O :

* L’équipe semble s’améliorer dans ses pratiques de développement
* Les tests automatisés (Selenium) sont de mieux en mieux maitrisés par l’équipe et cela renforce la qualité de l’application
* L’application fonctionne !

Bref, on est plutôt content … et l’équipe aussi. On décide de célébrer cela en début de Sprint en s’organisant une p’tite bouffe à la fin du Sprint Planning Meeting, histoire de bien démarrer cette (courte) semaine.

Ce jour, 16h, « Atchoum » et « Timide » pendant qu’ils binomisent devant les tests : (suite…)

Lors du dernier Sprint du projet Marguerite, l’équipe avait l’impression de ne travailler que sur des User-Story peu importantes (d’un point de vue métier), pour ne pas dire cosmétique. Elle avait l’impression d’avoir perdu la « vision » du produit et ne comprenait plus les priorité métier.

En tant que ScrumMaster

Je veux que l’équipe projet ait le sentiment de produire de la valeur métier dans un logiciel utile

Afin que l’équipe reste mobilisée sur le projet !

Je suis donc allé voir le P.O pour parler avec lui du Backlog (et du manque de compréhension qu’en avait l’équipe). (suite…)

Déjà 7 Sprints consacrés au projet « Marguerite ». Nous avons une vélocité de 31 points pour un sprint de 1 semaine. Les tests automatisés sont entrain de rentrer dans les habitudes de développement, même s’il reste encore une marge de progression :)

Avant le démarrage du projet, l’équipe n’était pas « en forme » : le projet « Chardon » était laborieux, plusieurs départs dans les équipes et le projet (ca reste entre nous hein) n’est pas des plus sympa.

J’ai donc mis en place, dès le début du projet « Marguerite » un Niko-Niko : lors de la démo de fin de Sprint, tous les membre du projets (Equipe, PO et ScrumMaster) votent anonymement sur leur humeur de la semaine. (suite…)

Comme on me l’a fait remarqué dans un précédent article, l’entretien d’un jeu de test est une problématique à part entière.

Je n’ai pas la prétention d’avoir trouvé « LA » solution miracle, mais disons que nous avons trouvé une organisation qui nous simplifie grandement l’entretien de nos cas de test : « nous n’en avons pas » ! (suite…)

La mise en place « des tests » au sein de l’équipe est un vrai challenge : nous partons de 0. Les réactions ont rarement été positives : « Ca sert à rien », « De tout façon, je ne fais pas de Bug », « Le projet existe depuis 5 ans sans tests, donc soit on fait tout, soit on fait rien … Et comme on n’a pas le temps de faire des tests sur tout l’existant, ca sert en rien d’en faire » et le dernier « De toute façon, tout ne peut tester : on n’est pas dans la tête des utilisateurs ».

Bon, une fois qu’on a dit ca, qu’est-ce que l’on fait ? Et bien pour ma part, je prend mon bâton de pèlerin et on essaye d’expliquer :

• Il faut être pragmatique dans les tests : Entre rien faire et tout faire, il y a évidemment un compromis à trouver.
• Il y a des tests souvent plus prioritaire que d’autres (En tout cas, avec une valeur métier plus importante que d’autres)
• Il pourrait même être envisageable d’être piloté par les tests ! (Sisi, j’vous assure .. ça existe !).

Bref, on est parti pour faire œuvre de pédagogie avec l’équipe (Est-ce le rôle du ScrumMaster ?). (suite…)

La semaine dernière, je posais sous forme de jeu une question qui semblait très simple, avec seulement 2 réponses, incompatibles entre elles : Soit on implique l’équipe, soit on ne l’implique pas).

Tout d’abord, je suis très content de la « réussite » de ce jeu : le taux de participation a dépassé mon objectif et les résultats montrent qu’il n’y a pas d’évidence dans la réponse, dans l’action à mener !

Évidemment, la réponse doit tenir compte du contexte (Que veux exactement le manager ? Quelle maturité à l’équipe ? Quel relation de confiance existe entre l’équipe et Le ScrumMaster, etc …). Aucune formation Scrum (certifiante ou non) ne donnera la « bonne » réponse ! Scrum est là pour nous faire nous poser des questions ! Scrum nous suggère d’essayer et de mesurer quels seront les effets. Dans mon contexte, j’ai choisi de prendre un risque !

(suite…)

Lorsque l’équipe a exprimé l’envie de faire de « l’intégration continue », je me suis bien demandé de quoi ils pouvaient me parler. Wikipédia étant notre ami, voici ce que nous avons lu :

L’intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l’application en cours de développement. Bien que le concept existait auparavant, l’intégration continue se réfère généralement à la pratique de l’extreme programming.

Et là, l’équipe était bien embêtée : « Ben, euh … On voulait surtout que notre application soit plus facilement packagée et installable. On peut faire quelque chose quand même ? Et puis t’as vu, c’est agile ! « .Touché. (suite…)

Cela fait un peu plus d’un mois que « Ca Scrum ! » est maintenant un blog actif. Ce blog, je l’ai voulu agile dans son contenu, mais aussi dans sa forme : Certaines propositions d’articles sont issues de « demandes utilisateurs », j’essaye autant que possible de privilégier la qualité (hum hum) à la quantité … J’essaye aussi d’obtenir le plus de « feedback » possible : les commentaires sont libres et un ROTI est en place (dont les résultats sont visibles sans voter).

Je vais essayer de conserver l’approche « Agile » de ce blog en faisant ma première p’tite rétrospective et en mesurant les effets.

(suite…)

Lors d’un précédent projet (Le projet Génépi), l’équipe a exprimé, lors de la rétrospective, sa difficulté à s’approprier les Users Story. En effet, nous affichons sur notre « Dashboard » Scrum les Users Story (entre 3 et 8 Users Story par Sprint).

Dans un premier temps, ces Users Story étaient rédigées sur des post-it. Globalement, ca ressemblait à ca :

(suite…)

Le projet marguerite a commencé, mais nous devons toujours faire vivre le projet précédent : le projet Chardon (Oui, Marguerite et Chardon sont dans le même pré d’application :p) Comme son nom le sous-entend, le projet Chardon est un projet critique pour l’entreprise, mais c’est un aussi un projet épineux ;) Avec le P.O, nous nous sommes posés la question suivante : Le projet Marguerite va nous occuper pendant plusieurs mois. Il ne nous parait pas possible de ne rien livrer pendant cette période sur le projet Chardon : son Backlog contient une centaine d’item, certaines importantes d’un point de vue business ! Alors comment s’organiser ? (suite…)

On continue le Sprint 0 ! Notre objectif est toujours d’avoir un Backlog, plus ou moins affiné selon les thèmes, mais valorisé et priorisé.

Nous avions, la semaine dernière, une collection de MindMap où chacun a présenté sa vision, ce qu’il avait retenu de nos visites. Pour arriver au Backlog, la première étape va être de synthétiser la contribution de chacun. Pour cela, l’équipe a proposé que l’on utilise des outils ultra modernes : Brown Paper, Post-it ! (suite…)

Aujourd’hui se termine le Sprint 0. (Durée du Sprint 1 semaine).

Quel était l’engagement de ce Sprint ? Obtenir 7 MindMap décrivant le projet Marguerite.

Quels étaient les critères d’acceptation ? Chaque MindMap devait être numérisé pour être projetable lors de la démo (ce matin) et imprimable afin de le mettre au mur pendant quelques jours encore.

Qu’avons nous livré ? Seulement 5 des 6 MindMap répondaient aux critères d’acceptation (pourtant très très simples :p). (suite…)

Cette semaine, j’ai découvert avec plaisir une nouvelle pratique, que l’on peut considérer comme agile : le FishBowl.

Dans Scrum, il existe 3 réunions : le daily StandUp (mélée quotidienne de l’équipe), le Sprint Planning Meeting (réunion de début de Sprint) et le Sprint Review (Revue de fin de Sprint). Cette semaine, nous avions en plus notre réunion annuelle (comme dans beaucoup d’entreprise) où les équipes se rassemblent, présentent leur travail, … En général, cela se déroule avec 3 heures de Slides projetés.

Cette année, la formule a changé ! (suite…)

Aujourd’hui, nous avons commencé le projet « Marquerite ». Comme je l’ai expliqué, ce projet commence par une phase de rencontre de nos utilisateurs sur leur lieu de travail. Objectif : découvrir leur manière de travailler et leur utilisation de l’outil actuel.

Sur le fond, la journée s’est bien déroulée. La première équipe était dans les Hautes-Alpes et nous dans la Drôme. Pour certains développeurs qui travaillent avec nous depuis plusieurs années, c’était leur première rencontre avec les utilisateurs ! Il était plus que temps !! (suite…)

Pour le nouveau projet (en cours de démarrage), les équipes techniques et les équipes métier vont ensemble se déplacer à la rencontre des utilisateurs pour faire émerger les besoins. Pour synthétiser ce que les équipes auront découvert, nous allons utiliser une MindMap.  L’objectif est d’obtenir rapidement (et visuellement) un retour, un échange construit dans le partage ! Cette démarche est une évidence pour nous car elle reprend quelques éléments de l’agilité :

• Toute l’équipe est acteur à tous les moments du projet. En effet, pourquoi se limiter à seulement 2-3 cerveaux (uniquement l’équipe métier) alors que l’équipe entière en possède 7 !
• MindMap : un outil visuel ! Le management visuel existe dans les pratiques agiles sous différentes formes : DashBoard, Kanban, Burndownchart, post-it, … Le MindMap paraît alors comme une évidence pour présenter et structurer de l’information … Mais surtout la communiquer ! (suite…)

La construction d’une équipe est, pour moi, l’un des moments les plus intéressant mais aussi l’un des plus critiques.  J’ai toujours pensé qu’il y avait plus de chance qu’une équipe arrive à produire du logiciel si l’équipe « fonctionne » bien (même si elle manque de compétence) plutôt qu’une équipe d’expert ou de Geek mais qui sont incapables de travailler ensemble.

Dans notre entreprise, nous avions jusque là 2 équipes : une équipes MOE (une dizaine d’informaticien répartis sur différents projets) et une équipe MOA (5 experts métiers, eux aussi sur différents projet). Comment s’organiser lorsque l’on met Scrum en place ? Comment faciliter la transition ? Parmi les experts métier, un seul Product Owner (Facilement identifié, c’est déjà une très bonne nouvelle !). Mais que deviennent les autres membres de l’équipes ? Pour cela, j’ai proposé que l’on considère les anciens membres de la MOA comme des membre de la Team ! Certes, ils sont un peu spécialisés (ce qui est une entorse à Scrum, ce sera la seule). (suite…)