Agilité : Le bonheur est dans le flux

Mihaly Csikszentmihalyi en plus d’avoir un nom imprononçables pour nous français (une petite aide ? « tchik-sainte-mi-aïe-i » … ), est un psychologue hongrois qui étudie et enquête sur l’«expérience optimale». Ces travaux ont révélé que ce qui rend une expérience véritablement satisfaisante est un état de conscience appelé flux.

Au cours du « flux », les gens ressentent généralement la jouissance profonde, la créativité et une implication totale avec la vie.

Dans son livre, Monsieur Csikszentmihalyi démontre comment cet état positif peut être contrôlé, et non, seulement laissé au hasard.
Il enseigne aussi comment l’expérience optimale, en ordonnant l’information qui pénètre dans notre conscience, peut permettre de découvrir (ou redécouvrir le vrai bonheur et grandement améliorer la qualité de nos vies.

Le flux concrêtement c’est quoi ?

Pour Csikszentmihalyi c’est un état psychologique.

De façon simple :
Imaginez un instant que vous êtes en chemin d’une pièce à une autre pour accomplir quelque chose et qu’en chemin la porte d’une pièce à l’autre se bloque à mi-parcours. Votre flux vient d’être interrompu, et vous en ressentez de la frustration, soudain vous prenez conscience que vous perdez du temps, et que cette fichu porte vous embête bien car elle vous fait perdre le contrôle sur votre action.
Imaginez que vous recherchez (peut-être comme moi) de façon continue de l’information, sur internet pour résoudre une problématique, et que soudain lors de l’affichage d’un sujet, une page met trois plombes et force jauges de progression pour s’afficher interrompant l’état extatique dans lequel vous vous étiez mis pour accomplir votre tâche. soudain votre temps vous parait non productif, inutile, vous vous sentez frustré.

Bon de façon plus scientifique en gros le flux ce caractérise par ces choses :

  • la dissociation temporelle ou la perte de la notion du temps ;
  • l’immersion ou la concentration totale dans une tâche ;
  • l’intensité du plaisir ;
  • le sentiment de contrôle de l’interaction ;
  • la curiosité sensorielle et cognitive.

En gros, le flow est un « underlying thinking » une forme de psychisme sous-jacent, de pensées en double voix, de concentration profonde et intuitive.

En grande partie, Mihaly Csikszentmihalyi explique que le flow peut principalement être atteint parce que la mémoire et les compétences se sont longuement et correctement construites et qu’elle sont confrontée au défi, au challenge, d’une réalisation.
Funders & Founders en on fait une représentation assez facile à comprendre :
flow 2

Mais quelle rapport avec l’agilité ?

Forcément, étant entourée d’agiliste (et en étant, modestement, une, moi-même) je n’ai pu m’empêcher de leur soumettre ce sujet et de les faire parvenir à la conclusion que l’agilité était une forme d’extension du Flow, à la réalisation d’un produit…
Et que donc, il était parfaitement possible de vivre un état de plénitude, lorsqu’un projet était réalisé grâce à cette pratique. (bon là ce sont mes conclusions personnelles, j’avoue)

Explication.

  • La méthode/ pratique agile a pour but de mettre à disposition de l’équipe de réalisation suffisamment (et en même temps suffisamment peu) d’informations et assez d’interactions avec le métier / client, pour que le déroulement de leur tâche se fasse sans l’interruption d’un manque d’information nécessaire mais surtout dans l’état de contrôle de l’intéraction
  • Aussi, le fait que l’équipe de réalisation dispose des informations qui permettent de vérifier la qualité et l’adéquation de sa réalisation avec le métier en même temps que les spécifications (les tests d’acceptation avec le backLog) permet, par l’immersion de provoquer l’état de flow, de bien être dans la continuité de l’action, mais aussi de contrôle et de pleine exploitation des potentialités et des compétences.
  • Le cérémonial agile sert comme une forme de Kata en art martial : plus on le pratique, plus on maîtrise la gestuelle et par conséquent, plus on est fluide et détendu en le faisant. C’est aussi une garantie de ritualisation, et de planification des interruptions dans le travail, pour parvenir à ne pas trop interrompre l’équipe de réalisation (leur permettant ainsi de rentrer dans l’état de flow)
  • L’ergonomie est une forme d’extension du flow. Produire un applicatif qui ne vous soumettra pas à des interruptions incessante vous aidera toujours mieux à accomplir ce que vous étiez venu faire dessus. L’agilité, qui offre la possibilité d’introduire du changement, par l’expérimentation et les démonstrations, apporte progressivement à l’utilisateur final l’expérience utilisateur optimale à son utilisation.

En conclusion, je ne sais pas si le bonheur est dans tous les flux*, Mais il est au moins dans celui de Monsieur Csikszentmihalyi et certainement dans celui de l’agilité.

*tampax

Weekly links (02) – Contractualisation Agile

 

Parce qu’on parle quand même beaucoup de contractualisation Agile et de son incompatibilité avec le modèle classique au forfait, voici quelques liens pour une lecture approfondie.

Agile Ruining fixed price contracts

http://www.contrat-agile.org/

Le contrat Agile par Agiliste.fr

http://alistair.cockburn.us/Agile+contracts

 

Ce qu’il en ressort en conclusion c’est que :

  1. Il faut définir un modèle de contrat agile, adaptable, mais utilisable, car sans contrat, l’adoption de l’agilité, par les sociétés structurées par une direction des achats, est ralentit voire se fait de manière chaotique.
  2. La facturation se fait en 2 temps :
    Un sprint 0 doit être facturé au réel, quelque soit sa durée, comme une simple régie, car il s’agit ici de faire les bons choix fonctionnels et architecturaux de départ et que cela peut avoir un impacte sur le long terme.
    – Puis, le reste des sprints peut être facturés au Sprint, avec éventuellement un facteur de pondération sur un mécanisme de prime basés sur un ensemble d’indicateurs dont (entre autres) : la qualité, la satisfaction client, la predictibilité…
  3.  Si le client veut toutefois avoir plus de contrôle que dans une situation agile régie pure, il convient peut-être d’appliquer le modèle de Bob Martin, qui rétribue la performance et la qualité en bonus, et fait perdre de la marge si des indicateurs ne sont pas atteints.
  4. L’équipe agile doit être sensibilisée au mode de contractualisation pour en suivre les indicateurs et s’améliorer en continue, le contrat agile doit donc se faire en co-construction avec le client et l’équipe en charge de la réalisation du projet.
  5. Un contrat agile doit engager le client, le risque doit être partagé. Car c’est trop facile de dire que la qualité n’est pas là, ou que des fonctionnalités ne correspondent pas à ce qu’on voulait en fait si on ne s’est pas impliqué dans le projet, ou qu’on a pas fournis les bons entrants à l’équipe pour travailler.
  6. Les projets agiles ne peuvent jamais vraiment être menés au forfait. Mais il ne ne faut pas faire abstraction de la visibilité budgétaire à donner au client afin qu’il puisse défendre son projet/produits à réaliser devant un conseil d’administration, ou des investisseurs…

Sinon il reste une solution, celle d’opter pour la zFactory…

Le modèle spotify

La première partie

et la suite

  • Les petites phrases à noter

Release should be routine not drama« 

La meilleure explication pour se mettre au DevOps à mon sens.

« We are fearless because fear kills innovation »

« If everything is undercontrol you’re going too slow »

« MVP is the minimum Lovable Product »

« things that are blocking us : what to do about it ? »

La recette pour éviter l’immobilité.

« Power comes from empowerment. »

Et pour un peu plus de matière je vous envoie au blog de Christope Addinquy : Free Thinker

Savoir ce que l’on peut faire amène à l’auto responsabilisation

Lors du premier jour du ScrumDayFr, j’ai pu assister (Comme peut-être certains d’entre vous) à une conférence que j’ai trouvée super intéressante !

« Reinventing organizations » par Michael Sahota et Olaf Lewitz
vous pouvez trouver le Slideshare de la présentation ICI

Cette conférence passionnante nous apprenait en substance que « Faire de l’agilité » différait d' »Être agile » (« Doing Agile =/= Being Agile« ) et qu’il y avait des différences fondamentales entre les pratiques agiles, et l’agile mindset. On comprend donc que au delà de la stratégie, et de la tactics, la culture d’entreprise occupe une place majeure dans le fait d’être agile.

When you listen to your guts how does it make a difference ?

Olaf Lewitz

« Small And localized changes leads to failure or limited success »

Michael Sahota

whereisagile
Il y présente un magnifique modèle de progression vers l’agilité.

On peut y voir par exemple que pour parvenir à l’auto-management (l’auto responsabilisation ou self management) il faut d’abord passer par l’octroi de plus de pouvoir aux individus ou aux groupes pour agir sur leurs conditions de travail (empowerment)

Knowing what you can do leads to self responsabilization

Olaf Lewitz

2. Ensuite une petite images qui n’était pas prévue à la présentation, mais qui a émergé des tables rondes organisées pour l’organisation. (désolée pour l’angle de vue pas terrible)

VAST-Cycle

Ce qui n’a pas manqué de me rappeler ce magnifique livre (et Ted Talk de Brene Brown)

3. Enfin les différents indices de mesures pour savoir où se positionne vraiment l’organisation concernée :

Everything you do reshapes the way your work, look at your desk’s placement for exemple… »

Olaf Lewitz

Trust
Trust no one 0 < = = = = = = = = = = > 10 Trust

Openness Level
Keep Calm and cover your ass 0 < = = = = = = = = = = > 10 Vulnerability

Safety Level
Fear 0 < = = = = = = = = = = > 10 Safety

Connexion level
Alone 0 < = = = = = = = = = = > 10 Authentic Connexions

Wholeness level (capacité à être soi-même, ou « entier »)
Wear a mask 0 < = = = = = = = = = = > 10 Whole personn

Power and Leadership
Centralized 0 < = = = = = = = = = = > 10 Distributed

Information Acess
Restricted 0 < = = = = = = = = = = > 10 Transparence

Planning and Control
Predict and Control 0 < = = = = = = = = = = > 10 Emergent (en fonction des besoins lorsqu’ils se présentent)

Performance and compensation (répartition des mesures de performance et rémunération)
Centralized 0 < = = = = = = = = = = > 10 Distributed

Après cette analyse vous devriez pouvoir positionner votre société par rapport à l’agile mindset ou plus précisément la « culture agile »

plan

Conclusion :

Tout cela reste mon retour suite à une conférence et je n’ai pas (encore) lu le livre qui a inspiré ce talk, mais ça m’a non seulement donné envie, mais cela m’a aussi bien inspirée, et je n’avais pas eue autant de palpitation depuis les TAZ de Hakim Bey (mais cela sera peut-être l’objet d’un autre post). Et vous ? ça vous inspire ?

Toi qui fais de l’agilité… pourquoi une user story TECHNIQUE est un aveu d’apprentissage.

Pourquoi une user story technique est un aveu d'échec par pablo pernot

Bon on arrivera quand même à la conclusion que lorsqu’on tricotte et qu’on retricotte perpetuellement, vient un moment où un tricotage de simplification et de solidification est nécessaire et ce n’est pas un aveux d’échec pour le développeur, mais plutôt pour le client, qui s’il change d’avis trop souvent pour son besoin et a finalité de valeur de chaque user story, il plante lui même les graines de l’échec, il ne récolte donc que des user story de refactoring.
Je garderai donc la formule d’aveux d’apprentissage, pour le presta comme pour le client.

Merci à Raphaël pour ce lien.

Et Dieu Créa l’Agilité pour les projets…

Au départ, au commencement, la gestion de projet Agile c’était meugnon, plein de grands principes et de jolis propos, visant à rendre une meilleure et plus rapide qualité de service, de faire apparaitre plus vite des outils… Ben oui, au lieu de faire de gigantissimes expressions besoins, des spécifications à n’en plus finir, des cas d’utilisations discriminant, et déterminant, à la pèle en veux-tu-en-voilà , le tout pour partir gentiment en excursion sous marine de mise en œuvre pour parfois revenir, au mieux, en ayant été oubliés (mais payé) ou, au pire, en ne correspondant plus aux attentes qui avaient évoluées entre temps (les coquinoutes), on pouvait alors prôner l’Agilité, la Souplesse, le Dynamisme ! Et c’était aussi émouvant que la déclaration d’indépendance, que l’abolition de la l’esclavage et que l’invention de la roue.    

Les développeurs étaient  tout le temps, à s’agiter sous les yeux d’un représentant métier et à lui demander tout plein de choses à faire, et le chef de projet passaient son temps à poser des questions  ça donnait la garantie certaine qu’ils bossaient et qu’ils essayaient au mieux de répondre aux besoins…  

Oui mais voilà, du coup, il a fallu mettre en place des modes de fonctionnement très très rigoureux, parce que le manifeste qui disait que la « collaboration des parties » devait prendre le pas sur la contractualisation, a fait déborder un peu les caprices de la clientèle dans des proportions budgétaires aussi hasardeuses qu’exponentielles.

C’était de fait, donc, plus cher mais au moins là du coup, on savait dans quoi on dépensait, puisqu’on le suivait à la semaine parfois à la journée, alors open-bar on faisait sa liste de course et en toute mauvaise foi on osait dire que les développeurs, qui travaillaient déjà comme des chevaux de poste qu’on remplaçait régulièrement, tellement on les usait moralement, n’en faisaient pas assez dans le périmètre du projet.

Et c’était bien là tout le problème. Le périmètre du projet n’étant défini que dans ses grandes lignes, il devenait le tonneau des développeurs à défaut de celui des Danaïdes.

Ce qu’on tricotait avec ses petits doigts de développeurs, un jour, on le détricotait le lendemain pour faire une autre partie. A la fin, on était à la fois plus tellement sûr de réaliser un pull-over tellement on y avait mis de poches, de raccords, de bout de laines ou de ficelles, de ci de là et on avait tellement découpées de parties, remplacés des bouts par d’autres, que la cohérence technique ET fonctionnelle de l’ensemble en pâtissait, mais on était un peu incapable de comprendre comment on en était arrivé là, puisqu’on avait quand même assigné des chefs de projets qui étaient sensés assurer la maitrise de l’ouvrage, et donc, tout l’équilibre de l’ensemble…

Vite fait bien fait, il a donc fallu mettre en place un mode de gestion budgétaire tangible, compréhensible, pilotable, et à défaut d’un processus (puisque le manifeste encourageait plus à la compréhension humaine qu’à la rédaction de spécifications) mettre en œuvre une méthodologie et une flopée de bonnes habitudes :

Dans les grandes lignes ça a donné ça :

Phase 1 : Définir un périmètre fonctionnel à grosse maille, et un pré-découpage fonctionnel rapido –et les chiffrages correspondants) –Et demander la production en conséquence d’un budget pour cela.

Phase 2 : Prévoir le bas de laine : laisser quelques cases vides avec de quoi faire dedans, pour les fonctionnalités supplémentaires à venir (inévitablement) –et les clients, quand ils peuvent faire quelque chose, ils auraient tort de se priver, alors ils font-   

Phase 3 : Surveiller, quotidiennement la consommation des ressources et vérifier la cohérence entre la vélocité des équipes, le consommé, le reste à faire, et les briques fonctionnelles (et là tous les outils sont bons pour réaliser cela : de votre cerveau en passant par votre calculette, votre tableau Excellent, ou votre pur outil de gestion de projet qui envoi du poney),

Phase 3.1  s’affoler vigoureusement si à 1/3 du budget, 1/3 des fonctionnalités n’ont pas été réalisées. –à noter que s’affoler vigoureusement, ne consiste pas agiter les bras frénétiquement mais bel et bien de faire un rapport d’identifications des raisons du retard, et d’en avertir le client-

Phase 4 : A 2/3 du budget consommé, procéder à un contrôle rigoureux du Reste A Faire (le RAF) et des fonctionnalités ajoutées dans les cases vides, et déterminer s’il faut rentrer en phase 5.

Phase 5 : Commencer à faire de la gestion des priorités –et donc commencer les exclusions voire la chirurgie- et/ou à demander à nouveau du budget.  

(Bon, ça ne s’applique pas si vos budgets sont infinis, vos clients adorablement réalistes, vos investisseurs peu exigeants, et que le monde autour de vous est peuplé de Bisounours)

Et en contrepartie ça obligeait :

– A chaque nouvelle « évolution » demandée par le client, à défaut de la refuser, de tracer les changements (et donc de quantifier les impacts (non, les méthodes agiles ne réduisent pas le temps de travail, surtout pas du Chef de Projets) pour pouvoir faire un ratio du Delta entre ce qui était prévu à T0, ce qui s’est passé à T1, T2, T3…TN et à faire la différence finale entre TN et T0 pour en apprendre un peu plus.

– A accepter que les temps de réalisation que vous aviez communiqués étaient a) Soit compressibles (et du coup, un tout petit peu bidons ;)) b) Soit incompressibles (et du coup, un tout petit peu pas réalistes) c) n’étaient pas les éléments sur lesquels on devait faire reposer la « dynamiques » de la gestion de projet agile, mais uniquement les bonus de celle-ci. –je vous laisse réfléchir sur quoi on plaçait la souplesse alors ;)-

A Ranger sa timidité ET son stress au placard pour communiquer, collaborer et joyeusement interagir avec les équipes techniques mais aussi ne pas leur transmettre de parasites (entendez sollicitations directes qui auraient pu être évitées), parce que déjà bien assez sollicitées (même si bon, c’est connu, les teckos sont des gurus, et on ne leur confierait pas ce travail s’ils n’étaient pas experts ( ?!) –Mais oui, ayez la foi… et, si vous n’avez pas la foi : persuadez vous !-)

– A apprendre à dire « non » en souriant, ou à répondre « ok pour ça, mais du coup, on doit retirer quelque chose, on enlève quoi ? » comme on faisait avant, sans Agile, et qu’il fallait placer son sacro-saint « oui, mais » dans les conversations avec le client.

En conclusion, agile c’est ni mieux ni moins bien que les méthodes de gestion de projet « classiques », c’est différent, cela dit, ça ne doit pas empêcher d’avoir un peu de rigueur, et donc d’en connaitre les écueils.