Agile Game France 2016 à Nailloux

La semaine dernière nous avons eu le plaisir de descendre à Nailloux (compter 30 minutes depuis Toulouse) pour participer à Agile Game France. Récit du voyage :

Pour nous, le voyage a commencé dès jeudi pour assister à la rencontre de la fédération agile. Levé à 4H30, arrivé à 6H00 à Orly, petit coup de stress pour attendre Yannick qui embarque juste avant la fermeture des portes et nous voilà parti pour trois belles journées sous le soleil du Lauragais :

Il est 9h et la fédé semble se languir de notre arrivée 😉 

Nous voici donc finalement réunis pour une super journée d’échange en compagnie de Claude, Alexandre, Romain et Johan. La fédération agile est un regroupement d’experts de l’agilité et l’objectif de cette journée est de passer un moment convivial pour échanger aussi bien sur les activités de chacun que sur des sujets pointus. J’ai eu la chance de me faire coopter par Yannick et Johan et de découvrir leur réunion, chouette !

Nous finissons tranquillement la journée vers 17H, il est temps d’accueillir les premiers arrivés et d’accompagner Claude et Ellène pour une balade autour du lac.

cdxkfcqwoaaaedu

Un bon repas, des premières rencontres passionnantes (merci Stefan pour ce chouette échange) puis au lit pour garder des forces pour la journée du lendemain.

Jeudi démarrage en fanfare

… par un IceBreaker survolté, animé par Aurélie et Axel. On y découvre 6 personnes en train de faire la patrouille de France, une équipe mimer le cycle en V en faisant l’aviron, d’autres faire du basket, du curling, …

Lire la suite

Nos interactions communautaires

Voici un retour sur notre point de gouvernance de ce jour, ou nous avons abordé le sujet des interactions avec les communautés. AgileTribu a pour valeur de rendre service aux agilistes et de promouvoir l’apprentissage et l’éducation.

Après plusieurs mois d’existence, nous avons constaté que le design suivant commençait à émerger :

  • en premier lieu nous découvrons une communauté
  • puis nous y participons
  • ensuite nous aimons et nous soutenons
  • éventuellement nous aidons à développer la communauté si elle en a besoin

Voici l’état des lieux au 9 février 2016 :

Nous découvrons :
Les Scrum Master Dojo

Nous participons à :
Lego Serious Play
l’association Agile France
L’association fédération agile
Facilit on
Nous aimons, nous soutenons : en communicant, en hébergeant
Les duchesses
Nous aidons à développer :
L’Aikido verbal (site & meetup)

Nous avons également acté qu’en premier lieu il fallait une envie, quelqu’un capable d’investir de son temps pour une communauté. Étant un petit groupe nous ne pouvons donc pas pour le moment soutenir toutes les communautés.

Quoi qu’il en soit, n’hésitez pas à nous contacter si vous représentez une communautés ou si vous souhaitez en fonder une sur contact@agiletribu.com

Crédit photo : Flickr

Agilité et LEGO® Serious Play®

Nous vous l’annoncions il y a quelques jours : la Tribu est certifiée LEGO® Serious Play® (LSP)

Tout au long de la formation, nous avons décelé des valeurs communes entre l’Agilité et LSP, notamment :

  • Co-construction
  • Respect de la parole de chacun
  • Émergence itérative

Les membres de la Tribu se sont donc rapidement posé la question suivante : comment utiliser au mieux LSP dans le cadre de l’Agilité ?

Aujourd’hui, l’Agilité s’appuie déjà sur les LEGO® dans le cadre d’exercices d’apprentissage :

  • Lego4Scrum qui permet de faire l’expérience concrète de la construction d’un produit à l’aide de Scrum
  • Cynefin Lego® Game qui permet d’illustrer les fonctionnements d’équipes en fonction de la complexité du contexte organisationnel

Ces exercices sont très intéressants, mais ils ne tirent pas parti du cadre LSP et ne s’appliquent pas au cœur d’un développement Agile.

Voyons ensemble quelques exemples d’utilisation de LSP dans un contexte Agile :

Lire la suite

La Tribu certifiée LEGO® Serious Play®

Du 11 au 14 janvier 2016, 4 membres de la Tribu (Yannick Ameur, Luc Bizeul, Nathaniel Richand et Nicolas Montens) assistaient à une formation à la méthode d’animation d’ateliers LEGO® Serious Play® (LSP pour les intimes)

20160113_171224

LSP est une méthode développée en partenariat par LEGO® et Rasmussen Consulting à partir du milieu des années 1990.

Initialement utilisée par LEGO® pour revoir sa stratégie et relever le challenge de la modernisation du monde des jouets (jeux vidéos, jeux électroniques…) elle fut développée et enrichie au début des années 2000, notamment par les dernières découvertes en neurosciences.

Gagnant en popularité ces dernières années, la méthode vise à réaliser des ateliers pour :

  • définir une stratégie,
  • revoir une organisation,
  • construire une cohésion d’équipe,
  • identifier et résoudre des problèmes…

Concrètement, les éléments qui font que cette méthode est efficace face aux méthodes traditionnelles de réunions / brainstorming :

  • L’aspect ludique permet de traiter de problématiques sérieuses dans une ambiance légère et un état d’ouverture d’esprit accru.
  • La méthode s’attache à mettre tous les participants au même niveau. Chacun construit à l’aide des briques sa vision personnelle (d’un idéal, d’un existant…) et l’explique aux autres participants. Puis les visions individuelles sont mises en commun, sans laisser personne de côté. Exit les réunions où la parole est monopolisée par 20% des participants ! On est ici dans une réelle co-construction.
  • Le fait de manipuler les briques et les constructions permet une meilleure émergence et stimule l’imagination de chacun; les neurosciences parlent ici de lien « main-cerveau »

20160112_161736

Bien sûr LEGO® Serious Play® n’est pas une « Silver bullet » ; il faut que les participants soient un minimum ouverts au concept de « Serious Play » et que les sponsors d’un tel atelier rassemblent les personnes compétentes pour atteindre l’objectif fixé en entrée.

 

Nos 4 participants ont donc brillamment obtenu leur certification de facilitateur à l’issu de 4 jours de formation au programme très dense. Ils en ressortent avec de nouveaux savoir-faire mais se sont également enrichis des rencontres avec les autres participants venus d’horizons différents mais qui partagent les valeurs communes de l’Agilité.

Place maintenant à la mise en pratique en interne et à la réflexion pour imaginer les rapprochements possibles entre l’ensemble des outils et méthodes LSP et Agile.

Ce sujet fera d’ailleurs l’objet d’un prochain article sur ce blog 😉

Et vous ? Avez-vous déjà utilisé des LEGO® dans vos ateliers de travail ? Etes vous certifiés LEGO® Serious Play® ou avez-vous l’intention de l’être prochainement ?

Partageons nos expériences !

Arbre de noël à la tribu

Samedi dernier nous avons eu le plaisir de fêter notre premier arbre de noël à la tribu. Fidèle à notre idée d’ouverture, nous avons invité également les amis de la tribu et leurs enfants.

Notre objectif : passer un bon moment tous ensemble et permettre aux enfants de jouer à nos jeux que nous  réservons d’habitude aux adultes lors de nos formations.

Nous avons commencé par le fameux marshmallow challenge :

IMG_1264

IMG_1265

 

 

 

 

 

 

 

Nous avons pu valider l’hypothèse que les enfants sont plus doués à ce jeux que la majorité des adultes, ceux-ci ont réussi une première réalisation à 46cm en moins de 5 minutes!

Lire la suite

Dashing : alors ça dépote?

Dernier article pour cette série sur comment faire un dashboard qui déchire avec Dashing. Nous avons préalablement vu pourquoi utiliser dashing, puis nous avons vu comment faire un super widget giphy, aujourd’hui je vous propose de finir avec un widget JIRA.

Tout d’abord, avant d’attaquer la partie technique laissez-moi vous expliquer pourquoi ce widget nous est utile.

Notre équipe est organisée dans une logique Kanban, c’est-à-dire que nous travaillons en flux tiré et nous nous efforçons de limiter l’encours. Afin de gérer notre flux nous utilisons principalement deux outils : le suivi du nombre d’éléments en cours et notre « throughput », c’est-à-dire notre débit. C’est ce deuxième indicateur qui va nous intéresser aujourd’hui.

Après avoir étudié notre débit pendant plusieurs semaines, nous nous sommes rendu compte que nous délivrions environ quinze éléments en quinze jours.

Nous allons donc faire une petite jauge pour dashing pour visualiser en temps réel le nombre d’élément qui sont sortis les quinze derniers jours et ainsi avoir un feedback pour nous prévenir lorsque ce nombre chute (ou pour nous arrêter boire un coup s’il augmente trop 😉 ).

Je pars du principe que vous avez lu l’article précédent et donc que vous avez déjà un embryon de dashboard à minima.

Pour commencer nous allons donc ajouter à notre dashboard (/dashboard/foodash.erb) un nouveau widget de type « meter » :

<li data-row="1" data-col="1" data-sizex="1" data-sizey="1">
      <div data-id="throughtput" data-view="Meter" data-title="Nb tickets DONE (15j)" data-min="0" data-max="30"></div>
    </li>

Nous utilisons pour le moment le widget de base, si vous démarrez votre dashboard vous devriez avoir quelque chose comme ça :

Capture d'écran 2015-12-10 09.34.11

Bien, passons à l’alimentation de notre widget. Nous allons maintenant créer un fichier jira.rb dans le répertoire jobs :

# encoding: utf-8
require 'httparty'

require 'json'

SCHEDULER.every '5m', :first_in => 0 do |job|

nbDays = 15

auth = {:username => "USERNAME", :password => "PASSWORD"}

url_jira = "http://your.jira.com/rest/api/2.0.alpha1/search?jql="

issues_done = getIssues(url_jira, auth, nbDays)

send_event(:throughtput, value: issues_done.length)

end

def getIssues(url_jira, auth, nbDays)

jql = 'project=SEC AND status=Closed AND resolution = Fixed AND type!=Epic AND resolutiondate>startOfDay(-'+nbDays.to_s+")"

url = url_jira+ERB::Util.url_encode(jql)

res = HTTParty.get(url, :basic_auth => auth)

return res["issues"]

end

A noter qu’en fonction de votre version de jira, il faudra que vous modifiez l’appel à l’API, mais ce ne devrait pas être bien compliqué à migrer. J’ai par facilité préféré utiliser une authentification par login/password. Dans l’idéal il faudrait transformer ceci en authentification oauth (si quelqu’un veut proposer une amélioration ce sera avec plaisir). Attention à bien penser à encoder l’url sinon il y a de grande chance pour que l’appel à Jira ne fonctionne pas.

Suite à la création de notre job, notre widget se met à jour automatiquement toutes les cinq minutes :

Capture d'écran 2015-12-10 09.35.23

Maintenant, ce que nous souhaitons faire c’est y apporter un peu de couleur pour faciliter la lecture. Dans l’idéal notre widget sera vert si nous avons fini au moins 12 éléments, jaune jusqu’à 9, puis rouge en deçà (bornes définies avec l’équipe).

Nous ajoutons donc dans notre job une petite méthode pour définir la couleur (méthode bien verbeuse pour en faciliter la lecture cher lecteur) :

def getBackgroundColorByNBIssuesDone(nbIssues)
hotness = "cool"
if nbIssues < 12
hotness = "warm"
if nbIssues < 9
hotness = "hot"
end
end
return hotness
end

Et nous modifions le send event pour envoyer également cette couleur au widget : 

send_event(:throughtput, value: issues_done.length, hotness: getBackgroundColorByNBIssuesDone(issues_done.length))

Pour que la couleur de fond soit modifié nous allons modifier le fichier coffeescript de notre widget meter, widgets/meter/meter.coffee et ajouter cette partie :

onData: (data) ->
node = $(@node)
hotcss = switch
when data.hotness == "cool" then "#00C176"
when data.hotness == "warm" then "#FABE28"
when data.hotness == "hot" then "#FF003C"

$(@node).css("background-color", hotcss)

Ainsi notre widget ressemblera à ça :

Capture d'écran 2015-12-10 09.35.58

Ou sinon :

Capture d'écran 2015-12-10 09.36.36

Capture d'écran 2015-12-10 09.37.06

 

 

 

 

 

 

 

Voilà, notre widget est déjà terminé. Comme vous l’avez-vu, nous avons quelque chose de très précis, facile à lire et ceci pour tout juste une trentaine de ligne de code. De plus, cette jauge colorée pourra être réutilisée pour d’autres indicateurs.

C’est ainsi que se termine cette série d’article Dashing, j’espère que cela vous aura donné envie de vous lancer, vous aussi, dans la création de joli dashboard très utile. Si vous avez besoin d’aide, n’hésitez pas à nous contacter.

Notre ambition : Bonifier l’écosystème et ses parties prenantes

Nous ne sommes ni l’Uber l’agile ni une énième entité sans salarié.

Notre vocation est d’être un soutien pour notre écosystème en aidant et en mettant en avant les personnes et organisations qui se reconnaissent dans nos valeurs.

Les personnes avec qui nous travaillons ont une entière liberté de s’associer, de contribuer avec d’autres personnes ou d’autres entités, de développer leurs sociétés ou de contribuer à d’autres marques.

Pour cela voici la liste des moyens que nous constituons pour être au service de cette vocation :

Nous sommes convaincu que l’exemplarité est le meilleur moyen de transmettre nos valeurs et nos convictions qu’un monde professionnel basé sur l’ouverture et la transparence radicale est à la fois possible, fun et bénéfique à tous 🙂

Cercle des « Associés »

Comme nous l’avons vu précédemment, chaque cercle doit définir :

  • sa raison d’être (pourquoi?)
  • ses conditions d’entrée
  • ses conditions de sortie (si nécessaire)

Dans le cas du cercle « Associés » son objectif est d’assurer le long terme de la tribu en veillant à la pérennité d’Agile Tribu et à son modèle. Pour cela les membres du cercle ont pour devoir de :

  • S’assurer de faire vivre et de diffuser les valeurs et la vision d’Agile Tribu dans tous les autres cercles
  • S’engager sur la gestion financière de la structure

Rôle des associés

Dans le cadre des rencontres du cercle, les associés ont tous le même droit de vote donc le même poids lors des prises de décision au consentement.

Les associés peuvent être membre d’autres cercles.

Pour devenir associé, il faut être candidat au cercle des associés et avoir le consentement de tous les autres membres du cercle.

Lors de l’assemblée stratégique d’AgileTribu (bi-annuelle), le candidate sera alors entendu par le cercle, puis le cercle débattra de sa candidature au consentement.

Pour sortir, tout membre peut sortir sur demande du cercle ou sortir par consentement du cercle.

Les Responsables

Le cercle des associés possède un sous-cercle restreint les Responsables.

Les responsables sont un garde fou de l’Agile Tribu. Ils n’ont pas plus de pouvoir en tant normal que les autres associés.

En cas de crise profonde ou de blocage mettant en péril la tribu, les Responsables devront agir.

Pour y rentrer il faut :

  • être candidat au cercle des responsables
  • être membre Associé depuis 2 ans
  • avoir le consentement des associés
  • acheter des parts de la structure d’Agile Tribu

Responsabilité supplémentaire des Responsables par rapport aux associés

  • Porter et supporter les coûts financier de la structure en cas de besoin.

Pour sortir, tout membre peut sortir sur demande du cercle, il devra revendre ses parts au cercle des Responsables au prix d’achat ou à la valeur en cours si inférieur au prix d’achat.

Contribution financière

Les associés et responsables n’ont pas vocation à être salarié par la structure.

Cependant, nous souhaitons tisser un lien fort entre ces personnes et la tribu. Nous demandons donc aux membres de ces cercles de s’engager de la sorte :

  • Une contribution mensuelle fixe
  • Une part variable sur la facturation

Par exemple ces montants pourra être 500€ mensuel et 5% sur la facturation. Ces montants évolueront en fonction des besoins de la tribu et avec l’accord de tous les membres du cercle.

Cette contribution a pour vocation de mutualiser les moyens, de payer les locaux de la tribu, les salaires, factures à payer (stagiaire, comptable, équipement, …) et non pas à accumuler du capital.

Références :

Pour définir ce modèle nous nous sommes beaucoup inspiré de plusieurs sources, notamment :

Dessine moi un cercle

Ce jeudi nous nous sommes retrouvés, comme de coutume, à la tribu pour travailler.

Nous avions fait la proposition via notre meetup d’accueillir des gens extérieurs pour l’après-midi et Nicolas Montens s’est gracieusement prêté au jeu (un grand merci à lui).

L’objectif de cette demi-journée était de poser sur le papier les bases de notre modèle afin de commencer à le faire vivre et pouvoir le communiquer à l’extérieur pour l’enrichir.

Une valeur importante à nos yeux étant la transparence radicale, voici donc les résultats de nos travaux et les prémices de la tribu. Ceci n’est pas parfait, mais au moins ça a le mérite d’exister et d’être une base pour débuter.

N’hésitez pas à commenter et à apporter vos idées, nous sommes totalement ouvert 🙂 dans les commentaires.

Nous avons beaucoup d’idées encore en stock, mais comme tout Agiliste nous avons beaucoup utilisé le principe YAGNI. N’essayons pas de régler des problèmes que nous n’avons pas encore…

Notre modèle

Tout d’abord, pour comprendre le modèle que nous avons dessiné, il est important de repartir des valeurs qui sont au coeur de la tribu (pour plus de détails voir sur le site web) : 

  • Une communauté « ouverte »
  • Transparence radicale
  • Auto-organisé dans la bienveillance
  • Rendre service aux agilités
  • Apprendre et enseigner

AgileTribu-Valeurs

Afin de mettre en pratique ceci nous nous sommes beaucoup inspirés des « cercles » sociocratique. Nous avons défini pour le moment 5 cercles mais l’objectif est que cette organisation soit vivante et dynamique et donc que ces cercles ne soient pas figés.

Chaque cercle pour exister doit définir à minima ces critères :

  • sa raison d’être (pourquoi?)
  • ses conditions d’entrée
  • ses conditions de sortie (si nécessaire)

Nous avons défini que chaque cercle avait à minima comme condition d’entrée le consentement de tous les membres de ce cercle. Nous détaillerons ce point plus tard.

Voici vu d’avion à quoi cela ressemble : 

IMG_4588

Nous allons dans les prochains articles détailler ces premiers cercles, en commençant dès demain par le cercle de base « associés ».