Software Freethinker

Ce livre est une déception. Il est à côté de son sujet et s’intéresse plus au refactoring ou au TDD et au mieux aux interfaçage avec les outils de test d’acceptance. La presque totalité du travail avec les acceptance tests est passé sous silence. Pire, j’ai eu l’impression que l’auteur « s’écoute coder », mais même ces trop longues parties ne parviennent pas à être intéressantes. Peut-être cela l’est-il d’avantage en « live »…

La seule conclusion valable de cette lecture est qu’il faut donc que je m’attaque au fameux « specification by example » pour rattraper tout ça.

La seconde partie « collecting and analysing your team data » est nettement plus importante, avec 90 pages et 4 parties. Il débute avec la chapitre 3 « trends and data from project-tracking system » qui occupe 24 pages. On commence fort avec une orientation forte : abandonnez votre management visuel physique pour ne garder que l’outil électronique (ici Jira). La capacité de tracking semble avoir le pas sur le bien-être de l’équipe… C’est néanmoins l’un des chapitres les plus clairs. Mais les mesures tournent beaucoup autour de la productivité et des temps de développement.

Le chapitre 4 évoque sur 20 pages les métriques issues du système de versionning, en l’occurrence Github. Comprendre comment extraire des données de Github est réellement intéressant. Ici, c’est surtout le volume de lignes modifiées, l’activité de l’équipe autour des commits, le délai entre pull request et commits ou la présence de commentaires qui sont regardés. Je ne suis pas certain que le CLOC soit une mesure si pertinente, alors que la corrélation entre tâche et impact des changements dans l’espace (nombre de classes, nombre de packages) aurait donné un éclairage en terme de qualité. J’ai bien aimé l’idée de la mesure du « lagging pull », de l’interprétation des commentaires, et aussi la corrélation avec Jira, mais en fait guère plus.

Au chapitre 5, ce sont intégration continue et déploiement continu qui sont à l’honneur, et c’est Jenkins qui illustre cela. La chaine de build et les informations exploitables de Jenkins sont bien abordés, apparemment cet aspect est l’un des points forts de l’auteur. Malheureusement encore, l’auteur échoue à produire des diagrammes traduisant clairement son propos. J’imagine qu’ils sont moins hermétiques quand on est dans le projet, mais c’est assez douloureux pour le lecteur…

Cette seconde partie se referme sur la chapitre 6 qui se focalise sur la surveillance de la santé du système en production. C’est sur New Relic et StatsD que la collecte de ces informations repose. Un chapitre très intéressant aussi bien sur la finalité des mesures que sur quelques clés de mise en place. Dommage qu’il n’y ait pas de corrélation avec les autres mesures. Je pense que l’on aurait pu faire quelque chose, ne serait-ce que pour montrer l’évolution des tendances entre 2 mises en production…

La troisième partie agrège ce qui a été vu précédemment pour donner de l’information de plus haut niveau. Du moins est-ce l’idée. 4 chapitres sur 95 pages sont consacrées à cela. On commence par le chapitre 7 qui explore l’agrégation des données collectées sur 25 pages. Plutôt que donner des mesures standard, l’auteur y expose sa méthode pour créer des mesures agrégées. C’est un peu ennuyeux, à part l’utilisation de mind map pour explorer les questions. Le cas d’étude sur la « continuous release quality » n’est pas aussi passionnant qu’il devrait.

Le chapitre 8 traite de la qualité interne du logiciel, les fameuses « illités » au long de17 pages. Il s’agit surtout de métriques de maintenabilités, s’adossant essentiellement à des mesures de temps de cycle et de couverture de code, ce qui n’est pas génial, car il s’agit là d’indicateurs « proxy ». L’usability est abordée, mais de manière franchement superficielle.

Le chapitre 9 traite d’un sujet d’un peu plus haut niveau : la publication de métriques. La question occupe 23 pages qui rassemble des aspects tels que : quelles informations pour quels acteurs ? Comment publier ? Comment adapter le mode de publication et la fréquence aux acteurs ?

La 3ème partie se referme sur le chapitre 10 qui évoque les métriques par rapport aux principes agiles. Encore une fois l’auteur interprète les choses assez singulièrement. Par exemple, on utilise des informations de Jira pour mesurer le « face to face conversation ».

Au global, le livre est une déception. J’ai été aussi pugnace que possible, mais l’ennui m’avait déjà largement gagné au chapitre 7. Pourtant, on part de bonnes idées, celle de collecter des informations de différentes sources et de les corréler. Mais d’une part, ces idées prennent une direction qui n’est agile qu’à moitié. Et d’autre part la forme échoue à être intéressante. J’aurais d’avantage imaginé un découpage par domaine de pratique et des propositions de métriques sous la forme de patterns, ciblant à chaque fois une nature d’information actionnable et les corrélations de données nécessaires à sa construction.

Référence complète : Agile Metrics in Action – Christopher W. H. Davis – Manning 2015 – ISBN : 978 1 617292 48 4

Référence complète : Workflow Management : Models, methods and systems – Wil Van der Aalst & Kees Van Hee – MIT press 2002 – ISBN : 0-262-01189-1 (V.O. : Workflow Management : Modellen, Methoden en Systemen, Academic Service 1997)

Scrum, c’est une structure très simple, une Scrum Team composée d’un PO qui fait le lien avec le monde extérieur et une équipe de développement pluri-disciplinaire. Des artéfacts réduits au minimum, avec un Product Backlog et un Sprint Backlog.

Le Sprint, l’unité de temps de Scrum a une structure bien définie, elle commence avec le planning meeting et se conclut par le Sprint Review, puis la rétrospective. Mais ce n’est pas la seule façon de faire ! La cadence des rétrospective peut être décorrélée des sprints. De même, si les Sprint Reviews donnent la cadence, le planning meeting peut suivre une autre régularité. D’ailleurs en Kanban, ce dernier disparait pratiquement !

Pourquoi ça marche ?

Parce que l’approche agile diminue les risques ! Les gros projets ont une méchante habitude : ils échouent ! Pour l’auteur, un gros projet s’assimile à un tir au canon : de longs calcul, un seul essai… qui a toutes les chances de rater la cible.

Le projet agile serait plutôt un missile à tête chercheuse, capable de réajuster sa direction en permanence !

Le « big risk » du projet classique est transformé en « mini-risques » qui sont autant d’incréments. Des incréments qui ne sont pas des étapes de construction mais des tranches de fonctionnalités, des niveaux d’accomplissement du besoin. Les éléments principaux de la recette ?

Des équipes pluridisciplinaires, où les membres travaillent ensemble et se complètent.

Un focus sur l’optimisation de la valeur, et non des fonctionnalités livrées (et encore moins de l’occupation).

Revenir au « pourquoi » et identifier les options qui s’offrent à nous, comme nous le faisons avec l’impact mapping

Parlons planning

L’entreprise est un milieu différent, plus difficile. Il nécessite certaines règles. En effet, on va impliquer dans des jeux des collègues mais surtout des supérieurs hiérarchiques dont notre salaire dépend ! Livia nous propose 2 axes :

Le « cercle magique » : On fait du lieu et du temps de jeu un espace où les règles du monde extérieur ne s’appliquent pas.

Faire du « hors site », pratiquer les jeux dans un contexte différent pour signifier le changement de contexte.

Enfin l’oratrice nous expose comment le savoir-faire de la création de jeu peut aider à construire la vie et la progression professionnelle en entreprise. C’est l’attitude du « game designer ».

Tout d’abord, le parcours professionnel peut être conçu comme un parcours de jeu, avec des niveaux (débutant, régulier, enthousiaste), avec des moments de repos ménagés entre ces étapes.

Il faut aussi concevoir et prendre en compte l’échec, qui sera plus fréquent que le succès.

S’appliquer à aller vers une logique de volontariat.

Considérer la notion d’équité : il n’y a pas de hiérarchie dans le jeu.

Pourquoi les jeux sérieux, avec Raphael Goumot

La première réponse de Raphael est : créer une vision en fabriquant de la cohésion, et ainsi permettre la création d d’un plan d’action. Le jeu sérieux s’oppose au « blah blah meeting », il améliore la qualité de ce qui est produit et brise les biais cognitifs.

Les ateliers proposés par les jeux sérieux (la référence « gamestorming » en propose 80 !) permettent d’impliquer le client, de la faire participer pour qu’il apporte les éléments de réponse qu’il détient.

Au-delà d’organiser le travail en groupe, les jeux sérieux nous permettent de revenir à l’émotion, à visualiser et imaginer. Les relations entre les participants deviennent plus symétriques, ce qui nous permet de passer de la participation à la co-production.

Fin de soirée

Ce n’est pas très facile de transcrire l’énergie et la passion des 2 orateurs de la soirée. Sans parler du « fun » de Raphael qui s’est évertué de m’appeler « Stéphane » sans discontinuer.

La quatrième partie s’articule autour du Scrumban. L’idée du Scrumban est surtout celle d’une transition de Scrum vers Kanban. Elle démarre avec le Scrumboard que l’on migre vers un flux tiré, en s’aidant de WIP. Avec le Scrumban niveau 2, on travail autour de petites tâches, rendant inutile l’estimation et la « prochaine chose utile à faire » qui rend obsolète le planning meeting. La fin de cette partie avec ses considérations autour du flux, de la bande passante et de l’architecture est un peu ardue.

La 5ème partie nous propose de considérer le fonctionnement d’un système Kanban. On commence par le Daily Standup Kanban, très différent de celui de Scrum. On s’intéresse au mode de fonctionnement avec le business qui s’axe sur la priorisation « on demand » et le SLA de l’équipe de développement. La gestion des défauts fait le lien avec la partie suivante.

C’est à la gestion des queues et des buffers qu’est consacrée la sixième partie. Un propos assez technique qui évoque les notions d’asynchronisme, de buffer partagé et de WIP regroupant buffer et traitement (comme dans le getkanban) ! Le fonctionnement des features / bucket brigades n’est pas facile à suivre, même si l’auteur fait un effort important de nous y conduire progressivement par son raisonnement.

Enfin, la 7ème partie est consacrée à la planification. L’auteur y développe plusieurs concepts tels que l’IFR (Ideal Final Result) et le priority filter. Le plus utile reste cependant le « perpetual multivote » !

Ne vous laissez pas leurrer par le format réduit de cet ouvrage. Il s’agit d’agilité niveau Jeidi ! Dans ses essais, l’auteur porte une grande attention à nous faire suivre son raisonnement pour nous amener à un fonctionnement final. On regarde au long du texte le Kanban sous plusieurs angles, en amenant des techniques de fonctionnement complémentaire au Kanban que nous connaissons. Bref, un beau condensé d’expertise pour nous aider à réfléchir et à aller plus loin !

Référence complète : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149

De l’équipe à l'individu

Scrum insiste beaucoup sur la notion d’équipe et l’auto-organisation. C’est la raison principale pour laquelle il n’y a pas d’autre rôle qu’équipier au sein de l’équipe de développement. On doit travailler ensemble pour traiter une User Story et c’est ensemble que l’on escompte atteindre l’objectif de Sprint.

Et soudain, au stand-up, c’est à l’accomplissement individuel que l’on s’intéresse. Pas à la user story si on y a travaillé à 3, mais à la part que chacun y a pris. Une bonne façon d’induire les comportements individualistes dont on voulait se débarrasser en premier lieu. Plus souvent, cela conduit les équipier à s’approprier individuellement des items de backlog. Autant pour l’esprit d’équipe !

Mais ce n’est pas fini.

Les auteurs de Scrum nous suggèrent aussi de mettre à jour le reste à faire des tâches. En heures. Nous nous éloignons encore un peu plus du regard vers l’objectif de sprint. De la valeur ou de l’impact, nous portons maintenant notre attention sur la quantité de travail.

Du Scrum praticien au Scrum Zombie

La mise à jour du reste à faire induit aussi une autre logique : celle de la justification. Finalement notre logique du reporting, celle que nous avions sorti par la porte, est de nouveau rentrée par la fenêtre. Une logique encore agravée par les fameuses 3 questions. Car la première d’entre-elle est : « qu’ai-je fait hier ? ». Comme il s’agit de la première question, ce sera celle à laquelle on accordera le plus de temps et d’attention. Pourtant ce point est purement informatif, et ce sont bien les deux autres questions qui doivent nous aider à prendre des décisions et à nous organiser. Ce devrait être le but premier du stand-up. cette adhésion aveugle à une consigne est aussi la manifestation d’un autre phénomène : Le Scrum Zombie.

Le Scrum Zombie dévoile sa face hideuse lorsque la forme prends le pas sur le fond. Ses lieux de manifestation favoris sont la rétrospective et le stand-up. En focalisant sur la routine et la tyrannie du chronomètre, l’équipe finit par perdre de vue le contenu lui-même :

Quel intérêt offre l’information sur ce que j’ai fait ? En quoi cela va aider un de mes équipier à prendre une décision ? Cela va-t-il leur permettre de me donner un feedback qui va m’aider ?

Les informations sur les problèmes que j’ai rencontré ou sur ce que je compte faire peuvent-ils influer d’une manière ou d’une autre sur l’adaptation tactique de notre plan d’action ? Cela peut-il aider mes collègues à me proposer leur aide, ou à moi-même de proposer la mienne ?

Quand pour la dernière fois avez-vous pensé à l’une des questions ci-dessus en prenant la parole lors du stand-up ?

C’est bien, vous utilisez le stand-up pour synchroniser l’information au sein de l’équipe. L’information échangée a de la valeur. Hélas, même là le stand-up peut dégrader la qualité de l’interaction au sein de l’équipe !

Quand le stand-up retarde la circulation de l'information

Pour certains, le stand-up est le moment réservé pour parler avec les collègues afin de ne pas déranger ceux-ci durant la journée. C’est plutôt une bonne idée : ne pas déranger ses collègues et ne pas perturber leur concentration pour une information qui peut attendre.

Mais toutes les informations ne peuvent pas attendre. Il y a des choix de conception qui peuvent impacter ce que font vos coéquipiers si ils dépendent du module sur lequel vous travaillez. Certains refactoring assez larges entrainent des modifications qui ne sont pas anodines pour vos voisins. Vous avez pu obtenir une information importante pour l’ensemble de l’équipe et qui remet en cause un de vos postulats. On pourrait trouver bien d’autres exemples.

Dans les cas que nous avons cité, attendre pour informer le reste de l’équipe est le meilleurs moyen pour générer du gâchis et du délais, sans parler de la frustration générée...

Bref le stand-up se transforme parfois en mécanisme pour traiter l’information en mode batch au sein de l’équipe. C’est exactement l’effet inverse de ce que nous souhaitons obtenir.

Alors le stand-up, c’est mal ?

Nous n’avons même pas évoqué le stand-up détourné, par exemple comme outil de pouvoir. Même utilisé dans son but premier, le stand-up peut avoir des effets contre-productif. Mais qu’essayons-nous de faire réellement avec le stand-up, au-delà du folklorique petit cercle ?

L’un des principes majeurs de Scrum, c’est « inspect and adapt ». Le stand-up est notre boucle de feedback journalière, comme je l’avais déjà évoqué. C’est un point de synchronisation qui nous permet d’adapter continuellement notre plan d’itération à une maille qui n’est pas plus longue qu’une journée. Et ce mécanisme est réellement important.

Pourrait-il prendre d’autres formes ? Sans doute. Déjà, lorsque les situations sont tendues il n’est pas rare de voir des équipes opérer spontanément des stand-up deux fois par jour. Des équipes très matures peuvent aussi développer leur propre protocole de resynchronisation au fil de l’eau, rendant le stand-up inutile.

Ce sont près d’une centaine de pages qui sont dédiées au chapitre 3, dévolu à l’implémentation de RS232C sur l’UART 8250. Toute la première partie expliquant le fonctionnement de l’UART est réellement très intéressante même si je regrette le peu qui est consacré au 16550, certes nettement moins rependu à l’époque, mais nettement plus intéressant. Hélas la seconde moitié du chapitre est de nouveau consacré à de fastidieux listings bien peu expliqués…

Le chapitre 4, shared interrupt device rompt la monotonie avec seulement 25 pages. Il est consacré à l’accès aux ports COM dans l’architecture PC via les 2 interruptions qui leurs sont dédiées (pour 4 ports en principe accessibles). Le code du handler et les principes de gestion sont clairement appréhendés. Des informations par ailleurs rares dans la littérature, pour ne pas dire plus.

C’est à un périphérique plus exotique qu’est consacré le chapitre 5 : le Digiboard ! C’est donc une nouvelle sous-classe de RS232 qui nous attend. Un chapitre dont je soupçonne qu’il tenait à cœur à l’auteur, mais qui n’a pas retenu mon attention.

Plus intéressant pour moi, mais hélas plus légèrement traité, le chapitre 6 nous propose une nouvelle sous-classe de RS232, mais cette fois en s’appuyant sur les primitives disponibles dans le BIOS. Seul 30 pages y sont consacrées et l’auteur aurait pu faire plus d’effort pour développer plus clairement les interruptions du BIOS et leur exploitation.

Au chapitre 7, le FOSSIL driver se voit lui aussi consacrer une trentaine de pages. La profondeur de traitement est à peu près la même que pour l’implémentation BIOS. Mais j’avoue encore une fois que l’aspect exotique de cette norme fait que le chapitre n’a pas retenu mon attention.

Nouvelle alternative au chapitre 8 : une implémentation sur les API Windows. Près de 50 pages sont noircies sur le sujet. Cela paraît mieux, mais à l’époque où ces informations étaient vitales pour moi, la profondeur des informations restait bien insuffisante. Mais au moins le livre fournit des informations d’exploitations de ces APIs, choses pratiquement indisponibles par ailleurs en 1993 !

Le chapitre 9 est long de 40 pages. C’est un changement, car on quitte la couche RS232 pour s’attaquer à la gestion des modems, avec les fameuses normes V24, V32 et autres et bien sûr le protocole Hayes. La question est bien traitée et fort clairement. C’est probablement la meilleure source d’information que j’ai pu croiser sur la question.

Au chapitre 10, on s’attaque aux transferts de fichier, avec les protocoles XModem, YModem et ZModem. La question ne m’intéresse guère et j’ai du mal à avoir un avis sur le chapitre. Le sujet semble bien traité et le listing de fichier une fois encore un peu longuet.

Le dernier chapitre du volume va s’intéresser à l’émulation de terminal. Le thème remplit 60 pages et ne semble guère passionnant tel qu’il est traité ici. On est beaucoup dans l’explication de texte du listing, fort peu sur la déconstruction du problème.

L’auteur a développé une petite librairie de classes multiplateformes, multi-modems et multi contrôleurs qui, ma foi, m’a bien fait de l’usage à son époque. Le livre gravite entièrement autour de cela ce qui rend parfois le propos un peu rébarbatif et les listings ennuyeux. Mais le volet technique est très affuté et ce fut très clairement la meilleure source d’information sur bon nombre de sujets qui y sont traités. Difficile de faire valoir une pertinence après presque 25 ans, pourtant le volume mérite d’être conservé à titre d’archive !

Référence complète : Serial Communications : A C++ Developer’s guide – Mark Nelson – Prentice Hall / M&T Books 1992 - ISBN : 0-13-011776-1

Beyond Budgeting

Bjarte n’est pas venu seul. D’autres intervenants sont au programme. A commencer par Anders Olesen, l’actuel directeur du Beyond Budgeting Institute !

Le Beyond Budgeting, c’est à la fois le nom d’un réseau et d’un modèle de management. Ce n’est pas non plus quelque chose de nouveau, car le Beyond Budgeting Institute existe depuis maintenant 15 ans !

Le Beyond Budgeting Round Table est une émanation de cette organisation, dont le but est de rassembler les organisations mettant en œuvre le Beyond Budgéting, de permettre et organiser le partage d’expérience.

Bjarte Borgsnes

Il y a un problème avec le management. Les organisations qui font la transition vers l’agilité ont besoin que change la posture du management. Le Beyond Budgeting est un moyen pour cela.

L’orateur nous propose une métaphore, celle des feux de circulation. Dans cette situation, la performance du système est entre les mains du programmeur (ou du managers, dans le cas présent). Son intention est bonne, mais hélas il n’est pas sur place. C’est un management basé sur les règles.

Le rond-point est sensé être plus efficace. Ici, on cherche à créer les conditions d’une bonne performance. C’est ce dont les entreprises agiles ont besoin : créer plus de « self-direction ». Le beyond budgéting s’oppose au management traditionnel orienté vers les systèmes statiques et la « théorie X » de McGregor (le contrôle) en étant orienté vers les systèmes dynamiques et la « théorie Y ».

Le contrôle est en fait de l’illusion de contrôle. Avoir l’information n’est pas synonyme d’être capable d’influencer. La transparence est un meilleur levier. L’exemple que nous donne Bjarte est assez connu : la gestion des notes de frais.

Chez Roche, plutôt que fixer des règles ou des limites aux notes de frais (cela me rapelle « cherchez les bottes » dans Liberté & Cie), on rend toutes les notes de frais de tout le monde (jusqu’au sommet de la pyramide) visibles à tout le monde (jusqu’en bas de la pyramide). Cela a fait baisser les coûts liés aux déplacements sans qu’il soit nécessaire d’édicter la moindre règle...

Le Beyond Budgeting combine 3 idées majeures :

Pas de budget.

Pas de cible budgétaire

Transparence totale

Il y a 12 principes sous-jacent. Comme le dit Bjarne, c’est assez volumineux, mais on n’est pas obligé de tout faire en même temps !

Gouvernance et transparence

Valeurs : rassembler les personnes autour d’une cause commune, pas d’un plan central.

Gouvernance : Diriger au travers de valeurs partagées et d’un jugement éclairé, et non par le biais de règles détaillées ni de régulations.

Transparence : L’information doit être ouverte et transparente ; Ne pas la contrôler ni en restreindre l’accès.

Des équipes responsables

But : Placer des but moyen-terme ambitieux, pas de buts court-terme fixes.

Récompenses : Baser les récompenses sur les performances relatives et non sur l’atteinte d’objectifs fixes.

Planning et contrôles

Planning : Faire du planning un processus continu et inclusif et non un évènement annuel imposé par le hiérarchie.

Coordination : Coordonner les interactions de manière dynamique et non au travers de budgets annuels.

Ressources :  Opérer l’allocation de ressources « juste à temps », et non « au cas où ».

Contrôles : Baser le contrôle sur une boucle de feedback fréquente et rapide, pas sur des écarts de budgets.

A l’image du manifeste agile, ce sont de grandes recommandations, et non des recettes.

La question du budget est bien évidemment au centre du Beyond Budgeting. Quelle est sa finalité ? En fait, elle n’est pas unique, elle est plurielle :

Fixer une cible

Établir un prévisionnel

Permettre l’allocation de ressources.

Pour Bjarte Borgsnes, cette vision budgétaire étriquée porte nombre de défauts.

Tout d’abord, les 3 dimensions citées ci-dessus doivent être décorrélées. Ce sont 3 données différentes.

Le processus budgétaire annuel est un non-sens. Une entreprise n’est pas ouverte un seul mois par an !

Les mesures seules ne valent rien. La façon dont nous délivrons la valeur a autant d’importance que ce que nous délivrons.

L’évaluation doit être holistique, ce qui n’est pas facile.

La transparence est un moyen de régulation beaucoup plus puissant que le contrôle, il fait appel à l’auto-régulation. Mais cela ne signifie pas pour autant avoir une posture naïve.

Jean-Michel Segui

Notre second orateur nous parle de l’adoption du Beyond Budgeting chez Schneider Electric. Disons simplement que ce n’est pas la PME de quartier, avec 25 milliards de CA et 70000 employés !

Tout d’abord 2 constats :

Le management du groupe se plaint de la lourdeur du processus budgétaire.

Il y a des réflexions sur les objectifs, qui sont fixés « en descendant », chaque strate de l’organisation ayant la responsabilité de reformuler ces objectifs à son niveau.

Le processus budgétaire doit faire 7 choses (j’ai oublié la 7ème) :

Fixer une cible

Établir un prévisionnel

Permettre la Planification

Fourbir un plan d'action

Planifier des actions

Gérer les récompenses

Il y a 2 phases dans ce processus : une phase stratégique et une phase opérationnelle.

La phase stratégique se déroule en 2 temps :

Le programme d’entreprise (sur 3 à 5 ans) issu de la direction générale et représentant l’engagement de l’entreprise par rapport au marché, mais sans un grand niveau de détail.

La stratégie opérationnelle, plus détaillée mais sans être exhaustive.

La phase opérationnelle concerne les objectifs que se donnent les départements, qui donne lieu à des itérations avec la direction sur 6 mois. Ces objectifs se déclinent jusqu’au objectifs individuels. Ils s’expriment sur plusieurs axes tels que :

La satisfaction client

L’augmentation du chiffre d'affaire

L’augmentation du cash

Le prévisionnel est géré séparément de l’objectif. Il fait l’objet d’une vision glissante à 5 trimestre (le carnet de commande couvre lui 3 à 4 mois).

Il m’a semblé que nombre d’éléments restent très conventionnels dans la façon dont Schneider Electric à mis en œuvre le Beyond Budgeting. C’est sans doute lié à une logique grand groupe difficile, voir impossible à casser et une logique marché / actionnariat qui va elle, complètement à l’encontre. Mais on voit qu’un certains nombre d’éléments vont dans le bon sens, comme la définition des objectifs par les entités qui en sont responsable.

En conclusion

Mary Poppendieck nous emmène vers les communautés auto-organisées et vers Elinor Ostrom qui identifie 8 règles de gouvernance des biens communs :

Définir une limite du groupe claire

Faire coïncider les règles gouvernant l’usage du bien commun avec les besoins et les conditions locales.

S’assurer que ceux qui sont affectés par les règles peuvent participer à la modification de ces règles.

S’assurer que le droit d’édicter des règles des membres de la communauté est respecté des autorités extérieures.

Développer un système, porté par les membres de la communauté, permettant de surveiller le comportement des membres.

Faire usage de sanctions graduées envers les violateurs de ces règles.

Donner accès à des moyens de résolution de problèmes à faible coût.

Une gouvernance à multiples niveaux.

Quelle taille de groupe est la plus pertinente ? C’est au nombre de Dunbar qu'évoque l’oratrice, celui évoqué dans le Tribal Leadership, et ses variantes :

Le cercle d’intimité : 3 à 5 personnes

Le groupe de sympathie : 7 à 10 personnes ; c’est la taille d’un groupe pouvant accomplir « quelque chose ».

Le groupe de chasse : de 30 à 70 personnes ; c’est la taille nécessaire pour construire un sous-système indépendant et indépendemment.

Le clan : de 100 à 150 personnes ; C’est la taille d’une compagnie, dans les organisations militaires.

Complexité

Pour aborder la question de la complexité, Mary Poppendieck nous parle de micro-services, en évoquant le livre de Sam Newman (que je n’ai pas encore lu).

Les micro-services fractionnent les ensembles complexes en petits systèmes indépendants (jusqu’à la base de données) qui ne font qu’une seule chose, mais bien. « small » est bien le mot d’ordre pour les micro-services :

Petit services qui font une seule chose, mais bien. Nous l’avons dit.

Petites équipes, capables de prendre en main un service, depuis la compréhension du besoin avec les équipes métiers, jusqu’au suivi en production, en passant bien évidemment par la construction et le déploiement. qui s’effectue indépendamment des autres briques du SI.

Petites itérations et petit coût de démarrage: de zéro à une première étape en 3 semaines !

L’aptitude à réaliser des microservices a des corolaires.

Pas de couplage avec les autres briques du SI (nous l’avons évoqué).

Automatisation extensive des opérations : tests, intégration, déploiement.

« canary release » qui permet de pré-tester le système en situation réelle.

Continuous delivery et aptitude a être toujours « prêt au déploiement ».

Equipes pluridisciplinaires.

Etat d'esprit

Le focus sur le projet a fait son temps ! Place au focus sur le produit !

Vous êtes focalisés sur « le métier » ? Ce n’est même pas un concept … et pendant ce temps on laisse filer le focus sur le client… Il faut changer de regard.

Passer du focus métier au focus client

Passer du gestionnaire de projet à l’entrepreneur leader.

Migrer du développement qui execute les commandes à une équipe proposant des réponses.

Ne plus faire des choix sur les planning, mais sur les marchés.

Abandonner la mentalité « centre de coût » pour un état d’esprit « centre de produit ».

Dans son livre Inspired, Marty Cagan localise la création de grands produits à l’intersection de la valeur, de l’utilisabilité et de la faisabilité ! Pour donner vie à cette vision, il faut 3 personnes d’agal statut, l’un d’entre-eux est le « product manager », qui n’est pas un Product Owner : son rôle n’est pas d’écrire des User Stories ou de concevoir la solution, mais d’être un canal direct avec le client.

Focus

C’est se focaliser sur les bonnes questions. Et comme l’a popularisé Simon Sinek, cela commence par « pourquoi ? ».