Dans le manifeste agile: “Les individus et leurs interactions plutôt que les processus et outils”. Pourtant, sur une transformation d’un grand compte :

plutôt que les outils
Nous déployons Jira + Greenhopper, comme unique alternative autorisée à l’utilisation d’Excel, avec 2 variantes : Seulement les user stories dans Greenhopper (qui contient donc le Product Backlog), ou bien les user stories ET les tâches (notamment pour les projets distribués). Donc tous les projets vont avoir le même outil, imposé. Est-ce que la perte de cette latitude de choisir l’outil est un drame ? Il y a des avantages : mutualiser le support sur l’outil, d’éventuels plugins développés une fois pour toute. On change de dimension. Ce n’est plus le projet, mais la DSI qui adopte un outil. Il est indéfendable d’expliquer au management de la DSI que l’on va prendre des outils différents pour différents projets, que chaque projet va concevoir un choix d’outil.

Encore faut-il que cette mutalisation se nourrisse vraiment des remontées et besoin du terrain. Que périodiquement les représentants (le Scrum Master) de chaque projet rencontre le coach responsable de cet outil, une sorte de “scrum de scrum”, bref des interactions. On a bien un projet jira avec les demandes d’évolutions de l’outil mais ça ne remplace pas les échanges.

plutôt que les processus

L’entreprise bénéficie d’un réseau d’ingénieurs qualité, qui effectuent des revues de qualité des projets à certains moments de leur déroulement. Ils vont le faire notamment pour les projets agiles. Dans le cadre de la transformation, un travail a été fait avec eux sur les questions à se poser, et nous a amené à formaliser un référentiel agile. Il ne s’agit pas vraiment d’un processus figé, mais d’une description du framework Scrum, des pratiques d’ingéniérie tirées d’Extreme Programming et des spécificités de l’entreprise. L’approche est très proche de Scrum en tant que framework. C’est ce qui nous sauve : il y a largement place à interprétation.

Pourquoi ne pas utiliser directement le Scrum Guide ? ou le bouquin de Claude Aubry ? Cela vient des objectifs de ce référentiel. Les ingénieurs qualité sont supposés être compétents pour évaluer la bonne adéquation d’un projet à l’agilité. Ils sont supposés être formés, et avoir le même regard qu’un coach qui auditerait le projet. Le but est pour eux d’avoir une référence. Le référentiel est là à but normatif, pour poser des règles à respecter, pas pour enseigner expliquer comment faire. Nous nous sommes efforcés d’avoir un ensemble de règles cohérent & souple, avec juste ce qu’il faut de contrainte pour indiquer la direction aux projets.

L’ingénieur qualité collecte des preuves (fut-ce lors d’entretien) du respect des règles. Le référentiel ne dit pas comment s’y prendre. La réelle difficulté, et c’est comme pour CMMI, réside dans le fait qu’un ingénieur qualité fonctionne sur la base soit de preuve, soit d’entretiens très brefs, et que ni l’un ni l’autre ne se substituent au retour que peut faire un coach par exemple. Du coup nous (coach) participons aux revues. Que se passera-t-il quand la transformation sera finie ? quand l’entreprise décidera de réduire le coaching qui sert actuellement à déployer l’agilité ? Est-ce que les revues ne se baseront plus sur les traces d’exécution d’un processus (les livrables) et moins sur une évaluation fine du fonctionnement de l’équipe ? Et où iront les responsables qualité chercher leur connaissance de l’agilité ?

Quand je regarde ce que j’ai pu apporter aux projets que j’ai coachés, c’est 20% de forme, de respect des règles du processus Scrum, et 80% de fond, d’état d’esprit. Difficile de résumer l’état d’esprit agile dans une checklist destinée à être appliquée par des personnes qui n’ont jamais participé à un projet agile ni été Scrum Master. C’est peut-être au fond une limitation de l’agilité, plus difficile à généraliser dans une entreprise qu’un processus lourd comme UP.

Les projets sont des entités organisationelles qui ont chacune besoin de son propre SI

Partant de là, je vois un parallèle (un peu abstrait) à faire entre :

• informatiser une entité organisationnelle (par exemple la direction commerciale / turbine à qui on fournit une série d’applications, plus ou moins liées, pour se gérer)
• informatiser un projet de développement informatique (fournir à un projet une série d’application, plus ou moins liées, pour se gérer)

Une sensation de déja vu, comme le chat noir dans Matrix.

Des échanges récents chez mon client actuel m’ont replongé dans mon passé. J’avais, à la demande d’un autre client, essayé d’utiliser Caliber RM (un outil de gestion d’exigence) pour outiller la traçabilité de bout en bout des projets (y compris stocker des risques ou des liens vers des cas de tests). Là, on aimerait utiliser la suite Atlassian (wiki confluence + gestionnaire de tickets jira) pour gérer tout, les scénarios de tests, etc…

Les objets métier d’un projet informatique

Un projet informatique (un minimum complexe) gère des objets “métier” : user story, backlog, scénarios de test, rapports d’exécution de test, bugs, … Il y a des principes d’associations entre ces objets, d’où la fameuse traçabilité : être par exemple capable de pouvoir dire qu’il n’y a plus aucun bug portant sur cette user story. Etre capable de dire que toutes les user stories de la release ont été testées (ça s’appelle chercher des trous dans la matrice de traçabilité).

La charrue avant les boeufs.

Sur un projet informatique, on commence par réfléchir au besoin, recenser les story, etc… Pourquoi ne pas faire pareil ? Commencer par recenser les user story de notre SI projet ?

En tant que développeur, je peux de manière transparente associer un commit à une user story et ou à un bug.

En tant que scrum master, je peux obtenir un rapport d’avancement des tests d’acceptance par le business.

En tant qu’ingénieur qualité, je peux obtenir un rapport d’exécution des tests automatisés et manuels pour chaque version

Etc…

Intégration entre les outils

A chaque fois, on se perd dans les détails de tel ou tel outil. Comme un projet se perdrait dans les détails d’intégration ou de flux entre outils.

Dans l’idéal, il faudrait une combinaison miracle d’outils, chacun étant accessible par service web, en consultation, en modification. Chacun étant capable d’accéder à d’autres outils par service web ( par exemple pour pouvoir sélectionner une user story dans le backlog afin de l’associer à un cas de test).

Mais n’est-ce pas un leurre ? Est-ce qu’on ne peut pas se contenter d’un champ en saisie libre où l’on mettrait l’identifiant de la story. C’est moins bien (risque d’erreur contrôlé a postériori), mais ça peut être tolérable dans certains cas.

Où est le product owner capable d’arbitrer ça ?

Alors il y a les grands comptes qui peuvent se permettre des suites (hors de prix). Et les autres qui bricolent, comme ils peuvent.

Spécifique

J’ai une tendance à préconiser du spécifique à chaque projet, par opposition à une “cellule transverse” qui spécifierait et mettrait en place la solution d’ALM pour tout le monde. Dans mon ancien client, j’avais connu des projets hardware + software, d’autres que software, d’autres de type EAI, bref des configurations qui faisaient que le besoin du projet en solution d’ALM était différent d’un projet à l’autre. Comme on aurait des besoins métiers différents entre des directions métier différentes. Quoi d’étonnant ?

Ca implique surtout d’articuler le besoin

• Les besoins au niveau de la direction des études : le product owner du SI des projets est le responsable outil/méthodes
• Le paramétrage de la solution retenu / les besoins spécifiques pour chaque projet : le product owner du SI du projet est le chef de projet/scrum master, avec arbitrages avec le responsable outil/méthodes (souci de capitalisation, d’homogénéité, …)

Rétrospectivement, mon ancien client avait adopté une démarche sensée au niveau entreprise

Analyser le besoin (outils/méthodes + représentants des Chefs de projet/Scrum Master)

1. Prioriser le besoin (idem)
2. Sélection des outils sur des critères comme l’ouverture par API, la facilité à synchroniser les données de référence, etc…
3. Faire un pilote, avec une première intégration des outils (avec le CP comme product owner)
4. Faire un deuxième pilote, avec une intégration différente (idem)
5. Capitaliser
6. Animer une communauté
7. Intégrer un budget “SI du projet” dans chaque budget de chaque projet.

• documentation utilisateur en ligne ou papier
• supports de formation (pour les différents auditoires)
• documentation d’administration fonctionnelle
• documentation d’installation
• documentation d’administration technique
• documentation d’exploitation
• documentation pour la maintenance corrective et évolutive (notamment design & tests)
• etc…

Mon propos est que la documentation est comme le code, et devrait être élaborée comme le code. Voici quelques idées qui découlent de ce principe.

Produit

Le corpus documentaire livré avec un projet gagne à être considéré comme un produit en soi.
Cet ensemble de documents doit être cohérent, un jeu de versions cohérent, et cohérent avec une version de chacun des composants de code.
Quelle différence avec un incrément de code, si ce n’est qu’il s’agit de langage naturel et de documents office au lieu de code ?

Traçabilité
Il y a une adhérence entre la documentation et le code, et une modification structurelle, dans le cadre de l’implémentation d’une user story, va engendrer un impact sur la documentation.
Le travail sur chaque user story aura un impact sur la documentation, à plusieurs endroits, mais on ne pourra pas forcément découper chaque document en paragraphe par user story (pensons par exemple à un modèle de donnée pour l’exploitation que l’on ne sait pas ramener à telle ou telle user story).
Il y a la même problématique que pour le code, avec la traçabilité code/user story.
Dans certains cas, il faudra aller jusqu’à tracer le lien entre user story et chapitre de doc (des outils existent), comme on le fait parfois pour les liens entre le code et les user story (dans les commentaires, ou dans les commentaires subversion).

Au fil de l’eau
Quelle différence entre la doc et tel ou tel aspect (au sens POA) que l’on décide de couvrir au fur et à mesure, plutôt que d’attendre à la fin, comme les transactions ou le reporting.
L’idée est de ne plus dissocier dans le temps le design, l’implémentation, la documentation, et d’adopter comme unité de travail la user story de bout en bout.
Comment s’assurer que, si on a décidé de l’écrire au fil de l’eau, la doc l’est réellement ? Comment sensibiliser l’équipe ? Faire des revues documentaires (par leurs destinataires) ?
Ce qui n’est pas revu n’est pas comptabilisé, et la user story correspondante ne l’est pas (Inclure tel incrément de tel doc dans la definition of done).
Une doc qui n’est mise à jour dans un sprint est une dette technique, dont le coût s’alourdit au fur et à mesure qu’on oublie ce que l’on a fait.

Comment se fait il que les développeurs expérimentés, qui ont déjà vu des fins de projets douloureuses, avec une documentation difficile à rattraper dans des conditions budgétaires très tendues, comment font-il pour oublier ça, et recommencent-ils à repousser sans fin la doc à l’itération suivante ?

Refactoring
Le bon niveau de doc rend le code plus facile à refactorer (vue globale du système, analyse d’impact, points de vigilance, …)
Quand on y pense, il est plus facile de réécrire le code à partir de la doc que d’analyser le code pour produire la doc,donc il serait presque plus logique de privilégier la doc sur le code.

Génération
A défaut de se demander si on peut générer une partie de la documentation, on peut l’organiser pour qu’elle soit facile à maintenir.
Une nouvelle fois, il s’agit de réflexions que l’on se fait aussi pour le code.
Si génération il y a, il faut, comme pour le code, quelque part, décrire l’information, la génération n’est qu’une mise en forme.

Auditoire
La doc est un produit, elle a donc a avoir une ergonomie, à être pensée en fonction de l’utilisation qui va en être faîte.
Si la définition de l’auditoire est trop abstraite, pourquoi ne pas définir des “persona” de la documentation, qui matérialiseraient les utilisateurs type, les administrateurs opérationnels type, l’exploitant type, … comme on le fait pour le code.

Négociation
Il faut s’assurer des attentes de l’auditoire.
J’ai vu des forets entières disparaître parce que l’on anticipait à tort les attentes de tel service ou tel organisme de contrôle, sans en débattre avec eux, sans négocier.

Politique documentaire
Définir une politique documentaire concrète et explicite, adaptée au contexte plutôt qu’appliquer une liste des modèles de doc, sans remettre en question l’usage de telle ou telle doc, ou la structure des tables de matière.
L’équipe élabore cette politique sous les contraintes des partenaires, et la revoit au fur et à mesure du projet, en intégrant les retours des lecteurs.

Documentation & Agile

Quand on parle de réduire la doc en agile, on parle de réduire la contractualisation entre les acteurs, pas la doc finale.
On prétend juste que la doc à produire in fine n’est pas la documentation utilisée en cascade pour élaborer le produit, mais bien une documentation adaptée aux personnes qui vont l’utiliser, à jour, cohérente , minimale, optimale, adaptée, fruit d’une négociation avec son lectorat.

• Casting de haut niveau de sélection. Je ne parle pas du nombre d’années d’expérience, mais de la motivation et des compétences (voire des capacités) de chacun. Un individu à la traîne qui ne connaîtrait pas les enjeux finira exclu. Un individu à la traîne mais qui s’approprierait les enjeux pourrait monter dans le train, et en sortir grandi.
• Des membres curieux d’esprit, ouverts aux autres idées, qui écoutent les autres membres.
• Du respect, pas nécessairement de l’amitié.
• Des individus ambitieux, pour eux et pour le projet.
• La présence d’un ou plusieurs leaders au sein de l’équipe, pour mettre la machine en marche, pour pousser à aller plus loin.
• La volonté de faire avancer le projet globalement qui pousse ceux qui sont “en avance” à aider ceux qui sont “en retard”.
• La place laissée (et prise) à chaque membre de l’équipe pour s’exprimer, à sa façon, le moment venu.
• Un souci partagé de fonctionner comme un système harmonieux, en synergie, tout en n’hésitant pas à débattre tant que nécessaire afin d’aboutir s’il le faut à une troisième voie.
• Un sens de l’urgence, certains membres qui entraînent les autres vers la nécessité de produire, régulièrement, des incréments livrables, démontrables, quitte à renoncer à certaines subtilités fonctionnelles.
• Un sens de l’importance du projet, nourrie de rencontres avec les acteurs métiers et les utilisateurs finaux. Une équipe qui partage les enjeux et les objectifs du projet.
• Un rythme soutenable mais soutenu.
• Une équipe qui s’éclate.
• Une équipe qui prend les difficultés à bras le corps.
• Des moments de déconade sincères pour laisser un peu filer la pression, et partager la joie de travailler ensemble.
• Une équipe à qui on laisse l’opportunité de s’organiser et qui le fait, collectivement, en remettant sa méthode et son organisation en question tout le long du projet.
• Une équipe qui débat de ses ambitions (qualité, rythme de livraison, …).
• Un défi technique, une perspective d’enrichir le CV.
• Un top management qui met la barre assez haut et pas trop.
• Un top management qui se rend disponible et sait prendre des décisions.
• Un middle-management charismatique mais aussi et surtout soucieux du bien-être des membres de l’équipe.
• Un management présent, pas systématiquement directif, qui rappelle les contraintes et aplanit les difficultés hors du périmètre de l’équipe.
• Une adoption comprise et sincère de pratiques agiles et lean, adaptée au projet.
• Du coaching (par un externe, pas par un hiérarchique), pour guider, prendre du recul, et aider à trouver là où ça fait mal.

Je suis convaincu que l’application de l’agilité au sein d’une équipe gagne à avoir une grande partie de ces caractéristiques. Posséder ces garanties n’est peut-être pas indispensable. Posséder ces garanties n’est peut-être pas un gage de succès assuré dans l’absolu. C’est par contre selon moi lié à un voyage en commun mémorable et enrichissant. N’est-ce pas après tout le plus important ?

I started this summer a very simple experiment.
I think that this should sound familliar to anybody practicing agile.

I had for year 2011 a kind of “Getting Things Done” list (as a matter of fact, it is a xmind map, much easier to group, split, … than an excel file).

Now I have also iterations, of 2 weeks. When I start an iteration, I select entries in my GTD list and I split them in concrete short term tasks (that I will be able to do in 2 weeks delay, knowing the fact that I am only working part time on my personal GTD), my sprint list.

Items in my sprint list are more concrete, more simple, don’t need long term thinking.

During my sprint, I take a greate pleasure checking items in the list to mark the fact that they are done. Or de-scoping them to further iterations.

If I find new ideas, I add them to the global GTD list, and I try not to change the scope of the sprint.

What is fun is to feel the power of having 2 level a granularity (PBL Items/Tasks) also for “personal” tasks.

Moreover, the use of a mind map is not innocent : it also helps to collapse items in order to hide their details and get a more synthetic view. Sounds like epics, no ?

It’s like a training where the trainer would ask you :

• Imagine you make a list of things to do this year.
• Detail them.
• Arrange them.
• Then select some of them for the next two weeks.
• Split them into concret tasks.
• Manage them
• Look at what you have done at the end of the sprint.
• Retrospect.
• Start the next sprint.

Except I do it for real.

And it works !

Nous avons constaté un phénomène assez particulier, que nous avons mis du temps à canaliser.
Il peut se résumer à “2 coachs valent plus que 4 coachs“.

Une réunion à 2 coach sur une activité de transformation est constructive.

Une réunion à 4 coach part dans toutes les directions, change plusieurs fois d’agenda, et pourra être sérieusement contre productive.

J’ai une théorie selon laquelle, à 2 coach on négocie de manière plus explicite et moins fréquente les changements de “mode” d’interaction :

• la créativité (chacun propose, chacun suit librement ses associations d’idées)
• le retour d’expérience (une personne raconte)
• la présentation (une personne expose quelque chose qu’elle a élaboré)
• la réflexion (une personne réflechit à voit haute)
• l’argumentation (deux personnes débatent)
• la meta-communication dans le message élaboré (que vont penser les équipes si on met ça dans le wiki de transformation)
• les concepts (on essaie d’établir un consensus sur un ensemble de concepts)
• le paradigme (on essaie d’établir un consensus sur le cadre même de la réflexion)
• la méta-communication sur l’interaction (on parle de la réunion qui a lieu)
• la méta-communication sur la relation (on parle des rôles et rapports entre les participants)
• l’humour
• …

Les modes changent beaucoup plus vite à partir de 3 coach, et l’ensemble est instable.

Ensuite, je ne pense pas que cela soit un problème d’ego. Je ne pense pas non plus qu’il s’agisse de rigidité intellectuelle, nous sommes tous souples et ouverts. Je pense plutôt à une déformation naturelle.
Le coach est là pour mettre son client, son équipe en mouvement (même en coaching non-directif il y a un transfert d’énergie). Un coach a toujours quelque chose d’intéressant à dire, un recadrage, une reformulation, pour faire progresser.
Difficile de s’arrêter de jouer quand on est en coulisse.

Du coup, il me semble que la nature de la réunion doit dicter le casting.

• ce qu’il vaut mieux préparer seul
  • élaboration d’un contenu non structuré
• ce qu’il vaut mieux préparer à deux
  • revue de détail d’une présentation
  • structuration, articulation d’un contenu
• ce qu’il vaut mieux préparer à plus de 2
• partage
• brainstorming très “ouvert”, très en amont
• planification

Avant

• Une invitation est envoyée : date et heure de début, durée, agenda, contexte (supports, lien vers le compte rendu des réunions précédentes)
• L’animateur de la réunion arrive à l’avance, et s’assure du matériel : le cas échéant vidéo projecteur, paper board, whiteboard, marqueurs, post-its, papier krafts, stylos, portable branché sur le cable vidéo, sur son alimentation, télécommande du portable.
• L’animateur dispose les tables dans la configuration qu’il a conçue si ce n’est pas la configuration standard de la salle
• L’animateur affiche au mur les rappels des principes de la réunion (open space, brainstorming, …)
• Les participants arrivent en ayant pris connaissance du contexte qui leur a été fourni en pièces jointes de l’invitation
• Les réunions sont préparées par les acteurs : finalisation des actions attendues (notamment collecte d’information)

Début

• La réunion démarre à l’heure prévue (même si tout le monde n’est pas là), cela poussera chacun à venir à l’heure
• L’animateur rappelle l’objet de la réunion et propose l’agenda, qui restera visible pendant toute la réunion

Pendant

• La réunion a un time keeper. Il rythme la réunion avec dynamisme. Il surveille le temps qui reste par rapport à la vitesse constatée. N’est pas forcément l’animateur, mais gagne à l’être, notamment si l’animateur est un facilitateur et pas un opérationnel.
• La réunion a un seul animateur, pas plus
• La réunion a un secrétaire qui produira le compte rendu ou édite les documents. N’est pas forcément l’animateur.
• Pendant la réunion, un indicateur de l’avancement et du temps restant est évalué et partagé
• Une seule conversation est tenue à la fois (pas d’aparté)
• Des pauses (de durée stricte) ont lieu, donc le reste du temps les participants ne s’absentent pas de la réunion
• On note les sujets hors agenda, mais on ne les traite pas
• A part le secrétaire, personne n’a son portable ouvert. les documents à partager avec le groupe auront été transmis au secrétaire au préalable
• On ne se coupe pas la parole
• On ne monopolise pas le temps de parole (on ne parle pas plus de 2min sans passer la main)
• Tout le monde a le droit à la parole
• Tout le monde a le devoir de participer
• Les conversations qui s’éternisent et qui ne sont pas bloquantes pour la poursuite de la réunion sont arrêtées par l’animateur, qui les note pour qu’elles soient traitées à part
• L’animateur formalise tout le long de la réunion les tâches (qui, quoi, pour quand)
• Au fil des sujets l’animateur fait le point sur les tâches des réunions précédentes

Fin

• L’animateur collecte les informations : prend en photo les murs de post-its, roule les papier kraft, prend en photo le whiteboard, récupère les papiers du paperboard
• L’animateur (aidé par certains participants) remet en état la salle : efface le white board, remet les tables en place, …
• La réunion se termine à l’heure prévue (même si on n’a pas fini dans les temps), cela poussera le groupe à apprendre à gérer son temps
• La réunion donne lieu à un compte rendu de décision diffusé à tous, en plus d’une éventuelle mise à jour de supports (backlogs, …)

Après = Avant

A suivre…

PS: Plus j’y pense, et plus j’ai envie de relire “Collaboration Explained: Facilitation Skills for Software Project Leaders” de l’excellente Jean Tabaka.

• L’équipe apprend à s’organiser sous les contraintes du projet, et cet apprentissage est rythmé par les rétrospectives.
• Que dire des autres projets agiles au sein de la même organisation ? Une communauté agile émerge quand l’organisation déploie l’agilité, des échanges ont lieu, mais je ne suis pas sûr qu’une norme émerge, il s’agit plus de retours d’expérience (essais et erreur).
• Chaque projet est libre de ses choix, tout en bénéficiant de retours d’expérience des autres projets
• Il n’y a pas de niveau d’agilité dans l’absolu, car il n’existe pas dans la “nature” de modèle agile standard.
• S’il y a des audits par un coach agiles, c’est par l’observation et non par l’étude de preuves écrites.

L’approche CMMI :
L’organisation apprend à s’améliorer.

• Elle décrit ses processus, apprend à les exécuter, les contrôler, les optimiser. Des dérogations justifiées sont cependant possibles.
• Son apprentissage est rythmé par les évaluations (par exemple Scampi), et sanctionné par un niveau (que l’on gagne pour 3 ans), car il existe un modèle CMMI standard décrivant ce que l’on s’attend à ce qu’une organisation mature gère (pas forcément comment elle le met fait)
• Les évaluations reposent sur la traçabilité (la collecte de preuves sous forme de documents).

Lean Software Development
Des pratiques d’amélioration continue issues du manufacturing, qui s’étendent à la conception de produits (Lean Product Development) et pourquoi pas au software (Lean Software development).

• Elimination des gaspillages (à tous les niveaux)
• Rangement du poste de travail (et par extension du code et du référentiel documentaire)
• Optimisation globale et non locale à une activité.
• Etc…

Il ne s’agit pas forcément d’un processus structurée mais plus d’une grille (d’une méthodologie ?) d’identification d’axes d’amélioration et des techniques allant dans ce sens.

Je rêve de projets agiles qui s’améliorent en appliquant les grilles Lean à leurs rétrospectives, au sein d’une organisation
qui applique un CMMI ajusté (par rapport aux preuves, par exemple),et qui anime une communauté de pratiques agiles,et utilisera en particulier la possibilité de décrire, pour chaque règle ou pratique qu’elle aura cru bon de formaliser, dans quelle configuration projet on doit ou ne doit pas l’utiliser.

L’organisation elle même s’appliquera Lean, pour améliorer son organisation par exemple.

(et bravo à Laurent Bossavit qui a fondé et anime ce vénérable institut)

AVANT
- préparer la salle (chaises, post-it vierges, instructions, numéros des salles, rôles)

PENDANT
- café, jus d’orange pour chauffer l’ambiance
- speech d’introduction par le sponsor du forum ouvert (objectifs)
- speech de présentation des modalités du forum ouvert (par Jean-Claude)
- collecte des sujets : les membres de l’assistance se levent, montent sur l’estrade, disent leur sujet, collent leur postit
- organisation : regroupements des post-its
- vote : chaque membre de l’assistance vote pour 3 groupes de post-its
- sélection des 8 groupes ayant reçu le plus de votes, affectation aux sales et aux animateurs
- 4 x 2 sessions dans 4 salles. L’animateur anime, ne donne pas d’avis, note les idées.
- debrief à l’ensemble en 3 minutes par session par l’animateur
- plan d’action immédiat
- rétrospective
- roti
- pendant toute la durée : profiter de l’expérience

APRES
- récuperer les post-it géant en marquant sur chacun le nom de la session & un numéro qd il y en a plusieurs
- ranger les salles avec le public
- debrief à chaud, plan d’action court terme
- saisir sous informatique (xmind puis word) les idées, et constater la richesse du résultat
- débrief à froid, plan d’action long terme

Sensations :
- vraiment très sympa
- Jean-Claude sait insuffler beaucoup d’énergie, maîtrise le format, maîtrise l’agenda et le timing (cf son article sur QualityStreet)
- grande mobilité du public
- intéressant de voir que l’on peut avoir 50% du public par moments et 2 personnes à d’autres moments

Ce que j’ai fait et ce que je n’ai pas fait (je vous laisse deviner)

AVANT

• faire une pub ciblée avant
• se mettre d’accord clairement sur qui fait quoi (en préparation, et pendant la conf)
• bûcher son sujet
• non vraiment, bûcher son sujet pour être parfaitement clair dans les explications que vous donnerez
• et le bûcher aussi pour pouvoir inter-agir avec vos pairs, si vous en avez dans l’assistance
• penser l’articulation de la présentation (un plan simple et clair)
• éviter l’abstrait
• épurer ses slides à la présentation zen
• lire, relire, re-relire, compléter, affiner, alléger, en remettant plusieurs fois votre ouvrage sur le métier, et en s’y prenant suffisamment à l’avance

PENDANT

• prévoir 50% de discussion
• lancer la discussion très tôt (prévoir des alternances de présentation et de question)
• ajuster le tir quand on voit que ça démarre mal (ne pas coller à l’organisation prévue si elle n’est pas pertinente)
• gérer la cohérence avec votre idée de la conf et ce que dit le co-présentant (pas toujours évident)
• gérer votre fatigue (c’est plus simple en co-présentant)
• gérer les bavards
• gérer les silencieux
• gérer le temps
• rester présent tout le long

APRES

• obtenir un retour de l’assistance
• profiter du pot qui suit pour rencontrer, échanger (sans se limiter au sujet)
• obtenir un débriefing détaillé d’un proche

TOUT LE TEMPS

• Surtout profiter de l’expérience !

Distinguer

• Exemple 1 : le product owner doit gèrer le “quoi”, l’équipe (animée par le scrum master) doit gérer le “comment”. Le product owner exprime des besoins, des histoires utilisateurs, l’équipe fait des maquettes et des suggestions. On se laisse par exemple facilement embarquer dans des situations où c’est le product owner qui fait des maquettes (ne serait-ce que pour échanger avec les utilisateurs), avec les implications que cela peut avoir en terme de faisabilité et de coût.
• Exemple 2 : dans le cadre d’un contrat, l’estimation “vendue” qui correspond plus à une évaluation du prix que le client est prêt à payer pour la fonctionnalité et l’estimation par l’équipe, qui vient souvent plus tard et qui correspond au coût de réalisation objectif, à la complexité réelle.

Regrouper

• Exemple 3 : les tests. Quand on implémente une fonctionnalité à base de flux, on est bien obligé de la tester sur des fichiers de données, dans le cadre même des tests unitaires ou d’assemblage des différentes couches. A quoi bon séparer dans ce cas les tests dits “fonctionnels” ou d’intégration et les tests unitaires ? Une approche à base de fitnesse réconcilie les deux, en fournissant à l’équipe les données avec lesquelles tester. Mais cela suppose que l’on admette qu’il y a une étape de test unitaire et une étape de test d’intégration.

Articuler
Exemple 4 :  On entend tout et n’importe quo sur XP, Scrum et Lean Software Development, sans parler de Software Craftmanship.

• Scrum est venu après XP, ceux qui l’appliquent s’inspirent souvent de XP pour les sujets que Scrum ne couvre pas.
  Scrum ne couvre pas tout (en particulier par les activités d’ingéniérie), pour lesquelles certaines pratiques xp restent pertinentes. Il faut aussi considérer les pratiques plus modernes (TDD, TDR), voire Software Craftmanship.
• Scrum est un processus de développement, ce que XP faisait de manière plus diffuse, moins formelle.
• Scrum et XP viennent en partie du Toyota Way, repris de manière peut-être plus directe par Lean Software Development.
• Scrum est plus adapté pour les developments (orienté quantité de valeur métier que l’on arrive à faire rentrer dans un plan de charge), Lean (en particulier l’approche Kanban (pull) ) pour la maintenance (orienté délai de prise en compte des demandes métier).
• Certains débats sur Software Craftsmanship le voient comme un mouvement post-agile. D’autres comme une approche hyper-rétrograde. Selon moi, le Software Craftsmanship est dans la continuité de XP : une réflexion innovante sur les pratiques d’ingéniérie. Le débat avec l’agilité consiste “juste” à trouver un équilibre (enfin) entre livrer de l’utile au plus vite et maîtriser la capacité à livrer de l’utile par la suite.
• Etc..

Chers lecteurs, à vos claviers !

Un collaborateur d’une SSII (à part peut-être les plus seniors ou les managers) se spécialise plus ou moins par plateforme ( jee / .net / php ), voire par produits. Il est naturel de recenser les collaborateurs experts en weblogic portal, ou plus généralement en portail, animer leur réflexion, leurs échanges, leur veille techno, le code réutilisable, les frameworks maison. Naturellement donc les effectifs devraient appartenir à une (ou plusieurs) cellules de veille, cellules archi, … appelons ça “centres de compétences”. Rien ne rend nécessaire de confondre l’offre et le centre de compétence. Un centre de compétence “portail & CMS” pourrait servir plusieurs offres.

Enfin, il y a l’approche manageriale. Chiffre d’affaire, marge, intercontrat. Pour piloter “numériquement” l’activité, il faut des frontières autour d’entités, chacune étant supposée rentable. A la base il y a le projet (avec un chef de projet dont le variable dépend de l’issue du projet), mais dont la durée de vie est limitée. L’entité stable est la “business unit” qui regroupe quelques dizaines de  collaborateurs et qui doit être auto suffisante, quitte à “sous-traiter” pour d’autres business unit. A sa tête, un manager, dont le variable dépend (entre autres) des chiffres de la business unit. Les business unit s’empilent (business unit, département, agence, groupe). Il n’est pas évident que les offres doivent toutes être matérialisées par une business unit (avec des collaborateurs exclusivement dédiés). Pourquoi pas une approche matricielle ? Un centre de compétence peut être transverse, aussi (mais difficile alors d’en garantir le budget, la pérénité).

De la claire articulation entre ces 3 concepts (catalogue d’offres, liste des centres de compétence, hiérarchie des business unit) dans une organisation dépend :

• la pertinence de l’action commerciale et d’avant vente sur les offres, et donc leur pourcentage de réussite
• la formation continue, l’émulation des collaborateurs et un faible turnover
• la rentabilité gagnée en focalisant les énergies du management vers la rentabilité d’un périmètre clair

Exemple d’offres : par secteur (l’assurance, les labos pharmaceutiques) et/ou par problématique (le tunning de performance, les applis de gestion de contrat d’assurance)

Exemple de centre de compétences : la mobilité, la “stack” Spring, l’AMOA, la TRA, …

Une approche cohérente serait d’avoir des centres de compétence assez larges, qui contribueraient chacun à un certain nombre d’offres (s’appuyant potentiellement sur plusieurs centres).

Après, reste :

• à trouver la bonne organisation en business unit pour répartir les gens (au moins par centre de compétence, mais ce n’est même pas évident. Mes missions sont variées et couvrent plusieurs centres)
• à mettre en place un suivi quantitatif des offres : investissement, effort de prospection, résultats, chiffre d’affaire, … mais même ça c’est discutable : pourquoi une bu ne prendrait-elle pas le risque d’investir lourdement sur une offre peu viable au début (parce que c’est l’avenir, parce que l’on dispose de la compétence…) en la financant par les autres ?

Tout ceci a surement l’air un peu banal, mais “quand on est dedans”, il n’est pas toujours facile d’y voir clair.

Les livres sur le brainstorming, une technique de créativité collectivent, illustrent bien à mes yeux le processus très particulier de l’inception, l’étincelle initiale d’un projet, qu’il soit une oeuvre ou un projet informatique.

D’abord un cadre. Qu’essaie-t-on de résoudre. Quelles contraintes se donne-t-on (temps, forme, … )

Ensuite les idées arrivent, et par une étrange combinatoire se multiplient. Deux idées proches engendrent une troisième qui va plus loin. Deux idées contraires engendrent un nouvel axe de réflexion, un contraste. On fait appel à d’autres domaines (des idées qui ont été utiles dans un autre contexte).

Après cette phase d’expansion, une phase de contraction. Les idées s’organisent. On identifie des catégories, des sous-catégorie. On classe, on enrichit la classification. En classant, les idées se confrontent, s’enrichissent encore. La classification permet d’identifier des lacunes, d’où de nouvelles idées. Des idées sont fusionnées, d’autres éliminées, d’autres articulées (besoin, solution du besoin, solution du besoin de la solution du besoin, …). Avec l’ordre apparaissent des axes, une carte, et donc la possibilité de vérifier l’exhaustivité, la cohérence, et d’enrichir le tout, et d’avoir le même niveau d’approfondissement pour tout.

Je vois deux façons de tenir un blog. La première (qui n’est pas la même) consiste à rédiger des articles structurés, fouillés (après l’inception). La seconde (qui est ma ligne ici) consiste à prendre un frémissement, et de le jeter en pâture à la multitude pour recevoir en retour des échos, déformés, enrichis. L’inconvénient c’est que mes articles ne sont pas aboutis. L’avantage c’est qu’ils ne sont pas aboutis ;-)

En fait, je transcris des demi-dialogues, comme si je retranscrivais une ligne sur deux d’une conversation à la machine à café. Un appel assumé à des échanges (pour avoir les autres lignes).

La direction décide de structurer l’organigramme en reflet du catalogue d’offres (une offre ca peut être une valeur ajoutée spécifique pour un secteur d’activité (ex:les entreprises de logistique ou les organismes de santé), pour une problématique (ex: la mobilité ou les portails), pour une famille d’activités (ex: le conseil/audit en processus ou l’amélioration des performances)). Le principe est que l’organigramme doit refléter la stratégie de l’entreprise qui est de mettre l’accent sur un certain nombre d’offres. Tout le monde rame dans le sens voulu par la direction, les offres se développent.

Pour moi, les offres (définies par le marketing et le bon sens des consultants de terrain) devraient être considérées comme un besoin auquel on répond par un certain nombre de solutions (des pools de compétence). Les assurances et les logisticiens ont tous les deux des problématiques de flux. Peut-être serait-il plus pertinent d’avoir un pôle de compétence “flux” (talend, etc…) qui servirait à 2 offres ?

Il faut bien un “porteur” de l’offre, détaché (si possible à temps plein) sur l’offre pour coordonner les efforts des différents pôles, objectivé sur les résultats de l’offre et doté du pouvoir d’objectiver les collaborateurs qu’il sollicite. Là où j’ai plus de mal c’est l’idée que ces offres soient coulées dans le marbre d’un organigramme, qui ne va pas changer souvent. Il faudrait un écosystème plus vivant, une notion d’incubation (prouver avec un petit peu de moyens la pertinence d’une offre).

Là où les collaborateurs ont du mal c’est l’idée d’être spécialisés sur une offre. C’est sympa la mobilité, mais bon de là à en faire pendant 3 ans ? Alors qu’il y a un spectre tellement riche de projets possibles. Vous me direz que la vocation d’une SSII n’est pas de balader les collaborateurs en les maintenant dans un état de perpétuels débutants. Vous me direz que les collaborateurs seront bien contents de pouvoir mettre “expert mobilité” sur leur CV. OK. Pourtant l’inquiétude est souvent palpable. Vais-je devoir me spécialiser ? Peut-être que les modalités d’entrée/sortie dans une offre devraient être éclaircies. Peut-être devrait-on pouvoir être rattaché à 2 entités ?

Imaginons que je veuille développer plus avant une offre de coaching agile tout en “finançant” cet effort par des missions plus classiques d’architecte ou de scrum master. Comment le puis-je dans un organigramme par offre ? Et pour quelle raison le porteur de mon offre “de base” aurait intérêt à financer l’autre ? Il faudrait clarifier le processus de définition des offres, d’allocation de budget, et, surtout, le rendre plus fluide, plus transparent. Créer des communautés spontanées, et non à l’initiative des managers, avec un budget inspiré des 20% de Google.

Qu’est-ce qui permet de gagner en efficacité ? un savoir faire, des livrables type adaptés, des guides de référence adaptés, parfois des composants et des frameworks, des processus et outils adaptés. Une organisation qui spécialise les équipe n’est pas garante d’une amélioration de l’efficacité. La condition sine qua non est l’investissement dans la capitalisation, son organisation, son contrôle, son adaptation au contexte, une bonne compréhension (et un intéressement) de chacun. Et la capitalisation est d’autant plus visible et effective qu’il y a de mouvement (entrées ou sorties). C’est un peu comme d’éviter l’appropriation du code. Alors oui, un spécialiste du RIA serait plus efficace. Mais jusqu’à quand, s’il s’ennuie ? Et puis on progresse en expliquant son savoir.

Enfin, qu’est-ce qui permet de toucher au mieux les clients ? Une bonne remontée par les acteurs du terrain (même les développeurs), qui au contact des clients sentent les préoccupations du moment et les spécificités d’un contexte. Collecter ces remontées, synthétiser des propositions, les confronter a quelques clients, ou dans des conférences, etc… Bref une agilité dans l’élaboration d’un produit innovant et approprié. Cette agilité doit être communautaire (les remontées de 10 valent 100 fois l’a remontée d’un seul).

Une bonne vieille organisation matricielle, avec une colonne par offre et une ligne par pôle de compétence, ça a aussi du charme, non ?

Je consommé trop d’agilité je pense : j’ai presque envie de dire : laissez l’entreprise s’organiser comme en l’entend, à chaque niveau sur la base des remontées des acteurs du niveau inférieur. Après, c’est peut-être ça qui se passe, mais tout est souvent si opaque…

Quelques idées en vrac :

• C’est une erreur de dissocier conception fonctionnelle (spécifications fonctionnelles détaillées) et technique (dossier d’architecture applicative, …). Un projet doit être conçu dans sa globalité. Faire des itérations de synchronisation entre le fonctionnel et le technique ?
• Distinguer “product breakdown structure” (la décomposition fonctionnelle ou technique de l’application à produire) et “work breakdown structure” (la décomposition du travail à réaliser pour produire)
• Distinguer reste à faire et valeur restant à acquérir. Je réconcilie les deux en comptant mon reste à faire en heures idéales et en évaluant la vélocité en heures idéales. La valeur acquise devrait sans doute être évaluée en faisant intervenir une quantification de la valeur et pas seulement l’estimation en charge.
• “Design to cost” et “Time to market “: deux raisons pour simplifier (et réduire) au maximum ce qui est livré. Contrainte de coût ou contrainte de délai. Comme par hasard (coût, délai, qualité)
• Notion de tracabilité prédictive (vers l’avant). Indiquer a priori quelles exigences devront faire l’objet d’une mention dans le DAT ou dans les specs (et contrôler cette mention une fois le livrable produit)
• Notion de tracabilité multiple : pour être complètement couverte, telle exigence doit être mentionnée dans le DAT, dans les specs, dans les tests, … (évaluer un niveau de couverture)
• Y a-t-il une différence de nature entre le paramétrage et le codage spécifique dans le cadre d’un framework avec suffisamment de valeur ajoutée ?
• Comment trouver une mesure unique de complexité des tâches, alors que l’on fait intervenir des activités très différentes (spécification, conception, implémentation & tu, tests d’intégration, …) Peut-être que la seule mesure réelle est le temps idéal. Un peu l’impression d’additionner des choux et des tire bouchons, mais bon.

Implicitement ou explicitement, le product owner estimera lui en points, quelque chose qu’il lie confusément au service rendu, aux tâches simplifiées, aux économies futures dues à un surcroit de productivité ou au gain de compétitivité avec des fonctionnalités nouvelles. Il pense s’appuyer aussi sur une vision de la complexité de réalisation, mais celle-ci est approximative. Il pense avoir une vision du coût, mais finalement ce qui compte c’est l’analyse de la valeur perçue, bref du prix qu’il est prêt à payer.

Dans tous les cas, il y a un mismatch entre le prix accordé à une user story (ce que je veux bien payer, basé sur ce qu’elle m’apporte) et son coût (ce qu’il faut payer pour l’obtenir). Sans parler des cas où le product owner prétend chiffrer lui même la complexité.

Cela vaut aussi pour la priorité : priorité demandée par le product owner (fonctionnalités dont j’ai besoin opérationnellement), priorité de réalisation (contraintes, fonctionnalités dont j’ai besoin pour tester, pour des économies d’échelle).

Pour les priorités, la réconciliation est relativement simple : le product owner fixe les grandes lignes, l’équipe s’organise dans ce cadre en déplaçant les user story d’une itération à l’autre mais en respectant la priorité des release.

Ca ce gâte quand on discute lotissement en releases, en introduisant les estimations. Le débat est plus compliqué, passionnel.

Il faut intégrer d’autres facteurs, comme la confiance (initiale, puis méritée) qu’à le product owner dans la capacité de l’équipe à avancer, dans la bonne fois de la DSI. Elle s’appuie bien sûr sur l’historique.

Il y a aussi la maîtrise de la “dette technique” de façon à ne pas mettre en danger la productivité future pour des gains à court terme.

• nombre de story points (de user story) réalisés dans une période (une itération, une release) par jour.homme, pour intégrer les variations de capacité de production (vacances, disponibilités partielles). Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Voici le backlog, voici la colonne story points, voici le total, je divise par tel ratio, voici le nombre d’itérations, voici la date d’atterrissage, vous pouvez décaler la release de x mois si on ne change rien.
• nombre d’heures idéales (de tâches) réalisées dans une période (une journée, une itération) par jour.homme. Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Pas évident d’expliquer qu’en une journée on fait 5,8 h idéales et pas 7 ou 8, si ce n’est en le montrant
• % des story points prévus qui ont été effectivement livrés dans l’itération. Pour éviter de trop s’engager à chaque fois et conserver la confiance.
• % des story points prévus et livrés qui ont été finalement inclus dans la release finale, pour évaluer la quantité de changement du périmètre et la rationalité de la priorisation sur laquelle s’est appuyée la planification.
• % des story points des user stories qui ont été ajoutés en cours de release, pour évaluer la stabilité du périmètre. Ok pour accepter le changement, mais ca prend du temps.
• Somme de l’estimation en heures de correction idéales de bugs injectés par itération, pour évaluer la qualité du processus de devt, la surchauffe.
• Etc… (Je n’aborde pas ici l’efficacité directe des rituels, comme la durée du standup ou le temps entre le moment où une idée est évoquée en rétrospective et le moment où elle est prise en compte (ou abandonnée))

L’essence de ces indicateurs est toujours la même. On confronte le projet au réel (demandes du métier, développement et corrections de defects) pour en déduire a posteriori des indicateurs sur le fonctionnement du projet permettant, en s’appuyant sur cet historique des projections sur l’avenir (toutes proportions gardées, le cône d’incertitude se réduisant au fur et à mesure de l’avancement du projet) ou pour identifier des plans d’action (resensibiliser le product owner, améliorer la qualité, …).

Ne pas mesurer le temps passé par les uns et les autres mais bien les progrès effectués par l’équipe.

Inclure des correctifs de la capacité de production quand une personne est absente ou ne l’est pas.

Rester prudent en exploitant ces résultats, les indicateurs ne se stabilisent pas forcément dans le temps. Il faut les assortir d’hypothèses, et assortir les conclusions que l’on en tire de ces mêmes hypothèses.

Le but ultime : annoncer les mauvaises nouvelles dès qu’on les connait pour prendre les mesures qui s’imposent (réduire le périmètre, augmenter l’équipe (à utiliser avec modération), arrêter le projet). Ne pas faire l’économie de l’effort de communication, de préparation du discours (s’appuyer sur des faits et non des impressions). S’attendre à une résistance, un frein à l’action. Personne n’aime annoncer des mauvaises nouvelles ou demander une rallonge.

• Se faire violence pour aller vers ses collègues
• Ecouter les autres et le leur montrer
• Envisager avec sincérité les autres alternatives
• Etayer son discours (de références, de preuves,…)
• Trouver des appuis
• Mettre de l’eau dans son vin, pour espérer faire avaler la coupe. Mettre du vin dans son eau, pour que cela serve à quelque chose
• Négocier point par point, savoir prioriser ses points
• Anticiper les objections
• Ne pas oublier pour qui l’on travaille (qui paye son salaire, qui paye la facture, qui finance le projet…). Ceci dit, un client vous sera gré de jouer le rôle de poil à gratter, si vous êtes habiles.
• Ne pas mettre les autres en porte à faux en leur absence
• Ne pas mettre les autres en porte à faux en public
• Etre irréprochable : on ne doit pas douter de la sincérité de la démarche
• Améliorer le crédit dont on dispose auprès de ses interlocuteurs
• Utiliser le système : prendre la parole en rétrospective, utiliser le bon sens, la bonne foi, puis s’appuyer sur le plan d’action établi.
• Revenir à la charge autant de fois que nécessaire, à chaque retrospective s’il le faut.
• Ne pas attendre de la reconnaissance ou des remerciements, viser juste l’efficacité.

Bref, la politique reste présente, elle se pratique dorénavant vers les côtés, en plus de vers le haut. On est loin des aspirations idéalistes du geek. On parle de guerilla facilitation, l’art de faire avancer les choses sans statut officiel.

Il y a en particulier la valeur agile du courage.

Courage de dire vers en haut (ou même à son client) : non, il vaut mieux faire comme ça, ou même, non, ça n’est pas faisable.

Courage de dire vers en haut : nous en sommes encore à la première itération, il est très prématuré de nous demander des dates. Attendons la fin de la 3ème pour avoir un début de visibilité sur notre vélocité.

La possibilité d’avoir ce courage vient de sa mise en avant comme valeur, mais aussi de l’accord explicite entre le management et l’équipe d’utiliser les méthodes agiles. On peut dire beaucoup de chose à un client qui adhère au discours agile, même si c’est pour de mauvaises raisons.

L’agile est un objet bien pratique. C’est un bel objet, bien marketé par les signataires du manifeste et leurs héritiers. C’est aussi un objet à géométrie variable, qui s’adapte au contexte.

Il faut du coup du courage au coach, puisqu’il y a des degrés de liberté, pour ne pas se laisser embarquer dans la direction qui convient le mieux au management ou dans celle qui convient le mieux à l’équipe. Il doit pousser gentiment tout le monde dans une bonne direction, où l’on se remet en question, où l’on confronte ses idées au monde réel. Il doit donc communiquer sur l’agilité, sans être non plus dans une orthodoxie trop fermée au spécificités du terrain.

Faire parler tout le monde, tous les corps de métier. Refuser de s’engager indument, mais tenir ses engagement. Savoir dire non. Savoir dire oui.

Ce n’est pas si nouveau que ça, mais c’est devenu plus facile.

PS: Ou bien est-ce juste une question de génération, les ex-développeurs étant maintenant aux manettes, et se souviennent-ils du temps où ils étaient dans la boue ?

Une solution consiste à chercher le contact de ses pairs. Si possible de même niveau mais dans des branches différentes de l’organigramme, sans relation opérationnelle avec soi, histoire d’éviter les conflits d’interet (difficile de négocier avec quelqu’un dont on a sollicité l’aide la veille). Le “supérieur” hiérarchique ne peut jouer ce rôle que partiellement, car il a aussi comme tâche l’évaluation. Passer son temps à poser des questions à quelqu’un sensé vous évaluer n’est pas forcément le mieux (ca dépend des cas, ceci dit)

De ces échanges, le jeune (ou moins jeune) manager pourra retirer des bonnes pratiques, des retours d’expérience, une aide à la réflexion sur un cas concret que l’on n’arrive pas à poser, mais aussi peut-être des éléments sur le fonctionnement de l’entreprise, ce qui est toujours bon à prendre (même si dans les potins il y a aussi parfois du faux). Peut-être aussi des éléments sur le consensus ambiant (par exemple : quelle rémunération donner, sujet parfois tabou pour la hiérarchie ? Les comparaisons en la matière sont toujours instructives)

Et puis le manager doit-il vraiment être seul ?

 ”Parce qu’une seule personne décide au final”. C’est faux : la plupart des décisions de fond sont à défendre et faire valider par l’étage au dessus. Et puis, surtout,  l’agilité montre que la meilleure décision est collégiale.

“Parce qu’une seule personne est objectivée sur le résultat du projet”. Ce n’est pas une nécessité. Un manager éclairé m’avait un jour proposé un variable sur le résultat de mon projet plus une somme à répartir entre les membres de l’équipe.

Peut-être que l’aspect du rôle le plus incarné est celui du sens. Donner du sens. Communiquer une image de l’équipe à l’exterieur. Communiquer une image de l’entreprise aux collaborateurs. Avoir une réponse.

 Il y a aussi le rôle d’annoncer les mauvaises nouvelles. Une équipe scrum, même démocratique, répugnera à prendre un collaborateur dans un coin pour lui dire de changer d’attitude. Il faut quelqu’un pour recadrer, même s’il vaudrait mieux que les membres de l’équipe les plus proches du fautif lui en touchent deux mots, en apparté (l’idéal étant la ‘stéréo’ : le chef + les potes)

Et puis j’apprécie mes entretiens de “performance”, il me faut un interlocuteur. Avoir quelqu’un avec qui se poser, faire un bilan, trouver des axes d’améliorations. Je ne sais pas ce qui se passe dans la tête de mon manager, alors. Je ne peux que l’imaginer en étant dans la situation inverse, à essayer de donner des pistes à mes collaborateurs pour qu’ils s’améliorent, en les secouant parfois, en ne cédant pas forcément à toutes leurs attentes, en essayant de trouver des solutions pour qu’ils poursuivent au mieux leur carrière chez “nous”.

C’est peut-être ce “nous” qui change tout. Un manager (dès le premier niveau dans l’organigramme) représente l’entreprise. Et l’entreprise souhaite avoir des collaborateurs autonomes. Donc ses représentants doivent l’être, et se débrouiller seul. Ou au moins, en avoir l’air, même si personne n’est complêtement dupe.

Ne pas concevoir maintenant en faisant des hypothèses sur le futur sans avoir les éléments.
Ne pas supposer que l’on va avoir besoin de quelque chose. Ne pas supposer que l’on ne va pas avoir besoin de quelque chose.
(cf Options Thinking dans Lean Software Development de Mary & Tom Poppendieck)

Avec agilité, mais avec clarté

Concevoir quand même à chaque itération, en équipe, pour bénéficier d’un maximum de créativité, pour partager la conception. Poser vraiment le problème, à fond.

Ne pas aller trop vite, aller assez vite

Prendre le temps d’étudier les différents scénarios, les critères selon lesquels on va les retenir, l’évaluation des scénarios afin de prendre la bonne décision.

Concevoir dans un intervalle de temps limité (ex: réunion de conception de 15h à 17h30, pas plus). Cela oblige à se concentrer sur l’essentiel.

Articuler besoin & solution

Concevoir et affiner sa conception en articulant les différents niveaux de besoin et solution.
J’ai besoin d’un historique règlementaire pour ça je logge tout dans un fichier pour ça j’utilise log4j et la programmation orientée aspect
Bien distinguer besoin (pourquoi) et solution (quoi). La solution d’un besoin devenant un besoin attendant lui même des solutions.
Ex:

Besoin = historique règlementaire, Solution = log dans un fichier
Besoin = log dans un fichier,Solution = log4j + POA
J’ai appliqué cette approche à mes initiatives open-source, cf http://softreves.wordpress.com)

Confronter sa conception au réel, au fur et à mesure.

Le réel ca peut être de tenter de l’implémenter et voir comment ça vient.
Le réel ca peut être d’élaborer des exemples et voir comment ils sont traités par l’algorithme.
Le réel ca peut être un collègue qui fait une revue de conception pour voir si elle est bien posée, si on n’a rien oublié d’évident.

Laisser faire le temps

Laisser reposer un peu, aussi, pour que les neurones et les synapses communiquent en vous et maturent l’idée.

Avec le courage de défaire et refaire

Et puis si, confronté au réel, quelque chose cloche, avoir le courage de remettre ses plans sur le métier, en particulier de prendre le temps de le faire.
Plus tard, si confrontée à de nouveaux besoins, la conception qui a été implémentée est maintenant inadéquate, re-concevoir, re-factorer (grâce à une couverture par les tests automatiques élevée).

Inversement, j’ai récemment répondu à un twitt de @bcourtine qui demandait s’il fallait rentrer dans subversion les fichiers de conf de Eclipse, i.e. s’il fallait que les environnements de tous les membres de l’équipes soient identiques, s’il fallait uniformiser ces environnements de développement. Je pense que oui, je pense que l’équipe doit échanger sur les pratiques et se mettre d’accord (dans le cadre du projet précis qui lui est confié). Je pense aussi que c’est un pré-requis indispensable à la construction de scripts ou d’outils de productivité innovants, parfois propres à chaque projet. Il a très bien détaillé son point de vue sur son blog.

J’en reviens à mon délire sur le personnage de l’Oracle. Il faut que les membres de l’équipe, des équipes, puissent s’exprimer, apprendre, inventer, tester, construire. Pas seulement pour leur motivation, cela importe aussi pour leur éducation et donc leur valeur.  Il faut aussi qu’ils échangent, qu’ils confrontent, qu’ils partagent. Est-il vraiment indispensable de leur offrir de ce fait un ennemi commun, la direction de projet qui n’y connait rien ?

Peut-être cela a-t-il aussi à voir avec l’artisanat logiciel. L’artisant est un expert, mais aussi un designer et quelqu’un qui organise toute sa production pour concilier les pôles de son activité : produire de la valeur et de la qualité, tenir ses engagements de budget et délai, innover car le marché innove.

Croire que l’on peut appliquer pendant des années des pratiques vieilles de plus de trois ans et des socles techniques aussi agés me semble une douce illusion.

CMMI n’est pas incompatible avec l’innovation. Ce qui est incompatible c’est l’idée anti-agile que la nature des innovations ne peut venir que d’en haut. L’innovation vient des échanges et de la confrontation au terrain, ainsi que de la confrontation aux idées passées et présentes. Cela n’est pas possible si chacun bosse dans son coin. Cela n’est pas non plus possible si la direction n’alloue jamais de budget pour tester ou capitaliser un test reussi.

Je pense en particulier au renversement des choses. C’est l’équipe qui prend la main sur certains aspects dévolus jusque là au chef de projet. Pour le web 2.0 c’est le visiteur du site (le client) qui alimente une partie du site (commentaires, …). Dans les 2 cas, il y a un courant issu de la base vers le haut.

Il y a par ailleurs une vision très pragmatique des choses, démocratique. On vote pour estimer une user story. On vote pour qualifier l’intérêt de tel ou tel produit.

Maintenant, les sites qui ont du 2.0 ne sont pas que cela. La publicité, le contenu éditorial ou marchand continuent d’exister, mais l’adéquation est plus grande.

De même, le projets agile ont un budget, des sponsors, des contraintes. C’est juste qu’ils se passent mieux, qu’ils atteignent mieux leurs objectifs.

Quand je parle d’agilité à des non informaticiens ils me regardent avec des yeux ronds : comment avez-vous pu imaginer procéder différement si longtemps ?

Pourtant il ne faut pas oublier que nous évoluons nous mêmes dans le temps. Par exemple j’ai débuté comme développeur, puis chef de projet, puis architecte, puis… A chaque époque (à chaque contexte ?) ses outils, ses préoccupations. Le même article me parlera différemment maintenant et par le passé. Comment même savoir ce qu’il m’aurait apporté dans le passé ?

Tout ce que je peux dire c’est ce que j’ai trouvé sur internet pour les développeurs à l’époque où je l’étais, puis pour les chef de projet à l’époque où je l’étais, …

J’ai la sensation d’une évolution, mais qui a évolué : le monde ou moi ?

Ca me fait penser à Héraclite (?) : Un même homme ne peut pas se baigner 2 fois dans le même fleuve. La deuxième fois ce n’est plus le même homme ni le même fleuve.

Elle fait partie du système, mais elle est là pour que les humains s’intègrent au système, pour qu’ils aient la sensation d’avoir leur mot à dire, d’être maîtres de leur destin, tout en revenant dans le giron du système à la fin.

Cet “empowerment” des humains me fait penser à l’agilité, et au rôle du chef de projet dans un contexte agile. Au final, il faut que les choses soient faîtes, que les contraintes soient respectées. Pourtant, les décisions doivent venir de l’équipe.

Cela vaut aussi pour le recrutement ou l’encadrement dans une SSII. Il faut que le collaborateur s’y retrouve, qu’il ait la sensation de progresser. Et pourtant il faut que les choses soient faîtes, que les contraintes soient respectées.

La beauté du personnage de l’Oracle est qu’elle croit sincèrement oeuvrer pour le bien commun, malgré ses contradictions. Et vous ?

• Moi : Comment tu fais pour coder ?
  • Lui : Quand je démarre une tâche de développement, je me lance sans conception et ça marche très bien.
• Lui : pourtant j’ai lu “Coder proprement“.
  • Moi : Regarde la notion de design patterns, lis le gof (ou un autre bouquin plus récent sur la notion de patterns)
• Moi: Comment font tes collègues ?
  • Lui : Ils font de la conception (diagrammes sur papier) avant de se lancer.
  • Moi : Il y a des gens qui raisonnent “visuellement”, d’autres différemment. Peut-être est-ce ton cas ?
• Moi : Regarde la conception émergente. (Etape par étape, sans anticiper)
  • Lui : Mais ce n’est pas de la conception si tu le fais pas avant
  • Moi : Tu le fais au fur et à mesure. Ca marche. J’ai réussi comme ça à implémenter des choses vraiment compliquées en très peu de temps.

• Méthodes agiles. Customiser le mode de fonctionnement pour chaque projet. Notion de cône d’incertitude pour expliquer que les estimations initiales sont très aléatoires. L’idée d’abaque de chiffrage est impensable
• CMMI. Formaliser les pratiques, donc les uniformiser pour tous les projets, jusqu’à faire des statistiques (des charges, mais aussi des taux de defauts, …)
• Software craftsmanship. Emphase mise sur les pratiques d’artisanat (parfois par opposition à l’ingéniérie).

On les oppose, mais dans un contexte réel, il faut plutôt chercher à la articuler, à les faire coexister.

En effet, les méthodes agiles me semblent parfois être le rêve fou de développeurs qui ont pris le pouvoir. Software craftsmanship de vieux développeurs expérimentés, pour les “techniques” par opposition aux gestionnaires, pour la créativité individuelle par rapport à l’uniformité et à la norme. CMMI de chefs de projet (et encore il y a PMBOK), PMO et ingénieurs qualité. Tous ces profils ont leur place dans un ecosysteme.

Chaque contexte se fait sa sauce. A quand un paradigme chapeau ? Voire un guide avec pour chaque aspect des alternatives avec chacune ses conditions d’application ? Et une cross-fertilization (enrichissement mutuel d’approches différentes) ?

Vous pouvez le trouver ici, cette liste sera mise à jour régulièrement.

J’apprécie toujours autant l’idée que l’on jette sciemment des actions à la poubelle sans même y prêter attention :-)

La “cross-fertilization” (terme issu du brainstorming) c’est l’apparition de nouvelles idées du fait de la mise en regard de deux thèmes que l’on ne met pas en regard d’habitude. De cette confrontation naissent des idées.

Faire des passes sur son code en le considérant uniquement sous l’angle de la lisibilité, comme un texte qui doit être lisible. Indentation, espacement. Intention. Titres, sous-titres.

Inversement, il serait productif d’appliquer à la rédaction des (longs) documents des principes tirés de la gestion de corpus de code assez volumineux : règles de nommage, homogénéité, mais aussi principes objets (ne pas multiplier les niveaux d’héritage, …)

Considérer les modèles de document/les plans types comme on considère des design patterns. Condition d’application, structure / guide d’utilisation, combinaison de plusieurs “documents patterns” pour un document final.

Faire des statistiques sur les mots “flous” dans un document pour déterminer son niveau d’aboutissement (je ne pense pas uniquement aux TBD)

Uniformiser la production du document final, travailler uniquement sur la créativité + le contenu + les méta-données, générer le produit fini automatiquement (uniformité, look léché, productivité)

Outils de CMS appliqués à la rédaction de documents ?

Je pense qu’on peut généraliser cette confrontation au réel au quotidien, à de nombreuses activités.

Par exemple, il y a une différence entre

1. se dire ce que l’on va mettre dans une présentation
2. être assis devant son portable et faire vraiment la présentation en 20 slides maximum avec si peu de place (ou trop de place)
3. être debout devant tout le monde et dérouler sa présentation en 50 minutes maximum avec tant de choses à dire (ou si peu à dire)

Passer du théorique à la rédaction/conception/devt, puis passerà la confrontation des pairs (au test), puis aux clients. Et faire cela souvent.

Identifier les tâches, les ressources, les contraintes d’affectation.

Estimer les tâches

Estimer les dépendances (strictes ou pas)

Une fois que c’est clair, la date se calcule toute seule.

Et ce n’est qu’alors que l’on doit la mettre en regard des contraintes de dates, et revoir l’ensemble si ca ne “rentre” pas, en priorisant à la baisse certaines tâches, en acceptant explicitement de prendre le risque d’en paralléliser d’autres, …

L’acte de  planifier en mode agile se fait en équipe, pour que chacun puisse contribuer : contrainte à laquelle on n’a pas pensé, tâche que l’on n’a pas explicitée, …

Ne pas se focaliser non plus sur la tête qu’il aura dans MS-Project, mais bien sur le découpage le plus adéquat, le plus proche du mode de fonctionnement réel.

Et puis, un de mes mentors m’a indiqué qu’il dressait son planning sous excel et n’utilisait MS-Project que pour le communiquer (en ressaisissant les éléments à un niveau de granularité faible).

Pour moi, on ne peut pas dissocier le temps (3j) de ce à quoi il est consacré. Ca change tout de savoir que :

• pour cette tache on a du faire un refactoring de toute l’application
• pour cette tâche on a du changer de version de composant …

La vraie question c’est plutôt :

• fallait-il ou non faire ces tâches annexes ?
• quel niveau de qualité fallait-il se fixer ?
• Ces choses ont-elles été décidées officiellement ?

Ensuite, il faut rappeler un point : le problème n’est pas que le chef de projet avait prévu 2j, on peut aussi bien passer 4j.

Le problème c’est que l’on a vendu 2j (de budget) ou une date.

Sur la base de quoi ?

Avait-on fait une analyse profonde des caractéristiques des tâches, des tâches sous-jacentes ?

Dans CMMI on capitalise un modèle de charge à passer (en moyenne), mais il n’est pas toujours assez finement paramétré par le niveau d’exigence du client ou les spécificités du projet.

Dans les méthodes agiles, il y a la “definition of done”, mais elle est générale (pour qu’une tâche soit finie, il faut avoir mis à jour la javadoc, passé tous les tests, …) alors que les décisions à prendre sont “locales” : ai-je besoin du même niveau d’exigence ergonomique pour les écrans d’administration, …

Bref, il est surtout urgent se concerter, de faire valider par le décideur (chef de projet ou product owner).

Et s’il faut utiliser des statistiques, d’utiliser des statistiques portant sur le projet en cours (velocité), si tant est qu’il n’ait pas évolué dans la nature de ses tâches (architecture technique stabilisée, bugs suite à mise en production, …).

Ceci étant dit, il convient de s’adapter au mieux à la réalité du projet : personnalité de l’équipe, historique commun ou non, expérience des uns et des autres, …
En particulier renoncer à avoir une norme agile au niveau de l’entreprise.

Cela revient à opposer agilité et CMMI : définition d’une norme, respect de cette norme, optimisation basée sur des statistiques sur les autres projets, …
Sauf à identifier au niveau CMMI un certain nombre de pratique, leur domaine et conditions d’application, les dérogations possibles, les interdépendances (pas de campagnes de refactoring sans tests unitaires automatisés,…)

Si CMMI est la norme, s’il faut expérimenter et quantifier pour adopter, eh bien allons y. Expérimentons et quantifions.

Et soyons souples sur le terrain, en “oubliant” peut-être de préciser tous les détails d’implémentation lors des revues CMMI…

Peut-être que pour finir de se généraliser, l’agilité devrait renoncer à son nom. Pousser les pratiques en faisant appel au bon sens, unitairement, au lieu de faire un agile big bang. Le but n’est pas d’avoir 100% des projets estampillés agiles. Le but est d’améliorer 100% des projets pour qu’ils atteignent leurs objectifs métier. Ne pas renoncer non plus à l’évangélisation, mais essayer de ne pas faire trop peur.

Capitaliser sur les bonnes pratiques, extraire des éléments réutilisables dans ce qui a été mis en place concrètement pour un projet (au lieu d’implémenter dans le vide du code transverse).
Pas de grande théorie ou de consensus préalable.
Pas de solution générique, mais faire émerger des patterns, en mutualisant les aspects fastidieux.

Concentrer ses forces sur un petit nombre de cibles, pour être pertinent et efficace.

Eviter les gros chantiers à effet tunnel, se mettre au contraire en situation (migration à blanc, démonstrations et retours utilisateurs, mise à disposition d’un environnement de test par les utilisateurs).

Surtout : apprendre au fur et à mesure, ne pas hésiter à jeter quand on comprend mieux les besoins, et l’outil (contraintes, forces).

Parade, recommandée par les formations Krauthammer : se préparer par écrit.
Ne pas aller à une réunion sans une liste des points à soulever, des réponses à obtenir, …
Cela libèrera l’esprit sur place, et vous pourrez, préparé, être plus réactif, plus souple (paradoxal, non ?)

Même si vous faites votre liste 5 minutes avant le début (mieux vaut prévoir un délai plus grand, parce que dans l’élaboration de votre liste, vous ferez des comparaisons fructueuses, et aurez des questions, des compléments à apporter avant la réunion).

Et dans le même esprit, si vous préparez une présentation ou une formation, imprimez vos notes séparément, écrit gros (visibles de loin), agrafées… Vos capacités cognitives doivent être au maximum disponibles pour les interactions.

Nos rêves de soft doivent sortir de nos têtes et se confronter au monde réel : contraintes (de temps de réalisation, de fiabilité, …), échanges critiques.

Reste aussi l’activité d’inception, si elle sait faire la part des choses entre besoin et solution (cf http://softreves.wordpress.com)

Des développeurs contre les chefs de projet et les méthodologues qui prétendent leur dire comment faire ou comment penser ou comment s’organiser. De l’abolition de la hiérarchie au sein d’un projet, en mettant tout le monde sur le même plan. Du raz le bol des développeurs qui n’aiment pas rédiger de la documentation ou suivre un plan et une attribution des tâches.

Mais aussi des chefs de projets à leur tour contre les managers de Business Unit et les contrats au forfait.

Tout ceci a un côté très lutte de classes. La direction me semble bonne, mais il ne faudrait pas jeter le bébé avec l’eau du bain.

• in : les contraintes internes : moi je veux bien fournir un service qui renvoie le nom du client mais pour ça il faut me donner l’id du client ou une autre manière de le retrouver
• out : les contraintes d’utilisation par l’extérieur : moi j’ai besoin d’un service qui me ramène la liste des dossiers du client, je ne veux pas appeler n fois le même service

Cela vaut aussi pour l’organisation des équipes qui gèrent une famille de services :

• in : pour intégrer au mieux les contraintes internes, il faut les connaitre, donc les membres de cette équipe gagnent à rester au sein de l’équipe un minimum, à tourner sur les différents services gérés par l’équipe pour connaître au mieux le métier, etc…
• out : pour adapter les services au mieux aux contraintes externes :
  • ne pas réaliser les services par anticipation. Ne pas décider maintenant des besoins futurs (ou de l’absence de besoins futurs). Réaliser les services pour un (idéalement 3) projets actuels qui en ont besoin tout de suite
  • les membres de l’équipe “services” devraient être détachés au sein du projet une partie de leur temps, pour concevoir avec le projet les interfaces, pour les assister dans l’intégration, les jeux de données (les fameux bouchons), … Ils seront d’autant plus conscients des contraintes du projet, sauront au mieux justifier celles de l’équipe. Et les projets seront naturellement synchronisés en terme de planning.

Encore faut-il savoir poser la bonne question, la bonne combinaison de mots clefs qui va permettre d’obtenir la meilleure liste de réponse. Pour cela, il faut déjà connaître un peu le sujet, la problématique, pour pouvoir canaliser le moteur de recherche.

Par ailleurs, quand on survole un résultat de recherche, tout dépend de son état d’esprit, des documents que l’on vient de lire, de sa façon d’aborder le problème sur lequel on se documente, du contexte concret du problème, des idées que l’on a eu, de l’ordre dans lequel on a lu les documents précédents, du temps dont on dispose.

Ne pas lire trop de documents. Faire une sélection de 5 ou 6 sources bien choisies. Les comparer. Décider dans quel ordre les lire.  Les lire indépendamment en prenant des notes. Organiser les notes au fur et à mesure (avec un outil de mindmapping comme xmind ou au moins avec le mode plan de word). Faire cet exercice en ayant bien en tête le but (présentation à produire, décision à prendre et à argumenter, …)

La force de conviction est indépendante de la pertinence du point de vue.

En particulier en ces temps agiles où l’on se remet plus en question, ayant paradoxalement du coup l’air d’être moins sûr et ayant pourtant un point de vue beaucoup plus adéquat.

• que l’on pense que l’on peut changer les choses
  • y-a-t il un intérêt à changer les choses
  • sera-t-on assez convaincu pour être convaincant (sans parler du fait qu’il vaut mieux garder un peu de recul pour trouver les meilleurs arguments)
  • pourquoi serai-je mieux placé que les autres pour changer les choses ? pourquoi moi et pas un autre ?
• que l’on est prêt à prendre le risque de proposer autre chose, que l’on accepte la possibilité d’un échec
• que l’on soit prêt à répondre à la question : “qu’est-ce que tu y gagnes”
  • parce que l’on y gagne quelque chose
  • ou pas (quand on est altruiste)
• que l’on connaisse le sujet  / le problème suffisamment pour être pertinent
  • en particulier parce qu’on l’a creusé (sans avoir eu l’aval de consommer de la charge dessus)
  • par ce qu’on a échangé dessus avec ceux qui savent (sans avoir la légitimité)
  • malgré un manque d’expérience (pour prouver que l’on a l’expérience de faire une chose pour la première fois, il faut l’avoir déjà faite. pas simple)
• que l’on soit prêt à exprimer une opinion non sollicitée (on s’expose à l’indifférence ou au rejet)
• que l’on accorde plus de crédit à sa propre opinion que le consensus mou existant, qui s’appuie sur l’expertise et l’expérience accumulée
• que l’on franchisse le fossé qui sépare l’idée de l’action, malgré un agenda chargé par ailleurs, avec des tâches priorisées, elles
• que l’on empiète sur les prérogatives de sa hiérarchie avec les risques de conflit vertical que cela comporte.

Mais il faut, avec mesure et bon sens, sortir de bois. C’est la seule façon de faire avancer les choses, de recadrer un effort collectif, de prendre du galon. Une fois que vous serez sorti du bois, on attendra de vous que vous sortiez à nouveau, à bon escient, mais souvent.

Il y avait le développeur, le team leader, l’architecte, le chef de projet…

Chacun s’occupait de sa paroisse. L’architecte de la qualité des devts. Le chef de projet des délais. Le team leader du moral des troupes. Etc…

Maintenant que l’équipe s’organise comme elle le souhaite, les choses sont plus fluctuantes.

Tant mieux.

A condition que les débats s’organisent tous seuls autour des vrais axes. Arbitrage entre qualité et budget. Arbitrage entre veille techno et impératifs de délai.  Entre impératif pour l’équipe et formation des uns et des autres. Etc…

Peut-être faut-il quand même toujours un meneur de jeu, qui vérifie que l’on continue à se poser les questions (sans y répondre).

Le meilleur meneur de jeu étant celui qui s’efface, une fois son travail de mise en situation fait, derrière les joueurs et leur interprétation, les laissant libres et créatifs…

Un gros projet c’est plus de personnes, chacune avec un rôle plus spécialisé, et puis avec de nombreux intermédiaires. Du coup la responsabilité est diluée. Et si la responsabilité est diluée, disparaît la capacité à réagir, mue par une volonté claire qui dépasserait les clivages

Un gros projet c’est des réunions avec plus de personnes, une combinatoire en n2 du nombre d’interactions au sein de ces réunions, des réunions qui durent longtemps, les participants qui se désintéressent, les listes d’action qui s’allongent.

Un gros projet ça fait des fois x3 le budget.

Un gros projet ça échoue même parfois. Ou pire, ça dure sans qu’on arrête les frais…

Je pense que c’est en partie du au fait que chaque action vient avec sa grille de perception, son filtre (polarisé vers une direction précise). Quand on fait une chose précise, toutes les informations qui arrivent sont passées au crible de ce but : est-ce que ce document va m’aider dans cette tâche, …

Changer continuellement de tâche reviendrait à changer continuellement de grille, à remettre en question continuellement ces grilles successives, à remettre en question les tâches.  Peut-être est-ce cela l’explication du surcoût de trop de “context switch”. Trop de réflexion tue l’action.

En revanche, entre les tâches, ou avant de commencer la journée, ou après l’avoir finie, prendre le temps de regarder les actions à venir (sous forme de liste et non plus dans le détail), pour comparer, prioriser, …

Bref, un moment pour l’action, un moment pour le recul.