Retour sur Scrumday Paris 2015

J’ai eu le plaisir de participer au Scrumday de cette année (2015) qui s’est déroulé le 2 et 3 avril passé à l’hôtel new york à disneyland paris 🙂

IMG_2246         IMG_2237

Oui je sais, cela fait plus d’un mois………. mieux vaut tard que jamais non? 🙂

La thématique de cette année était « ScrumCorp : au-delà des équipes« , en gros, c’est Scrum à l’échelle et surtout au niveau entreprise et pas seulement au niveau des équipes de développement.

Ce que j’ai aimé

IMG_2227

selfi avec MR Xavier Warzee – President of the French Scrum User Group

hormis la super ambiance bon enfant et le fait que cela se soit déroulé à Disneyland, j’ai aimé:

  • La Super organisation :Les sessions démarraient à l’heure, on savait quoi faire, le programme était clair… Bref, moi qui suis assez critique quand il s’agit d’événement de ce type-là, bah, j’étais content
  • La Qualité et le niveau des discussionsQue ce soit avec les participants, les organisateurs, les speakers… y avait toujours quelque chose à apprendre au cours d’une discussion.
  • l’Accessibilité des gens et esprit de partageLes personnes présentent (participant, speaker,..) étaient très accessibles. J’ai eu l’occasion de discuter avec pas mal de personnes, et franchement, à chaque fois c’était agréable de partager des expériences.
  • Coach clinicJ’ai eu l’occasion de discuter un coach Agile -très sympathique d’ailleurs- (Gwenael Bonhommeau … j’espère qu’il ne m’en voudra pas de le citer) avec lequel j’ai partagé les problèmes auxquelles mon équipe et moi faisons face, ce qui m’a permis d’avoir un regard critique sur certaines choses….. Bon, on a pas tout réglé en 20 minutes, Mais ça m’a quand même donné des pistes
  • Discuter avec Mr Alexandre boutin Un retour d’expérience super intéressant, … on sent l’expérience qui parle, je vous recommande le suivre sur twitter.
  • Les sessions d’ateliers ouverts:Le 2eme jour, il y a eu 2 ou 3 heures ouverte durant lesquelles les participants pouvaient inscrire sur un tableau un thème de leur choix qu’ils voulaient aborder. J’ai tout de suite inscrit le thème « Etimate VS no Estimates ». Le débat était super intéressant, je me suis rendu compte que personnes ne faisait du No estimate (je reviendrais sur ce sujet plus tard dans un autre post) et que faire un focus sur les deadlines et les estimations étaient simplement pas très pertinent et anti-agile
  • La présentation de Mary Poppendieck,Qui a un peu taquiner Scrum en disant que Scrum était plus un « IT mindset » plutôt que « product mindset » (et qu’en 2015, c’est le product mindset qui gagne), Mais j’ai appris beaucoup de choses concernant l’esprit de l’agilité et la finalité des choses… on développe des produits pour que les gens les utilisent et non pas juste pour les livrer à temps.
  • Le super concept du charging place , une espèce de borne qui permet de charger son téléphone. 

Ce que j’ai moins aimé

  • Le nombre de sessions parallèlesFranchement, je voulais assister à toutes les sessions, et il y avait 6 ou 7 sessions en parallèle, j’ai dû y aller avec Excel pour faire mes pros and cons, afin de choisir le bon programme! Si le programme était étalé sur 2 jours, ça nous auraient permis d’assister à plus de sessions…. après je peux comprendre que 2 jours de boulot de perdu, c’est trop pour certains!
  • L’accent british de Mr Dave Snowden Attendez, j’ai rien contre les Anglais -j’ai même de la famille la bas- c’est juste que je n’ai pas pigé grand-chose! Il y avait même des gens qui rigolaient aux blagues… moi j’ai eu du mal. Le lendemain, avec l’accent américain de poppendick, j’étais content 🙂
  • L’arrêt du RER A, au retour vers paris suite à des problèmes survenu sur le traffic…. bref, on sait pas quoi.

Les phrases et les moments qui m’ont marqué

  • le moment ou les speakers d’IBM ont dit qu’ils ont fait des erreurs en adoptant l’Agilité et qu’ils étaient en train d’apprendre!!! j’en parle plus bas
  • Le moment où j’ai demandé à l’équipe SNCF « Attendez, Mais c’est qui qui valide les specs? » et qu’ils m’ont rétorqué  « Ah non, Ya pas de validation! On est drivé par les feedbacks, et on est sur des cycles de développement courts, du coup, si ce n’est pas bon, on réitère »

et les phrases que j’ai apprécié:

« Les développeurs devraient passer plus de temps à discuter qu’a coder » -Alexendre boutin-

« TOUT le temps que tu passe à estimer en détail, c’est du temps perdu » – Alexendre boutin

« Les enquêtes marketing, ça ne marche pas » ( équipe SNCF)

Mes amis marketeur, ne vous énervez pas, j’explique ce que ça veut dire réellement plus bas.

« Cela ne sert à rien de respecter la deadline si ce que vous faites n’est même pas utilisé »

C’était lors de la session improvisé estimates VS no Estimates et je crois que c’était David Koss – Consultant Agile- qui l’a dit, j’ai adoré 🙂

« Vous mesurez la réussite par le respect de la deadline, et la value propositions vous en faites quoi?  » – une coach agile- Amadeus

C’était lors de l’atelier improvisé suite à une question de ma part, qui concernant, l’évaluation de l’atteinte des objectif de l’équipe de développement, et qui sont très souvent axé sur le respect des deadline. Je n’ai pas retenu le nom de la dame, Mais son intervention était très pertinente.

« Avec le marketing, ça marche à la confiance, on leur fait confiance pour définir ce qui a de la valeur, il nous font confiance pour faire de notre mieux pour les réaliser » – une coach agile- Amadeus

La même dame, qui parle de la relation entre la team développement et la team marketing.

Ce que j’ai retenu

Cette participation était l’occasion pour moi de prendre du recul et remettre en cause notre façon de faire. C’est surtout dans l’esprit (plus que dans les process et outils) que j’ai noté les idées sur lesquelles on devrait revenir.

  • Peur de l’echec

Si je devais citer UN TRUC que j’ai vraiment senti c’est cette culture de l’échec sans complexe. Je ne sais pas si c’est culturel, Mais, chez nous l’échec est généralement très mal vécu.

Quand j’ai Vu lors de la présentation d’IBM, que les speakers n’avaient aucun complexe à dire, « nous avons essayé ça, ça a marché, ça par contre, on n’a pas réussi à le faire correctement, …. Nous apprenons encore nous essayons » (oui oui, je parle d’IBM), bah j’ai senti cela comme une très très grosse claque… elle m’a fait mal d’ailleurs 🙂

Seul conditions pour l’échec:

  1. échouer rapidement
  2. apprendre de ses erreurs et se corriger
  • Tout le monde est responsable de délivrer de la valeur

On tombe très souvent dans le cas classique ou les équipes marketing ou costumer service demande à une équipe de développement de réaliser telle ou telle fonctionnalité, ou modifier et supprimer telle ou telle fonctionnalité.

Sur le long terme, les équipes de développement, deviennent ce que marry popendick appel des « Order taken developpement Team »? Et ils deviennent incapables de solutionner les problèmes des utilisateurs, car ils ne sont pas dans une logique de value proposition, Mais plutôt une logique « d’implémentation technique des solutions ». Paradoxalement, ce sont spécialement les équipes de développement qui connaissent mieux le système qu’ils développent.

L’idéal est que chacun pense avant tout à la valeur et aux POURQUOI, et ne pas se contenter de répondre au comment.

  • Penser produit et non pas projet

Le mindset projet est axé sur les coûts et les deadline, alors qu’il faudrait penser à la valeur ajouté qu’offre le produit et ce que cela peut générer comme profit.

  • Celui qui a raison c’est l’utilisateur final

Qui n’a pas assisté à des réunions à ne pas en finir, ou chacun affirmait que sa proposition était celle qui devait être faite, car « il est sûr », que c’est ce que veulent les utilisateurs, ou pire encore, forcement c’est plus simple pour les utilisateurs de le faire d’une certaine façon.

ce n’est qu’en mettant de vraies utilisateurs devant ton système , que tu sauras si ce que tu pensais était vraie… et ce qu’importe le degrés de connaissance que tu estimes avoir de tes utilisateurs.

Cela implique de faire, des prototypes, des usability testing, …. Mais surtout de faire des hypothèses et de mesurer avec des metrics objectifs l’impact des idées réalisé.

  • La technicité est intrinsèque à l’agilité

Les gens parlent de TDD, de continious develivery, de tests automatisés, de REfactoring, de microservices, d’architecture stable…. BREF, si tu veux que l’Agilité fonctionne bien, il faut que la technicité suive.

Sur un projet technique, on peut faire de l’agile avec les moyens du bord, Mais ça ne sera pas aussi efficace que d’avoir les outils, les process et une véritable culture d’engineering au sein de l’équipe.


il y avait d’autres points que j’aurais aimé abordé, Mais l’article devient déjà trop long 🙂

Conclusion

Grossomodo, c’était super, j’ai appris beaucoup de choses et je compte essayer plein de nouvelles choses. je vous recommande vivement d’y aller l’année prochaine.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s