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 ?

Weekly links (01)

* Réduire la dette technique agile.
http://mariolucero.cl/agile/reduce-technical-debt/

* Un petit jeu DevOps agile.
http://babagile.wordpress.com/devops-game/

*  Vous en avez marre de lire dans vos RFP des histoire de partage de gain de productivité ; ici vous trouverez un petit tutoriel video pour vous expliquer ce que c’est.
http://www.sesflacher.fr/pages/les-ses-en-animation/le-partage-des-gains-de-productivite.html

Un jeu pour vous entrainer en HTML 5 pendant la pause, heureusement, il n’y a que 35 niveaux.
http://gameaboutsquares.com/

le mélange des pinceaux

Lors de mes études terrain, séminaires agiles et expériences professionnelles, j’ai vraiment pu me rendre compte que les sociétés, quel que soit leur domaine, avaient des perceptions de l’agilité très disparates et diverses (de l’agilité, c’est une mode à ok je veux de l’agilité au forfait en passant, notre société est agile par nature -et parfois c’était vrai, mais pas souvent, la seule agilité qu’on pouvait voir c’était la courbure d’échine dorsale) ce qui n’a pas manqué de m’étonner non parce que l’agilité ne peut pas prendre plusieurs forme, mais juste par le fait qu’on appelle parfois des projets agiles, agilisés, agilifiés (oui, moi aussi je kiff les néologismes), ou de transformation agile; des projets qui sont tout tout tout… sauf agiles.

J’ai donc eu l’occasion de constater que des comptes de faits peu réjouissants existaient sur l’agilité :

Voici deux cas un peu représentatifs de ce que j’appelle faire de l’agilité comme Stephen Hawking fait de la GRS.

Stephenhawkinglikesgym

  • Cas 1 : « Attention peinture fraîche »

Dans le premier (et le pire) des cas, l’agilité n’est qu’une épithète appliquée à un projet comme on applique une nouvelle peinture sur le mur : l’équipe ne change pas ses méthodes de travail et faire toujours du prédictif sur moyen à long terme, on la renomme juste « équipe agile » comme on change un étiquetage et de la même manière, on rebaptise gentiment le Chef de projet maîtrise d’œuvre en « Scrum Master » ou pire encore chef de projet agile (et pourquoi pas Chef du projet à Gilles tant qu’on y est ?), le Chef de projet client se transforme comme Sailor moon en « Product Owner ». L’équipe agile reste une brochette de ressources qui n’ont pas trop leur mot à dire sauf quand ça compile sur leur machine mais pas sur le serveur… et niveau « package documentaire » ? Même topo, un « cahier des charges » qu’on ose renommer en backLog alors qu’il ne comporte aucune user story, des « spécifications » (là on ose pas trop changer le nom), et éventuellement on se colle un « cahier de recette » (parce que c’est connu la restrospective, la démo tout ça ça sert à cacaouette), et enfin…. de la comitologie à gogo… coproj, copil, coex… Bref ça n’a d’agile que le nom.

saiormoonproductowner

  • Cas 2 : « De l’agilité, par petites touches de ressentit »

Dans le deuxième cas, on applique de l’agilité en autorisant l’équipe de réalisation à utiliser quelques outils de l’agilité : (éventuellement un ptit kanban par ci, pour décorer le mur, quelques post-its histoire de faire de jolies dessins sur les vitres, peut-être un peu de poker planning estimation quand on s’ennuie à la pause… mais sans changer le fondement du mode de gestion du projet : On doit livrer un projet -et non un produit- sans pragmatisme, ni priorisation, ni prise en compte des changements… en gros, on fait semblant de faire de l’agile comme si on jouait à la dinette dans un 3 étoiles du guide Miqueline.

bernardloiseauaimeladinette

Le problème ? Ben c’est surtout que ces pratiques, lorsqu’elles interviennent dans le cadre d’une « transformation agile » (parfois vendues par des sociétés dont je tairais les noms), sont génératrices de frustration pour le client (et de traumatismes, du coup après, pour les guérir en leur disant qu’on le fait avec un médoc éprouvé : l’agilité, ben euh difficile de dialoguer….) : En gros, certaines société promettent une « transfo agile » avec un rafraîchissement du cadre de travail, plus de confort, plus de résultat, plus de lumière, plus de potentiel, plus de gens heureux et finalement on a juste repeint mode truelle couleur agilité, on a enduit (oui oui du verbe enduire) le client dans l’erreur et on l’intoxique à l’agilité mauvaise qualité.

duluxvalentinechanson

Du coup, le client, il opte soit pour faire machine arrière, soit pour continuer mais « à conditions forfait » car ça lui fait craindre que tous les projets se dérouleront de la même manière….

Bref l’agilité, soit t’en fait, soit t’en fait pas mais y’a pas d’agilité où on trempe que les doigts de pieds.