Agile Framing

Le Framing Agile donne du sens à nos initiatives de BootCamp et des starterKit Agile qu’AgileTribu a lancé ces dernières années.

Le Framing Agile est née de différente aventures initialisées avec Nathaniel Richand, poursuivi avec Judicael Paquet lors de nos missions communes.

Judicael à réussi à formaliser les réflexions sur : comment industrialiser le bootstrapping de Produit Agile avec Agile Framing sur son blog MyAgilePartner :

framing-agile-2

Bravo pour cette synthèse que nous partageons et qui évolue avec les différents coach, clients, Produits, tests réalisés autour des différents éléments du Framing.

Je conseils de lire les articles liées ici :

https://blog.myagilepartner.fr/?s=framing

A suivre pour 2019.

ScrumBan en Action

Why de l’article

Je ne trouve pas sur le web de définition du ScrumBan qui me satisfasse.

How

J’ai cherché à avoir un schéma proche des habitudes Scrum mais plus orienté ScrumBan.
Mais la littérature web ne montre que des images de board Kanban.

What
ScrumBan

 

Quelques explications :

Pour rester simple, cela représente un flux continu avec en entrée le backlog qui est entretenu par le processus ScrumBan et en sortie l’incrément qui est alimenté en continu comme en méthode Kanban.

La particularité du flux ScrumBan, quelque soit votre workflow, est que vous devez réaliser les actions en « just in time ».

Le ScrumBan est un mélange de Scrum (cérémonies et sprint) et Kanban (le flux tiré, la gestion des limites du travail en cours, du just in time ..) adapté à l’équipe et par l’équipe, dans mon cas voici la description des actions de notre flux :

  • Pas de sprint planning en début d’itération, mais des cérémonies d’affinage pour lever les loups entre analyste / dev
  • et des cérémonies d’estimation pour valider le ready d’une user story.
  • Nous avons gardé la rétrospective de fin d’itération.
  • Nous avons des rétrospectives technique.
  • La mise à disposition des US Done sont délivrées toutes les nuits, via le déploiement du ‘master‘ du gestionnaire de code source.
  • Nous avons aussi gardé le sprint review de fin d’itération pour communiquer vers les clients et sponsors les réalisations Done du Sprint.

Quand déclencher une action just in time ?

Quand une limite est atteinte ou quand le flux tiré le demande.
C’est à dire pour nous quand la limite de 3 US dans la file « A affiner » ou quand la file « Prête pour dév » est vide, alors nous déclenchons un atelier d’affinage ou d’estimation.

Un des objectifs de l’équipe et du coach est d’avoir un flux équilibré et fluide.

Vous pouvez lire le livre de Laurent Morisseau Kanban pour l’IT.

Dans mon cas, le kanban commence de la planification des prochaines études et fini à la mise en place de la feature dans le master de notre GitLab.

Vous pouvez lire l’article de Martin Fowler sur le FeatureBranch.

Je serai ravi de discuter avec vous de ce sujet à un Meetup Agile Tribu ou lors d’un BBL.

La tribu fait deux Cubes le Jeudi 26/01

Oyé Oyé

Agile Tribu fait son 2ème et 3ème Cubes : Prioriser, estimer et planifier et Expliquer l’agilité dans mon entreprise

le Jeudi 26 janvier 2017

logo_1cubego_officiel

Cube Après-midi : Expliquer l’agilité dans mon entreprise

Depuis plusieurs jours, semaines ou mois, vous entendez des personnes de votre entreprise dire qu’il faut passer à l’Agilité.

Vous entendez des : « Agile c’est quand tu collabores pour réaliser des user stories grâce au Scrum Master », « Tu es agile, tu mets des post-it au mur, et tu fais des points courts quotidiens » ou encore « Agile c’est un truc de dev, c’est pour qu’ils arrêtent la spec’ ! »…

Deux possibilités : vous ne savez pas exactement ce que c’est et vous aimeriez bien qu’on vous éclaire sur ce qu’est réellement l’agilité ou bien vous connaissez le sujet par cœur mais ne savez pas comment bien l’expliquer aux acteurs de votre projet.

Comment expliquer la démarche à mon équipe de développement sans qu’elle ne prenne peur ? A mon manager pour qu’il se sente impliqué ? A mon métier pour qu’il se sente rassuré ? A mon client pour qu’il se sente valorisé ?

Cube matin : Prioriser, estimer et planifier

De responsable métier avec son cahier des charges à Product Owner avec son backlog produit, prioriser est probablement un des sujets les plus délicats.


Estimer la valeur, le contentement client ou l’effort, tous ces critères sont indispensables pour faire une bonne priorisation et satisfaire tout le monde.


Vous testerez plusieurs techniques de priorisation, d’estimation et de planification. A pratiquer seul ou en équipe, de basique à complexe, il y aura des pratiques pour tous les goûts.

Venez prioriser, c’est une priorité !

Vos hôtes : Nathaniel Richand, Jean-Claude Grosjean et Yannick Ameur.

Rendez-vous chez nous au 4 ter passage de la main d’or 75011 Paris de 8:45 à 12:30
Métro Ledru-Rollin

Tarif : 216 € TTC / cube
Inscriptions à la Billetterie :

Product Owner : études récurrentes, Studies Loop

Comme d’autres Product Owner, dans le monde de l’Agile, j’ai besoin de clarifier certain mode de fonctionnement.

En ce moment, je suis confronté à définir un Produit qui encapsulera et simplifiera d’autres produits. Chaque produit à intégrer se transforme donc en épic.

Donc voici le mode de fonctionnement que j’ai décidé de tester :
Je considère que chaque épic à intégrer représente une release dans ma roadmap, donc un lot fonctionnel à mettre en production en fin de release.

La Release sera composée de tout ce qui est nécessaire pour livrer l’épic : son découpage en stories fonctionnelles, mais aussi les stories techniques ou autres stories transverses nécessaires à la livraison.

Processus de l’étude de la Release commence par un Sprint 0 :

etudeproduitenboucle

Step 1 : Workshop de Définition

  • Timing : Selon l’épic, le workshop prendra entre 3h et 2j
  • Participants : les responsables et acteurs de l’épic
  • Animateur : un facilitateur externe au projet
  • Target / output / livrables :
    • Première vision de la vie actuelle de l’épic
    • Première vision de la cible intégrée et simplifiée
    • Les utilisateurs concernés par la cible : la liste avec nom prénom pour le 2.1
    • Les gains attendus pour établir la business value

Step 2.1 : Découverte des utilisateurs

  • Timing :
    • 30min à 1h par type de end-user,
    • observation de 3 à 4 actions différentes
  • Passer du temps avec les end-users :
    • Laissez-vous guider par leurs explications sur les cas d’utilisations, les besoins
  • Observez leurs manières de travailler et … trouvez le moyen de simplifier leurs actions, interactions, délais d’attentes…
  • Type de rencontre : One To One ou sur les genoux du end-user
  • Target / output / livrables :
    • Affinage de l’épic en end-user Stories dans votre Release Backlog ou Epic Backlog

Step 2.2 : Design cible

  • Timing :
    • en parallèle du Step Customer Discovery
    • cette étape continue dans les sprints de la release, car l’ergonomie, le look&feel, l’UX devront être challengés par vos équipes de réalisation, votre UX designer et par vous.
  • Réalisez vos Mockups des écrans à réaliser
  • Avec un UX (ou pas) alimentez le schéma des écrans avec les chemins d’utilisations de votre application.

Step 3 : Release Roadmap Mapping

  • Timing : 2 heures
  • Target / output / livrables
    • User Stories avec :
      • une priorité
      • une business value
      • une estimation avec vos équipes
    • Une estimation du nombre de sprint

Fin du sprint 0 :

  • Début du sprint 1 de la release
  • Début du sprint 0 de la prochaine Epic pour vous

Voila, merci pour vos commentaires, vous répétez cela en l’améliorant à chaque fois jusqu’à épuisement du Product Backlog ou de vous ;o)

Yannick AMEUR

Pimp my gif : création d’un widget avec dashing

Je vous ai brossé dans l’article précédent tout l’intérêt d’un dashboard sur mesure avec Dashing. Aujourd’hui je vous propose de voir comment celui-ci fonctionne à travers la création concrète d’un widget. 

Pour cet exemple je vous propose de créer avec vous un widget permettant d’afficher sur notre dashboard dashing un gif animé, qui sera récupéré en fonction d’un ensemble de mots clés.  Pour cela nous allons utiliser Giphy et son API.

Avant de commencer je vais vous expliquer les concepts clé dans Dashing :

  • nous allons commencé par créer un dashboard, celui-ci déclarera l’ensemble des widgets que nous allons avoir et leur définira un id
  • pour la partie widget nous pouvons soit utiliser les widgets existants soit créer un widget custom.
  • enfin pour envoyer la donnée nous pouvons soit l’envoyer directement via un appel POST en HTTP, soit créer un job en ruby dans dashing.

dashing-architecture

Création du dashboard

Pour commencer vous aurez installé Ruby & Dashing (qui vous demandera certainement également l’installation de NodeJS). 

Puis pour initier notre projet nous allons utiliser la commande : 

Lire la suite

Supprimer les comportements négatifs avec le sourire!

Notre problème : quand la revue coince

Lors de la dernière rétrospective, nous avons identifié tous ensemble que le principal point de contention de l’équipe se situe lorsque les développements sont terminés, au moment de faire une revue du code par les pairs, pour que la story puisse ensuite passer en recette.

Nous avons discuté sur le fait d’éviter de bloquer trop longtemps l’auteur de cette pull request (nous utilisons git). En effet si la story n’est pas revue rapidement le cout du switch et du travail parallèle devient très fort. En contrepartie, l’équipe ne peut pas s’arrêter immédiatement pour la valider afin de ne pas casser son flot et dans ce cas-là, elle aussi switcher…

PullRequest-blurred
Un exemple de pull request (certaines sont plus utiles 🙂 )

Lire la suite

La Vision d’Agile Tribu

Agile Tribu
Agile Tribu

Depuis plus de trois ans, je travaille sur la vision d’une société libérée (merci Ugo Bourdon).

L’aventure a débuté avec Gabriel le Van et Nathaniel Richand dans un café, nous avons commencé par utiliser du Lean Startup dont voici un exemple : lean canvas.

Puis  Jas Chong et Luc Bizeul ont rejoint l’aventure qui s’est concrétisé avec la création d’un lieu ouvert pour les rencontres et les formations sur Paris.

La suite dépendra de chaque membre de la tribu, peut-être vous.

Voici la VISION d’Agile Tribu

C’est une structure Ouverte et Libre.

Agile Tribu a la vocation de regrouper les personnes qui ont besoin de soutien, de partage, d’intelligence collective, de services habituellement fournis par les entreprises.

Le statut des membres est libre : indépendant, salarié, bénévole ou employé d’autres structures.

Notre vocation : permettre à chacun de s’épanouir dans son travail en apportant le soutien moral, de la logistique, du conseil et du travail.

Les membres du premier cercle sont porteurs et co-pilotes de la VISION d’Agile Tribu.

Agile Tribu permet aussi la mise en relation entre les équipes Agiles chez les clients et les membres du réseau de la Tribu pour du conseil, de la formation, de l’animation ou de l’aide au recrutement dans des équipes Agiles avec notre service RH Agile.

Retrouvez nous sur www.agiletribu.com et blog.agiletribu.com

Ou encore mieux en vrais en participant à nos rencontres hebdo via le meetup Agiletribu.