Le jeudi 11 avril s’est tenue la troisième édition du Scrum Day, un événement organisé par le French Scrum User Group (ou FSUG) autour de l’agilité.

Avant d’aborder mon compte rendu, je tiens à remercier chaudement la société Zenika qui m’a permis d’assister à cette conférence. En tant que sponsor de l’événement, elle a proposé de gagner une place avec un peu jeu concours sur Twitter. Et c’est moi qui ai gagné \o/ Donc merci à eux.

Pour nous accueillir, Xavier Warzee débute avec un discours d’ouverture où il rappelle ce qu’est le FSUG, ses activités, son bilan. Il fait également venir les sponsors sur scène, pour une courte présentation. Puis il laisse la main à Robert Richman…

Keynote “Culture Hacking”

La journée commence vraiment avec la keynote de Robert Richman. Il travaille dans le département Zappos Insights de la société Zappos, l’un des leaders de la vente de chaussures sur Internet (eh oui), aujourd’hui rachetée par Amazon.

Il se définit comme un Culture Hacker, il est également l’auteur du livre Culture Blueprint. Il nous incite ainsi à comprendre comment fonctionne une culture d’entreprise, de groupe, etc. Il débute en nous racontant une petite histoire à propos du Burning Man. Il s’agit d’un rassemblement culturel et artistique qui a lieu chaque année dans le désert du Nevada, où se cotoient plusieurs dizaines de milliers de personnes. Cette rencontre pourrait s’apparenter à un chaos total, pourtant les gens s’y retrouvent avec bonne humeur, et une harmonie certaine. Le succès tient entre autres à un ensemble de règles régissant la communauté :

• Inclusion radicale : tout le monde est le bienvenu.
• Pratique du don : pas d’argent, tout se fait par des cadeaux, des prestations, des dons.
• Décommercialisation : pas de publicité, pratiquement aucune transaction financière.
• Auto-suffisance médicale.
• Expression de soi radicale, poussant ainsi les participants à s’exprimer sous des formes variées, en particulier à travers des oeuvres artistiques.
• Effort en commun, où l’on favorise le travail d’équipe.
• Responsabilité civique.
• Pas de trace : malgré le grand nombre de participants et des manifestations, l’endroit doit être rendu tel qu’à l’origine. Le respect de l’environnement est omniprésent.
• Participation.
• Culture du moment présent.

Robert Richman parle également de l’ouvrage ”Tribal leadership”, de Dave Logan, où il est montré l’importance d’avoir une liste de règles pour qu’une communauté - ou une tribu - puisse fonctionner. Il nous montre qu’à Zappos, où il travaille, il est également établi une liste de règles, définissant les valeurs communes de leur “famille” :

• Deliver WOW Through Service
• Embrace and Drive Change
• Create Fun and A Little Weirdness
• Be Adventurous, Creative, and Open-Minded
• Pursue Growth and Learning
• Build Open and Honest Relationships With Communication
• Build a Positive Team and Family Spirit
• Do More With Less
• Be Passionate and Determined
• Be Humble

L’ambiance à Zappos transparait dans l’excentricité des open spaces

Robert Richman nous pose une question. Ne pourrait-on pas considérer qu’une culture est aussi un produit ? C’est un peu pour cela qu’à Zappos, ils créent des événements pour “promouvoir” leur propre culture. Il ajoute quelque chose qui est tout à fait vrai : parfois, lors de ce genre d’événement, on est satisfait par l’information que l’on en tire, mais c’est avant tout l’expérience que l’on vit qui est fantastique (Information is OK, but experience is amazing). Quand il a dit ça, j’ai tout de suite pensé à ma propre expérience à Devoxx : j’en tire beaucoup d’informations intéressantes, mais c’est vraiment l’expérience de la conférence elle-même qui reste un souvenir fantastique.

Robert Richman nous fait maintenant une petite liste de Culture Hacks :

• How to walk into a room can shift a culture. Lorsque l’on entre dans une pièce, il faut montrer son assurance, son énergie de façon à pouvoir faire la différence, créer une synergie.
• Destroy something. Détruire est tellement plus puissant que créer, et cela apporte de l’énergie. Il faut détruire quelque chose d’inutile ou qui ne marche pas.
• Frustration is gold. La frustration n’est jamais que de l’énergie bloquée.
• Use ritual for energy. Robert Richman nous explique que des petits rituels peuvent créer de l’énergie au sein d’une équipe. Il nous explique qu’à Zappos chaque jeudi à 15h, tout le monde arrête de travailler pendant 10 minutes… pour danser ! C’est la 3PM Thursday Dance Party.

Pour finir, il nous rappelle que Scrum lui-même a ses propres valeurs :

• Focus
• Engagement
• Respect
• Courage
• Ouverture

J’ai adoté cette keynote pour son côté énergique et rafraichissant. De façon générale, les orateurs américains ont un vrai sens du show, et ce n’est pas Robert Richman qui me fera penser le contraire. J’ai aussi beaucoup aimé la façon dont il a pu nous transmettre l’ambiance qui règne chez Zappos.

---

Introduction au leadership tribal

Florent Lothon est coach agile pour CSC (site agiliste.fr). Il nous parle du Leadership Tribal, tiré d’un livre éponyme. Cela fait une bonne transition avec la keynote précédente.

A l’origine, il y a une étude, menée pendant 10 ans sur un panel d’environ 24,000 personnes. Cette étude s’est concentrée uniquement sur deux aspects : le langage et le comportement des personnes étudiées, considérant que les mots que l’on utilise influencent directement notre comportement. Cette étude a permis d’établir cinq stades, et donc cinq discours associés, au sein d’une tribu. Mais avant d’aller plus loin, il est nécessaire de définir ce qu’est une tribu.

Une tribu est un groupe, une organisation de 20 à 150 personnes qui se connaissent suffisament pour se saluer quand elles se croisent. Une petite entreprise est une tribu, tandis qu’une société de taille plus importante est une tribu de tribus.

Les cinq stades

1. La vie est nulle (~ 2%). Ces persones vont avoir un comportement de sabotage et un type de relation d’exclusion.
2. Ma vie est nulle (25%). Ces personnes, plutôt isolées se posent en victimes passives. Florent cite la bande dessinée Dilbert comme exemple.
3. Je suis génial (sous entendu “pas les autres”) (49%). À ce stade, on rencontre plutôt des guerriers solitaires ayant une tendance à la domination personnelle.
4. Nous sommes géniaux (mais “pas les autres”) (22%). À ce stade déjà très élevé, les membres ont une fierté tribale, et établissent des partenariats stables.
5. La vie est géniale (< 2%). Le comportement de ces personnes est un émerveillement innoncent, et forme une véritable équipe. À un tel niveau, l’énergie de la tribu rayonne au delà de leur cercle, et “contamine” les personnes alentours. Florent nous cite l’histoire de Matt, un anonyme qui a filmé ses scènes de danse au quatre coins du monde. Florent rebondit aussi sur la keynote précédente en citant Zappos comme exemple de société de niveau #5.

Les leviers d’évolution

Au delà de ce constat, la question que tout le monde se pose est de savoir comment on peut passer d’un niveau à l’autre ? Une chose importante est de savoir qu’il ne faut pas sauter des étapes. On ne pourra pas passer du stade #1 au stade #3 sans passer par le deuxième stade, car chaque stade se base sur les acquis du précédent.

1. Du Stade #1 au stade #2. Les principaux leviers à ce stade sont les suivants :
2. Il faut aller là où est l’action : participer à des réunions, des conférences, ou simplement aller déjeuner avec les gens.
3. Se convaincre que la vie peut fonctionner, même pour soi.
4. Se couper des autres personnes qui stagnent à ce stade #1.
5. Du Stade #2 au stade #3, les leviers sont :
6. La création des relations dyadiques (2 personnes).
7. Souligner les compétences et les forces des personnes.
8. Proposer des projets à court terme avec une forte probabilité de succès, et qui nécessite peu de suivi.
9. Du Stade #3 au stade #4. À ce niveau-là, les personnes ont appris à se faire confiance, mais ils ont tendance à vouloir conserver un certain nombre d’informations pour eux, pour garder une sorte de pouvoir. On pourra tenter de les élever au stade supérieur ainsi :
10. Encourager des relations triadiques (3 personnes), et dont le succès nécessite un partenariat fort.
11. Faire comprendre que le vrai pouvoir n’est pas dans les connaissances, mais dans les réseaux.
12. Forcer la transparence grâce à une communication à outrance, plutôt que de n’y avoir recours qu’au besoin, en se limitant au strict nécessaire.
13. Du Stade #4 au stade #5. Au stade #4, le niveau est déjà élevé. Pour atteindre le nirvana, le stade #5, des leviers ne suffisent plus, il faut mettre en place une stratégie. Celle-ci doit résulter de la tribu dans son ensemble, selon le contexte, et non seulement d’une personne, d’un leader. La stratégie est celle-ci :
14. Définir les valeurs fondamentales de la tribu. Ce sera la moteur de la stratégie.
15. Les résultats : que voulons-nous atteindre ?
16. Les actifs : qu’avons-nous ?
17. Les actions : qu’allons nous faire ?

Image de Florent Lothon, http://www.agiliste.fr

Florent termine la présentation par une citation tirée du livre de Dave Logan :

Alors que les leaders tribaux travaillent pour le bien du groupe, non pas pour eux même, ils sont récompensés par la loyauté, le travail acharné, l’innovation et la collaboration. La tribu produit un travail de la plus grande qualité en moins de temps. […] L’avenir de l’entreprise est le stade 5.

Juste avant de nous laisser, il nous parle du 21 days challenge, une sorte de challenge à réaliser en 3 semaines. L’idée est de regarder une petite vidéo chaque matin, qui va nous lancer une sorte de défi dont le but final est de faire de nous un meilleur leader. Il cite un exemple de défi : aller voir 3 personnes dans son entourage professionnel, et demander ce qu’ils pensent de nous, de notre réputation.

A lire, le billet sur son blog retraçant cette présentation et sa présentation sous Prezi

---

Transition agile dans une grande banque européenne à l’aide des Innovation Games

Catherine Boudlal et Xavier Warzee de Palo-IT nous raconte comment ils ont mis en place l’agilité d’une grande banque (non, ce n’est pas la mienne ;o)) grâce aux Innovation Games. La situation est simple lorsqu’ils arrivent chez le client : l’agilité est totalement absente, mais ils veulent la mettre en place afin de pallier à leurs problèmes récurrents sur les développements, les mises en production, etc. Hélas, cela doit se faire en peu de temps (quelques semaines tout au plus). Xavier et Catherine décident donc d’opter pour les Innovation Games afin d’engager le processus de transformation agile. Les étapes sont les suivantes :

• Collecter des informations sur la situation actuelle, sur les blocages.
• Démarrer la transformation agile.
• Faire émerger de nouvelles organisations agiles.

Les jeux (qui sont appelés “ateliers” auprès du management, ça passe mieux !), sont les suivants :

• SWOT. Le principe de SWOT est l’identification des forces, des faiblesses, des opportunités et des risques. Ils ont ainsi pu collecter des informations sur les pratiques, identifier les problèmes et processus des développements. De ces informations sortent des recommandations, telles que la mise en place de l’intégration continue et d’autres outils, de la réorganisation des équipes et des espaces de travail, la définition de KPI simples, etc.
• 20/20 vision. Le but est d’apprendre à prioriser des fonctionnalités. Ainsi, on peut définir des sortes de lois, qui établiront un chemin commun vers l’agilité (cf http://guide.agilealliance.org/subway.html).
• $100 test. Grâce à ce jeu, Xavier et Catherine ont pu mettre en place la transformation agile d’une équipe, et améliorer le fonctionnement de cette équipe en tant qu’équipe, et non plus en fonction d’individualité ou de coeur de métier.
• Graphic Gameplan. Ici, l’intérêt est de trouver les blocages, et de définir les étapes qui permettent de les résoudre.

Xavier et Catherine nous ont aussi parlé de la façon dont les participants ont réagi par rapport à cette approche “ludique” de l’agilité. À part une poignée d’irreductibles, il semble que la grande majorité des personnes présentes lors de ces “ateliers” a apprécié la démarche et a joué le jeu.

Au final, cette session était un retour intéressant, mais avec un bémol. Ils nous expliquent qu’une fois ce stade des IG terminée, ils ne sont pas restés dans la société (une autre entreprise a pris la suite). Du coup, nous n’avons pas pu savoir si cela a vraiment porté ses fruits, si l’agile a bien été adopté, et quel niveau de maturité pouvaient avoir les équipes aujourd’hui.

---

Transformation à grande échelle, 18 mois plus tard… (SGCIB)

J’assiste donc à un retour d’expérience sur la transformation agile à la SGCIB, société que je connais plutôt bien :) Celle-ci nous est racontée par Clémo Charnay et Myriam Roux de la SGCIB ainsi que de Céline Stauder, coach agile chez Coactiv.

Ils nous présentent donc l’histoire de la transformation agile qu’ils ont initiée à la SGCIB pendant plus d’une année dans un service gérant environ 70 applications. Tout commence par un constat : le service informatique est en perte de contrôle du SI. Les mises en production sont sans cesse décalées, la qualité n’est pas au rendez-vous, et la complexité omniprésente. Ainsi, une demande peut faire intervenir jusqu’à 7 équipes différentes !

Ils commencent par mettre en place 2 PoC :

• Le premier se fait dans un contexte favorable, où le projet démarre de rien, et où il est ainsi beaucoup plus facile d’y intégrer des notions d’agilité (TDD, intégration continue, etc.). Le succès est au rendez-vous.
• Dans la deuxième équipe, les choses sont plus compliquées, car le contexte est une application legacy - essentiellement de la maintenance ou du catalogue. Ici, le succès est plus mitigé, comme on pouvait s’y attendre.

La mise en place de l’agilité permet de passer d’un rythme de 4 releases par an à une presque tous les mois. Toutefois, si cela peut paraitre une bonne chose, elle est aussi un défaut. En effet, cela implique une plus forte charge pour les équipes, et cela implique une certaine fatigue.

Les trois présentateurs soulèvent 4 points importants à prendre en considération durant une transformation agile :

• Il faut savoir gérer les demandes du support. Le ”Production first” ne doit absolument pas devenir le ”Production only”. Il faut savoir faire la part des choses.
• Faire attention aux process de release, parfois (souvent ?) trop lours.
• Le découpage d’un projet est souvent orienté coûts plutôt que valeurs.
• Il faut savoir prendre du recul, et se demander pourquoi on fait certaines choses.

Au final, il y a une vraie prise de conscience que l’agilité est un plus. Mais il faut savoir comment la mettre en place. L’un des avantages de l’agilité, qui pourrait être vu comme un défaut par certains, est qu’elle a tendance à mettre en lumière des problèmes.

Les orateurs finissent par citer quelques problèmes rencontrés lors de cette transformation :

• L’organisation même d’ITEC, qui impose certaines limites, en particulier au niveau des budgets.
• Pas de reconnaissance ni de valorisation des profils agiles par les Ressources Humaines (peut être anxiogène pour certains).
• La mise en place de beaucoup de chantiers dont beaucoup ne sont pas terminés est un processus épuisants.

Voilà un retour d’expérience assez classique, rien de bien nouveau sous le soleil au final.

---

Mon DSI veut un indicateur sur l’agilité : Cadeau ou Poison ? (REX Total)

Yann Poles travaille pour Total, et nous raconte son expérience sur la mise en place de l’agilité chez eux. La DSI y est assez importante, puisqu’elle concerne un millier de personnes pour environ 200 projets par an.

En 2011, c’est le début de l’agilité chez Total, avec une vingtaine d’expériences plutôt concluantes. Toutefois, on reste dans une situation où le management laisse faire.

En 2012, suite à une réorganisation importante, de nouvelles ambitions sont présentées. Parmi elles, il y a ce chiffre de 50% de projets agiles d’ici 2017. Très bien, mais ce chiffre, que veut-il dire ? Que mesure-t-il ? Le souci est là justement : avec un tel indicateur, il n’est pas possible d’évaluer le degré de maturité de chaque équipe, leur niveau d’efficacité, de vélocité.

Chez Total aussi la transformation agile pose une question importante : comment faire ? Les équipes sont perplexes, les managers, qui ne trouvent pas leur place dans l’agilité, sont bousculés.

Les changements apportés par l’agilité vus par l’équipe :

• Travailler en équipe.
• Prendre des risques.
• S’engager.
• Être visible.
• Être autonome dans la prise de décision.
• Savoir se remettre en question.

Du côté des managers :

• Accompagner le changement.
• Déléguer, donner de l’autonomie.
• Avoir une posture de Servant Leader.

Rendre visible cette transformation, c’est :

• Être plus exposé (dans ses réussites mais aussi dans ses échecs).
• Crainte de la course au label “Agile” (que le projet ait à tout prix le tampon ”Ici on est agile” sans forcément faire de l’agilité).
• L’échelle n’est plus la même : on touche de plus grande équipe.

Dernière question que pose Yann Poles : comment péréniser l’agilité, ancrer la transformation ?

• Du côté de l’individu, il faut recourir à un accompagnement, éventuellement des formations.
• Du côté de l’équipe, il faut investir dans la communauté IT. Savoir aussi mesurer et soutenir la vélocité, la fluidité, la réactivé, le moral des équipes, la satisfaction du client.

Il termine par une citation de Gandhi :

Vous devez être le changement que vous voulez dans ce monde.

Un dernier point, en résonance à la mesure du nombre de projets qui sont agiles chez Total. Yann, ainsi qu’une partie de l’assistance, pense qu’il serait plus pertinent de mesure non pas le nombre de projets, mais d’équipes agiles.

Un nouveau retour d’expérience. Je ne sais pas si c’est exactement ce que je m’attendais à avoir en venant dans cette salle, mais c’était tout de même intéressant.

---

L’organisation et bilan

C’était ma première participation au Scrum Day (c’était la 3^ème édition), et je dois dire que cela m’a plu, j’ai eu toutefois une préférence sur mes sessions du matin, en particulier de l’excellente keynote de Robert Richman. J’ai vu plusieurs retour d’expérience sur des transformations agiles au sein de grandes sociétés (dont la mienne !) et j’ai quand même un peu l’impression d’entendre toujours les mêmes discours. Tant pis.

Dans l’ensemble, l’organisation s’est bien déroulée, mais j’ai quand même 2 critiques à formuler. Premièrement, les locaux (merci à IBM pour les avoir fournis) n’étaient pas toujours adaptés, car certaines salles étaient trop petites pour profiter de certaines sessions, en particulier les ateliers. J’ai ainsi dû passer mon tour pour la session L’agilité selon Starcraft 2 à 12h45. L’autre reproche c’est peut-être un manque d’accompagnement des speakers et du cadrage des sessions. Certaines ont un peu débordé, ce qui fait que le timing n’était pas toujours respecté. Cela n’enlève en rien toutefois le travail formidable des organisateurs, et de leur travail bénévole.