Valtech sera présente au rendez-vous incontournable de la communauté Agile française qui se déroule le 26 et 27 Mai au Chalet de la Porte Jaune. Pour cette édition, diverses conférences seront animées par des consultants Valtech :

« Dans la peau du manager agile »

Présenté par Jean-Claude GROSJEAN, COACH AGILE  et  Consultant UX

Quand il s’agit d’agilité, ne laissez pas vos Managers au bord du chemin ! Aidez-les plutôt à devenir des managers Agiles… et à maîtriser l’évolution de leur métier. Entre nécessité et opportunité, le métier de Manager Agile (au sein d’une organisation agile) devient un savant compromis entre le maintien de certaines responsabilités, l’abandon de certaines autres et l’acquisition de nouveaux savoir-faire et savoir-être… L’ère est au management Agile & Lean.

“Quand Product Owner rime avec Marketeur – Agile UX et ATDD”

Présenté par Hélène Granboulan-Bensalem, Consultante Senior & Formatrice, Analyste Agile et Jean-Claude GROSJEAN, COACH AGILE  et  Consultant UX

Le marketing donne naissance à des projets particulièrement créatifs & réactifs. L’expérience montre que l’agilité permet de répondre à ce contexte et à ses véritables enjeux: livrer à temps, un produit opérationnel, que l’on sait adapter jusqu’au dernier moment. Cette session se propose d’illustrer les responsabilités, les pratiques et certains outils du rôle de Scrum “Product Owner” dans lequel le marketeur va se glisser : Agile UX (expérience utilisateur agile), ATDD (spécifier ensemble par l’exemple), et plus encore…

“Une usine logicielle pour une usine, vers le déploiement continu en production”

Présenté par Claude Falguière,  Consultante Senior Java et Maxime Lemanissier (ancien Valtech, PhotoBox)

Retour d’expérience sur la mise en place d’une usine logicielle sur un ensemble d’applications qui gèrent un site de production (Java, Flex, Python).

Pour conserver l’aspect très réactif des déploiements actuels mais améliorer la qualité, nous voulons mettre en place un processus de déploiement continu jusqu’à la production.

“Lire du code”

Présenté par Etienne Charignon, Consultant et Extreme Programmer

Au cours de notre parcours de formation de programmeur ainsi que dans notre travail, nous dépensons beaucoup d’énergie à apprendre à écrire du code.

Je vous propose ici de nous arrêter quelques minutes sur cet aspect méconnu et qui occupe pourtant la plus grande partie du temps d’un développeur : lire le code.

“Product Owner : Valorisez vos Epics”

Présenté par Yannick Ameur, Consultant Senior et Coach Agile

Il s’agit d’un atelier pour les PO pour leur montrer les différences entre une gestion de type concurrentiel interne à l’entreprise et une gestion Collaborative des différents PO  responsable de leur domaine.

“10 ans après… Ma première expérience agile”

Présenté par Xavier RENAUDIN, Consultant Confirmé et certifié Scrum Master  et Katia Aresti (Xébia)

Un échange entre Katia, qui découvre le monde de l’agilité sans aucune formation théorique et Xavier, Scrum Master essayant d’appliquer ses connaissances théoriques dans l’Agilité.  Un échange autour d’un retour d’expérience.

Les inscriptions sont encore ouvertes. Soyez nombreux à l’évènement Agile de l’année

Alistair Cockburn, l’un des leaders de la communauté Agile, sera à Paris lundi 28 mars.
A cette occasion, Valtech invite dans ses locaux tous les agilistes curieux de le rencontrer.

 
Programme de la matinée :

• 9h30 – 10h00 : Accueil / Petit déjeuner
• 10h00 – 12h00 : Session de brainstorming autour de l’agilité avec Alistair Cockurn

 
2 thèmes abordés au cours de cette session :

• “Advanced Agile” : discussion autour de l’état de l’art de la démarche Agile en France
• “ICAgile Program“: présentation du programme de certification Agile

 
Plus d’infos sur Alistair Cockburn :

Alistair est un des initiateurs du mouvement Agile ayant participé en 2001 à l’écriture du manifeste Agile. Il est connu dans la communauté pour ses écrits autour de la spécification logicielle par les Uses Cases. Il a fondé  Cristal Clear, une des méthodes Agiles. Plus récemment, en février dernier, Alistair a rassemblé les leaders de la communauté Agile pour fêter les 10 ans du Manifeste.

 
Inscription & Accès :

Si vous êtes intéressé(e), c’est avec plaisir que Valtech vous accueille pour cette occasion.
Cet événement gratuit est ouvert à tous.

• Inscription par e-mail : evenements@valtech.fr.
• Lieu : Valtech, 103 rue de Grenelle, 75 007 Paris (Plan d’accès)

Le 11 février matin, Valtech Training vous propose un séminaire gratuit à Toulouse avec retour d’expérience client.

Pour la partie conférence proprement dite, les points abordés seront :

• Origines et raisons du Manifeste Agile
• Ce que n’est pas l’agilité : cassons les caricatures
• Introduction aux frameworks agiles (Scrum, XP et Lean)
• Contraintes et flux : vos clients sont agiles !
• Mise en œuvre : agilité organisationnelle
• Contractualisation agile
• Quel ROI attendre ?

Le retour d’expérience sera réalisé par Richard Hugues, Lean Software Development Director au sein d’Arkadin Montpellier, qui exposera la mise en œuvre concrète des méthodes agiles dans sa société :

• Comment Arkadin a mis en œuvre Scrum ?
• Les difficultés rencontrées
• Les bénéfices pour Arkadin et ses équipes

En savoir plus et s’inscrire au séminaire sur les méthodes agiles du 11 février à Toulouse.

Découvrez également notre offre de formation sur les méthodes agiles.

Valtech accueillera la prochaine soirée mensuelle du French Scrum User Group. Ça se passe au 103 rue de Grenelle dans le 7ème arrondissement de Paris. Le rendez-vous est à 18h30 le jeudi 18 novembre 2010.

L’évènement est gratuit, une simple inscription ici suffit.

Le programme a été finalisé. Après une introduction de Xavier Warzee, l’actuel président du French Scrum User Group, deux parcours en parallèle vous seront proposés:

Retours d’Expérience Agile

Dans l’auditorium, 3 présentations se succèderont:

• Transformation Agile alliant Scrum, Kanban et ‘lab days’ chez PriceMinister  par Martin Sudmann (40 min)
• Expérimentation de Scrum & XP dans une DSI de culture Cascade dans le secteur bancaire par Céline Stauder (30 min)
• Scrumers, l’outil et l’adoption de Scrum dans une start-up par Ludovic Galabru (30 min)

Techniques de Coaching

Dans une autre salle, un atelier sera dédié à une technique de facilitation.

• Focused Conversation Method par Le Thi Lan Huong (90 min)

Les places à l’atelier étant limitées à 15 personnes, vous pouvez vous inscrire spécifiquement à partir du lundi 8 novembre sur cette page dédiée.

En clôture, un cocktail vous permettra de rencontrer les participants à la rencontre.

Des scénettes pour illustrer quelques anti-patterns organisationnels

On parle souvent de retour d’expérience (REX). Pour décrire des anti-patterns organisationnels en respectant l’anonymat des projets concernés, je vous propose ici du TDREX.  C’est la mouvance TDD / TDR (Test Driven Development/ Test Drivent Requirement, c’est-à-dire développements / spécifications dirigés par les exemples), qui m’a inspirée. J’ai donc inventé des scénettes – des exemples fictifs – pour exprimer un retour d’expériences difficiles.

Anti-pattern 1 : pas de communication coordonnée

Les différents acteurs du projet communiquent deux par deux au lieu de réunir toutes les personnes impliquées.

Exemple : Marc, Sophie et Eric

Marc et Sophie travaillent sur le même projet avec Eric. Marc prépare les ordinateurs, Sophie forme et explique aux utilisateurs où vont être installés les logiciels, et Eric livre les ordinateurs aux utilisateurs.

Pour s’accorder sur la date de livraison des ordinateurs, qui doit être la plus tôt possible…

1^ère version de l’histoire : l’anti-modèle (anti-pattern)

Eric va voir Marc pour savoir quand ils seront préparés, puis il va voir Sophie pour savoir quand elle pourra expliquer. Marc a répondu le 5 octobre (en fait, il peut avoir fini entre le 1 et le 7). Sophie répond (more…)

J’ai fait du RAD il y a quinze ans, était-ce déjà de l’agilité ?

Il arrive d’entendre cette question lorsque l’on fait découvrir l’agilité à ceux qui sont passés sur les plateaux de développement il y a quelques années. A tous ceux qui se posent la question, voici une mise au point sur le sujet. Dans cet article, on considère que l’acte de naissance de l’agilité est le manifeste agile en février 2001. La méthode RAD est quant à elle attribuée à l’américain James Martin qui la formalise dans son livre Rapid Application Development publié en 1991.

Le RAD formalisé

La méthode RAD s’est complétée au cours du temps avec les ajouts de 1994 versés notamment par le franco-canadien Jean-Pierre Vickoff. Si bien qu’il est difficile rétrospectivement de reconnaître les valeurs originelles de RAD… C’est précisément cette revendication agile tardive qui est parfois reprochée au RAD dans des débats passionnés avec les supporters de chaque camp. Mon objectif étant de ne pas rajouter de l’huile sur le feu de ce débat stérile (“ma méthode est plus grosse que la tienne” ), je tenterai de rester factuel dans cet article.
Ce qui est sur, c’est que cette méthode apparaît en réaction au cycle de développement en cascade. On pense alors que c’est la durée qui est le paramètre clé qui fait échouer les projets: on veut améliorer l’adéquation aux besoins en rencontrant plus vite les utilisateurs: Limitation dans le temps du projet RAD de 90 jusqu’à 120 jours maximum

Et dans la réalité ?

Derrière toute théorie, il y a une mise en application, plus ou moins fidèle au modèle… Les coachs agile en savent quelque-chose !
Comment le RAD a-t-il été appliqué ?
La vitesse de développement sera accélérée par des outils !
On a fixé la technologie sur tous les plans: la base de donnée, la technologie de communication client/serveur et les outils de développement. C’est cette calcification de tous ces paramètres qui permet la capitalisation sur des outils de productivité.
Les éditeurs de l’époque ont bien compris d’ailleurs la position de force que cela pouvait leur procurer.
La focalisation est forte sur la donnée dans la base relationnelle. Ce sont les heures de gloire de Merise en France. Le développeur conçoit ensuite des écrans en glisser/déposer à partir des champs de la base. La dynamique client est codée par des scripts sur les composants d’interface graphique.
A long terme de la sur-complexité et de la duplication apparaît bien souvent dans les traitements côté client. Les procédures stockées peuvent subir aussi de nombreux ajouts qui peuvent en altérer la clarté.
Les personnes qui ont pratiqué le RAD se sont semble-t-il fortement préoccupés des outils qu’on a appelé CASE pour Computed Aided Software Engineering tels que PowerBuilder, OracleForms et autres L4G.

RAD et agilité

Voici des exemples de différences entre le RAD et l’agilité:

• [Edit]les cycles itératifs en RAD sont plus longs (90~120 jours) et ressemblent a du “mini tunnel” (contre 2 semaines idéalement en SCRUM par exemple) L’itération en RAD s’inscrit seulement dans la phase de “réalisation”. Elle est bornée par un “focus” qui provoque une intégration et permet une démonstration à l’utilisateur.[/Edit]
• il y a toujours des phases de planification, design et développement séparés (contre un design émergeant en eXtreme Programming par exemple)
• les découpages temporels impartis aux phases du RAD sont assez stricts (moins de souplesse)
• les rôles sont apparus tardivement dans RAD (comme cela existe en SCRUM ou en XP)
• pas de préconisations pour les estimations collaboratives de la charge, les notions de reste à faire et de suivi (présent en XP et en SCRUM)
• il n’y a pas vraiment de notions de rétrospective et d’amélioration continue

Et voici quelques points communs:

• logiciel fonctionnel prépondérant à une documentation exhaustive, pragmatisme
• “Time-boxing” (limitation du temps)
• mise en avant de l’équipe intégrée (SWAT)

Aujourd’hui

Les raisons du succès du RAD ne sont pas éteintes. On peut aussi ajouter que le RAD n’est pas mort, on trouve des éditeurs comme PCSoft en France par exemple qui revendiquent une base de clients pour qui le RAD fonctionne très bien. Un éditeur comme Microsoft par exemple permet encore aujourd’hui de mettre en pratique le développement RAD avec la programmation .Net basée uniquement sur les DataSets. A l’heure de l’open-source, ne serait-on pas capable de composer, autour d’une pile logicielle standardisée (telle JavaEE ou .Net) une suite d’outils pour faire du RAD ? La place du test devrait en tous cas y être prépondérante. Ruby On Rails qui a popularisé la technique de l’échafaudage (ou scafolding) qui permet de générer les vues web au dessus d’un schéma relationnel s’inscrit dans cet héritage qui mélange outillage productif, génération de code et framework de tests avancés.
En tous cas, si le RAD a montré une chose, c’est que tout framework, outil ou méthode aussi performant qu’il soit, ne saurait être efficace qu’avec une organisation pertinente où les individus sont respectés et la communication est assurée.

Conclusion

Le succès du RAD dans les années 90 a permis de se rendre compte qu’il existait une façon plus souple de produire du logiciel que le cycle en cascade (l’évolution des langages de programmation n’y est pas étrangère non plus). La focalisation client et les prémices du développement itératif ont permis aux outils RAD de se déployer massivement.
Aujourd’hui, on a pris de la maturité. Par exemple, on attend d’un développeur agile plus de responsabilité en développant du code “durable” (testé). Il a aussi une exigence de compréhension de la dynamique d’équipe dans laquelle chacun doit trouver sa place. S’il le faut, l’équipier ira lui-même chercher les outils pour améliorer la productivité de l’équipe.
L’apport de la méthode RAD à permis d’expérimenter à grande échelle les architectures 2 tiers et d’en identifier les limites. On a aussi pu voir à grande échelle l’exploitation d’un buzzword par l’industrie IT et les dérives au moment de déployer la méthode à travers simplement des outils.
Vous m’avez compris, l’intention initiale était louable et mérite notre intérêt encore aujourd’hui, ne serait-ce qu’en termes de leçons à retenir.

Merci à tous les consultants Valtech qui ont participé à l’élaboration de cet article.

L’été est une période agréable où l’on peut partir en vacances et prendre du repos. Pour ceux qui sont déjà ou pas encore partis, c’est aussi une période révélatrice de l’”indispensabilité” de certains collègues.

Si on trace le schéma du cycle de développement classique, on trouve ces activités de base :

(more…)

Dr Alistair Cockburn animera une session certifiante ScrumMaster du 22 au 24 février à Paris. Pour les dernières places, le prix a été porté de 2 400 à 1 800 €. La CSM suivante se tiendra en octobre 2010 avec Craig Larman.

Issy-les-Moulineaux, dans les nouveaux locaux de Microsoft.

Une réunion du French SCRUM User Group

Le French SCRUM User Group organisait hier soir une conférence avec Ken Schwaber.

C’est donc Luc Legardeur, fondateur du SUG français, qui a débuté la séance en remerciant Microsoft et le co-créateur de Scrum, Ken Schawber d’être passé. Il a annoncé que Ken va présenter son nouveau site Scrum.org et répondra aux questions de l’assistance, le tout suivi d’un cocktail. Le programme du prochain trimestre du Scrum User Group a été annoncé:

• Rencontre avec Scott Ambler mi-mars. Il est lead architect chez IBM. IBM est devenu il y a peu sponsor du SUG.
• Soirée anniversaire le 30 mars chez Microsoft à nouveau.

La vision Microsoft sur l’agilité

C’est ensuite Xavier Warzee de Microsoft France qui a pris la parole pour tout d’abord nous rassurer : Microsoft ne fait pas une OPA sur le SUG, c’est simplement l’opportunité du passage de Ken à l’occasion d’une formation en France. Xavier a poursuivi sur un ton franc : pourquoi aujourd’hui Microsoft s’intéresse à l’agilité ? La société essaye de structurer et faciliter les efforts dans le monde de l’agilité. Ils commencent a avoir une offre qui se formalise un peu plus au travers de leur outil Visual Studio Team Foundation Server qui supportera directement SCRUM. Mais il s’agit pour Microsoft d’être pertinent et d’apporter de vraies solutions et, d’après Xavier, pas simplement de “préserver leur chiffre d’affaires”. Il annonce travailler de façon très proche avec Agile France et Laurent Bossavit qui était présent ce soir. Cela explique que Microsoft soit sponsor de plusieurs conférences agiles. Xavier revendique aussi des partenaires et un labo qui essayent de fournir des solutions, des sessions, des ateliers qui permettent d’adopter les technologies soutenant l’agilité. Microsoft, Scrum.org et différentes sociétés de formation se sont donc associées. Selon Xavier, le piège de SCRUM est de penser que les pratiques se suffisent à elles-mêmes quelque soit le cas de figure, le projet. Or, il convient de ne pas ignorer tout l’acquis en ingénierie logiciel, en pratiques de test et d’intégration continue. L’idée est de rechercher avec les outils Microsoft les meilleures pratiques et technologies soutenant SCRUM. Par exemple, vu la taille des itérations dans un projet SCRUM, le temps ne peut pas être perdu en construction du logiciel ou en tests.

Présentation de scrum.org par Ken Schwaber

Xavier a ensuite passé la parole à l’invité du soir : Ken Schawber.
Après un “bonjour, comment allez-vous ?”, nous avons épuisé tous les mots de vocabulaire francophone de Ken. Il introduit son discours : s’il y a quelque chose que vous n’aimez pas dans SCRUM, c’est à lui que vous devez vous adresser car il en est à l’origine ! Il sort d’une formation de deux jours pour Microsoft dans laquelle il a formé des personnes en profondeur à SCRUM. En outre, il s’est excusé de sa tenue vestimentaire. En s’habillant avec un maillot des “All Backs” ce soir, il ignorait que la France avait une équipe nationale qui pouvait rivaliser avec les blacks ! De toute façon, les néo-zélandais lui ont déjà dit que, visiblement, il ne connaissait rien au rugby !

Ensuite, il a présenté Scrum.org. Moins ambitieux que la ScrumAlliance, c’est une organisation dont le but n’est pas de transformer entièrement la façon dont les entreprises travaillent mais “seulement” d’améliorer notre monde du développement logiciel professionnel.

A l’origine, ce qui a plu à Ken dans le développement logiciel partait d’une proposition simple : “voilà une machine vierge, faites comme vous voulez, mais faites que ça marche !”. Mais depuis, selon lui, nous nous sommes perdus en chemin : nous avons introduit le cycle de développement en cascade et nous nous sommes laissés séduire par le style de management “Command & Control”. SCRUM est donc là selon lui pour redonner l’envie aux développeurs de se lever chaque matin pour aller satisfaire des utilisateurs auxquels ils ont manqué tellement ils adorent les merveilleux logiciels qu’ils produisent ! SCRUM devrait contribuer à rendre la profession relativement plus envieuse.

Un guide, des certifications en-ligne et des formations

Scrum.org s’inscrit dans cette volonté. Ce site propose le guide définitif de ce qu’est SCRUM. Ce guide de 16 pages montre que SCRUM est un framework simple. Il garantit l’intégrité de la définition de SCRUM par ses pères après qu’on ait tant cherché à la mélanger à d’autres méthodes (Kanban, Lean, SixSigma, etc. – ce que Ken ne déplore pas).

Scrum.org s’associe donc à des organismes partenaires afin de mettre en œuvre des formations SCRUM et des certifications. Ken nous assure qu’on peut échouer le passage de cette certification, ce n’est pas qu’une simple formalité ! Il existe aussi un questionnaire en ligne (gratuit jusqu’à mi-2010) pour s’auto-évaluer mais qui permet aussi au staff de Scrum.org d’obtenir du feedback sur SCRUM lui-même. Il donne alors quelques exemples de questions qui lui donnent l’occasion de créer un vote dans l’assemblée et de vous transmettre la première citation mémorable de la soirée :

“Being in the majority does not always mean you are right, as the waterfall as proven.”
“Être dans la majorité n’implique pas forcément avoir raison, le cycle de développement en cascade peut en attester.”

Concernant l’adoption de SCRUM, il pense que de nombreuses sociétés tendent à trop préparer les contextes des projets SCRUM. Ken leur conseillerai plutôt de se lancer plus vite. Les rétrospectives sont là pour commencer à s’améliorer dès le début ! Ken explique que le succès de SCRUM vient surtout de l’envie de sortir de la médiocrité du cycle en cascade. Mais, contrairement à ce qu’on pourrait penser et conformément à sa longue expérience, la force du changement qui pourrait être générée par les échecs répétés du cycle en cascade n’est presque jamais une suffisante pour arriver à mieux faire en adoptant SCRUM, ceci étant vérifié dans l’attitude des managers comme des ingénieurs. Il a souvent constaté que cette habitude de médiocrité dans les organisations à tendance à augmenter l’effet “ScrumBut” (le mot est malicieux) : “Nous faisons du SCRUM, MAIS pas … <n’importe quelle pratique qui les dérange, rend leur médiocrité visible, atteste de leur non efficience, etc.>…”. Après ce passage plutôt sombre dans son discours, une proposition constructive nous attend.

Pour améliorer cette situation, il est donc en train de monter des formations complètes pour des équipes entières dans lesquelles on choisit une pile technologique (open source java, Microsoft VisualStudio par exemple) et on est formé à SCRUM, aux techniques d’ingénierie agiles et aux outils ! Ce sont des formations qui sont donc plus complètes mais aussi plus exigeantes.

Les questions de l’assistance

C’est sur cette annonce que sa présentation s’arrête pour faire place aux questions de l’assistance.

1. Traduction des cours SCRUM ?
   “Work-in-progress” !
2. SCRUM dans de grand projets ?
   SCRUM est très adapté aux petites équipes. Il y a des livres qui traitent de ce sujet, en particulier le sien: “The Enterprise and Scrum”, Microsoft Press – 2007. Et hop, nouvelle citation à retenir :

   “And, just in case you are tempted, waterfall is NOT an alternative [to scale agile for large teams].”
   “Et, juste au cas où vous seriez tenté, le cycle en cascade n’est PAS une alternative [au déploiement de l'agilité à des équipes plus grandes].”

3. Critique : Les certifications sont individuelles alors que SCRUM fait l’apologie du travail en équipe.
   Dans le cours qu’il est en train de monter, la note finale se décompose en un score donné par les coéquipiers de formation et un score individuel.
   C’est bien évidemment une formation plus dure à monter que la certification SCRUM classique car elle nécessite des formateurs compétents sur la méthode et la technique.
4. Votre expérience relevant le plus grand défi en SCRUM ?
   DoubleClick. Le logiciel n’était pas bon du tout, peu de connaissance partagée. Une implication trop forte des managers dans l’allocation des tâches. Le défi était donc d’intégrer des nouveautés en parallèle sur le logiciel. La meilleure nouvelle pour eux fut de se faire racheter par Google et ne plus jamais entendre parler de développement logiciel, ils avaient sortit “notre” Champagne pour fêter ça…
5. Remarque : SCRUM apporte essentiellement un isolement pour l’équipe de développement pour commencer à faire les choses bien.



6. Remarque : Le rythme de livraison dans SCRUM peut être comparé à la régulation de la température dans une pièce. Il ne sert à rien de ré-évaluer la température trop souvent pour ajuster les radiateurs. Mais il n’est pas non plus efficace de ne le faire qu’une fois dans la journée car la température a peu de chances d’être constante au cours de la journée.
7. SCRUM ne s’applique-t-il que pour les technologies objet moderne ?
   SCRUM peut même nous aider dans notre vie quotidienne : pour nourrir un enfant par exemple. Votre enfant est votre client. Vous tentez de lui faire avaler son repas, il refuse toujours d’avaler une seule cuillère sous la contrainte. Le lendemain, retentez l’expérience en lui demandant combien de cuillères il veut manger ce soir ? Troublé par la question, il répondra “une”, vous lui donnez alors une cuillère et il vous répondra de lui-même, “j’en voudrais deux maintenant” parce que c’est lui qui l’aura choisi.
8. Vivre dans une organisation avec un cycle en cascade ?
   Ken raconte comment on peut commencer à faire du SCRUM sans jamais prononcer le mot. La méthode ne propose rien d’autre que de se mettre tous ensemble, construire quelque-chose, tout en y trouvant du plaisir.
9. Gérer une équipe infrastructure avec SCRUM ?
   Rendre visibles les problèmes de ce type (délais trop long pour commander un serveur, ouvrir un port, avoir accès à des métriques) constitue déjà une partie de la solution.
10. SCRUM + CMMI, vous adhérez ?
    SCRUM vous mène directement à un niveau CMMI niveau 3, il adhère !
11. A propos de l’applicabilité de SCRUM à d’autres domaines que le développement logiciel ?
    Ken voit bien SCRUM s’inscrire dans un mouvement sociétal plus global. Il défend une vision d’une société post industrielle mature dans laquelle le management doit s’adapter en passant du paradigme “Command & Control” vers une façon différente diriger des équipes : le “servant leadership” c’est-à-dire une position beaucoup plus humble du manager qui se met au service de ses collègues en tant que facilitateur. Parce que c’est simplement le moyen le plus sain et le moins stressant pour tous de mener des équipes à accomplir les objectifs dans des projets de plus en plus complexes. Mais cela représente évidemment une révolution culturelle à accomplir. En outre, cela court circuite le pouvoir, l’autorité ou le prestige et réclame de la transparence pour que les collègues se fassent confiance.
12. Quel est le secret de Ken pour restaurer la passion ?
    Vendre un produit peut aider. Le succès est toujours très vendeur. Par exemple, on peut rétrospectivement analyser pourquoi Toyota rencontre un succès plus important relativement à la faillite des sociétés américaines de production automobile.

Conclusion

La session a été conclue par un cocktail très sympathique au cours duquel les conversations ont pu se prolonger.

D’après moi, Ken a réussi à délivrer ce que je qualifierais de “message d’amour”. On sent réellement qu’il aime son métier et qu’il n’a pas inventé SCRUM par hasard. Sa volonté de nous faire aimer (ou aimer à nouveau) notre métier est palpable. Sentir son envie d’apporter une contribution positive à notre industrie du développement logiciel m’a fait plaisir ce soir-là.

Et vous, qu’allez-vous faire pour SCRUM demain ?

Thales a publié au cours de l’été une vidéo intitulée “Lean, une mise en application”.

On y trouve des informations importantes sur le Lean :

• nécessité de l’ouverture d’esprit, d’esprit d’équipe
• beaucoup d’ingénieurs logiciels tous équipiers, pas de multiplication des rôles (de développeur, d’architecte, de chef de projet, etc…)
• on sent que l’amélioration continue n’est pas un vain mot, ces ingénieurs maîtrisent leur processus, ils sont capables de détecter les redondances dans leur production, leurs goulots d’étranglement (ou ‘bottleneck’ en anglais) qu’ils ont su résoudre: leur phase d’intégration, leur taux de re-work, leur qualité de code au sens large.

Nous vous encourageons à consulter ce document bien réalisé. C’est un retour engageant sur l’utilisation du Lean appliqué au développement logiciel. On y voit l’équipe à laquelle appartient Emmanuel Chenu, à ne pas manquer !