Petit rappel sur un principe agile : Avoir un rythme soutenable

Un collègue m’a envoyé récemment un lien qui vaut le détour. Un petit speech intéressant sorti par Bryan Dyson ex CEO de Coca-Cola.

Pour les non adeptes de la langue anglaise ou pour ceux qui n’auraient pas le courage ou le temps d’aller lire le lien ci-dessus, Bryan donne un conseil très pertinent :

« Travaillez bien pendant les heures et bureau puis partez à l’heure. Donnez vous le temps nécessaire pour votre famille, vos amis et sachez vous reposer. »

Dans son speech, Bryan compare la vie à un jeu de jonglerie où l’on doit garder en l’air les cinq balles de la vie : le travail, la famille, la santé, les amis et l’esprit.
L’analogie est très bonne, elle souligne notamment la nécessité de savoir tenir le bon équilibre entre votre vie personnelle et professionnelle.

Et si on en revient à l’Agile ?
Eh bien il s’agit d’un des 12 principes agiles :

  • Les processus agiles promeuvent un rythme soutenable

Autrement dit, tout les acteurs d’un projet doivent être capable de tenir le rythme indéfiniment. Se mettre régulièrement dans le rouge entraine toujours des conséquences. D’ailleurs tiens, c’était aussi le message de Philippe Houssin et Ralph Hyppolyte à l’Agile Tour 2010 : un bon travailleur, comme un bon sportif, a besoin de période de repos entre les efforts pour rester performant.

C’est d’ailleurs un piège classique pour certains décideurs qui ont souhaité passer à l’Agile mais qui en ont « oublié » ces principes fondamentaux.

Et vous, proche du nervous breakdown ou bien avez-vous su trouver le bon rythme de croisière ?

 

Transitions agiles, où en sommes nous ?

VersionOne vient de sortir son étude annuelle sur l’implantation des méthodes agiles dans les entreprises.

http://www.versionone.com/state_of_agile_development_survey/10/default.asp

Les résultats sont intéressants, je vous laisse les regarder. L’un de ceux qui m’a le plus amusé c’est le décalage entre les bénéfices attendus et les bénéfices obtenus (page 4 et 5).

Et si les chiffres ne sont pas forcément représentatifs, notamment sur le sol français, le taux d’adoption est relativement important, notamment dans les grandes entreprises.

Pour info, VersionOne est un éditeur qui propose un outil pour la gestion de projet orienté méthodes agiles.

 

 

Agile Tour 2010

Voilà, c’est fait, j’ai participé à l’Agile Tour 2010.
Je suis arrivé vers 8h30 vers Denfert Rochereau pour assister à la présentation et au mot des sponsors. La session était dirigé par Patrice Petit fondateur de l’Agile Tour.
Bon ok, on apprend dans cette introduction que l’informatique est en cours de changer le monde actuel et que l’agile en y introduisant l’humain est en passe de révolutionner l’informatique. Un peu présomptueux peut-être, l’informatique n’a pas attendu l’agile pour parler de l’humain ^^
Enfin bref, début du marathon à 9h00.

… 

 

Euh, l’agilité finalement c’est pas un peu une secte ?


Provocateur comme titre ? Pourtant, après une rapide petite recherche Google je constate que je ne suis pas le seul à le penser.

En 2009, sur le blog Valtech, Thierry Girodet plaisante sur le parralèle entre Agilité et secte et sur le blog d’une certaine Aline, suite à l’Agile Tour 2008 de Grenoble petite citation :

oh mon Dieu, là on a peur d’être tombé dans une secte bizarre !
et on n’en est pas loin…

Et effectivement parfois on se demande…

Déjà en agile, on dit « en agile on dit que »
Dans les méthodes traditionelles, on ne dit pas « en cycle en V on dit que »

En agile on a l’Agile Tour
En cycle en V (vous voyez, c’est pas naturel), on n’a pas le Cycle en V tour (ou alors je suis pas au courant)

D’ailleurs en agile, l’Agile tour est là pour promouvoir un mouvement agile (et c’est gratuit)
En cycle en V on n’imagine pas un truc gratos qui serait la pour promouvoir (pour le compte de qui d’ailleurs ?) la gestion de projet traditionnelle

En agile on a des agilistes.
En cycle en V on a des informaticiens.

En agile on parle de rythme soutenable
En cycle en V faut pas déconner, on finit à l’heure et puis c’est tout.

En fait en agile on évoque la vie après le boulot, oui il y en a une !
En cycle en V la seule fois où on évoque la mort c’est dans le bilan post mortem du projet. Il y a un projet après le projet…

En agile on parle d’individus et de fun
En cycle en V on parle de ressources qui doivent réaliser un projet, point.

En agile on a des évangélistes.
En cycle en V on a… je sais pas, je vois pas l’équivalent.

En agile on a des coachs agiles (oui oui, un coach, comme dans super nanny)
En cycle en V on a des PMO

En agile on a des facilitateurs
En cycle en V on a des managers

En agile on fait partie d’une communauté
En cycle en V, euh, non. Déjà on bosse ensemble, on va pas non plus partir en vacances ensemble

En agile on a des stars (Jeff Sutherland, Mike Cohn, Claude Aubry)
En cycle en V on a des références (mais dont personne ne parle)

En agile on a un manifeste (pour rappel, Cf. Wikipédia : Issu du latin manifestus, les premières occurrences du mot « manifeste » en français sont attestées au XIIe siècle, dans le vocabulaire de la théologie)
En cycle en V… vous me voyez venir ?… Ben il y a rien.

En agile on fait des blogs
En cycle en V on fait des articles

En agile on fait des dojos
En cycle en V on fait des ateliers de travail

En agile on fait des jeux dans les formations
En cycle en V, ben on bosse quoi…

En agile, on y croit ou pas
En cycle en V, on adhère ou pas

En agile on se convertit aux méthodes
En cycle en V on se forme

En agile on cite parfois des écrits, « Saint Jeff a dit ceci, révision 3 du manuel Scrum chapitre 4 ».
En cycle en V on parle du PMBOK édition 4

Bon bref, j’arrête là.

En tout cas même si j’aborde le sujet avec dérision, il y a quand même une message derrière tout ça. Il existe un côté communautariste (qui a dit génération Facebook ?) et dogmatique dans les méthodes agiles avec ce manifeste, ces évangélistes, son vocabulaire pour les initiés et évidemment comme tout dogme, le risque est parfois d’oublier de prendre du recul.
Et comme dans tout dogme, le risque c’est de susciter le rejet. Vous avez déjà entendu parler d’informaticiens qui rejette les valeurs du cycle en V ? Moi pas, par contre il y a bien des réfractaires à l’Agile (des paiens ?).
Parmi les personnes qui rejettent ces méthodes, on entend parfois, « je n’y crois pas ». Ah bon ? C’est une question de croyance ? Eh oui, l’agile insiste sur le rôle des individus et leur engagement. Pas quelque chose d’aussi tangible qu’un recueil d’expressions de besoins, c’est sûr. D’ailleurs même moi je suis sceptique, pourquoi une personne faisant ce métier de façon alimentaire depuis 10 ans changerait subitement d’état d’esprit parce qu’il « bosse en agile » ?

Une phrase surprenante entendu aujourd’hui en conférence Agile :
« L’agilité favorise l’auto-exclusion »

Ah ok, cette fois c’est clair, en fait si l’agilité ne vous a pas changé, c’est à vous de partir.

Pourtant dans une autre conférence aujourd’hui, une autre personne disait « il faut de tout pour faire un monde, des créatifs, des méthodiques, des séniors, des juniors etc… » Ah ouf, cette fois j’adhère un peu plus. J’ai du mal à concevoir qu’on puisse exclure des personnes sous prétexte qu’elles ne rentrent pas dans le dogme.

Bref, petits conseils :

  • Prenez du recul : Si Saint Jeff a dit, c’est pas pour autant que c’est parole d’évangile. La dernière fois sur une liste de diffusion je lisais quelqu’un qui conseillait des sprints de 2 semaines car c’est le temps optimale d’après la dernière édition de Scrum. Pas parce que c’était adapté au contexte, mais parce que c’était écrit dans un livre !! Adaptez pour vous !!

 

  • Faites attention au vocabulaire employé : Ca vous fait peut êtrer marrer ce vocabulaire (perso je le prends au second degré) mais ce sera pas le cas de tout le monde.

Et rappelez vous… On ne fait que de l’informatique…

 

L’agilité est elle réservé aux projets JAVA ?

Titre provocateur n’est-ce pas ? Pourtant je reviens de l’agile tour 2010 et j’ai pu remarquer qu’une grande majorité des intervenants provenait du monde Java. Alors quoi ? Cette technologie est plus propice à l’agilité ?

En fait en poussant plus loin je suis allé voir les blogs des principales boites que je connais qui prônent l’agilité.

Xebia : pour eux pas de débat, le blog s’intitule J2EE, Agilité et SOA.
[email protected] : cette fois c’est Agilité, J2EE et .NET. Il y a un peu plus de sujets sur JAVA mais pas de façon trop flagrante (16 contre 13).
Octo : En regardant le nuage de tag sur la page d’entrée du blog, on voit une seule entrée pour .NET. Par contre JAVA a plusieurs entrées : Maven, Spring, GWT etc…
Valtech : pas de parti pris cette fois-ci, les thèmes du blog inscrit sur la première page ne parle ni de .Net ou de Java mais d’architecture. Par contre en feuilletant les deux premières pages de ce thème, je n’ai trouvé qu’un seul sujet sur .Net et plusieurs sur JAVA.

Je n’ai pas particulièrement d’explication sur le sujet et je ne sais même s’il s’agit d’une spécificité française. Mais l’agilité semble bien plus souvent associé à JAVA. Son côté communautaire ? Ses multiples frameworks open source ? Le fait qu’un grand nombre d’outils orienté pratiques d’ingenierie (Junit, Bamboo, TeamCity, Sonar, Hudson, Maven etc…) sont souvent issus du monde Java ?

Et vous, votre avis là-dessus ?

 

 

Réussir une transition agile, pas si simple

Les méthodes agiles gagnent en popularité ces dernières années. Elles ont su séduire les entreprises par leur capacité à s’adapter à un marché mouvant, leur force reposant sur l’acceptation des changements. Elles ont aussi su séduire les équipes de développement qui y voient une valorisation de leurs compétences et une mise en avant des bonnes pratiques d’ingénierie.
Cependant adopter ses méthodes est bien souvent un exercice périlleux. Une transition mal abordé peut entrainer un rejet pur et simple des valeurs agiles.

Je vous propose un petit tour d’horizon des différentes façons d’aborder les transitions agiles avec l’aide de retours d’expériences glané à droite à gauche et j’aborderais mes propres retours d’expérience au dernier chapitre.

… 

 

Attention aux habitudes

Vous connaissez le théorème du singe ? Wikipédia nous en donne un résumé sur cette page.

Si la comparaison avec la culture  d’entreprise peut paraître un peu sauvage, elle n’en reste pas moins intéressante. Et si on veut faire le parallèle avec les bonnes pratiques projets :

  • avec des réunions de rétrospective on analyse et on tend à corriger nos actions. On remet en question nos habitudes
  • en lean management, on parle aussi de la recherche des causes profondes : évitons de traiter les problèmes en surface mais cherchons les causes profondes du problème pour qu’il n’arrive plus (pourquoi faisons-nous ça déjà ?)

En résumé, attention aux habitudes !

 

Retours d’expériences agile et lean

Les retours d’expérience sont bien souvent le meilleur moyen de discuter de la pratique agile. En fait ils sont mêmes nécessaires car le cadre agile est volontairement très léger. Se contenter de lire les principes Scrum laisse souvent perplexe une personne qui aurait décidé seul de s’y mettre.

Bref, pour l’inspiration sur les pratiques à mettre en place, voici quelques retours d’expériences trouvés sur le net :

Et pour le lean :

 

Prenez garde au référentiel !

Prenez garde au référentiel !!

Vous vous souvenez de vos cours de physique lorsque vous étiez au Lycée ? On y parlait de référentiel. L’idée étant que selon le référentiel selon lequel on se plaçait la mesure était différente.
L’exemple le plus courant était celui du voyageur immobile dans un train selon les yeux d’un autre voyageur mais voyageant à 300km/h pour une personne qui observait le train.

Mais quel est le rapport avec l’agilité me direz-vous ? Eh bien le rapport c’est l’équipe projet dédié et colocalisé !

« Colocalisation, référentiel… hum, je ne vois pas le rapport ? »

L’agilité insiste en effet sur les équipes dédiées et colocalisées comme facteur d’amélioration sur la communication et la collaboration. C’est un des prérequis majeurs pour faire de l’agile. Mais pourquoi être au même endroit implique donc une meilleure collaboration ? Eh bien justement, tout est question de référentiel. En partageant le même référentiel, les acteurs partagent plus facilement la même vision du projet.

A l’inverse, conserver des équipes organisées par silos qui s’assemblent et se désassemblent à la demande c’est l’assurance de conserver des référentiels différents. Et qui dit référentiel différent dit conflit, car on ne partage pas le même but, les mêmes contraintes. Que ce soit sur l’organisation des priorités ou des bonnes pratiques, ce type d’organisation va régulièrement favoriser le conflit entre équipes.

Avoir le même référentiel c’est l’assurance :

  • de partager une vision commune du projet
  • de partager les mêmes contraintes et les mêmes priorités
  • de partager l’info sans déperdition
  • de comprendre les préoccupations de chacun

A un niveau plus personnel, la capacité à entrevoir les différents référentiel c’est aussi la base du travail du facilitateur, le fameux Scrum Master. C’est justement cette faculté à entrevoir les situations selon différents angles qui lui permettent de favoriser les liens entre individus.


Pour aller plus loin :
Convaincu mais esseulé ou pas convaincu, je vous invite aussi à lire le bloc d’Octo qui aborde la colocalisation selon un autre angle : la transmission de l’information.

 

 

L’informaticien, artisan des temps modernes ?

Je viens de lire à l’instant un billet sur l’informatique et un parrallèle avec l’artisanat. C’est un sujet qui revient souvent. Mais peut-on comparer notre métier avec la pratique de l’artisanat ?

Personnellement je ne le pense pas, notre métier peut couvrir un large spectre, du technicien spécialisé à l’expert dans son domaine mais en aucun cas je ne le comparerai à de l’artisanat.

Allez, je vais tenter un petit billet sur le sujet.

…