Les échos sur la keynote de cette chercheuse du CNRS à Devoxx 2013 étaient arrivés jusqu’à moi par de multiples canaux. Cette présentation est en ligne, nous pouvons en partager le bonheur. A 70 ans (je crois), Mme Herrenschmidt a l’énergie d’une horde de geeks ! Et elle nous convie pendant 40 minutes à un voyage dans le temps depuis les premiers systèmes de comptage, jusqu’à Alan Turing !
Cette rencontre-là avait pour but de mettre en lumière de possibles modèles d’entreprise du XXIème siècle et d’en discuter entre nous. C’est en fait l’objet de son livre, Pleine Valeur paru il y a une dizaine d’année.
On parle ici de co-création de valeur, ou comment se rendre mutuellement meilleurs !
Plus précisément, Manfred Mack évoque l’approche développée par Spi-Batignolles dans l’offre Concertance dont l’origine remonte à la réponse à un appel d’offre pour la construction d’une soufflerie pour un consortium regroupant Renault et Peugeot. Non seulement Spi-Batignolles a pu répondre avec un tarif plus bas, mais le coût final s’est même avéré encore moins élevé, sans pour autant hypothèquer la satisfaction du client !
Pour se faire, Concertance s’appuie sur 3 axes :
La recherche d’optimisations en amont
Un fonctionnement en équipe projet conjointe fournisseur-client
La transparence
Les deux derniers points sont réellement à l’encontre de le la culture BTP, comme nous le confirme Manfred !
Le principe est d’avoir toujours : Coût < Prix < Valeur perçue
L’approche managériale est adaptée en conséquence : on demande ainsi aux managers d’être toujours capables de montrer comment et en quoi les plans qu’ils proposent contribuent à la création de valeur.
Les points abordés par Manfred Mack me rapellent beaucoup les principes du Lean tels qu’ils sont mis en oeuvre chez Toyota.
D’ailleurs Spi-Batignolles a fini par élargir cette approche à l’entreprise elle-même : si l’on considère les clients comme des partenaires, pourquoi n’en serait-il pas de même avec les collaborateurs ? C’est ainsi que l’entreprise a mis en place son projet “zéro accident” avec réussite, semble-t-il. Mais au-delà de cet exemple, il est frappant de constater l’influence de ce nouveau mode de pensée sur l’ensemble de l’entreprise.
Comme le dit Manfred Mack : on obtient au final une meilleure performance en abandonnant le focus purement financier pour la création d’une “sur-valeur”.
Le dernier point concerne les conditions initiales nécessaires : Une direction en recherche “d’autre chose” donc un PDG visionnaire.
Le monde du BTP est bien le dernier où j’aurais pensé voir ce type d’approche. Manfred Mack semble en tout cas être extrêmement enthousiaste sur ce qui a été accompli avec Concertance. Il endosse depuis un moment déjà un rôle d’évangéliste dans le monde professionnel comme celui de le formation des futurs diplômés.
Christine Koehler nous a proposé ensuite de discuter par petits groupes de 4, sur 3 questions gravitant autour de cette approche.
Dans mon groupe, la majorité des participants étaient intéressés par les questions d’intelligence collective et de co-développement. L’idée de “penser autrement” les relations entre client et fournisseur semblait en tout cas une pensée partagée.
Notre second tour de discussion a tourné autour des points importants de cette approche. Plusieurs éléments en vrac:
L’importance d’un objectif commun entre client et fournisseur.
La nécessité d’établir une confiance.
Effacer la notion de rôle telle qu’on l’entends généralement, qui implique un retranchement derrière un périmètre et des responsabilités non partagées.
La nécessité de travailler sur ses peurs et les peurs des collaborateurs. Et au contraire valoriser les personnes et les parties prenantes.
L’importance de l’expérimentation.
La 3ème question était plus personnelle : en quoi cette démarche nous concerne plus personnellement ?
Chaque membre du groupe appréhende nécessairement ce point avec sa propre sensibilité, selon ce qui le touche le plus. Ainsi nous avons soulevés des points tels que :
La déonthologie par rapport aux clients : travailler pour résoudre les vrais problèmes. Ce ne sont pas nécessairement ceux pour lesquels les clients nous ont appelés.
Contribuer au plaisir dans le travail : Accomplir une mission non pas parce que l’on fait un travail que l’on nous a demandé, mais parce qu’on fait quelque chose d’utile, qui aidera réellement ce client en adressant son problème de départ.
Gagner en légèreté : Rendre le travail plus agréable et plus efficace.
Pouvoir faire plus demain que ce que l’on fait aujourd’hui.
Je vois un fil directeur à travers ces points : notre besoin semble de nous sentir en harmonie avec notre travail, d’assouvir un véritable besoin sinon physiologique, du moins intellectuel.
Pour finir Manfred nous suggère de réfléchir à cette question fondamentale qui guide cette démarche : Qu’est-ce que la valeur ? Pas seulement la valeur financière !
Cette question et d’autres points soulevés par Manfred Mack figurent dans le support que Christine a eu la gentillesse de mettre à disposition.
Plutôt qu’un livre, c’est un livret de l’aveu même de l’auteur. Long, ou plutôt court de 70 pages et un petit format. Il vous durera 1 journée de lecture bien assidue ou plus si, comme moi, vous le lisez à dose filée. L’auteur de Management 3.0 n’a pas perdu la main, c’est sûr : c’est bien écrit, pertinent et ça repose sur des références sérieuses !
S’agit-il vraiment de changer le monde ? Parce que là, ça ne paraît pas très sérieux ! En fait, il s’agit plutôt de changer une organisation ou une entreprise. Donc un petit monde. Mais si 500000 personnes font de même, là peut-être… Mais nous n’allons pas extrapoler aujourd’hui.
Pour Jurgen Appelo, impulser un changement c’est agir sur un système complexe (un des thèmes favoris de l’auteur) en travaillant sur 4 aspects. Le premier chapitre, long de 8 pages expose cette approche dans ses grandes lignes.
D’abord « danser avec le système ». C’est le sujet du second chapitre et couvre 11 pages. Pour cela, Jurgen a un modèle (ou plutôt il en emprunte un). D’ailleurs, l’auteur a un modèle pour tout ! C’est beau la technique… Ici, c’est le modèle PDCA, la fameuse roue de Deming,
Après (ou en même temps, ou avant) avoir travailler sur le système, il faut travailler sur les personnes, créer la volonté de changer. Dans le chapitre 3 qui est dédié à ce thème, Jurgen nous présente le modèle ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) pour amener les personnes de la prise de conscience à l’action. 12 pages sont consacrées à cela.
Une organisation, ce ne sont pas seulement des personnes, ce sont des interactions entre ces personnes. Le chapitre 4 vaillamment intitulé « stimulate the network » s’appuie sur la courbe d’adoption des technologies (la fameuse courbe de Moore avec son fossé) pour aborder les différentes populations. C’est ce qu’aborde la substance de ce chapitre : innovateurs, early adopters, early majority, late majority et laggard. A chaque population, son approche ! 11 pages suffisent au propos.
On finit ce tour des aspects par l’environnement. Sur ce volet, l’auteur emploie le modèle des « 5 I ». Il y en avait 4 à l’origine, mais il en a rajouté un : Information, Identity, Incentives, Infrastructure et Institution. Le vilain petit canard est « Infrastructure ».
Le chapitre de conclusion remet tout cela en perspective.
C’est vraiment un petit opuscule, qui nous donne un peu l’impression de manger un bonbon acidulé : le goût est bon, mais il ne dure pas longtemps. Pourtant la substance est là, et je pense qu’elle va me servir de boussole quand je devrais aborder des questions d’agilification d’entreprise ! Un dernier point que j’ai bien aimé et m’aidera certainement : la check-list figurant en fin de chacun des 4 chapitres principaux.
Jurgen Appelo avait fait une présentation sur le thème de ce livre (pardon, livret)lors du printemps agile à Caen. Vous trouverez ici mon résumé sur cette présentation, ainsi que le support visuel de l’auteur.
Voilà un petit qui vaut chaque minute que j’ai passé à le lire !
Référence complète : How to Change the World, change management 3.0 – Jurgen Appelo – Jojo Venture BV 2012 – ISBN : 9789081905114
Il existe aussi un traduction française, faite par Yannick Grenzinger disponible en eBook chez Lulu.
Sacha Labourey n’est pas un inconnu pour moi. Pour vous non plus peut-être. Soat nous poposait une rencontre avec cette figure marquante du monde Java à la veille de Devoxx France (je sais, ça fait déjà un bail …), je ne pouvais que sauter sur l’occasion.
Pour ceux qui l’ignoreraient, Sacha Labourey fut le CTO de JBoss après le départ de Marc Fleury, mais c’est en tant que fondateur et CEO de CloudBees qu’il se présentait à nous ce soir-là.
En fait de présentation, j’ai hélas rarement mis de photo aussi médiocre sur mon blog, mais c’est ainsi. La voilà.
CloudBees propose une plateforme pour héberger la totalité du cycle de vie d’une application Java sur le cloud. En l’occurrence, il s’agit du cloud d’Amazon, mais ils travaillent activement à rendre leur plateforme indépendante de l’infrastructure du géant de l’e-commerce afin de donner plus de flexibilité au client.
Hardware as a commodity
A la base, il y a la conviction que l’on se dirige vers une commoditifaction (est-ce vraiment un mot ?) du hardware. Sacha Labourey évoque le parallèle avec l’électricité : si à ses débuts, il fallait posséder son propre générateur et gérer les aléas de la régularité de l’alimentation, aujourd’hui nous nous sommes “débarassés” du problème chez des prestataires. Nous n’avons plus que des prises de courant nous délivrant un courant normalisé, le reste est l’affaire de ce prestataire.
Ce mouvement inéluctable : spécialisation -> standardisation -> régulation, Sacha Labourey le voit s’appliquer aujourd’hui à l’infrastructure.
Doit-on aujourd’hui encore s’occuper des machines, de les configurer, gérer les mises à jours système et même les “piles logicielles” ? Existe-t-il une valeur spécifique à se construire sa pile logicielle spécifique ? Si elle existe, elle doit être marginale (du moins dans la plupart des cas) et ne justifie pas les efforts et le détournement de focus de la problématique métier que l’on souhaite adresser.
C’est là la proposition de valeur de CloudBees : rendre l’infrastructure aussi facile à exploiter qu’une prise électrique !
Cloud vs cloud vs cloud
On peut rappeler rapidement les 3 types de cloud proposés, ils sont déjà très connus:
IaaS : Ce sont les briques de base de l’IT. On pense à Amazon EC2, Rackspace, …
SaaS : Des solutions logicielles standardisées prêtes à l’emploi. Salesforce est probablement le premier nom qui vient à l’esprit.
PaaS : Il s’adresse aux développeurs. L’objectif est de ne plus avoir à gérer les serveurs et les services standard fonctionnant dessus : serveur d’application, load balancing, etc..
Le focus est sur le “S” final : voir les facilités comme des services, disponibles sous forme d’API. Cette dématérialisation offre aussi un avantage fort : la possibilité de faire des essais (donc des erreurs) et de commencer petit. On peut ainsi itérer rapidement sans devoir attendre des mises à disposition de serveurs et des installations logicielles. Elles sont prêtes et peuvent être exploitées tout de suite. Et être abandonnées tout aussi rapidement (le serveur ne finit pas à la cave).
Pour Sacha Labourey, une architecture typique d’entreprise serait la suivante :
Au niveau back-office : les systèmes “legacy”, très stables, intégrant peu d’innovation.
Au niveau front : des applications pour mobile (par exemple) communiquant avec un back-end évoluant très rapidement au rythme des nouvelles fonctionnalités disponibles dans l’appli mobile. Cette partie est peu stable et est le siège de beaucoup d’innovations
Une communication front / back selon les protocoles mis à disposition par le back-office
Aujourd’hui la partie front / produit est subordonnée aux frictions entre développeurs et départements “opérations”. Les personnes en charge des opération privilégient la sureté de fonctionnement et renaclent le plus souvent à déployer des solutions logicielles qui n’ont pas été validées en interne, ou en tout cas ne satisfont pas des critères d’acceptabilité.
PaaS et innovation
Pour améliorer la capacité à mettre en ligne, la tendance actuelle est le “devops”, faire travailler ensemble développement et opération et outiller les opérations de déploiement afin de pouvoir pratiquer très souvent des déploiement automatisés. Je fais là un gros raccourcis et ne rends probablement pas justice à ce qu’il y a derrière devops, mais l’idée est là.
CloudBees revendique du “no ops” ! Plusieurs facteurs sont nécessaire pour permettre cela. On verra aussi que c’est un peu une simplification, l’IT ne disparait pas.
Standardiser les environnements : à l’image de l’électricité délivrée en voltage et fréquence constants, la standardisation des environnements est un facteur clé. Chez CloudBees, ces environnements standards sont les ClickStacks.
Travailler en SLA : pour pouvoir se passer d’ops, il ne faut pas avoir à se soucier de contingences d’infrastructure telles que stockage, clustering, etc… Il faut pouvoir signer un engagement de performance, à charge du prestataire de faire les mises en oeuvre d’infrastructure nécessaires pour garantir cet engagement.
Avec le SLA vient la question du support : une plateforme intégrant des sous-systèmes tiers peut être sujete à des dysfonctionnements (ou des mauvaises utilisation) de n’importe lesquels de ces composants. Il est logique que le support de service intègre complètement le support ou la délégation de support de ces composants.
Bien sûr, cela n’a de sens que si l’on est capable de mettre cela en oeuvre non seulement sur l’environnement de production, mais aussi sur les autres environnements utilisés dans le cycle de développement : environnements de développement, d’intégration, de stagging, etc… Le support du cycle de vie de l’application est donc l’étape suivante logique. L’intégration continue y joue un rôle clé.
Cycle de vie applicatif et gouvernance
C’est Jenkins qui est au centre du cycle de vie applicatif chez CloudBees. Il faut dire que Kohsuke Kawaguchi, la figure emblématique de ce projet open-source est un des leaders techniques de CloudBees !
Aujourd’hui, la partie faible me semble être toute la partie acceptance testing, AB testing etc… Mais c’est déjà le point faible de pas mal de projets. CloudBees propose quand même un environnement de stagging permettant de tester ses applications en conditions réelles : beescloud.com
Dans cette image que Sacha Labourey nous dresse, nous voyons une entreprise avec de nombreux projets, sur chacun d’eux les développeurs font des choix indépendants transformant le système d’information en gigantesque tour de Babel. Justement ce que l’IT cherche à éviter et lui vaut cette image d’épine dans le pied. Quel doit être le travail et la position du département IT, alors ?
C’est ce que Sacha Labourey appelle l’IT pragmatique : laisser faire, mais rester informés. Puis travailler en consolidation des différents projets ensuite (comment ? mystère …). De toute façon, si on bloque les projets trouveront le moyen de passer quand même !
Donc l’IT ne disparait pas, mais elle cesse de s’occuper d’infrastructure pour se concentrer sur les workflow de données, de services, etc… Elle reste le gardien du temple.
Tirer les leçons
Sacha Labourey a une vision très radicale non pas de l’IT de demain, mais de celle d’aujourd’hui :
Passer son IT sur le cloud inquiète toujours. Mais la peur ne peut pas être une stratégie ! Rester organisés à l’ancienne peut nous valoir de voir un département de 20 personnes se faire griller la politesse par “4 punks dans une cave” comme le dit Sacha !
Il faut profiter des gains compétitifs que représentent des services prêts à l’emploi.
Aujourd’hui, les investissements ne prenant pas en compte le cloud sont déjà de la création de dette ! Méditez là-dessus mes amis…
Ce que j’en vois
Sacha Labourey nous a bien secoué sur une vision du développement se passant dans le cloud, en rupture avec nos habitudes actuelles. Et il est très convainquant sur l’aspect des choses que nous n’avons plus à prendre en charge…
Pour aborder cette rupture, il faut permettre la montée en compétence progressive des équipes. Le ClickStart que propose CloudBees s’apparente surtout à des assistants logiciels. Il faut apprendre à travailler avec son usine logicielle dans le cloud. D’après notre orateur de la soirée, cela va vite. Mais quand même…
Accepter la standardisation : c’est une condition sine qua non.
On peut avoir un développement produit dans le cloud. Mais qu’en est-il de la communication front-back, si le back-office est dans les murs de l’entreprise ? C’est très probablement un point faible. A moins que le back-office soit lui-même dans le cloud, ce qui est la solution préconisée par Sacha Labourey. Un tel choix nous amène rapidement à des considération de vulnérabilité de notre entreprise, dont les avoir ont quitté les murs pour être localisés … à des endroits que nous ne savons même plus localiser ! Mais ne sommes-nous pas déjà, voir plus, vulnérables avec l’informatique chez nous ? Il y a eu pas mal d’échange avec Sacha Labourey sur ce sujet et j’avoue que ces arguments ne manquent pas de fondements. Je ne vais cependant pas les développer plus avant, cela m’emmènerai trop loin.
La présentation de ce soir-là avait un ciblage très managérial, j’ai un petit regret là-dessus, surtout que notre orateur est un expert de haut niveau. Mais ce point m’était connu à l’avance, je n’ai donc pas de regrets à avoir.
Si vous avez le courage de voir le contenu complet, la video a été mise en ligne par Soat.
Il vous faudra un peu de la persévérance, car la video dure 2h30 … et contrairement à ce que Sacha annonce au début, il oubliera de répéter les questions !
Il me reste à remercier Soat pour cette opportunité d’en savoir plus sur le développement sur le cloud en général et sur Cloudbees en particulier, avec l’un des grands noms du monde Java.
Le GUSS, c’est à dire le Groupe des Utilisateurs de SQL Server organisait cette rencontre pour évoquer un sujet qui m’est cher au sein d’une communauté pas franchement reconnue pour son adhésion à l’agilité. Franchement, je ne savais pas à quoi m’attendre !
Déjà un bon point pour le cadre de rencontre convivial, certainement à retenir pour de prochaines Scrum Beer !
Maintenant, arrivons-en au fond. Je ne vais pas laisser trainer le suspens : j’ai passé une excellente soirée !
L’agilité est un sujet jeune dans cette communauté, on n’y trouve pas la touche de suffisance que l’on croise par ici ou le regard blazé que l’on rencontre par là … L’enthousiasme est là, avec l’envie d’avancer , la soif de faire mieux et le questionnement sur ce que l’on fait.
En parlant de questionnement, j’ai été aussi surpris par l’ouverture d’esprit des personnes présentes. J’ai souvent été confronté dans ce milieu à des personnes prisonnières de leur paradigmes, empreintes de dogmes pour ne pas dire de certitudes. Rien de tel ce soir-là.
Il me serait difficile de vous faire un compte-rendu circonstancié des discussions, mais je vais évoquer quelques points qui m’ont marqué. Dans le désordre.
Les limites de l’outillage
On peut aimer les outils qu’on utilise et faire preuve de lucidité à leur égard. La difficulté principale rencontrée par les développeurs BI utilisant Integration Services semble être l’aspect monolithique des solutions SSIS qui rendent inopérants les fonctionnement en branches avec les merges que cela nécessite.
Le second point évoqué est le problème de la resynchronisation des métadonnées qui fonctionne manuellement et nécessite de repasser sur tous les packages. Si on souhaite travailler sur un modèle de manière itérative, on fait face à ce problème très rapidement, et c’est d’autant plus handicapant que le projet est gros…
Le future du BI agile n’est peut-être pas le cube
Travailler sur un cube de manière itérative n’est pas facile. Vraiment. D’abord si on souhaite faire des “sashimi”, on devrait travailler sur un modèle de données évolutif. Or la synchronisation des métadonnées de SSIS est un obstacle à cela.
D’un autre côté, il n’est pas possible de rajouter des dimensions à un cube une fois en production, car cela remet en cause la granularité des faits qui alimentent déjà le cube !
Mes observations et mes réflexions m’amènent à penser que l’avenir du BI et surtout du BI agile réside dans des solutions “sans schémas” adoptées de manière différentes par le monde des bases NoSQL, je pense surtout aux bases orientées colonnes comme Hadoop. Il s’agit là non seulement de la disparition du schéma explicite, mais d’un paradigme différent où la structuration de la données disparait au profit de la capacité à retrouver cette donnée et à la traiter, et souvent de manière scalable. Un aspect prépondérant quand le monde du BI est tiré vers le Big Data.
C’était mieux avant…
Une voix discordante s’est élevée au milieu de ces reflexions agiles.
“Lors d’une itération, on a oublié de décliner des règles métiers sur d’autres tables. Avec un cycle en V, la spécification détaillée aurait pris en compte cela et évité l’erreur.”
Bien sûr l’argument ne tient pas. Notre interlocuteur aurait dû au contraire se féliciter de n’avoir eu à attendre qu’une itération pour corriger un oubli que le cycle en V ne saurait pas plus garantir ! De toute évidence, la contre-argumentation est d’ors et déjà acquise pour nos DBA Agilistes. Que du plaisir !
La difficulté d’un résultat de sprint démontrable
Quand je demande à mes interlocuteurs de m’expliquer leurs découpage en sprint, j’entends un motif recourent : d’abord un sprint de modélisation de base, un ou plusieurs sprints d’alimentation de Sas, puid d’ODS, viennent enfin les sprints de construction de cube puis de présentation !
C’est le moment de prendre mon air horrifié : pourquoi ne pas construire les sprints verticalement, avec une tranche fine allant de la modélisation de la base à la présentation en passant par les différents étages d’alimentation ?
Nous avons donné la réponse plus haut : la difficulté de construire une table de fait dont la granularité se rafinerait au fur et à mesure de l’ajout de dimensions, la pénalité de SSIS aux changements de métadonnées, etc…
Seconde question, donc : mais alors, si vous n’allez pas au bout de la tranche, que démontrez-vous ?
La réponse est bien sûr : ce qu’on peut ! Dans le cas d’un sprint de modélisation, par exemple, ce sera le modèle de données. Sur papier !
Bref, Scrum c’est l’art du possible, mais il y a vraiment matière à progression de ce côté. On en est pas au “vrai Scrum” !
Le poids des cérémonies de Scrum
Autre point évoqué : 2 semaines, c’est court, et en plus il faut ménager du temps pour la démo, la rétro, le planning meeting. Sans compter que ce dernier se trouve souvent pénalisé par la découverte “in situ” des aspects fonctionnels, laissant la portion congrue de la réunion au découpage en tâches et à l’estimation.
Ces problèmes ne sont ni nouveaux, ni spécifiques au BI avec SQL Server. Ce sont des choses que j’ai rencontré avec des équipes de développement Java. De ce côté nous avions amélioré les choses avec quelques pratiques courantes ou non :
Découpage en 2 (à quelques jours d’interval) du planning meeting : un volet découverte fonctionnel, et après 2 jours pour réflechir et assimiler, un pur planning meeting plus court.
Des workshops de tests d’acceptance regroupant développeur, PO, client final (quand il est différent) et représentant de l’équipe de test (quand il y en a une).
Et bien sûr des rétrospectives pour introduire des pratiques, alléger ou faire disparaitre celles qui paraissent inutiles.
En ensuite…
Pas mal d’échanges, l’envie d’aller plus loin … Le GUSS a émis l’idée d’une table ronde, elle me plait bien ! Tout le monde a l’air motivé, donc peut-être d’ici Juin ?
