Accompagner la transition agile
d’un grand projet
L’expérience Linky
Qui suis-je ?
Coach agile @ Zenika
Computer addict depuis 1980
Agile maniac depuis 2001
Graves antécédents : développeur, ...
Le projet Linky
Je ne suis pas ici pour vous en parler, mais…
✓Transition vers le « compteur intelligent »
✓Une nouvelle f...
Gros projet / Petit projet
Transition : comment ?
12 leçons (durement) apprises
Attention !
Il ne s’agit pas de recettes
magiques !
Ca marche pour moi. Et pour vous
?
Une base de reflexion pour
adapter ...
1 - Immersion agile
Une journée pour
appréhender les principes et
les concepts agile
Ne pas considérer les
principes agile...
2 - Commencer lentement,
délibérément
Apprendre les « gestes » Scrum
correctement
Pas de compromis sur la qualité
Le rôle ...
« Faites attention à ce que vous
demandez, vous risquez de l’obtenir
! »
Christophe Addinquy
Durant les premières itératio...
3 - Le droit à l’erreur
Rassurer d’entrée de jeu
Améliorations ➤ Expérimentation :
Sortir du « non risque » et
rechercher ...
VOUS avez le droit à l’erreur !
Etre humble : personne n’aime les donneurs de
leçons
Vous allez découvrir de nouvelles sit...
4 - Utiliser les tests d’acceptation
Créer de la compréhension
partagée
Lever les ambiguïtés
ensemble
Discipline de maîtri...
5 - La posture du management
6 - Veiller sur l’auto-organisation
7 - Craftsmanship
Le « savoir-faire » est un pré-
requis
Prendre la température aux
code-review
Injecter de vrais craftsme...
« Une interface doit être facile à
bien utiliser, et difficile à mal
utiliser. »
Scott Meyers
Responsabilité unique (class...
8 - Le fond et non la forme
« comment » « pourquoi »
Rôles
Cérémonies
Post-it
Collaboration
Interactions
Feedback
Focus
Im...
9 - Apprendre à s’améliorer
Comprendre Mesurer
Explorer
Le vrai challenge
du Scrum Master
10 - L’architecture compte !
Quelle efficacité dans votre cycle de
développement ?
11 - Off / On
Transitions douces ??
L’autonomie de l’équipe
Livrer en fin de sprint
Pas de challenge
insurmontable
12 - Parfois, il faut plonger pour
mieux réussir…
On ne peut pas forcer les
personnes à être aidées.
Une phase de dégradat...
@addinquy
http://freethinker.addinq.uy
christophe.addinquy@zenika.com
addinquy
addinquy
addinquy
addinquy
addinquy
Prochain SlideShare
Chargement dans…5
×

Accompagner la transition agile d’un grand projet

1 710 vues

Publié le

Basculer en agile un très gros projet est un challenge, pour certains cela peut même apparaitre comme une ineptie. Pourtant c’est que le projet Linky a décidé de faire ! Un tel choix fait émerger des difficultés souvent absentes de projets plus petits : culture « cycle en V » omnisciente, grandes équipes, intégration dans l’architecture du SI, etc.
Pourtant, si la route reste longue, les signes de succès sont réels. Au cours de cette session, nous allons aborder 12 leçons apprises lors de cette imporatnte transition agile toujours en cours, en y associant des conseils.

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 710
Sur SlideShare
0
Issues des intégrations
0
Intégrations
876
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Plus gros projet informatique ERDF depuis longtemps : plusieurs milliards d’euros
    C’est une transformation en profondeur d’ERDF ; une nouvelle façon d’opérer le réseau :
    de relever à distance des informations,
    de mieux connaitre les usages
    d’aller vers des « smart grids » adaptées aux énergies renouvellables et aux petits producteurs, etc.
  • Dans les gros projets, les membres ont l’habitude d’être une goutte d’eau dans une armée : Plus de résignation par rapport à une organisation rigide et avoir moins son mot à dire sur la façon de faire les choses : enclencher l’auto-organisation est moins facile.
    Organisation compliquée : il faut souvent « faire avec »
  • Je vais partager avec vous 12 leçons ou patterns, souvent durement appris.
    Pas des principes généraux, mais des choses actionnables.
    Vous allez voir que ces points ne sont pour la plupart pas indépendants.
    Ce n’est pas une liste exhaustive, mais ce sera déjà bien assez pour aujourd’hui !
  • Des leçons apprises ne sont pas des recettes ; il est dangereux de les appliquer sans comprendre ce que l’on fait et les implications de ce que l’on fait (tout a des implications.
    Ce n’est pas de la magie
    Utilisez-les, mais réfléchissez à ce que vous faites
  • Ne pas croire que l’agile « est naturel » et que les membres des équipes vont automatiquement comprendre en faisant
    Les équipiers risquent d’essayer de se fondre dans les rituels mais en gardant le vieil état d’esprit..
    1 jour pour comprendre les principes de base de l’agile et l’état d’esprit agile
    Des jeux
    Des discussions
    1 jour tout de suite vaut mieux que 2 jours plus tard
    L’investissement qu’acceptent les grands marchands de viande par rapport aux personnes est 0 !
  • Les équipes ont envie de rusher
    Focaliser agressivement les équipes sur le respect des règles du jeu.
    Demander explicitement à ne pas aller trop vite !
    Donc c’est :
    Faire du bon travail
    Améliorer l’efficacité et la vélocité … mais progressivement !
    Je n’aime pas le message « 600% » de Sutherland
  • Utiliser un (ou quelques) indicateurs qui influeront sur le comportement de l’équipe.
    Il y a des indicateurs qu’il faut enlever pour ne pas induire de biais.
    Ne pas mesurer, ni ne regarder ce qui risque de tirer dans le mauvais sens.
    « passer le message » ne sert à rien => Les gens regardent les actions ; en cas de divergence entre le message et l’action...
    Idéalement, le bon nombre d’indicateur est « 1 ».
    Au fait, n’oubliez pas qu’un indicateur doit être actionnable, sinon => out !
    Pas de notion d’indicateur « pour information » : il fait baisser la crédibilité des autres.
  • La chose qui a déstressé les équipes lors du passage à l’agile.
    Penser : si je rate, quelles sont les conséquences.
    Des erreurs, on en fera ; pas de recette magique pour ne pas en faire.
    Je laisse aller au bout des erreurs (si elles ne mettent pas l’équipe en danger) : c’est la meilleure façon d'apprendre
    Exemple : beaucoup de stories en cours (optimisation de capacité) au premier Sprint !
    Peu d’US terminées en fin de sprint : 1, parfois 0
  • Dites-le : cela montre que vous êtes humble et que vous n’êtes pas au-dessus de la mêlée.
    Une bonne façon de faire pour que le client n’attende pas de la magie de votre part.
  • Le bon truc pour obtenir quelque chose de terminé en fin d’itération.
    Problème du test en aval… => l’un des plus gros obstacles (on va revenir plus tard là-dessus)
    Mais pas seulement...
    Voir le « workshop des 3 amis » de Gojko Adzik
    Permet de débugger la spécification : un AT, c’est l’instanciation de la spécification
    En explorant les cas aux limites, on relève d’éventuelles incohérences
    On crée de la compréhension partagée
    Un bon AT est univoque : on est obligé de faire un choix par rapport à de l’information implicite et on relève les différences d’interprétation.
    Dans l’ancien modèle : spécification passée indépendamment à la réalisation et aux tests qui n’ont pas le droit de se parler !
  • L’une des actions d’accompagnement les plus importantes !
    Arrêter le « comment » !
    Utiliser les outils de Jurgen Appelo
    Pas de droit de dire aux personnes ce qu’ils ont à faire => pas facile et frustrant.
    Comment travailler sur le cadre pour induire les comportements que l'on cherche à obtenir.
    anecdote du nombre des « en cours »...
  • Combattre la culture « petits soldats ».
    Surveiller les symptômes :
    « on ne nous a pas demandé »...
    Qui est responsable de...
    Combattre les baronnies : les titres, les équipes transverses.
    Attitude ambivalente à ce sujet.
  • Hélas peu mis en avant aujourd’hui dans les accompagnements agile.
    Pourtant l’excellence technique est cité par les auteurs comme un prérequis à Scrum.
    Bonne méthode : de l’infusion « par l’intérieur » avec des développeurs expérimentés qui travaillent avec les équipiers en se mettant à côté d’eux.
    La méthode « par l’extérieur » est aussi à essayer, via des BBL, des coding dojos, etc… Mais pas de succès flamboyants. Entre autre en terme de participation.
    Au moins, cela permet de prendre la température de l’intérêt du sujet.
    Ceux qui viennent ces BBL sont plutôt ceux qui en ont le moins besoin.
    Générer de l’intérêt pour ce sujet est difficile : faire du bon code est plus cher que de faire du mauvais code, c’est aussi plus de réflexion, etc...
    Meilleurs moyen : créer une spirale vertueuse pour attirer les bons talents
    Mais le contexte organisationnel et contractuel rend cela plus difficile
    Les contractualisation se font beaucoup avec les grosses boutiques possédant peu de ces talents, sur la base du « cost cutting ».
    Les talents que l’on recherche sont attirés par les contextes techniques alléchants et où l’organisation leur laisse la marge de manoeuvre pour qu’ils s’expriment (voir [6], point précédent).
  • C’est ma boussole personnelle ; elle intrigue positivement les gens mais s’avère difficile à suivre
    Se focaliser sur des sujets que l’on hiérarchise.
    Traiter l’amélioration du code juste par Sonar, c’est rater de lui donner du sens !
    La qualité reste un des sujets d’insatisfaction, entre autre parce que ce n’est pas un sujet d’insatisfaction au sein des équipes !
  • Passer du « comment » au « pourquoi ».
    Le folklore Scrum, c’est du « comment » -> il est là pour aider à appréhender le pourquoi
    Se méfier des « audits » qui se focalisent sur le folklore (se méfier des audits en général, d’ailleurs -> rechercher leur « pourquoi »).
    Oui, il faut passer par la mise en place du « folklore » lors de la transition : il a été imaginé parce qu’il marche et constitue une bonne façon d’enclencher les bons comportements.
    Mais il faut regarder les choses importantes derrière ce folklore
  • Le « 2nd challenge » des SM.
    Utiliser la « communauté des SM ».
    Rétrospectives -> une logique d’objectifs / mesures / revue en rétro suivante
    Eviter les gros chantiers -> on ne le faits jamais car on a le « vrai projet à faire.
    Préférer les petits pas.
    Ne pas cantonner les améliorations aux rétrospectives
    Le A3
    Etre opportuniste => On remonte en cours de sprint des choses qui ne sortent pas forcément en rétro.
  • On entends parfois qu’Agile est indépendant de la technologie !
    En fait le technologie a un effet dimensionnant sur la mise en place de l’agile, même si à la base il s’agit d’un « mind set » humain.
    Des choix d’éditeurs rassurant => wrong
    Des choix basés sur une « feature list » => wrong again
    Des choix basés sur le retour d’expérience et l’opérabilité => bien mais pas suffisant
    Quid de l’utilisabilité en développement ?
    Testabilité ?
    Boucle de feedback ? Favoriser des outils qui peuvent se tester avec JUnit !
    Penser en « coût de transaction » : si le coût de transaction est élevé => on fera de grosses tâches, de grosses user stories.
    Regarder aussi la modularisation que permet l’outil, cela peut avoir un impact sur la modularisation et la parallélisassions du travail.
    Quel temps / difficulté pour packager / déployer
    Quel réactivité pour le « start up » et donc quel impact sur la durée des tests ?
    Imaginez un environnement de travail qui vous impose que tout votre code Java ou C# soit dans une unique fichier source...
    Votre serveur d’application induit-il des comportements différents de ceux que vous allez constater « en local » ?
  • J’ai cru pendant un certain temps que l’on pouvait introduire progressivement des concept agiles jusqu’à ce qu’un beau jour on constate que l’on est agile !
    En fait, c’est insatisfaisant car on est pas agile et on introduit de l’incompréhension.
    Le meilleurs moyens, c’est la rupture franche, avec des contraintes et des précautions
    Contraintes :
    Obtenir un produit utilisable en fin d’itération : nécessité de rapatrier les tests dans l’itération !
    l’ATDD est d’une grand aide ici.
    Mettre ensemble les personnes nécessaire au boulot et ne pas dépendre de ressources externes « matricielles » : le matriciel, c’est de l’optimisation de capacité !
    Précautions :
    Pas de contrainte sur la vélocité au début (voir [2])
    Accepter que ça ne va pas bien marcher au début (voir [3])
    Ne pas se fixer de challenge impossible : les tests doivent tous être automatisés
  • Dès que les équipes pensent « avoir compris », elles cessent de faire appel à vous.
    Surveiller les tendances : rigueur, interactions et collaboration, travail en cours
    Posez à l’occasion des questions dérangeantes. Mais cela n’a pas toujours d’impact.
    Quand les conséquences deviennent douloureuses => on vient vous voir !
    Votre aide prendra beaucoup mieux à ce stade.
  • Accompagner la transition agile d’un grand projet

    1. 1. Accompagner la transition agile d’un grand projet L’expérience Linky
    2. 2. Qui suis-je ? Coach agile @ Zenika Computer addict depuis 1980 Agile maniac depuis 2001 Graves antécédents : développeur, analyste, modelisateur UML, chef de projet, design patterns fan-boy, formateur, directeur de projets, etc.
    3. 3. Le projet Linky Je ne suis pas ici pour vous en parler, mais… ✓Transition vers le « compteur intelligent » ✓Une nouvelle façon de gérer le réseau ✓Le plus gros projet ERDF depuis … très longtemps
    4. 4. Gros projet / Petit projet
    5. 5. Transition : comment ? 12 leçons (durement) apprises
    6. 6. Attention ! Il ne s’agit pas de recettes magiques ! Ca marche pour moi. Et pour vous ? Une base de reflexion pour adapter et apprendre.
    7. 7. 1 - Immersion agile Une journée pour appréhender les principes et les concepts agile Ne pas considérer les principes agiles comme « évidents » 1 jour tout de suite vaut mieux que 2 jours plus tard ! Des jeux et des discussions
    8. 8. 2 - Commencer lentement, délibérément Apprendre les « gestes » Scrum correctement Pas de compromis sur la qualité Le rôle du management : pas de raccourcis ! L’équipe cherchera spontanément à aller vite !
    9. 9. « Faites attention à ce que vous demandez, vous risquez de l’obtenir ! » Christophe Addinquy Durant les premières itérations Focus sur la qualité fonctionnelle et technique Attention sur la dynamique de groupe, le partage et le focus sur peu de User Stories Pas de mesure de vélocité. Nous avons même rendu toute comparaison directe entre équipe presque impossible !
    10. 10. 3 - Le droit à l’erreur Rassurer d’entrée de jeu Améliorations ➤ Expérimentation : Sortir du « non risque » et rechercher des expérimentations peu coûteuses Une erreur est une opportunité d’apprendre quelque chose Laisser les erreurs (et non l’échec) arriver
    11. 11. VOUS avez le droit à l’erreur ! Etre humble : personne n’aime les donneurs de leçons Vous allez découvrir de nouvelles situations Vous allez apprendre quelque chose de votre client Ca va vous arriver de toute façon…
    12. 12. 4 - Utiliser les tests d’acceptation Créer de la compréhension partagée Lever les ambiguïtés ensemble Discipline de maîtrise et de validation de l’avancement
    13. 13. 5 - La posture du management
    14. 14. 6 - Veiller sur l’auto-organisation
    15. 15. 7 - Craftsmanship Le « savoir-faire » est un pré- requis Prendre la température aux code-review Injecter de vrais craftsmen au sein des équipes Organiser la montée en compétence Les métriques de la plateforme d’intégration ne suffisent pas !
    16. 16. « Une interface doit être facile à bien utiliser, et difficile à mal utiliser. » Scott Meyers Responsabilité unique (classe, méthode) Le nom révèle l’intention Tests unitaires pertinents (TDD)
    17. 17. 8 - Le fond et non la forme « comment » « pourquoi » Rôles Cérémonies Post-it Collaboration Interactions Feedback Focus Implication Transparence
    18. 18. 9 - Apprendre à s’améliorer Comprendre Mesurer Explorer Le vrai challenge du Scrum Master
    19. 19. 10 - L’architecture compte ! Quelle efficacité dans votre cycle de développement ?
    20. 20. 11 - Off / On Transitions douces ?? L’autonomie de l’équipe Livrer en fin de sprint Pas de challenge insurmontable
    21. 21. 12 - Parfois, il faut plonger pour mieux réussir… On ne peut pas forcer les personnes à être aidées. Une phase de dégradation peut succéder à la mise en place. L’aide en seconde phase est plus perenne.
    22. 22. @addinquy http://freethinker.addinq.uy christophe.addinquy@zenika.com addinquy addinquy addinquy addinquy addinquy

    ×