Retours sur le printemps agile à Caen (2/2)

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é.

printemps-agile13-lunch1

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 !

printemps-agile13-lunch2

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.

printemps-agile13-appelo01

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 …

printemps-agile13-public01

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

printemps-agile13-agile2_0

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 !

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s