Archives de catégorie : Evenement

Global Day of coderetreat, c’est parti !

C’est également parti pour Lille ! Le Global Day of coderetreat fait un tour dans le nord…

Les musiciens passent la plupart de leur vie à s’entraîner pour améliorer, peaufiner, exceller dans leur technique, pour ne performer que quelques instants sur scène. Qu’en est-il pour nous, développeurs, architectes, qui sommes sur « scène » à longueur de temps ?

Le code retreat a pour vocation de créer cet espace, pour nous permettre de lever la tête de nos projets et découvrir d’autres voies. L’idée est simple : un problème, des portables, des IDE et des binônmes.

Il est à noter que les participants doivent ramener leur portable, sur lequel ils auront installé leur(s) environnement(s) préféré(s). Toute technologie est intéressante, du moment qu’on puisse coder quelques lignes !

La journée s’organisera en sessions de 45 minutes. Chacune sera suivie d’une rétrospective pour échanger les approches, stratégies, trouvailles.

Pour s’inscrire c’est par ici : gdclille14.eventbrite.fr

Product Owner Survival Camp Paris

[Fédérateur d’événements agiles, Nord-Agile communique sur une prochaine session]

Alors comme ça vous êtes Product Owner dans une équipe Agile ? Félicitations !

Vous êtes maintenant en compagnie de milliers d’autres personnes a qui on a confié le rôle le plus difficile de l’Agilité. Vous vous rendez compte que vous ne « possédez » pas le produit, mais plutôt que vous gérez les demandes de quelqu’un d’autre. On vous demande de continuer comme avant, mais seulement avec des « récits utilisateurs ». Vous êtes censé avoir en permanence toutes les informations dont l’équipe de développement à besoin, mais vous êtes plutôt vu comme le goulet d’étranglement. Vous arrivez effectivement à livrer de petites choses, mais perdez de vue la vision à long terme.

L’intérêt des livraisons itératives devient limité, toutes les décisions sont prises avant vous, et vous êtes censé livrer l’ensemble des fonctionnalités malgrè tout…

Si vous vous reconnaissez dans cette description, le Product Owner Survival Camp peut vous aider !

Assistez à ces deux jours d’ateliers avec 4 experts reconnus, et apprenez comment appliquer les bonnes techniques au bon moment pour tirer tous les bénéfices des méthodes de développement Agile. Rejoignez le Product Owner Survival Camp pour apprendre comment :

  • Créer et communiquer une vision à laquelle l’équipe et les donneurs d’ordre vont adhérer,
  • Utiliser des cartes d’impact pour pouvoir challenger les objectifs Métier,
  • Savoir ce qui est vraiment utile d’écrire dans un récit utilisateur,
  • Découper et prioriser votre backlog avec des Story Maps pour livrer plus vite

Plus d’info sur EventBrite

Nord-agile est heureux d’avoir ouvert sa première conférence agile avec Cédric Pourbaix, agiliste à l’origine du Scrumbeer.

Réflexion personnelle sur de la place de l’homme dans les projets puis interactions fortes avec l’audience. Cédric nous a permis de faire un petit parcours dans l’histoire agrémenté de quelques unes de ces expériences. Les quelques mots qui suivent résument sa conférence…

La capacité à faire des projets est l’essence de l’homme, c’est ce qui le différencie par exemple des animaux. Il est difficile d’en retrouver des traces dans l’histoire ancienne, par exemple, nous ne savons encore pas à l’heure actuelle, comment se sont construit les pyramides, comment cela a été organisé…

Pourtant des monuments se sont construits, ils étaient plus issus de la maîtrise des artisans que d’un plan ou un projet préétabli. Le compagnonnage démontre la force de la transmission et la culture de l’excellence. Cette excellence permet aux différents corps de métier, en collaborant, en s’auto-organisant de construire des monuments qui nous dépassent !

« L’excellence technique est le moteur du projet » nous dit Cédric pour nous rappeler l’importance du métier de développeur, bien souvent oubliée !

Le plan apparaît vers 1400, avec Filippo Brunelleschi. Entendons-nous le plan : un dessin sur le sol, pour des monuments qui prendrons plus de 100 ans à voir le jour.

C’est l’émergence de la conception, qui reposait jusque là sur les savoirs faire.

Saut dans le temps à des époques plus actuelles, c’est avec la révolution industrielle et Taylor que le projet prend une dimension verticale, en séparant la conception, la formation, l’exécution.

On décompose le processus en tâche pour établir « The One best way » : le plan qui marche.
On devient capable de donner à l’avance tous les détails. Le challenge est de trouver LE plan… En d’autres termes, on assiste à la naissance du cahier des charges.

Le postulat sous-jacent est le suivant :

  • Le client sait ce qu’il veut
  • L’équipe sait comment faire
  • Rien ne va changer

A-t-on évolué depuis ?

Nous vous laissons trouver la réponse au travers de la vidéo 🙂

 

Jeudi dernier avait lieu une nouvelle édition du ScrumBeer Lille, organisée par Nord Agile et sponsorisée par Axa qui nous a accueilli dans les locaux de son Web Center. L’occasion, une nouvelle fois, de parler agilité, de partager nos expériences sur les projets et d’agrandir la communauté agile du Nord.

Une soirée sous le signe de la bière

De la bière dans les verres et sur les tables ! Après un petit discours introductif, nous voilà partis dans l’explication de l’activité de la soirée : le Beergame. Ce jeu simule la chaîne de production de la bière, depuis l’usine de fabrication jusqu’au détaillant qui livre les caisses de bières aux consommateurs finaux, en passant par le grossiste et le distributeur.

Le but de chaque acteur de cette chaîne est de minimiser ses propres coûts qui proviennent du stock et de l’en-cours (ou backlog) c’est-à-dire de toutes les commandes non honorées. Ainsi, chaque acteur doit s’occuper uniquement de son poste et ne peut pas communiquer avec ses voisins. A chaque tour, chaque acteur doit donc honorer les commandes qui lui sont faites (par les consommateurs finaux ou par un acteur de la chaîne) et essayer de prévoir la demande en faisant des commandes à son voisin.

Ah oui, dernière chose ! Pour ralentir les flux et compliquer un peu la situation, des délais sont introduits entre les entrepôts de chaque acteur et dans la transmission des commandes. Un peu comme dans la vraie vie !

Plateau Beer game

Le bullwhip effect

Si on a un détaillant un peu joueur, on se retrouve vite avec un gros pic de commandes lorsque la demande consommateurs finaux augmente légèrement, après quelques tours. Le temps que cette commande arrive à l’usine de fabrication, les commandes grossissent d’acteur en acteur et on assiste alors au phénomène du bullwhip effect. A cause des délais, les commandes gonflent et s’étalent aussi dans le temps. D’ailleurs, essayez de demander à la fin du jeu, à chaque acteur d’imaginer la demande client. Les résultats seront flagrants !

En effet, quand on est loin de la source, on ne peut pas communiquer et des comportements erratiques apparaissent. Chaque acteur commande beaucoup plus mais le temps que la commande arrive jusqu’au détaillant, des ruptures de stock se produisent, donc les acteurs commandent encore plus ! La situation devient insensée et finalement, tous les acteurs essaient d’agir localement pour résoudre un problème global. Mais au final, la qualité de service baisse grandement (le backlog grossit pour tous les acteurs) et les capacités de la chaîne ne sont plus du tout optimisées avec des coûts élevés.

 Le système induit les comportements

S’il y a une conclusion à retenir de ce jeu c’est que le système lui-même introduit les dysfonctionnements. Et pourtant, tout au long de la partie, on a l’impression que les problèmes viennent de nos voisins et on commence à les traiter de tous les noms, les jugeant incapables de prendre des décisions sensées et de bien faire la tâche qui leur est demandée. Désespoir et frustration sont le lot commun des derniers tours !

En réalité, il n’y a pas de coupable (eh oui, pour une fois le consommateur final est irréprochable et sait ce qu’il veut) mais c’est la structure du système qui est défaillante. Et les plus gros points de défaillance sont les suivants :

  • une communication entre acteurs inexistante
  • une optimisation locale (chacun essaye de minimiser ses propres coûts sans vision globale)
  • une structure qui présente de nombreux délais

En y regardant de plus près, on se rend compte rapidement que c’est à cette inefficience de l’organisation que l’agilité apporte des réponses. En réduisant au maximum les boucles de décisions et de retour, et en mettant l’accent sur la communication directe, les informations sont partagées par toutes les parties prenantes de la chaîne de valeur, les prévisions se construisent et s’affinent par l’échange et l’expérience, et finalement le rythme de tous est commun pour se concentrer sur l’essentiel : délivrer de la valeur au client final.

Encore un grand merci à Emmanuel Sciara (@esciara) et à Thomas De Clercq (@ThomasD59290) pour nous avoir fait découvrir le jeu et pour avoir animé les différents plateaux de jeux. On vous donne rendez-vous le 15 avril prochain à l’ISEN pour un nouvel évènement autour de l’agilité (un post sera bientôt publié pour vous donner l’eau à la bouche).

 

Jean-Baptiste pour Nord-Agile

 

N.B. : si vous voulez devenir des experts du BeerGame et reproduire le jeu dans votre entreprise ou chez vous, vous pouvez jeter un coup d’oeil au portail dédié au jeu et au document synthétique de l’université de Munster (en anglais) qui constitue un bon guide pour animer avec brio ce jeu.

On fait souvent le constat, nos pratiques en entreprise ne sont pas homogènes, nos expertises sont souvent réparties et peu connues, nos expérimentations et expériences ne servent souvent qu’à nous même.

Qu’elle soit technologique ou méthodologique, vient souvent l’idée de créer une communauté. Un regroupement des gens ayant « envie », travaillant dans le même domaine, mais répartis à travers différents projets, différentes équipes. Il « suffit » d’un forum, d’un blog, d’un intranet, de quelques heures par mois pour se rencontrer, partager et capitaliser !

Mais force est de constater que souvent ces communautés échouent, oui mais pourquoi ?

 

Ayant eu récemment avec Ben, l’envie de créer une communauté Agile en interne, j’ai donc  posé la question au ScrumBeer (ça tombait bienJ).

Pour répondre à cette question, par jeu, et de façon à distinguer mon contexte, nous sommes partis de la question inverse. Le côté Obscur permet parfois de mettre en avant la lumière.

La question centrale est donc devenue :              » Comment faire échouer une communauté ?  »

comment échouer

 

Nous avons ensuite par rapport à mon contexte d’entreprise focaliser sur un axe : Manque de vision.

Pour cela nous avons abordé le concept de « Leadership Emergent ».

whywhohowwhat

 

Plutôt que de me focaliser sur les actions que j’attends de la communauté : le What, et essayer de les porter ou pire de forcer les gens à prendre ces actions, je dois me concentrer sur communiquer le « sens » de la communauté. Par exemple « Elever le niveau de maturité des équipes agiles » à détailler ensuite de façon plus mesurable.

En expliquant le sens du « Why » de façon claire et mesurable, on peut provoquer auprès des membres de la communauté « Who » une adhésion et par eux même ils chercheront comment « How » apporter des actions concrètes : « What ».

A l’initiative de cette communauté, je dois donc me concentrer non pas sur les actions concrètes que je souhaite que ces membres mettent en œuvre, mais sur le fait de transmettre le sens de son existence, de la façon la plus mesurable et concrète possible.

 

Merci Thomas