Je vous avais laissé en fin de matinée de ce premier Printemps Agile. Il est temps de faire une pause déjeuner bien mérité.

Rien dans l’ostensibilité dans ce buffet, mais beaucoup en convivialité. J’avoue aussi que cette pause organisée dans une salle de TP a des allures plutôt inattendues !

Il est temps de reprendre le collier, et pour commencer, la seconde présentation de Jurgen Appelo.

Jurgen Appelo : Let’s Help Melly

Quand on aime, on ne compte pas. Et on a vraiment beaucoup aimé la première intervention de Jurgen. C’est avec plaisir que je remets le couvert pour la seconde.

Cette intervention était plutôt focalisée sur le thème de son premier livre (Management 3.0). Avec comme point de départ : comment rendre Melly (la persona qui servait de fil rouge) heureuse et productive à son travail ?

Aujourd’hui encore nous vivons majoritairement sous le joug de “l’organisation scientifique du travail”, le Taylorisme. Que nous appellerons ici “Management 1.0”. Il se traduit par un asservissement, une aliénation du travail.

Que faut-il pour dépasser cela ? Donner plus de sens à notre travail ?

Les initiatives qui vont dans ce sens sont le six sigma, Total Quality Management, Business Process Reengineering. Hélas ces initiatives n’ont jamais délivré leurs promesses. Sacrifier l’humain au profit de l’organisation ne semble pas la solution optimale.

Les cycles de changement s’accélèrent, les facteurs d’incertitude s’accroissent. Les systèmes prédictifs ne peuvent plus prétendre gérer cela.

La complexité est justement le terrain de jeu des courants de l’agilité" (Lean, Scrum, Kanban, etc…) . Si les pratiques proposées par les unes ou les autres diffèrent, il ne s’agit que de détails, et l’on retrouvera les mêmes buts et les mêmes valeurs dans différents courants de pensée :

• Scrum
• Kanban
• Beyond budgeting : abandoner l’idée des budgets annuals prévisionnels mais rendre transparents dépenses et revenus.
• Lean Startup : Créer un cycle vertueux de “validated learning”.
• Design Thinking

D’un point de vue pratique, l’adoption de l’agilité se heurte à de nombreux obstacles, les principaux étant liés au management. Jurgen Apello nous propose quelques clés de mise en oeuvre

Se mettre à l’entrainement

Donner de l’énergie aux personnes

A l’image du “Kudo Box”, une façon pour les employés de manifester leur reconnaissance envers une autre personne de l’entreprise.

Redonner du pouvoir aux équipes. Mais comment garder la direction d’une équipe auto-organisée ? En agissant sur les contraintes du système ! Le management est en charge des contraintes.

Authority board

Il y a différents niveaux de maturité du management sur la façon dont il peut manifester son autorité. L’autority Board permet de visualiser cela et même de le partager avec l’équipe.

1. Demander : C’est le niveau de base, du type contrôle / commande.
2. Vendre : C’est chercher à convaincre le collaborateur que ce que l’on souhaite est désirable.
3. Consulter : Le manager demande l’avis de ses collaborateurs avant de prendre une décision.
4. Donner le consentement : Le management n’engage l’action que lorsque les collaborateurs marquent leur accord.
5. Suggérer : Le manager va laisser les collaborateurs décider de leurs actions, sur la base de conseils prodigués.
6. Investiger
7. Déléguer : Le management fixe les objectifs et laisse les collaborateurs fixer le plan d’action.

Aligner les contraintes

Les outils pour cela peuvent être:

• Donner le sens de la finalité.
• Permettre aux personnes de s’identifier dans l’entreprise, par exemple en leur donnant la possibilité de se choisir un nom d’équipe !
• Leur donner l’opportunité d’être fiers de leur produit !

Développer les compétences

En permettant aux personnes de s’aguerrir en continu:

• Exploration days
• Brown bag lunches (là, c’est moi)

Faire grandir la structure

S’améliorer, ce n’est pas seulement améliorer les connaissances individuelles, mais aussi améliorer les pratiques et le corpus de connaissance des groupes dans l’entreprise.

Jurgen préfère parler de “guildes” que de “communautés de pratiques” … essentiellement parce que c’est plus sexy !

Améliorer l’ensemble

C’est être en quête d’amélioration continue, mesurer le plaisir des personnes à accomplir leur travail, ou plutôt de contribuer à l’entreprise !

Alors que la présentation du matin abordait les thèmes du dernier livre (ou livret, devrais-je dire) de Jurgen Appelo “How to change the world”, celle-ci traitait des thèmes de son désormais célèbre “management 3.0”. J’ai quand même préféré l’intervention du matin, dont le message était plus simple.

Management 3.0 reste une brique de connaissance ardue, difficile à rendre en seulement 1 heure !

Retour d’expérience SAP

Un retour d’expérience, ça peut être très bon ou très mauvais. Voir très très mauvais. En fait, les niveaux intermédiaires existent aussi. Qu’en est-il de celle-ci ? Le suspens est à son comble …

J’ai plutôt bien aimé ce retour d’expérience. Je n’y ai pas appris grand chose, mais c’est interessant d’observer ce qui a été fait, lorsque c’est exposé avec honnêteté et simplicité, ce qui était le cas ici.

La division Caennaise de SAP est en fait l’acquisition d’une société nommée Highdeal. Le passage vers l’agilité y a débuté en 2009 sous l’impulsion de la maison-mère, avec un focus sur le Lean Software Developpement, donc avec une attention particulière portée sur l’élimination du gâchis ! la déclinaison des différents principes agiles s’opère comme suit :

• Flow principle : PCP (Product Creation Process)
• Takt principle : ce sont les sprints
• Pull principel : Scrum, avec un backlog prioritisé
• 0 defect : C’est la mise en oeuvre de la roue de Deming.

Voici les points ont attiré mon attention :

Le product owner

Un vrai PO pour chaque équipe, c’est un vrai plus ! L’expérience du “PO partagé” s’étant avéré non concluante.

Il porte la vision, mais fait aussi le lien avec les interlocuteurs, et ils sont nombreux : équipes distantes, parties prenantes, partenaires SAP solution.

J’ai ressenti beaucoup de satisfaction par rapport à ces PO et au fait qu’ils s’approprient les projets et se sentent partie intégrante des équipes.

Difficultés sur la mise en oeuvre de l’agilité

Le projet est gros : il nécessite un “chief Product Owner” pour encadrer les POs !

SAP est une grosse mécanique, et cela signifie beaucoup (trop) de niveaux pour atteindre le client réel … si jamais on parvient jamais à le toucher directement !

Les items du backlog semblent aujourd’hui très gros : il faut souvent plus d’une itération pour les achever ! Cela a bien sûr un impact sur la fréquence des releases : 3 à 4 par an, ce qui reste un gros progrès par rapport à l’unique release annuelle qui était le standard précédent !

Teamwork

Chaque équipe dispose d’une “war room” qui sert aux réunions et à l’affichage de tout ce qui a besoin d’être affiché. L’équipe a d’ailleurs abandonné la gestion de tickets avec Jira au profit du tableau de tâches avec les post-it.

La visibilité a grandement progressé, mais il reste encore des problèmes telles que les “tâches non identifiées” qui apparaissent en cours de sprint et ne sont pas répertoriées sur le tableau. Cela impacte de manière non mesurable la vélocité.

La taille des équipes (environ 12 personnes) me semble trop importante ! Je serais curieux de voir comment cela fonctionne concrètement : il y a-t-il de petits groupes informels qui se sont formés ? Les membres des équipes travaillent-ils de manière isolée ? Curieusement, il y avait initialement 3 équipes plus petites et ce sont les équipes qui ont choisi de se réorganiser en 2 grandes équipes !

En conclusion

Beaucoup de progrès semblent avoir été effectués en 3 ans ! Cette société vient d’une culture “waterfall” très solidement ancrée et il me semble y voir de nombreuses réminiscences. Elle mettront du temps à partir !

Les Scrum Masters mesurent la maturité de leurs pratiques agiles en utilisant l’Agile Alliance Subway : je trouve cela assez futé et très pratique. C’est la première fois que je le vois utilisé ainsi !

Agilité 2.0

Durant cette dernière session de la journée, Sylvain Saby nous a présenté sa vision du “modèle étendu” de l’agilité. Il repose sur 3 piliers

Pour bien le comprendre, Sylvain évoque le modèle water-scrum-fall Evoqué par Dave West dans un rapport Forrester !

En effet, si le modèle est itératif dans la partie développement, il ne l’est souvent pas en amont dans les activités de définition de produit, pas plus qu’il ne l’est en aval dans les activités de production !

Devops !

Commençons par la parie aval.

Le passage en production casse la livraison itérative en lotissant les mises en production. On perd la boucle de feedback avec le client final et donc une importante part des bénéfices de l’agilité.

Là où les cellules d’opérations se focalisent sur le MTBF, donc des pannes les moins fréquentes possibles, ce qui exige de longues qualifications et un rythme réduit de passages en production, devops se focalise sur le “MTTR”, ou le temps nécessaire pour réparer !

Les conséquences du passage au devops sont :

• Nécéssité d’utiliser des technologies adéquates : des serveurs qui s’installent vite et simplement, des serveurs d’application qui démarent rapidement, etc…
• Intégrer dans la conception des “switeches” permettant d’activer ou désactiver des fonctionnalités à chaud.
• Lotir les évolutions par petits incréments de changements.
• Faire évoluer le concept de “done” pour le faire aller jusqu’à la production : “done”, c’est une feature déployée en production et utilisée par des utilisateurs !

Au final, devops lisse les passage en production (lorsque le mouvement a démarré chez Flickr, on en comptait en poyenne 10 par jours !).

Lean startup

Les cycles business se raccourcissent : on compte aujourd’hui en moyenne 7 ans entre la naissance d’une startup, son apogée puis son déclin (ou son pivot) ! Des plans projets couvrant des années ou même des mois ne sont plus de mise.

La définition du produit elle-même doit être agile. L’approche Lean Sartup avec son MVP et son cycle de “validated Learning” couvre bien cet aspect.

La technologie et le rôle de l’architecte

Sylvain a beaucop insisté sur le rôle de la technologie dans ce paysage. On voit que le sujet lui tient à coeur ! Il a évoqué 3 volets plus particulièrement.

NoSQL

Les différentes moutures de bases de données NoSQL offrent plus de flexibilité pour stocker les données et surtout permettre de faire évoluer la structure des données qui y sont stockées, car elles sont “sans schéma” pour la plupart d’entre elles.

Sylvian résume leurs caractéristiques par rapport aux bases de données relationelles : elles ne sont pas faites pour classer les donnés, mais sont fortes pour retrouver ! Ou de synthétiser leurs propriétés par les “3 V”: Volume, Variété, Vélocité !

Cloud computing

L’un des freins aux évolutions logicielle est le déploiement, la gestion de la compatibilité ascendante, l’hétérogéneité des configurations et versions déployées.

Pour se débarasser de ces freins, la solution est de déployer son soft en SaaS, donc en service hébergé. Les problématiques de configurations et de déploiement se trouvent immédiatement simplifiées. Bien sûr le prix à payer est de convaincre les clients de ne plus avoir ces services en local chez eux et aussi de suivre les évolutions de version qui leur sont imposées.

Architecture des applications

Le standard d’architecture de applications actuelles est le modèle en couche. Pour rendre le SI plus agile, il faut passer à une architecture plus “verticale” où les services sont modulariés sous formes d’applications indépendantes, communiquant potentiellement par les API implémentées sous forme de Web Services REST.

Une telle architecture devient plus facile à opérer et les évolulutions y ont un moindre impact. Sylvain milite sur ce plan pour un rôle accru de l’architecte (qui n’existe pas dans Scrum) par rapport au Product Owner.

La modularité permet aussi de basculer plus facilement vers de nouveaux frameworks ou des langages plus adaptés à telle ou telle technologies au fur et à mesure de leur apparition ! Ceci a des conséquences par rapport à notre appréhension des technologies:

• Des appliations qui deviennent “jetables”.
• Pas d’investissement “longue durée” sur des technologies, mais un usage qui se limitera aux “fonctionnalités centrales” faciles à appréhender et ne demandant pas un niveau d’expertise poussé.
• Un shift vers le “monkey développer”, allant très vite sur une nouvelle technologie ou un nouveau frameworks via un “copier-coller” de code issu d’une recherche Google !

Le constat peut sembler dur, je ne suis pas certain de le partager complètement, mais surement en partie toutefois.

En conclusion

L’agilité 2.0 vue par Sylvain Saby a plusieurs corollaires:

• Une manière d’opérer les systèmes “à la devops”, selon l’adage “you build it, you run it !”.
• La fin des architecture monolithique et la nécessité mettre l’architecture au même niveau d’importance que le travail fait sur le produit.
• La nécessité de tirer les profils vers le haut : travailler avec moins de personnes, mais des personnes plus solides, productives et capables d’appréhender très vite de nouvelles technologies, de nouveaux langages…

Partir revenir

C’est pour cette première édition du printemps agile !

Bien sûr le gros coup, c’était d’avoir fait venir Jurgen Appelo : encore bravo aux organisateurs pour ce tour de force !

Le reste du programme était tout à fait honorable, à la hauteur d’un agile tour, dirais-je. J’ai pu échanger un peu avec la communauté agile Caennaise et suis donc extrêmement heureux qu’elle existe !

Cette première édition du printemps agile est un succès, aucun doute là-dessus. Tout le monde semble motivé pour remettre le couvert l’an prochain. Moi aussi !

Ce n’est pas le premier évènement organisé par le club agile de Caen, mais c’était la première conférence d’importance qui se tenait en basse Normandie. C’était pour moi l’occasion de venir traîne mes guêtres sur le “campus 2” qui n’était qu’à l’état embryonnaire quand j’ai fait mes études.

80 personnes pour cette première édition, c’était tout à fait honorable, d’autant qu’il s’agit d’un évènement régional. Tout de même, je n’en reviens pas que le comité organisateur soit parvenu à faire venir Jurgen Appelo ici !

C’était bien sûr l’attraction de la journée, et Jurgen nous a gratifié de deux interventions d’excellente qualité. J’en ai bien sûr profité pour obtenir une petite dédicace de mon “management 3.0” tandis que lui-même a voulu photographier mon exemplaire orné de ses post-it multicolores !

Justement, parlons maintenant de la première intervention  de Jurgen, qui a juste suivi l’intervention introductive de Jean-Luc Lambert, initiateur et président du Club Agile de Caen, et professeur à l’université de Caen.

Jurgen Appelo : How to change the world ?

 Cette première intervention de Jurgen porte le nom de son second livre (dont la relecture viendra bientôt sur votre blog préféré). La question à laquelle l’orateur tente de répondre ici est : comment rendre mon organisation plus agile ? Ceci implique une autre question : comment influencer les autres personnes.

Ceci nécessite le plus souvent un changement même de la culture d’entreprise, ce qui ne va pas sans mal car la résistance au changement est l’état naturel des choses. Jurgen a appelé l’approche qu’il nous présente ici, la “mojito method”. Il y a 4 ingrédients (4 facettes) qui nécessitent d’être mélangés pour être efficaces. Commençons par la première

1 – Dancer avec le système

Comme le dit si bien Jurgen, il y a un modèle, de toute façon on a un modèle pour tout ! Celui qui va bien ici est la fameuse roue de Denning, ou cycle PDCA.

a) Plan (planifier) :C’est collecter des informations, prendre des décisions sur ce que l’on va faire, mais faire pour obtenir une différence … et avoir du “fun” !

b) Do (faire) : Dans les approches agiles, on va chercher à visualiser le processus et ce qui est réellement accomplis.

c) Check (vérifier) : Vérifier le résultat obtenus et le comparer aux attentes. Les rétrospectives auxquelles nous sommes habitués prennent place ici.

d) Act (agir) : Après la rétrospective, vient l’anion corrective: comment accélérer les résultats. Devons-nous renforcer ce que nous avons fait ? Persévérer ? Ou abandonner pour essayer quelque chose d’autre ?

Il est probable qu’aucune des actions que nous allons entreprendre ne donnera le résultat escompter. On ne peut pas dominer le système, seulement s’arranger avec lui … cancer avec lui ! 9 idées sur 10 échoueront probablement, mais avec la 10ème …

2 – Mind the people

Nouvelle facette, nouveau modèle. Ici c’est le ADKA model dont nous allons parler.

Ce modèle mous permet de prendre conscience de la maturité des individus par rapport à un changement et de faciliter leur transition.

A : Awareness (prendre conscience). Prendre conscience et engager le changement sont deux choses différentes. Jurgen évoque le cas des messages sur les paquets de cigarette: leur but est de faire prendre conscience, pourtant leur impact en terme de changement de comportement est à peu près nul.

D : Desire. C’est stimuler la volonté du changement.

K: Knowledge (connaissance). C’est procurer la connaissance nécessaire à mettre en oeuvre le changement

A : Ability (capacité). On facilite cela en éliminant les obstacles entre l’individu et le but à atteindre. Le “1 click purchase” d’Amazon illustre cela parfaitement, en rendant facile à l’extrême l’acte d’achat.

R : Reinforcement (renforcement). Pour donner de la permance à ce changement, il faut lui donner une dynamique d’entretien. La ramification illustre cela : l’atteinte de certains niveaux donne accès à des points (échangeables) ou des badges…

3 – Stimulate the network

On s’intéresse ici à l’effet viral du changement. Comment provoquer un effet de contagion ? Cela passe par le réseau d’influence entre individus. Evidemment, ici encore nous avons un modèle : le modèle d’adoption de moore.

Cette courbe divise la population en 5 segments qui nécessitent des approches différentes.

Les initiateurs / innovateurs : Ils sont sensibles à la nouveauté et à l’intérêt que peut apporter un changement. Ce qui est surtout nécessaire, c’est de leur faire briller les yeux.

Les early adopters : Pour les entrainer, il faut s’appuyer sur des “influenceurs” … ce seront les innovateurs.

L’early majority : Ce qui marche pour les “early adopters” ne marche pas pour eux. Ils n’adopteront pas un changement parce que d’autres le font, mais parce qu’on peut leur en montrer les bénéfices. Un message différent doit leur être donné.

La majorité tardive : Ce sont ceux qui disent que ça ne marchera jamais, ce sont les sceptiques. Il est important de les écouter afin de “neutraliser le poison”.

Les “laggards” : C’est la poche de dernière résistance, ceux qui ne veulent bouger sous aucun prétexte. Le mieux est de s’en débarrasser !

4 – Change the environment

Lorsque l’on parle d’auto-organisation, il ne faut pas oublier que celle-ci ne peut se mettre en place que dans des limites, parce que l’on établit un système contraint. Ici encore, nous avons un modèle, celui des “5 ‘I’ ”

Informations : C’est donner de la visibilité sur l’état des choses, permettre aux personnes de voir leur propre comportement afin de l’observer, à l’exemple des “buis wall” que nous avons pour l’intégration continue.

Identity : C’est donner un sens de l’appartenance, par exemple en permettant aux équipes de se donner un nom, d’avoir un élément de reconnaissance.

Incentives : Comment est effectuée la rémunération ? Comment sont accordés les bonus ? je ne vais pas revenir sur le “merit money” qui était le sujet de l’intervention de Jurgen à Stoos Connect. Vous trouverez ici le résumé de cette intervention, la vidéo ainsi que le support de présentation.

Infrastructure : Elle doit être libre de tout obstacle au bon fonctionnement de l’équipe telle qu’on l’entends et guider les bons usages.

Institutions : C’est définir et renforcer les règles de “bons comportements”.

A emporter

Jurgen Appelo nous propose une façon d’observer la situation d’une organisation selon 4 facettes. je pense que c’est quelque chose à retenir, car il n’est pas facile de savoir sous quel angle aborder une situation. C’est certainement, au minimum, un bon outil d’analyse.

Il ne faut certainement pas aborder les modèles proposés sur chaque facette de manière psycho-rigide. Ils peuvent s’avérer utiles et Jurgen Appelo prends soin de remplir la musette avec du matériel qui s’avèrera utile dans grand nombre de cas, mais il faut savoir prendre ici ses propres choix, ses propres décisions.