Bouzin Agile

Le Kanban expliqué à des étudiants

Cyrille — Sat, 18 May 2013 14:22:00 +0100

Il n'est pas toujours facile de comprendre les notions de Kanban quand on est étudiant. Lors d'un dernier échange j'ai décidé d'utiliser un exemple qui leur parle : "Les techniques de drague".
Nous avons modélisé le flux, mis en place les WIP, présenté l'importance du Slack et un début de classe de service.
Détaillons cela ensemble.

Etape 1 : Modéliser le flux

Le ("nouveau") vocabulaire utilisé est le suivant :

Numclose : signifie obtenir son numéro
KissClose : signifie l'embrasser
FuckClose : signifie coucher avec elle

Il permet d'avoir les 3 étapes de la "séduction", voici à quoi peut ressembler un board pour qu'un de très actif !!!
Et ce quelque soit l'endroit de la drague :

SPU = street pick up : drague de rue
NPU = Night pick up : drague la nuit
BPU = bar ou boite pick up
MPU = drague en centre commercial

Etape 2 : Valider les transitions entre chaque étape

Pas besoin de détailler : les noms des colonnes sont assez explicites

Etape 3 : Mise en place des WIP

On voit bien que le premier board, c'est le "bordel" (dans tous les sens du terme) :

9 personnes en KissClose : c'est ingérable, vous avez leur numéro mais vous n'allez pas passer facilement à la colonne suivante !!!
10 personnes dans FuckClose : c'est juste sur-réaliste

Il faut donc mettre en place un nombre maximum de personne par colonne (WIP : Work In Progress), après plusieurs minutes de discussion nous sommes arrivés au compromis suivant :

Numclose : Max 5
KissClose : Max 3
FuckClose : Max 2

Et le board devient comme ceci (nous faisons abstraction des disparitions du board et des techniques de priorisation ) :

Etape 4 : On se donne du "mou"

On voit dans le Board précédent qu'il n'est plus possible "d'insérer" des personnes dans les colonnes "NumClose", "KissClose" et "FuckClose" car le WIP est atteint, il faut donc "sortir" des personnes de la colonne "FuckClose" et ainsi de suite afin d'avoir du mou sur ces 3 colonnes, comme ceci :

Et voilà, avec un board comme celui-là on a des marges de manoeuvre, il va être possible de calculer le LeadTime : en combien de temps en moyenne une personne passe de la colonne "NumClose" à "Rupture" à partir du moment ou vous aurez ces valeurs vous pourrez (peut-être) revoir les WIP à la hausse...

Etape 5 : Les classes de services

David J. Anderson dans son livre présente plusieurs classes de services :

Urgent : à "traiter" en priorité,
Standard,
A date fixe : la personne part à l'étranger à une date bien précise, vous devez donc vous organiser pour arriver dans la dernière colonne avant son départ,
Intangible : il faut le faire mais le ROI n'est pas "palpable" rapidement (nous n'avons pas trouvé d'exemple concret pour cette classe de service),

Voici un exemple avec un date fixe (ou date due) : "Alexandra 25 Mai"
C'est "la même chose" que les autres ~~filles~~ fiches sauf qu'il y a une date indiquée sur la fiche, vous devez vous demander par quelle fiche "attaquer" en fonction de sa classe de service. Rappel "Choisir c'est renoncer"...

Conclusion

Nous passé une après midi assez marrante mais surtout tout le monde a assimilé les bases d'un système Kanban :

Visualiser le flux
Limiter le "travail" en cours
Manager le Flux
Placer des règles explicites entre chaque colonne (naturellement tout le monde les a vu !!!
Continuer à s'améliorer

Disclaimer

Bien sur cet exemple n'est pas du tout sérieux (mais super didactique)
Nous avons volontairement refusé d'ajouter la phase "BJClose" dans la board pour ne pas complexifier le modèle
Les prénoms ne sont que des exemples aussi
Oui il manque un CFD
Nous n'avons pas eu le temps de trouver des exemples de "Bac Rouge" : Si vous voulez faire une V2 de ce modèle, contactez-moi !!!

Maintenant vous n'avez plus d'excuse pour ne pas comprendre les flux tirés !

ScrumDay 2013 : Retour d'expérience

Cyrille — Tue, 09 Apr 2013 07:01:00 +0100

Dans 2 jours c'est le Scrumday, j'ai cru voir passer quelques twittes indiquant qu'il y avait des places disponibles.
Attention fermeture des inscriptions mercredi 10 au soir...
Je crois qu'il y a un code de réduction : FSUG-70euros
Pour ma part, je présenterai un retour d'Expérience sur la mise en oeuvre d'un projet mobile.

Rappel du Pitch :
"Vous hésitez à développer vos applications mobiles avec Scrum ? Figurez-vous que même dans des contextes hautement complexes c'est possible ! Différentes entités, différents développements : iPhone, Android, Webmobile, socle multicanal... Nous l'avons fait ! Elise PEYRET (Product Owner chez Cetelem) et Cyrille DERUEL (Delivery Manager chez OCTO Technology) se proposent de partager avec vous leur d'expérience sur la mise en œuvre agile (Scrum) du projet Cetelem Mobile.
A l’issue de cette session vous aurez reçu :
- Nos Do’s & Don’ts à propos des méthodes agiles lorsqu'elles sont appliquées à des projets de mobilité
- Les modèles d’organisation que nous avons mis en œuvre
- Les outils et les compétences clés pour démarrer un tel projet
Venez donc voir comment allier autant de technos mobiles sur 6 mois tout en gardant la tête sur les épaules avec des pratiques agiles."

J'espère avoir le temps de croiser certains d'entre vous (Alfred Almendra, Bruno Sbille, Claude Aubry, Etienne Charignon, Jean-Claude Grosjean etc...).

Pour le programme c'est ici : http://agenda2013.scrumday.fr/events/

En espérant avoir assez de temps pour échanger avec vous lors de cette journée.

My name is Bond, Scrum Bond

Cyrille — Sat, 23 Mar 2013 11:12:00 +0000

Depuis quelques jours, des Twittes avec le HashTag #agilemovies présentent des titres de films détournés avec le vocabulaire Agile.

Voici une liste des James Bond, Scumisé et une sélection de twitte

The Scrum Bond

Dr ProductOwner
On Her Backlog's Secret Service
Live and Let Done
The Man with the Golden Backlog
The ProductOwner Who Loved Me
For Your Retrospective Only
Licence to deploy
Tomorrow Never Done
The Story Is Not Enough
Demo Another Day

Some other twittes

The Silence of The Pigs
The Empire Strikes Backlog
Lost in continuous integration
Star Trek II: The Wrath of KahnBan
The Nightmare Before Estimates
The Defect Strikes Back
A Miracle on 34th Sprint
Trois hommes et un burndown #FrenchEdition
Scrum master and seven developers
The Lord of the Tests
Stop! Or my mom will deploy
White Men Can't Sprint

KISS - Keep it Simple, Stupid

Cyrille — Tue, 12 Mar 2013 10:05:00 +0000

Keep it Simple, Stupid (en français, mot à mot : « Garde ça simple, stupide », dans le sens de « Ne complique pas les choses »), ou principe KISS, est une ligne directrice de conception qui préconise de rechercher la simplicité dans la conception et que toute complexité non nécessaire devrait être évitée. Ce principe est appliqué dans grand nombre de disciplines telles que le développement logiciel, l'animation, le journalisme, la photographie, l'ingénierie, l'aviation et la planification stratégique. (Src WikiPedia : Principe KISS).

Mais la simplicité ce n'est pas simple à mettre en place.
Néanmoins, regarder les exemples de solutions simples à des problèmes qui semblaient compliqués.

Servez vous d’une pelle à poussière propre pour remplir d’eau un contenant qui n’entre pas dans l’évier

Mettre un élastique autour d’un récipient de peinture afin d’enlever le surplus sur votre pinceau et ainsi éviter de souiller le contour du récipient.

Servez vous d’un otagraphe au lieu de vos ongles lorsque vous voulez ajouter une clé à votre trousseau.

Mettre une cuillère en bois sur votre casserole afin d’empêcher l’eau bouillante de déborder.

Votre paille ne sortira plus de la canette

Vous servir d’un linge microfibre pour prévenir le gel sur votre pare-brise.

Servez vous d’un peigne afin que le clou soit stable.

Servez vous d’un “post-it” pour ramasser les débris lorsque vous percez un trou.

Quelques citations autour de la simplicité

« La simplicité est la sophistication suprême. »
« La simplicité est l'habit de la perfection. »
« La simplicité est le secret de la réussite »
« La simplicité est en définitive très difficile à atteindre. Elle repose sur l’attention, la pensée, le savoir et la patience. »

Lignes de CV qui m'irritent

Cyrille — Tue, 12 Feb 2013 12:24:00 +0000

Depuis 2 semaines je reçois beaucoup de CV, j'ai l'impression que

les gens pensent que la "crise" est terminée,
les gens ne se retrouvent plus dans les valeurs de leur société,
les gens ont envi de monter en compétence.

Ou peut-être les 3 en même temps !!!
Quoi qu'il en soit, voici des extraits d'un CV qui ont une forte tendance à m'agager...

Enjoy !

Méthodologie agile (SCRUM + XP + LEAN)

Celle là je l'aime bien, au mois en mettant les Scrum + XP + Lean on est certain de remonter dans les moteurs de recherche.
Sauf que d'expérience, au bout de 3 questions sur XP, Scrum ou Lean, le candidat se rend bien compte qu'il a mis 2 ou 3 mots en trop dans son CV.

Gestion des ressources de projet (recrutement, découpage et assignation des tâches)

C'est l'assignation des tâches qui m'a assommé, il doit y avoir un raté dans sa formation Scrum.

Rédaction de spécifications fonctionnelles générales et détaillées

Mmmm c'est bon ça, ce monsieur sait tout faire

Gestion des aspects financiers de projet (chiffrages)

Ah bah, oui tant qu'on y est, c'est le patron qui assigne les tâches et qui chiffre le projet, c'est vrai que c'est lui le mieux placé...

Conception et spécifications détaillées d’architecture technique

Mais elles font quoi les personnes qui travaillent avec ce monsieur ???

Conception et modélisation d’applications (MERISE et/ou UML)

Tiens encore des mots clefs des années 2000

Points d’avancement réguliers avec l’équipe et gestion du respect ou non du temps de développement

Je n'ose même pas imaginé ce qu'il peut se passer en cas de non respect du temps de développement...

J'oubliais, le titre du CV : "Responsable des développements" !!!!

Au final, tout cela est bien décevant et il n'y a pas eu de suite.

Il ne suffit pas de mettre des mots clefs dans un CV pour être embauché, même si cela fonctionne dans certaines sociétés.

A pousser toujours le même CV, il ne faut pas s'étonner d'être contacter par les mêmes types de sociétés...

Idées cadeaux pour vos "chers" collègues de bureau

Cyrille — Thu, 20 Dec 2012 21:27:00 +0000

Tout le monde n'a pas la chance de travailler au pays de Bisounours, alors je vous propose une petite liste de cadeaux subtil (ou pas) à faire à vos collègues de travail. Bonnes fêtes de fin d'année

Travailler avec des cons

Comment glander au bureau en passant pour un pro : Et autres techniques de survie en entreprise

Mon chef est un con : Guide d'actions concrètes pour travailler avec un chef difficile

Gérez les emmerdeurs

Petit chef ou vrai patron ?

Faits et Foutaises dans le management

Mon chef est un connard ! Et le vôtre ?

Comment se faire des amis

Attention : n'oubliez pas que c'est de l'HUMOUR et que le monde des BISOUNOURS n'existe pas !!!!!!!!!!!!!

La confiance : le carburant obligatoire pour vos équipes Agiles

Cyrille — Sun, 11 Nov 2012 16:21:00 +0000

Rien ne peut fonctionner sans la confiance.
Je pense qu'en Agile, c'est pire, sans confiance votre projet Agile est voué à l'échec,

mais alors comment ça marche la confiance ?
Comment cela se mesure ?
On en trouve sur eBay ?
LeBonCoin ?
Par pack de 6 :-) ?

On peut découper diviser la confiance en 2, la confiance immédiate et la confiance profonde.

La confiance immédiate peut être facilement atteinte. Elle est nécessaire dans les premiers moments d’existence d’une équipe.
La confiance profonde est plus longue à obtenir et demande des efforts continus dans chaque aspect du travail d’équipe

Les 4 critères de la confiance immédiate

La compétence : nous sommes convaincu que toutes les personnes qui travaillent sur ce projet, on les compérences nécessaire,
L'ouverture et le partage : je ne garde pas les informations, je communique, je partage, je passe du temps à capitaliser pour l'équipe,
L'intégrité : Je dis ce que je fais et je fais ce que je dis, si j'ai une difficulté je communique, si j'ai pas la date, je donne la date de la date...
La réciprocité : Je fais confiance aux gens qui me font confiance, alors quelqu'un doit commencer (pourquoi pas vous ? )

Les 6 critères de la confiance profonde

Compatibilité : Partagez-vous vos valeurs, votre histoire, vos centres d’intérêt et vos aspirations avec vos collègues ?
Bonne volonté : Vous souciez-vous de vos collègues et est-ce réciproque ?
Prévisibilité : Vos collègues, sont-ils constants dans leur comportement dans le temps et quel que soit le contexte ? et vous ?
Bien-être : Ai-je le sentiment que je n’ai rien à craindre des membres de mon équipe, de mon management ? Puis-je commettre des erreurs sans être jugé ?
Inclusion : Y a-t-il quelqu’un qui est mis à l’écart ou exclu de l’équipe ? Est-ce que tout le monde se sent intégré dans les différentes activités de l’équipe ?
Accessibilité : Avons-nous le sentiment que les autres peuvent être abordés facilement et sont disposés à exprimer ce qu’ils ressentent ?

Vous, votre manager et votre confiance

On peut voir rapidement, comment vous pouvez (ou pas) avoir confiance en un manager :

La compétence : votre manager ne remet pas en cause vos compétences et identifie vos axes de progression,
L'ouverture et le partage : votre manager partage avec vous toutes les informations sur le projet,
L'intégrité : votre manager tient ses promesses et vous suis l'avancement de vos demandes,
La réciprocité : votre manager est bienveillant,
Compatibilité : votre manager s'intéresse à ce que vous faites dans votre vie, vos passions, vos contraintes (en respectant votre vie privée !)
Bonne volonté : votre manager est volontaire, il n'hésite pas à vous aider (trouver des solutions) dans les moments difficiles,
Prévisibilité : votre manager est 'd'humeur constante',
Bien-être : votre manager sait que l'erreur est humaine et surtout source d'amélioration et non de sanction,
Inclusion : votre manager s'assure que n'oublier personne et d'avoir le même niveau d'information pour tous les membres de l'équipe,
Accessibilité : votre manager est disponible, vous le voyez au moins 30 minutes pas semaine et vous pouvez lui le rencontrer facilement.

Voilà maintenant que vous avez compris pourquoi vous avez (ou pas) confiance en votre manager/management, relisez ces 10 dernières lignes et demandez vous ce que pensez vos collègues de vous.

Petite piqûre de rappel : L'O3 (Le OneOnOnes) vout permet de suivre une bonne partie de ces critères de confiance : Un outil de management d'équipes.

Quelques citations sur la Confiance

« Si vous avez confiance en vous-mêmes, vous inspirerez confiance aux autres. »
« Qui a confiance en soi conduit les autres. »
« La confiance en soi est le premier secret du succès. »
« Celui qui a confiance en lui mènera les autres. »
« L'humilité naît de la confiance des autres. »
« La confiance ne se réclame pas, elle se gagne. »
« La confiance se gagne en gouttes et se perd en litres. »

Et une image

Qui m'a bien fait rire, si il suffisait que les hommes utilisent cela pour avoir plus confiance aux autres...

Disponible ici : http://www.facilavi.com/incontinence-autonomie/87-protections-absorbantes-confiance-pour-faiblesse-urinaire-masculine.html.

L'Agenda-Agile, 2 ans déjà !

Cyrille — Sun, 04 Nov 2012 20:34:00 +0000

Le 4 Octobre 2010, après l'Open World Forum, j'ouvrais l'Agenda-Agile pour présenter tous les évènements autour de l'Agilité en France et pas trop loin.
Voici un petit bilan de ces 2 années.

L'histoire

L'histoire de la création de l'Agenda est détaillée ici : Naissance de l'Agenda des Agilistes (merci la communauté)

Quelques chiffres

Les statistiques sont disponibles sur cette page : Statistiques
Voici la répartition des 278 évènements de ces 2 années :

MERCI pour avoir alimenter l'agenda

Comment ça marche ?

Vous montez un évènement, vous le proposez sur cette page : Soumettre un évènement
L'équipe de modération reçoit un mail et valide l'évènement, celui-ci est disponible sur l'agenda mais aussi sur le compte twitter : @AgendaAgile.

Ma rétrospective

Ce qui était bien (et ce qui l'est toujours bien)

Il y a de plus en plus de conférences en France sur l'Agilité,
Il y a de plus en plus de modérateurs sur l'Agenda,
L'Agenda est devenu en réflexe pour certain,
La V1 du site "fait le job" : même si avant le lancement je voulais développer pleins de modules !!!

Ce qui était moins bien

Il faut encore rappeler que l'Agenda-Agile ne présente que des évènements GRATUITS sauf quelques rares exceptions,
Je n'ai pas fait d'évolution technique depuis 1 an mais je n'ai pas eu de demande dans ce sens, alors c'est peut-être suffisant,
Je vois fleurir pleins de petits agendas sur le Web et que je n'ai pas trouvé de solution pour les agréger,
L'Agenda n'est pas pluggé à Meetup.com : cela serait plus facile pour l'ajout d'évènements,
Je découvre des évènements via d'autres canaux que l'Agenda-Agile

Les questions (que je me suis) posées (et que je me pose encore)

Ou est la frontière de l'Agilité ?
Est-ce que des formations TDD doivent être dans l'Agenda Agile ?
Est-ce que les sessions de "software craftsmanship" aussi ?
Est-ce qu'il ne faudrait pas étendre l'Agenda à l'Europe ?

Les leçons (ré-)apprises

Cela reste Simple et Facile à mettre en place,
Qu'une idée ne naît jamais bonne mais que si celle-ci comble une frustration, elle devrait aussi combler la frustration de quelqu'un d'autre !!!

Remerciements

Merci à tous les modérateurs pour votre travail sur ces 2 années :

Et pour devenir modérateurs, c'est sur cette page : Devenir modérateur.

Links of the month : October 2012

Cyrille — Wed, 31 Oct 2012 22:54:00 +0000

Here is a best of posts of this month on project management and agile

PMOT

Provide Project Management Structure Where There Is None - http://ow.ly/1P6iMM
5 Ways to Manage Team Conflicts - http://ow.ly/1P1w58
The Ideologue, the Zealot, the Practitioner, the Secular and the Non-believer - http://ow.ly/1P1w02
Project Managers How To Adopt The Language Of Your Customer - http://ow.ly/1OT7h7
What's Missing? - http://ow.ly/1OMrFS
A Project Manager’s Top 10 to a Successful Redesign - http://ow.ly/1OMrEi
Project Cost Planning and Management - http://ow.ly/1OMrv8
5 Reasons Why Projects Fail - http://ow.ly/1OLeK8
Managing Your Project Priorities - http://ow.ly/1OK06T
Are You an Assertive Project Manager? - http://ow.ly/1OITdU
Project Risk Is Essential - http://ow.ly/1OHMR3
Pick the Right Project Management Tool for the Right Purpose http://ow.ly/1PeCpm
Key Touchpoints for Successful Project Management – Part 2 http://ow.ly/1PeCuu
Effective Approaches to Project Prioritization http://ow.ly/1PgZLG

AGILE

Third Thing Agile Is Not: High Risk - http://ow.ly/1PbHRu
Getting Lean with Scrum - http://ow.ly/1PbHN7
Columbus Discovers Agile - http://ow.ly/1PaoTA
Certified ScrumMaster (SCM) Certification versus PMI Agile Certified Practitioner (PMI-ACP) - http://ow.ly/1PaoQK
Agile Means ... - http://ow.ly/1P6iYq
Scrum and Entrepreneurism - http://ow.ly/1P6iWk
How Scrum Manages Risk - http://ow.ly/1P6iUj
How we’re using story points - http://ow.ly/1P6iOC
Meeting Customer’s Needs Through Agile Development - http://ow.ly/1P1vY4
Agile Project Management - Controlled Chaos - http://ow.ly/1OXzzq
Principles of Evolutionary Architecture & Design for Agile PM (Part 1) - http://ow.ly/1OXzwo
Agile Today: An Interview with Jim Highsmith - http://ow.ly/1OXzuL
5 Ways Agile Helps Mitigate Project Quality Risks - http://ow.ly/1OT7k9
10 Things to Drive Your ScrumMaster Crazy - http://ow.ly/1OT7iM
Using Story Mapping For Defining Business Requiremets - http://ow.ly/1OMrJ4
5 Steps to Introduce an Agile Tool - http://ow.ly/1OLeHZ
Becoming ScrumMaster - http://ow.ly/1OLeFD
Project Managers are Change Masters - http://ow.ly/1OK0dD
Where Agile Starts - http://ow.ly/1OK043
Why Can't I Become Agile? - http://ow.ly/1OITd8
Continuous Delivery Using Jenkins - http://ow.ly/1OITbv
Writing a Fixed Contract for an Agile Project - http://ow.ly/1OIT9y
Your Agile Transformation Needs to Start with a Quiet Phase - http://ow.ly/1OHMUZ
Can You Be Agile Without Teams? - http://ow.ly/1OHMUc
How we’re using story points http://ow.ly/1P6iOC
Retrospectives: An alternative safety check http://ow.ly/1PeCym
Linking Agile to HR Theory http://ow.ly/1PgZGN
Two Levels of (Agile) Planning http://ow.ly/1PgZJb

Thank you very much to Sara

Saveurs agiles d'automne (Les présentations Agiles 2012)

Cyrille — Sun, 28 Oct 2012 20:34:00 +0000

Voici la liste des présentations que j'ai trouvé pour les conférences Agiles 2012 entre octobre et novembre.

Contactez moi via le formulaire ou par twitter @CyrilleDeruel si j'en ai oublié.
Cette page sera mise à jour toutes les semaines.

Agile Tour Rennes - Jeudi 4 Octobre 2012

Articles de blog :
Alexandre Boutin : Agile Tour Rennes 2012

Fabrice Aimetti : Rétrospective de l'Agile Tour Rennes 2012

Matthieu Barbereau - Agile Tour Rennes 2012

Agile Tour Marseille - Jeudi 11 Octobre 2012

Articles de blog :
Thierry Vallée : Agile Tour Marseille 2012

Xavier Nopre : Agile Tour Marseille 2012

Agile Tour Vannes - Jeudi 11 Octobre 2012

liens à ajouter.

Agile Tour Bordeaux - Vendredi 12 Octobre 2012

Jérôme Avoustin : Clean code en pratique
http://fr.slideshare.net/jeromeavoustin/clean-code-en-pratique-14732075

Thierry Cros : Agile et Sociocratie : bienvenue en Sociagilité
http://thierrycros.net/?post/2012/10/23/Agile-et-Sociocratie-%3A-bienvenue-en-Sociagilit%C3%A9-%282%29

Caroline Damour-Nobi & Emilie Franchomme : Des mots, des maux ? Démo !
http://fr.slideshare.net/carolilo/agile-tour-bordeaux-octobre-2012-des-mots-des-maux-demo

Gilles Mantel : Automatisation des tests : le mythe du ROI
http://fr.slideshare.net/gmantel/atbdx12-agile-testing

Isabel Monville : La communication au service du projet
http://ayeba.fr/2012/10/nous-etions-a-lagiletour-bordeaux-2012/

Articles de blog :
Olivier Azeau : Agile Tour Bordeaux 2012 : j'y étais

Thierry Cros : Agile Tour Bordeaux 2012 : impressions de voyage

Les vidéos de l'Agile Tour Bordeaux : http://www.youtube.com/user/agiletourbordeaux

Agile Tour Clermont-Ferrand - Jeudi 18 Octobre 2012

Marie-Laure : Dis qu'est-ce que ça fait de devenir Agile ?
http://fr.slideshare.net/malainda/dis-quest-ce-que-a-fait-de-devenir-v4

Articles de blog :
Alexandre Boutin : Agile Tour Clermont et Pau

Agile Tour Strasbourg - Jeudi 18 Octobre 2012

M. Lejeune & J. Batailler : Les déconnectés de la matrice
http://fr.slideshare.net/mileje/at-strasbourg-2012-trinity-ss

Arnaud Gervais : Outils de facilitation pour le scrum master
http://fr.slideshare.net/coactiv/outils-de-facilitation-pour-le-scrum-master-strasbourg

Valérie Taesch - Soigner la réunionite
http://fr.slideshare.net/valerietaesch/soigner-la-runionite

Jonathan Scher - Bref j'ai été product owner
http://fr.slideshare.net/jonathanscher/bref-jai-t-product-owner

Yves Hanoulle : agile and lean mindset
http://www.hanoulle.be/2012/04/slides-of-my-agile-and-lean-mindset-presentation/

Jonas Vonlanthen - L'agilité dans l'ADN d'une entreprise
http://fr.slideshare.net/jvonlanthen/lagilit-dans-ladn-dune-entreprise

Pierre Parrend - Retour d'expérience dev-ops
http://fr.slideshare.net/pparrend/retour-dexprience-devops-atstrasbourg-20121018

Agile Tour Pau - Mercredi 24 Octobre

Articles de blog :
Alexandre Boutin : Agile Tour Clermont et Pau

Fabrice Aimetti : Rétrospective de l'Agile Tour Pau 2012

Agile Tour Toulouse

Laurent Meurisse & Nicolas Deverge - Lean Startup
http://fr.slideshare.net/ekito-fr/lean-startup-ekito-agile-tour-toulouse-2012

Première année de transition Agile à Air France
http://prezi.com/gd2duot6-wtv/premiere-annee-de-transition-agile-a-air-france/

Romain Couturier - Il était une fois la vie d'un product owner
http://fr.slideshare.net/calton13/agile-tour-toulouse-2012-il-tait-une-fois-la-vie-dun-product-owner

Christophe Heral ‏- TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
http://fr.slideshare.net/christopheheral/tfs-2012-un-pas-vers-lagilit-en-avant-ou-en-arrire-14921788

Thierry Cros : Agile quel chemin vers l'agilité ?

Le projet dont vous êtes le héros agile - http://www.jabberwocky.fr/index.html

Articles de blog :
Olivier Azeau : Agile Tour Toulouse 2012, entre câlinothérapie et WTFs

Photos Agile Tour Toulouse : https://plus.google.com/u/1/events/ce17lpng3vd4v88fj36bbc6ma44

Agile Tour Bruxelles - Vendredi 26 Octobre

Tous est ici : http://atbru.be/presentations

Christophe Addinquy : Retours sur l’agile tour Bruxelles 2012

liens à ajouter.

Agile Tour Rouen - Mardi 6 Novembre

liens à ajouter.

Agile Grenoble 2012 - Jeudi 8 Novembre

Vincent Daviet : Collaborer, et si on improvisait ?
http://fr.slideshare.net/VincentDaviet/collaborer-et-si-on-improvisait

Jean-François Jagodzinski : Agilité pour les nuls
http://fr.slideshare.net/jfjago/agilit-pour-les-nuls

Alexis Monville & Bruno Sbille : The Agilists
http://fr.slideshare.net/alexis/the-agilists

Laurent Sarrazin : Sweet rupture
http://fr.slideshare.net/LaurentSarrazin/2012-1108agile-grenoblesweetrupture04final

Thierry Montulé : Aux frontière de la psychologie sociale
http://fr.slideshare.net/ThierryMontul

Xavier Nopre : Ingénierie Agile : n'oubliez pas vos développeurs
http://fr.slideshare.net/xnopre/ingnierie-agile-noubliez-pas-vos-dveloppeurs-15090468

Oana Juncu : Innovation (accéléré par) LeanStartUP :
http://prezi.com/tpmsm92wwwxc/lean-startup-succeeding-in-a-cloud-of-uncertainty-from-ideation-to-user-feed-back/

Articles de blog :
Olivier Azeau : Agile Grenoble 2012, ma journée chez les binômes

liens à ajouter.

Agile Tour Nantes - Jeudi 15 Novembre

liens à ajouter.

Agile Tour Paris - Mardi 20 Novembre

liens à ajouter.

Agile Tour Lille - Jeudi 22 Novembre

liens à ajouter.

Namur: La Journée Agile 2012 - Mercredi 28 Novembre

liens à ajouter.

Agile Tour Montpellier - Jeudi 29 Novembre

liens à ajouter.

Disclaimer :

Ces supports ne vous garantissent pas la compréhension des présentations,
Les dates des conférences sont disponibles ici : http://www.agenda-agile.org/,

Je ne travaille pas avec des ressources mais avec des Personnes

Cyrille — Sun, 21 Oct 2012 21:39:00 +0100

Je suis sidéré quand je vois le nombre de personnes qui utilisent le mot "ressource" à la place du mot "Personne", j'ai même repris des développeurs sur la phrase suivante :

On est 3 ressources sur le module bidule.

Donc mes 2 phrases sont :

Je ne suis pas une ressource, je suis une Personne.
ou
Je ne travaille pas avec des ressources mais avec des Personnes

Je comprends que votre outils magique MS Project vous induise en erreur :

Oui il y a un menu ressources,
Oui vous avez un tableau des ressources,
Vous avez même un "bonhomme" où vous pouvez ajouter des ressources dans lequel vous pouvez ajouter des "bonhommes", des ressources matériels ou des ressources de coût

Mais ~~BORDEL DE MERDE~~, une ressource c'est :

Quelque chose qui ne vit pas,
Quelque chose qui ne réfléchit pas,
Quelque chose qui s'épuise mais que l'on peut envoyer en réparation ou recharger,
Quelque chose que vous pouvez acheter dans un magasin,
Quelque chose que vous pouvez changer d'un claquement de doigt,
etc...

J'ai l'impression que les personnes qui utilisent le mot "ressource" ne se rendent pas compte que l'une des grandes difficultés n'est pas de trouvé du business mais plutôt de trouver des Personnes pour réaliser ce business.

Regardez les chiffres de l'Express-Board (un site d'offre d'emploi pour passionnés) :

Et avec 40 clients abonnés et contents...!

Regardez ce billet : un gros hameçon et vous comprendrez que le jour où vos "ressources" en auront assez de votre vision de l'esprit, elles pourront changer de crèmerie assez facilement.

Je suis persuadé que les "gros" sites sont en pertes de vitesse, malheureusement je ne trouve pas de statistiques

Vous voyez, c'est pas si évident de recruter des personnes par rapport à des ressources !!!

Je pense qu'il faudra encore 10 ans pour que les "gens" arrêtent d'appeler des personnes des ressources, c'est environ le temps qu'il a fallu à des sociétés privées issues du public pour appeler leurs usagers des clients mais dans 10 ans vous serez peut-être déjà tout seul dans votre société...

Un dernier point, si vous pensez que vos collaborateurs sont des ressources et donc interchangeable, quelle est la pensée de votre manager ?

Respectueusement vôtre

Engagement sur des itérations par l'exemple

Cyrille — Mon, 15 Oct 2012 22:54:00 +0100

Le billet "Développeurs mettez vos couilles sur le billot" a au moins eu le mérite de faire un peu de bruit
Alors au lieu de refaire un nouveau billet expliquant pourquoi je milite pour l'engagement des itérations et "risquer" d'être mal compris, voici un exemple sur ce que nous avons fait sur un projet, le tout en image.

Le contexte

Un projet de développement X avec Y développeurs (en régie), nous sommes à l'itération 82, les itérations font 2 semaines.
Nous sommes à la version Z qui sera déployée à la fin de l'itération 84.
Dans cette version, nous avons 11 fonctionnalités (indiquées A à K).
Les fonctionnalités ne sont pas toutes spécifiées et bien sûr de nouvelles Users Stories apparaissent au fil des itérations.
Les fonctionnalités A,D, E et J ont été identifiées par l'équipe comme plus grosses que B,C,F,G,H,I, et K.

L'engagement de l'itération 82

Comment cela se lit

En orange sont présentées les Users Stories terminées durant les itérations 79 à 81.
En rose, l'engagement de l'équipe pour l'itération 82, en j'aune 83 et en blanc 84.
Fonctionnellement cela donne ceci :

Nous allons avancer sur la fonctionnalité A durant l'itération 82 et nous pensons la finir durant l'itération 83,
Les fonctionnalités B,C et D sont terminées et peuvent être intégralement testées,
Nous pensons commencer la fonctionnalité E, mais nous pensons qu'elle sera terminée pour l'itération 84,
La fonctionnalité F devrait être terminée pour l'itération 83,
Les fonctionnalités G et H vont être commencés sur cette itération, mais ne seront pas terminées,

etc...

Une fois que l'on a affiché ce schéma, on entend ce type de questions (du PO, Métier) :

Cela représente combien de jour un carré ?
Vous ne pouvez pas déplacer les carrés de H pour terminer G ?
Et pourquoi vous ne terminez pas G, il ne reste qu'un carré ?

Il n'y a qu'une seule ligne de conduite :

Un carré est une unité abstraite qui représente grossièrement l'avancement d'une fonctionnalité,
Cet engagement est la prédiction de ce que nous (équipe) pensons réaliser sur l'itération 82 (en rose),
Cette "planification" prend en compte les priorisations du métier ainsi que les contraintes techniques,
Cet engagement n'est fourni qu'à titre représentatif, il ne saurait remettre en cause la capacité ou la motivation d'un ou de plusieurs membres de l'équipe,
Cet engagement n'est pas un document contractuel : vous pouvez lire en tout petit "Photo non contractuelle :-)".

Comment nous avons construit ce document

C'est la phase la plus délicate et ce qui a fonctionné avec cette équipe ne fonctionnera peut-être pas avec une autre car vous aurez peut-être raté votre communication.

Etape 0 : je liste les fonctionnalités de la version, les numéros des itérations, j'imprime (10 feuilles) et je prépare 3 feutres fluo,
Etape 1 : je scotch la feuille dans l'open space, à un endroit visible de tous, je réunis l'équipe,
Etape 2 : je demande "Quelles sont les fonctionnalités terminées ?" et je colorie B, C et D,
Etape 3 : je demande "Quelles sont les fonctionnalités commencées et ou pensez-vous que nous en sommes ?", et on arrive à des choses comme il reste quand même un peu de boulot sur la fonctionnalité A, disons 2 carrés, on a avancé mais très légèrement sur E mais c'est vraiment à la marge...
Etape 4 : La plus difficile : "Que pensez-vous que nous arriverons à développer sur cette itération ?" et là vous vous taisez et vous écoutez quand vous êtes arrivés à un consensus vous coloriez en rose : nous pensons finir A, finir la consultation de E, avancer sur G et H.
Point important : En tant que facilitateur, vous ne devez jamais juger ou commenter ce que disent les développeurs, par contre vous devez identifier tous les obstacles que vous entendez (on ne peut pas bosser là-dessus car on n'a pas ....), logiquement vous êtes au courant de tous ces points de blocage mais vous pouvez en découvrir de nouveaux.
Etape 5 : Refaites la même chose avec l'itération 83 (ça va encore vous coûter 1 ou 2 feuilles),
Etape 6 : Maintenant poser la question : "Est-ce que vous trouvez que les itérations sont équilibrées ?" (ne pas oublier de rappeler tous les évènements comme les congés, formations, jours fériés...). L'équipe peut avoir envie de faire quelques modifications.
Etape 7 : Remerciez l'équipe, prenez une photo et NE DITES RIEN.

Oui ne dites rien

Vous allez être frustrés lorsque vous allez faire le coloriage, vous aurez envi de colorier le dernier carré de H, mais NE LE FAITES PAS.
Ceci est l'engagement de votre équipe, vous devez apprendre à faire confiance à toutes les personnes de l'équipe, si vous modifier quelque chose qui ne vient pas de l'équipe :

Vous leur imposez un rythme,
Vous leur manquez de respect : vous pensez qu'ils ne sont pas capables de s'engager seuls sur ce qu'ils pensent réaliser,
Et donc vous leur montrez que vous ne leur faites pas confiance.

La séance de coloriage est très ludique, elle permet à l'équipe d'avoir le même niveau d'information. Parfois certains membres de l'équipe découvrent qu'une fonctionnalité est terminée, et oui la communication est parfois difficile même avec les personnes qui sont à quelques mètres de vous
Et maintenant, laisser agir et rendez-vous à la fin de l'itération.

Le résultat à la fin l'itération 83

L'itération 82 a été terminée et nous avons refait le même exercice pour l'itération 83 :

La fonctionnalité A n'a pas été terminée pour une raison technique (ce point a fait l'objet principal de la rétrospective de l'itération 82),
Nous avons terminé G et presque terminé H,
Et nous avons fini la consultation de C.

Oui certaines fonctionnalités n'ont pas été terminées mais d'autres le sont ou bien elles ont plus avancé que prévu.

En conclusion

L'engagement de l'équipe de développement n'est pas un engagement millimétré ni même chronométré.
L'engagement de l'équipe n'est pas discutable même si c'est tentant de vouloir "challenger" l'engagement de l'équipe : Ne le faites pas.
Cette feuille est affichée sur un mur bien visible, elle permet à tous les acteurs du projet de savoir où en est l'équipe de développement.
Par tous les acteurs j'entends :

Les développeurs,
Mais aussi le PO, qui sait ce qu'il peut tester, qui sait ce quelles Users Stories et quels tests fitenesses il doit rédiger,
Ainsi que tous les autres acteurs qui gravitent autour du projet (Manager, métier, ingénieurs systèmes,...)

Il n'y a aucune raison d'utiliser ce document pour blâmer l'équipe ou leur mettre une quelconque pression durant l'itération.
Ce document est la feuille de route de votre équipe et vous constaterez qu'ils feront ce qu'il faut pour atteindre l'objectif.

Acceptez que certaines itérations seront plus légères que d'autres car il y aura des tâches techniques mais cela est important pour votre produit : le refactoring est un investissement et comme tout investissement le retour peu être plus ou moins long.

Notez qu'il n'y a aucune couille accrochée sur ces documents

Hier j'ai (encore) tué un super héros

Cyrille — Sun, 14 Oct 2012 20:31:00 +0100

Je n'aime pas les super héros, il y a un peu plus d'un an j'écrivais : "Supprimez les super-heros", aujourd'hui je vais vous présenter une scène sur un plateau d'un projet avec :

Brenda: une développeuse
Brendon : Notre ingénieur système

Disclaimer

Je ne voudrais pas que les personnes avec qui je travaille/j'ai travaillé pensent que je parle de leur(s) voisin(s) de bureau !

Les personnages et les situations de ce billet étant purement fictifs, toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite

Le problème

Je trouve que depuis quelques temps tout se passe trop bien sur le projet, qu'il n'y a pas beaucoup de tâches de le bac rouge, je décide donc de passer une matinée avec Brenda, je suis à quelques mètres.
1h après mon arrivée j'entends : "Merde, plus d'espace disque, où est Brendon ? "
Je demande à Brenda de m'expliquer la situation :
Brenda : Facile, on n'a plus d'espace disque pour créer notre package
Moi : Ok et dans ce cas on fait quoi ? Brenda : Bah on appelle Brendon !
Moi : Ok allons chercher Brendon.

L'arrivé du super héros

Mais Brendon est déjà en train venir vers nous (rapide l'ingénieur système !)
Brendon : "oui, c'est quoi le problème ? "
Brenda : "on a encore plus d'espace disque pour notre package, donc pas de livraison, pas de tests etc..."
Brendon : "Ok je peux avoir ton clavier ? "
Et là je vois Brendon ouvrir une console Putty, saisir une IP et hop connexion en root.
Je vois défiler des commandes :

df -k
ls -lS | more
cd /tmp
etc...

et hop, je vois un "rm" et en moins de 2 minutes j'entends : Brendon : Voilà c'est réglé.
Brenda le remercie et Brendon saute sur l'occasion pour répondre : "Pas de soucis, vous me paierez un café à l'occasion."

Le débriefing avec Brenda

Alors Brenda qu'en penses-tu ?
Brenda : Rien, l'incident ne m'a interrompu moins de 5 minutes
Moi : Ok c'est vrai, il semble super efficace Brendon, mais cela arrive souvent les problèmes d'espace disque ?
Brenda : Oui de temps en temps, il y a trop de projets, trop de logs, je crois que la base de données aussi utilise aussi beaucoup d'espace sur un autre file system et je crois que Brendon a beaucoup de travail sur plein de chantiers donc l'espace disque ce n'est pas trop sa priorité.
Moi : Ok mais en 2012, on n'a pas le droit d'avoir des problèmes d'espace disque, cela serait quand même bien de ne plus casser notre ligne de production surtout avec un problème d'espace disque. Quelle taille il fait ton package ?
Brenda : 15 Mo
Moi : Ok et quel est le cycle de vie de tes packages ? nombre de créations ? combien tu dois en garder etc...
Brenda : On crée des packages à chaque commit que l'on déploie sur l'environnement de Dev par contre, on déploie tous les 2 ou 3 jours en intégration + le package d'itération que l'on doit garder, donc :

4 à 5 packages par jour,
Itérations de 2 semaines,
Au maximum, on a 5 versions à garder pour l'intégration,
Soit au Max : 50 packages par itération et 10 au minimum,
à 15Mo le package ça me fait entre 750Mo par itération au maximum et 150Mo au minimum,

Moi : Ok merci, nous avons toutes les informations nécessaires. Juste par curiosité, il reste combien de place sur le filesystème ou tu crées tes packages ?
Brenda : Il reste un peu plus d'1 Go donc dans un peu plus d'une itération on va se retrouver dans la même situation !!!!
Moi : Je vais aller payer un café à Brendon, je te tiens au courant.

Mon triple coup de boule rotatif avec cassage du tibia sans violence

Je suis donc allé payer un café à Brendon qui m'a expliqué sur le chemin de la machine à café qu'il était content de travailler avec Brenda, qu'heureusement qu'il était là car la dernière fois une équipe est resté planté toute l'après midi car il était en RTT...!!!
Moi : Mais tu ne penses pas que l'on pourrait éviter ce genre de problèmes ?
Brendon : oui on peut toujours s'améliorer mais il faudrait que l'on puisse avoir plus d'espaces disques et puis on ne va pas installer des Nagios sur tous les serveurs non ?

Moi : Ok mais cela serait quand même bien d'être alerté avant qu'il y ai un disque full ?
Brendon : Les développeurs me préviennent quand cela arrive, je ne vais pas passer mes journées à surveiller l'espace disque ?
Moi : C'est quel est ton rôle dans les équipes projets ?
Brendon : Installer les serveurs, régler les problèmes, je suis un peu celui que l'on appelle quand cela rien ne marche.
Moi : Ok, mais ça ne te plairait pas d'être le Monsieur qui fait en sorte que tout marche tout le temps ?
Brendon : Si mais si tout fonctionne, je ne sers plus à rien !

Etc etc et etc !!!

Mes agacements personnels

Brendon savait qu'il y avait un problème d'espace disque ou bien que celui-ci n'allait pas tarder à arriver, je suis presque convaincu qu'il attendait que cela plante pour intervenir...
Je dois être allergique aux personnes qui arrivent sur une console Putty pour taper des commandes ls, df, ls -ail, ls -l super rapidement pour montrer "leur maîtrise sous Unix/Linux".

Mais je pense surtout que le "fautif" n'est pas Brendon, mais son manager actuel et tous les managers qu'il a eu dans sa vie active : aucun ne lui ont expliqués que sont Job n'était pas QUE de régler les problèmes mais surtout de faire en sorte qu'ils n'apparaissent plus.
De plus, on retrouve un Anti-Pattern : "Si je ne sauve pas la planète, je n'existe pas, je peux donc perdre mon poste".

Ce besoin de reconnaissance est complètement légitime mais peu être réalisé d'une autre façon :

Communiquer sur les problèmes remontés de la semaine,
Communiquer sur l'avancement des chantiers d'amélioration identifiés (impacts, date de fin, ...)
Communiquer auprès des équipes projets sur les nouveaux processus,
Etc...

Brendon n'est plus que l'Homme qui règle les problèmes, c'est maintenant l'Homme qui fait aussi en sorte que les problèmes ne se reproduisent plus.

Conclusion : les solutions que Brendon a fini par mettre en place.

Installation d'un script de surveillance de l'espace disque pour le FileSystème de Brenda, disponible à cette adresse : http://www.cyberciti.biz/tips/shell-script-to-watch-the-disk-space.html

Ainsi qu'un script supprimant les fichiers plus vieux de 20 jours :

find /tmp/ ! -mtime -20 -exec rm {} \;

Cela nous a permis d'avoir du temps pour comprendre à quoi était utilisé l'espace disque, qui en avait besoin, combien, quelle consommation par semaine, etc...
Et Brendon a commencé à mettre en place des scripts pour protéger tous les projets.
Et maintenant, il a d'autres problèmes, il faut qu'il administre tous ces scripts, je pense qu'il va finir par utiliser un "vrai" produit afin de lui simplifier la vie, mais évènement exceptionnel : Brenda et son équipe n'ont plus eu de problème d'espace disque depuis plusieurs itérations

Hitler, Waterfall and Scrum

Cyrille — Sun, 14 Oct 2012 08:22:00 +0100

Encore une parodie du file "La Chute" mais cette fois autour de l'Agilité contre Waterfall
Quand Hitler découvre que ses ScrumMasters ont remplacé Scrum par du Waterfall, il devient dingue !
Enjoy !

Hitler, Waterfall and Scrum - YouTube

Développeurs mettez vos couilles sur le billot

Cyrille — Wed, 10 Oct 2012 21:07:00 +0100

En d'autres terme : "Développeurs engagez-vous !"
Mais attention :

Engagez-vous sur vos itérations et uniquement sur le contenu de l'itération suivante,
Et imposez vos conditions !!!

Pourquoi il est important que l'équipe s'engage sur une itération

L'engagement est la liste des Users Stories que l'équipe pense développer durant l'itération.
Cet engagement permet au PO de planifier ses présentations aux utilisateurs, de communiquer auprès de ses responsable, etc...
Mais l'engagement permet quelque chose de très important à mes yeux : de placer la barre à une certaine hauteur et de comparer à la fin de l'itération ce qui a été réalisé. A la fin de l'itération, vous avez 3 cas :

L'équipe finit au-dessus de l'engagement,
L'équipe finit au niveau de l'engagement,
L'équipe finit en dessous de l'engagement.

Personnellement, la seule chose qui m'intéresse est d'avoir de la matière pour la rétrospective de fin d'itération et avec l'engagement vous avez une situation que toute l'équipe partage et les questions que l'équipe doit se poser durant la rétro sont simples :

Est-ce que nous avons eu de la chance sur cette itération ?
Est-ce que nous pouvons penser que nous aurions pu faire mieux ?
Pourquoi pensions-nous que nous pouvions faire X stories alors que nous en avons fait Y ?
etc etc etc...

Comment définir son niveau d'engagement

Je considère qu'il faut 3 itérations pour que l'équipe trouve ses marques et arrive à être confiant sur son niveau d'engagement.
3 itérations ne veut pas dire 3 itérations de 2 semaines soit 1 mois et demi MAIS 3 itérations consécutives avec une équipe stable : tous les membres de l'équipe sont présents durant les 3 itérations, pas de semaine de congés, par de formation.

Lorsque l'équipe a trouvé ses marques, elle peut commencer à donner son premier engagement à la fin du planning game.
Ma demande auprès des équipes est très simple, elle se passe en 2 temps :

Pouvez-vous identifier les Users Stories que vous pensez être certain de livrer à la fin de cette itération ?
Maintenant, pouvez-vous identifier les Users Stories que vous pensez possible d'être réalisées si tout se passe très bien ?

Après quelques minutes d'échanges, de discussion, de mise en place d'hypothèses 2 listes apparaissent : les CERTAINES et les POSSIBLES.

Mon point le plus important est que l'équipe trouve ses marques et qu'elle ai confiance en elle, je ne cherche pas un engagement sur lequel elle va se planter, alors dans les débuts du projets je propose à l'équipe de prendre 80% des US CERTAINES pour que nous soyons certain de tenir notre engagement.
Ce 80% des US CERTAINES est généralement atteint et même dépassé, mais il permet d'entamer une logique positive dans l'équipe.
Bien sûr, tout le monde sait que nous avons communiqué 80% des CERTAINES mais cela permet de ne pas avoir une pression trop forte sur l'équipe.

Et quelques exemples de conditions (que vous pouvez exiger)

Maintenant il faut être honnête s'engager n'est pas aussi facile que cela, de plus s'engager est pour moi, un acte important pour l'équipe, celle-ci a donc le droit de lister toutes ses conditions, comme par exemple :
Nous équipes, sommes prêt à nous engager si :

Toutes les conditions des Users Stories sont testées dans les fitnesses
Les découpes des images à intégrer sont bien livrées ce soir et non dans 3 ou 4 jours,
Nous n'avons pas de méga réunions surprises mobilisant toute l'équipe,
Le PO est disponible tous les 2 jours afin de valider les Users stories développées et nous donner une feedback rapide,
Il n'y pas d'upgrade sur le serveur d'intégration et sur la base de données,
etc etc et etc !!!!

Ces conditions sont légitimes et doivent être prises en compte par tous les acteurs du projet.
Elles vous permettent aussi d'identifier tout ce qui peut ralentir votre équipe et donc ces conditions vous donnent des actions à mener pour sécuriser vos itérations :

Contrôler que les tests fitenesses sont bien renseignées, si non comprendre pourquoi le PO ne le fait pas,
Faire en sorte que les découpes des images arrivent 1 ou 2 jours avant le début de l'itération,
Comprendre l'origine des mégas réunions surprises,
Comprendre pourquoi le PO ne serait pas disponible pour tester les Users Stories ou comprendre pourquoi l'équipe a autant besoin de feedback régulier durant l'itération,
Pourquoi les environnements d'intégration sont indisponibles,

Votre rôle principale en tant que Manager d'équipe Agile ou même de Product Owner est de protéger l'équipe de développement contre TOUS LES PARASITES qui peuvent les perturber.

En conclusion

L'engagement permet à toute l'équipe d'échanger autour des difficultés qu'elle connait au début de l'itération, cet engagement permet d'échanger sur des cas concrets mais surtout il permet de créer un esprit d'équipe ce qui est le plus important.
Généralement, les équipes arrivent à trouver leur marques, définir leur temps de mou sur les itérations et cela permet de créer une relation de confiance avec le PO.
Au pire, si cela ne fonctionne pas, vous aurez un sujet pour votre rétrospective

Les 2 citations autour de l'engagement :

« La liberté n’est pas l’absence d’engagement, mais la capacité de choisir. »
« Tout engagement génère des compromis, et il est évidemment beaucoup plus facile de rester soi-même en ne faisant rien. »

Links of the week : October 1 to October 7

Cyrille — Sun, 07 Oct 2012 17:46:00 +0100

Here is a best of posts of this week on project management and agile

PMOT

What's Missing? http://t.co/6UOfxzcr
A Project Manager's Top 10 to a Successful Redesign http://t.co/KMrd9cPQ
Project Cost Planning and Management http://t.co/9OAbsbcb
5 Reasons Why Projects Fail http://t.co/5bT1XZMh
Managing Your Project Priorities http://t.co/SGbb3s0l
Are You an Assertive Project Manager? http://t.co/ypgZjnSR
Project Risk Is Essential http://t.co/HoFF4prY

AGILE

Using Story Mapping For Defining Business Requiremets http://t.co/vzkNJjnl
5 Steps to Introduce an Agile Tool http://t.co/DgQtfeyo
Becoming ScrumMaster http://t.co/LsKMffmU
Project Managers are Change Masters http://t.co/8qU1PJR3
Where Agile Starts http://t.co/WztiMGhG
Why Can't I Become Agile ? http://t.co/9ckvKLG5
Continuous Delivery Using Jenkins http://t.co/9s8Ovhxz
Writing a Fixed Contract for an Agile Project http://t.co/gHdH0QEf
Your Agile Transformation Needs to Start with a Quiet Phase http://t.co/hyPtmvb8
Can You Be Agile Without Teams? http://t.co/ym7IwZJu

On ne soigne pas une toux avec du laxatif

Cyrille — Tue, 02 Oct 2012 20:38:00 +0100

L'idée de ce post vient de cette blague (et d'un échange avec un client ) :

Le pharmacien voit un individu appuyé sur le mur. Il demande alors à son employé :
- "Qu'est-ce qu'il a ?"
- "Ah lui ? Il est entré c'matin pour acheter un sirop contre la toux. Y'en a plus en stock, je lui ai donc vendu une bouteille de laxatif."
- "Idiot, tu peux pas traiter une toux avec du laxatif !"
- "Bien sur que si, vous pouvez... regardez, maintenant, il n'ose plus tousser !!!..."

Voici des exemples de pratiques laxatives que l'on peut trouver sur des projets.

Les exemples

Partir en vacances en pensant que tous les problèmes seront réglés à votre retour
Ajouter des personnes sur un projet en pensant que cela permettra de tenir les délais
Négocier 1 journée auprès du PO (ou des utilisateurs) pour finir son itération
Refuser les congés de paternité d'un collaborateur qui vient d'être Papa pour tenir les délais
Engueuler un équipier dans l'OpenSpace pour se passer les nerfs
Accepter une augmentation du périmètre de votre projet (sans modification de budget et délai) car vous n'aviez pas l'énergie de dire non
Accepter qu'un collaborateur ai le droit d'arriver à 11h00 car c'est votre meilleur expert sur le projet
Envoyer un mail de 50 lignes et penser que tout sera plus clair maintenant
Pensez que tous les problèmes relationnels de votre projet sont réglés car vous avez fait un TeamBuilding un vendredi après midi

Le résultat

Oui ça marche, 24h ou 48h mais après c'est le drame !!!
Tous vos choix doivent être guidés par une vision à long terme, vous devez vous posez des questions comme :

Quelle sera cette situation dans 6 mois ?
Est-ce qu'il est plus facile de prendre cette décision maintenant ou dans 6 mois ?
Combien me "coûte" ce problème aujourd'hui et combien peut-il me coûter dans 3 ou 6 mois ?
Quelles sont les actions concrètes que j'ai mis en place, pour améliorer la situation dans 1 mois, 2 mois et plus ?

J'espère que la prochaine fois que vous aurez une petite pensé pour l'individu appuyé sur le mur lorsque vous aurez une décision difficile à prendre...

Links of the week : 24 september to 30 september

Cyrille — Mon, 01 Oct 2012 09:31:00 +0100

Here is a best of posts of this week on project management and agile

PMOT

What To Do When Your Project Is in Trouble http://t.co/201saJ8u
Project Management and Project Failure - Why your project may not be seeing 5 stars http://t.co/cEwAE5mW
Project Managers To Not Be Taken for Granted Be Brutally Honest http://t.co/CFfr8Wqz
Hard Boundaries - How to be a Project Leader Across Them http://t.co/xyl6M99r
One Thing That Leads to Project Success or Failure: Adaptability http://t.co/rdEZJ1yn

AGILE

The Flow Impact http://t.co/HOSgdtMI
Agile Enables Efficient Decision Making http://t.co/3bJfIsIh
When The Wheels Come Off Agile http://t.co/8JSOciBO
Agile 101: Tools http://t.co/VffyhyIw

8 raisons d'aller à BeMyApp

Cyrille — Sat, 29 Sep 2012 14:27:00 +0100

Ce Week-end se déroule un hackaton de 48h ça vous branche ? Le jury sera composé de bloggers techniques et l'évènement sera couvert par Influencia, une bonne occasion pour voir quelque chose de nouveau, de manger des pizzas grasses et de boire de la bière.

J'encourage particulièrement les 2 équipes suivantes :

BeMyGuest : Une appli pour partager des repas pour entreprise. Exemple typique : Maxence se propose de préparer des lasagnes pour 6 lundi, les premiers inscrits ont droit de les manger, et peuvent noter le repas...
CheckFood : On peut référencer sur son mobile tous les produits périssables de son frigo pour être notifié avant leur péremption pour les manger ou les donner.

1- Venez découvrir les bases de l'Agilité

Backlog, Storymap, point quotidien, itérations etc...
Bien sur, en 48h les itérations seront de quelques heures et non de 1 ou 2 semaines, mais ça vous donne un bon avant gout des principaux rituels.

2 - Venez demander aux équipes à quoi sert la colonne "TO VALIDATE"

3 - Regardez comment les 2 équipes d'Octo Technology livrent des applications à chaque commit

Après moins de 22h après le TOP départ : 14 versions de l'application sous iPhone ont été livrées et plus de 32 déploiements réalisés.

Merci Appaloosa !!!!

4 - Découvrez des équipes AUTO-ORGANISÉES

Pas de chef, pas de comité de pilotage, pas de comité projet... et pourtant ça marche !!!

5 - Ce n'est pas une réunion de GROS GEEK QUI PUE !

Sans commentaire

6 - C'est à côté de chez vous

L’appart SFR : 7 rue Tronchet, 75008 Paris
Et en plus le lieu est super classe.

7 - L'ambiance est studieuse mais ça ne se prend pas trop au sérieux

Chef, tu vois que l'on peut coder avec des Heineken !!!

8 - En Agile on fait de la doc

Mais on ne fait juste le nécessaire

Présentation des différentes applications : dimanche 30 Septembre à 18h00 !!!

Le TOP 10 des conneries que l'on peut voir lors des réunions d'estimation Agile

Cyrille — Sun, 23 Sep 2012 16:57:00 +0100

Connerie /kɔn.ʁi/ féminin
(Vulgaire) Fait d'être con, état de celui qui est con.
(Familier) Erreur ; acte stupide.
+
Réunion d'estimation (Planning Poker)
Une méthode ludique d'estimation, utilisées par de nombreuses équipes Agiles. L'équipe se réunit avec son client ou Product Owner. Autour de la table, chacun dispose d'un jeu de cartes représentant des valeurs typiques pour l'estimation en points d'une user story (Planning poker référentiel Institut Agile).

Mélanger le tout et regarder ce qu'il est possible de faire.

1/ Penser que 1 point = 1 heure

Bien sûr c'est tentant de détourner la "Suite de Fibonacci" comme ceci :
1 point = 1heure, 2 points = 2 heures, 8 points = 1 journée...
Mais soit vous faites vos estimations en points soit vous faites vos estimations en jour/homme mais vous ne mélangez pas les choux et les carottes.

2/ Chercher un ratio entre les points et les jours/homme

La scène : l'équipe estime la backlog en point et le manager (ou chef de projet) veut mettre cela dans son MS Project pour sortir un joli diagramme de Gantt mais bien sur MS Project ne sait compter qu'en jour/homme alors une petit règle de 3 et hop vos 6 itérations se retrouvent planifiées comme par ~~connerie~~ magie.
Une autre façon pour "embrouiller" votre manager est d'utiliser les tailles de T-Shirt (Cf : Réunion d'estimation : Enlevez vos t-shirts) là vous serez certain que cela ne rentrera pas dans un Gantt !

3/ Ne pas avoir 2 ou 3 repères pour les estimations

L'objectif des estimations en points est de faire de l'estimation par similitude et donc de comparer vos users stories avec d'autres Users Stories.
La meilleur façon pour le faire est d'avoir 3 Users stories de référence.
Vous comprenez pourquoi ne pas avoir de Users stories de référence est un non-sens.

4/ Changer de repères à chaque itération

Toutes les raisons sont bonnes pour changer les Users stories de référence :

l'équipe a été trop rapide,
l'équipe a été trop lente,
les nouvelles stories du backlog ne sont pas comparables avec nos stories de référence...

Mais changer de repère à chaque itération ne vous permet pas d'avoir une stabilité dans vos estimations.

5/ Confondre estimation et exactimation

ou confondre estimation et engagement Il n'existe que 2 façons de ne pas se tromper sur un chiffrage :

Attendre la fin du développement
Avoir déjà réalisé ce même développement dans les mêmes conditions (équipe, client, technologie et fonctionnalité)

Autant dire que cela n'arrive jamais.
Maintenant, soit vous accepter un chiffre qui est surement faux mais qui a été donné plus ou moins rapidement, soit vous patientez que le développement soit terminé.

6/ Prendre toujours la plus grosse estimation

Vous trouverez cet exemple dans les centres de service qui se sont engagés à un nombre de point par itération.
C'est la technique numéro 1 que j'expliquais dans un autre billet : Ma vélocité est plus grosse que la tienne

7/ Ne pas équilibrer le temps de parole de chacun

Dans toutes les équipes, il y a des introvertis et des extravertis, des timides et des bavards. L'objectif de l'estimation à plusieurs est d'avoir l'avis de tous les développeurs du projet et non pas uniquement les 2 ou 3 grandes gueules de l'équipe.

8/ Arrêter d'estimer quand on a atteint la vélocité

STOP, c'est bon on est FULL, on a fait 40 points à la dernière itération, et là on vient d'estimer plusieurs Users Stories pour un total de 41 points.
on fera les autres US à la prochaine itération.

Sans commentaire...

9/ Passer plus de temps à expliquer la Users Stories qu'à l'estimer

L'une des difficultés du PO est de présenter les US aux développeurs, la qualité rédactionnelle des US est un facteur important mais l'ordre dans lequel sont présenté les US aussi.
Si vous avez besoin de 10 minutes d'explication du contexte de votre US pour avoir une estimation en 30 secondes, Cher PO vous étonnez pas que ce qui est développé ne correspond pas à ce que vous avez rédigé.

10/ S'obstiner à estimer des Users Stories que l'on ne comprend pas

Après 3 heures de planning poker le seul objectif des participants à cette réunion est de quitter la salle (ce qui peut se comprendre !).
Alors le PO présente ces US et les développeurs ne font plus l'effort de comprendre mais juste l'effort de sortir le même chiffre pour en finir.

J'espère pour vous (et vos projets) que vous ne vous êtes pas reconnus dans un seul de ces cas.

J'espère aussi que le développeur de l'équipe de Benjamin Guimberteau s'est réveillé depuis