MixIT 16

Leave a comment

MixIT arrive, l’équipe infernale qui avait sévit à Grenoble, se relance dans l’aventure de la journée Agile en Live.

Venez participer a une journée intense d’agilité, venez (re)découvrir les pièges classique d’un projet: techno push, story mal spécifiée, …. et venez parler avec des devs, POs et SM avec plus de 10ans d’agilité derrière eux….

Des erreurs on en a fait pleins, venez profiter de notre expérience.

 

Petit souvenir

MerciCloud

Agile Grenoble 2015 : un projet Live

2 Comments

L’idée

Un jour, une idée un peu folle m’est venue. Plutôt que de parler d’agilité, montrons la en pratique et invitons les gens à venir la goûter.

Du coup, j’ai lancé un petit appel à contribution pour être une petite tribu de fou.

Capture_d_e_cran_2015_11_22_a_16.28.50

Xavier a été le premier à répondre, suivit de prés par Matthieu, Jean-Charles, Stéphane, Franck, ….

Quelques tweets alléchants et un coup de téléphone on suffit pour lancer le projet : le rendez-vous est pris, le jour J sera Agile Grenoble 2015. Les orgas (vivent les hommes en rouge) qui nous suivent, encore une fois merci! , et nous voila lancé.

Nous avons avec Xavier et Franck vu dans d’autre conférences des tentatives pour faire un tel projet. Les organisateurs se sont souvent confrontés à la difficulté d’inclure dans le projet des personnes de passages (personnes qui n’ont pas l’habitude de travailler avec 500 personnes dans le dos, de travailler en pair, sur un projet inconnu ….).

Pour remédier à cela, notre idée, a été de combiner à la fois une équipe technique (2 à 3 personnes) à 1 product owner et 1 scrum Master.

L’équipe technique

L’équipe technique a été présente tout le temps, pour assurer le passage de relai, la connaissance technique, et le déploiement de l’application.  Ce groupe à ainsi pu accueillir entre 3 et 6 personnes chaque itération (une itération durée environs une heure). Chaque itération a permis de discuter du fonctionnement de l’équipe, du rôle du développeur (conseils/échange avec le PO, excellence technique bien dosée, …).

Le(s) Product Owner(s) (POs)

Le PO avait un rôle de gestion du produit, il devait tenir compte des participants pour adapter le produit. Le PO avait aussi un rôle de gestion des questions, étant “en théorie” plus disponible que les développeurs.
Lors des 2 premières itérations beaucoup de personnes (débutantes et expertes) sont venues jouer aux POs en définissant des user stories et en gérant les priorités.

Nous avons ainsi, changé notre idée initiale de produit dès la fin de la première itération, ou notre vingtaine de POs a eu de très bonnes idées suite à notre première Démo.

Le Scrum Master

Le Scrum master, avait un rôle de gestion des impédiments (protection de l’équipe de dev:)) , inclusion des nouveaux en leur présentant le projet, animation des points de synchronisations.

Le rôle de SM est avec le rôle de PO, je pense un des points clés du succès de la journée, ils ont permis de faire l’explication en temps réels de ce qui se passe, tout en donnant à l’équipe de dev les orientations attendus par le public.

Le détail de la journée a été parfaitement raconté par Xavier, ici. Je vais donc jouer au fainéant et me concentrer sur un ou deux points techniques que je voulais partager.

Un peu de technique

Le repo GIT est disponible ici sur github.

Les technos utilisées sont, pour le Front end :

  • un peu de Php/Css pour la version 1 ultra simple
  • une lib javascript pour les V2 et V3 de l’affichage.

Un exemple de résultat ici (les tweets de la dernière heure à Agile Grenoble):

AgileGrenoble2015-tagDerniereHeure.png

Pour le backend :  Flink en Java/Scala .

Flink est un framework de processing Big Data, certains me diront n’est ce pas un peu beaucoup pour 75 tweets par heure ? Peut-être, mais un de mes buts était de me faire plaisir avec un framework que j’adore, de le faire découvrir ainsi que de permettre facilement de manipuler des flux de tweets.

Ci dessous, tout notre code produit (après quelques refactoring).

TwitterFilterSource twitterSource = new TwitterFilterSource();
twitterSource.trackTerm(#AG15);
DataStream<String> dynamicjson = env.addSource(twitterSource);

DataStream streamTwits = streamSource
.map(…)
.flatMap(new TokenizeFlatMap())
.filter(new RemoveLink())
.filter(new RemoveStopWord())
.keyBy(0).sum(1)
.map(… });

De ce point de vu, succès.

J’inclus ici, un des documents initiaux qui ont permis d’avoir une idée du logiciel que nous aimerions faire durant cette journée :

FlinkTwitter.png

La géolocalisation des tweets a disparu, en fait, très peu de tweet sont géolocalisés (~2% pour agile Grenoble).  Nos PO ont voulu un affichage qui alternait entre nuage de tweets et nuage de twittos (pour stimuler leurs activités), et un compteur de tweet est apparu.

 

Conclusion

En conclusion, que retenir d’une journée si riche ?

Un peu de frustration de ne pas avoir été un PO et un SM sur le projet.

Plein d’échanges, et du partage. Des idées d’amélioration. Une envie de recommencer vite.

Un grand merci à tous les participants et surtout à Xavier.

 

 

De quoi parle t’on sur Twitter lors des conférences Agile

Leave a comment

Lors d’Agile Grenoble 2015, nous avons fait une petite application qui permet de suivre les tendances (fréquence d’apparition de mots) sur Twitter, lors de la conférence. Du coup, il était tentant de lancer cette application sur les autre conférences agiles du moment.

Cette application (relativement simpliste, et développée en live sur une journée lors de la conférence), permet d’afficher un nuage de tag avec les mots utilisés sur Twitter. La taille des mots est proportionnelle à leur fréquence.

A Grenoble

Sur la journée de la conférence (image de gauche), on peut voir que les Post-its vivants , (Keynote faite par la ligue d’1pro38) ont eu leur petits effets, et que les agilistes participants sont repartis heureux et remplis de bonheur.

Dans une fenêtre glissante d’une heure (calée sur les sessions, cf image de droite) , nous voyons ressortir les sessions en court, et des thématiques plus précises.

A Toulouse

Toulouse

Malgré les bouchons matinaux, le bonheur (un des grands thèmes de la journée) est au rendez-vous. On note aussi qu’un fabricant d’avion joue un rôle important dans l’agilité locale.

A Nantes

Nantes

Visiblement du changement, dans une belle ambiance agile.

A Paris

Paris

Des leaders, des clients et du business, un petit effet lié à la capitale ?

Au total, que ressort il ?

 

All

Du bonheur, du changement, de la communication, de l’accompagnement, de l’action. Que de belles valeurs partagées par toutes les personnes présentes. Je sens une belle vague d’énergie renouvelée.

Merci à tous !

Le PO et la gestion du projet au quotidien: 6 qualités/facteurs de plus

Leave a comment

Nous avons vu dans le post précédent qu’avoir un backlog utile et à jour n’était pas si évident. Malheureusement, un bon backlog, ne suffit pas pour avoir un projet qui se déroule bien.  Dans Scrum, le Scrum Master est le garant du processus et il doit donc s’assurer que le processus ce déroule bien. Le PO (ou les artefacts dont il a la responsabilité : backlog, story) à/ont un rôle clé dans beaucoup des cérémonies : sprint planning, demo, ….

Le PO a donc un rôle clé, et je vais essayer de lister les points de vigilance qu’il doit avoir au quotidien sur ses projets.

  1. From the book : j’ai vu beaucoup d’implémentation de l’agilité, ou dès les premières itérations les équipes ont commencés à customiser scrum pour de “bonnes” raisons, en oubliant souvent l’esprit de scrum ou de l’agilité.  Quand on regarde les cérémonies scrum avec l’œil d’un PO, on pense immédiatement aux Démos et au sprint planning.  Un petit rappel de quelques bases pour nos PO :
    • Au début du projet on définit le DONE avec l’équipe, et on le raffine régulièrement si nécessaire
    • On ne démontre que les stories finies, sans défauts et avec tous les tests qui réussissent.
    • Si possible, l’équipe ne découvre pas la story au sprint planning, on a le droit d’en discuter avant, notamment pour clarifier les critères d’acceptances.
  2. Les rétros : souvent utilisées pour régler des problèmes, elles peuvent aussi servir à l’amélioration de l’équipe.  Voici quelques bonnes pratiques liés aux rétro :
    • L’équipe doit faire régulièrement des rétrospectives
    • L’équipe, lors de ces rétros définit des actions à réaliser, et les réalise.
    • En tant que PO, je peux proposer des sujets de retros.
    • Je collecte les retours des équipiers et j’en tiens compte.

    Les rétros peuvent être un lieu ou de temps en temps le PO peut par exemple faire réfléchir l’équipe sur comment améliorer la qualité du produit.

  3. Les métriques : Dans le quotidien de la gestion de projet, il est important de savoir où on en est. Les métriques classiques, telles que le value burn-up (la valeur que nous avons produite) ou l’effort Burn-down (ce qu’il reste à faire) permettent d’avoir une vision de l’avancement du projet. Par contre, elles ne sont pas forcement suffisantes.  Sans non plus rentrer dans le piège d’avoir 300.000 métriques, il est important d’identifier quels sont les indicateurs qui font du sens, et ne pas hésiter à les remettre en cause, voir les changer régulièrement.
    Il est donc important pour le PO de :

    • Définir au début du projet les métriques qu’il va suivre
    • Revoir régulièrement (release, sprint, …) les métriques utilisées, et de les adapter aux nouvelles contraintes du projet
    • S’assurer que l’équipe ne fait pas une course à la métrique, rendant contre productif toutes les métriques mise en places.

    Parmi les métriques que j’aime bien, il y a par exemple, la dispersion du temps de réalisation  des stories, qui permet d’identifier si régulièrement on a des stories à problèmes, mais aussi de voir si le découpage des stories permet une implémentation dans un temps raisonnable. On peut aussi regarder la répartition entre les différents type de stories, celles ayant de la valeur cliente, les stories soit disant “techniques” et le nombre de bugs corrigés.

  4. Les livraisons : tous le projets ne faisant pas encore du déploiement continu, il existe encore souvent une phase de livraison explicite, avec une phase de qualification du produit. Parmi les anti-pattern que nous pouvons identifier il y a :
    • la phase de validation avant la release est longue (au moins l’équivalent d’un sprint)
    • L’équipe fait un sprint de finalisation.
    • Je fais des démos avec des stories qui ne sont pas complétement finies (cf. DONE)
    • L’équipe n’est pas responsable de la livraison (et peut être du packaging).

    Si on veut avoir un rythme de production soutenable et prédictible, il vaut mieux éviter les points précédant.

  5. Le Rythme : si l’équipe veut être capable de garder un rythme régulier et prédictible au cours des sprints, il est important de :
    • définir des sprint cours (2 ou 3 semaines par exemple)
    • d’avoir des estimations fiables, sans pour autant passer de longues heures à détailler et raffiner les estimations. Il est important de ce poser des questions lorsqu’une story estimée à X journées, prend au moins 25% de  plus. Le graphique sur la dispersion des temps de réalisation peut aider a identifier de telles stories. Parmi les pratiques intéressantes,  j’ai vu des équipes qui en plus des estimations sur une story, évaluaient 2 facteurs de risques : techniques et métier.
    • Les échanges entre le PO et les développeurs sont fréquents. Ces derniers ne découvrent pas les stories le jour du sprint planning, et le PO ne découvre pas l’implémentation de la story le jour de la démo …..
  6. L’amélioration continue personnelle et de l’équipe:  parmi les facteurs de succès  la volonté de s’améliorer est un des piliers clefs. Parmi les indicateurs qui montre que l’équipe est sur la bonne voie:
    • L’équipe a des réunions productives
    • L’équipe a des réunions efficaces
    • L’équipe écrit des documents utiles
    • L’équipe suit les actions définies (par exemple lors des retros)
    • l’équipe s’améliore

 

En rajoutant ces derniers items, je trouve que le terme ‘qualités’ est de plus en plus mal choisi, peut être devrais utiliser plus facteurs, ou …. il va falloir que je me creuse un peu les méninges …. affaire à suivre ..

 

 

La journée du PO : Le Backlog et sa gestion

Leave a comment

Et zoup, un nouveau petit post sur les activités de notre cher PO :  la gestion du backlog et découvrons 6 des qualités du PO.

Pour illustrer les difficultés d’un PO à construite un backlog, Henrik Kniberg à réaliser une illustration parfaite, à méditer:

SplitStory

 

Une des premières étapes pour le PO dans un nouveau projet, est, dans mon idée, d’avoir une ébauche de son backlog et un plan de release.  En général, cette ébauche de backlog est réalisée par le PO avec les décideurs du projet, en amont du démarrage de l’implémentation.

La création du backlog se passe en plusieurs étapes. Au début, on peut utiliser des techniques comme l’impact mapping (présentée par Gojko Adzic), qui permettent entre autre d’obtenir une liste des épics avec la valeur attendue pour chacune d’elles (en définissant les hypothèses sur lesquelles les valeurs attendues sont calculées). Les informations sur les hypothèses et la valeur des épics servira plus tard pour la priorisation du backlog et la création du plan de releases.

Slide1

Dans une deuxième étape, les techniques de story mapping (ex : scrum alliance)  permettront d’aller plus loin dans le découpage des épics en stories et d’obtenir un plan de release.

Slide2

Dans une troisième phase, le travail du PO va consister à transformer le plan de release en liste de stories à implémenter par l’équipe  dans chacune des itérations.

Slide3

Notre PO, à donc maintenant un backlog,  mais attention, dans ce backlog toutes les epics ne sont pas détaillées. En effet, quel peut être l’intérêt de détailler des épics pour la release 2, sachant que nous remettrons peut être en cause le contenu fonctionnel de cette release. Pour la même raison, toutes les stories de la release 1 ne sont pas détaillées. En effet, certaines devront être découpées (suite aux estimations de l’équipe, …), ou évolueront au cours du temps.  Le PO doit faire à mon avis, le travail minimal qui lui permettra de travailler avec l’équipe, tout en ayant les informations nécessaire pour réaliser son plan de release (estimation, risques, …). Parmi les outils qui pourront aider notre PO dans l’écriture de son backlog, on peut noter la définition des personna (la vidéo de Jeff Patton illustre bien cette technique).

Une fois ce backlog en poche, notre PO peut commencer son travail quotidien et être confronté à de nombreux challenges:

  • Avoir un backlog à jour : cela semble le B-A,BA  mais est-ce que tous les PO maitrisent leur liste de livrables, questionne leur plan de release (validation des hypothèses sorties de l’impact mapping, …).
    Il doit préparer avec l’équipe les stories pour l’itération n+1 et n+2. Par préparer j’entends vérifier la compréhension de la story, définir les critères d’acceptations et peut être même l’écriture des scénarios de tests.
    Le PO doit aussi découper logiquement les stories trop grosses après l’estimation de l’équipe (Rappel : une story doit être indépendante des autres, négociable, avoir de la valeur, être estimable, réalisable en un sprint et testable). Parmi les ressources que j’aime bien pour aider a splitter les stories :
    * http://www.agileforall.com/2012/01/new-story-splitting-resource/
    * http://www.agileforall.com/2009/10/patterns-for-splitting-user-stories/
    * http://www.infoq.com/news/2011/04/how-to-split-user-stories
  • Comprendre et incorporer le fonctionnel caché : parmi les aspects que l’on oublie souvent dans le Done, ou dans un backlog nous pouvons citer la performance du logiciel, la sécurité, la traduction, la compatibilités dans les différents environnements ou l’application sera déployée ….
  • Adapter son backlog de manière continue : le travail de jardinage de son backlog est une activité quasi-quotidienne, ou le PO doit tenir compte des remarques de l’équipe, des métriques du projet, des remarques collectées lors des démos, de l’évolution de l’environnement, des retours des clients/utilisateurs, …
  • Gérer les défauts :  2 des objectifs des pratiques agile sont de rendre visible le travail réalisé, et de ne pas montrer de choses non finies (contenant un bug).  Cela implique que le PO doit rendre visible le travail réalisé sur les bugs (en donnant des métriques lors des démos par exemple),  minimiser la durée de vie d’un bug (pour rappel, un bug vue rapidement et corrigé directement par le développeur ne coute rien, proportionnellement à son occurrence en production). Il y a souvent un travail pour faire prendre conscience aux équipes de dev de l’importance ou des impacts de la non-qualité. Cela peut aussi aider l’équipe à prendre conscience de sa zone de responsabilité.
  • Tenir compte des taches techniques : qui n’a pas déjà entendu “sans le framework 2.0 on ne peut rien faire”, “on a du légacy”, mais aussi “cela est de la technique, ce n’est pas mon problème, c’est le vôtre”. Alors je sors le bouclier, et je dis non. Autant j’estime que le rôle d’un équipier est de fournir au PO les informations pertinentes (coûts, bénéfices, alternatives possibles, …), autant j’estime que le PO doit jouer son rôle d’arbitrage entre les solutions possible, et surtout dans la planification de ces évolutions dans le plan de release.
  • Gérer les releases : livrer fréquemment est possible, par contre, livrer incrémentalement de la valeur aux clients est beaucoup plus difficile et demande une discipline au PO pour ordonner les stories, valider et remettre en cause les hypothèses, supprimer régulièrement du logiciel les fonctionnalités sans ou peu de valeurs.

 

How to start a new Scrum project

1 Comment

Yesterday, with the Cara, we did a little Game on how to start a new Scrum project. I’ll try to summarize the key points, and encourage the personn who’d like to have more info to read proper books 🙂

  1. All the team (product + developers) : The Product present his vision quickly (5′) and the key objective
    ex : We want to create a new website for an hospital to better handle the relationship among the patient and the hospital. This tool should first help the hospital to make some economy, allowing patient to go home earlier, and the second objective is to make patient to be more confident at home.
  2. The product and the team discuss on the stories .  Story : what + acceptance criteria + benefits for the end use
    ex : As a patient, I’d like to contact a doctor to have information on my disease
    AC (acceptance criteria) : During the demo, i want to select a doctor to contact, ask him a question.  On a second screen, as a doctor, i want to see the question only when i decide, and answers it.
    B(benefit) :  For the patient the ability to ask any question to a doctor, for the doctor the possibility to answers all questions in a row, without being disturb all the time.
  3. The product can do a A4 page with : The key idea of the project, the key benefit … and may be the key story of the current sprint and it’s key benefit …
  4. Group the stories by themas … In order to have a kind of groups of functionalities.
  5. Prioritize the groups … only the first one and the second one … don’t need to do more … (don’t forget work only on what you can do soon …). Of course, if you need a full vision, or a more precise road map to share, do it, but it’s can be done after the real start. You don’t need it to start.
  6. Estimate your features : poker planing is a solution. Doing poker planing at the beginning may be difficult (new techno, new tools, …). In order to avoid the complex and useless task of precise estimation, you can do relative estimation. Relative to the smallest task you have (the smalest is 1), others are 2,3,5,8 …. You can also choose the average task (8), and others are relative to this average (1,3,5,13,20,40,…)
  7. Once you have estimate your first potatoes (or features group). You can start to plan your first release with the MMF (minimal marketable feature).  You may have to split some of your potatoes in order to match your sprint. The first release can occur after 2 or 3 sprint (of two weeks). To achieve this, you may have to define your velocity. The experience of the team may help you… don’t worry, if you over/under estimate that will be a good exercise for future sprint.
  8. Define your meeting schedule, …
  9. Start it !

Agile Development (Theory in practice) : James Shore and Shane Warden

Leave a comment

During a trip, I’ve read this book.  I think it’s a very good book to start with when you plan to implement agility in your team. Both as a developer or a Product.

Was chatting with a friend of mine some days ago, on the ‘where to start’. Indeed it’s difficult. You may be frighten to introduced agility as a whole, but it’s the best solution. Remove all your usages, challenge your team.  But this required both a highly motivated team, and a good Agile/Scrum practitioner to ask for help on a regular basis.

So, I’ll try why I love the book :

  • Reminder of the agile manifesto … most of the team who plan to move to agile, have read it one day … but it’s a good reminder 🙂
  • The book addressed different aspect of agility : developers, scrum master (scrum method), product, client ….  I’ve seen several team forgetting to quickly that one of the objectives of Agility is to make product and end-user happy. It’s not only about making developers happy.

Among the key tips & trap I’ve  read  in the book :

  • Stories : Ensure the team share the product vision, challenge your stories by asking : what’s the value for the customer … I especially love the challenge card game. One card, one idea challenge the feature….  Product should define MMF (minimal marketable feature). During TShirt sizing, product and developers should challenge each other, if product requires a feature complex to implement, sometime he will be happy with an ersatz of the feature, but easy to do. The product should also define, how to test the feature.
  • Sprint planning :  the team (or a team member) should have prepare the sprint planning, he should have understand what the product want, and anticipate most of the technical issues. Define the success criteria of your sprint.
  • Estimate : time give you idea on how you did mistake on estimation … a team will all the time estimate the same way… (same X% error)
  • Sprint :  remove task as soon as possible (if you have some delay), it will help team working on the most priority one, and will involve product on definition of the new priorities.
  • Demo : don’t lie … if your demo don’t work, be honest .. don’t hide something … elsewhere next sprint, or the “Go live” will be a disaster …

Release process:

  • Each release made by a different person, should be part of the sprint, as at the end of the sprint you should be able to go live …

Older Entries