Préparation de rupture douce No3 sur Colibri: une expérience sur intelligence collective et l’auto organisation

Il paraîtrait que depuis quelques mois, en terre d’Hurepoix, au sud de Lutèce, à chaque pleine lune, des grenouilles se métamorphosent en Colibris. Selon la légende amérindienne, lors d’un immense incendie, seul le courageux colibri versait consciencieusement de l’eau avec son bec pour éteindre le feu.

Nos Colibris ne savent pas qui a mis le feu, mais au fond d’eux même, ils savent que chaque fois qu’il y a le feu dans leur entreprise, des pompiers venu de l’extérieur l’éteignent à renfort de plan de sauvegarde de l’emploi. A chaque, fois l’espace habitable s’appauvrit et l’entreprise,comme une foret non entretenu, prend feu encore plus vite.

Changer c’est casser ce cercle d’une manière ou d’une autre, même si cela est insignifiant comme dans ce colibri de la légende amérindienne. L’important c’est de contribuer: Les Colibris du Hurepoix seront sans doute un jour suffisamment nombreux pour éviter les départs de feux.

Nos Colibris sont des faiseurs et souffrent que les décisions qui affectent leur manière de travailler sont prises par d’autres.

En faisant entrer le jeu dans l’entreprise, en puisant sur des idées extérieures, en amenant leur passions et leur talent cachés, nos colibris s’auto-organisent. Déjà des réseaux se tissent et cela redonne du sens aux relations humaines. Le réseau Colibri est reconnu par les dirigeants qui ont compris l’importance de laisser les faiseurs décider de comment il font les choses.


1. « Osons Jouer », Alexandre Boutin, Rupture Douce Saison 02 ;

2. « Facilitation Ludinovante », Laurent Sarrazin Rupture Douce Saison 02 ;

3. « Mener sa vie comme un projet et vice versa », qui ?, Rupture Douce Saison 03 ;

4. Agile at Home or Our Agile way of life

Be Radical, avoid Big Bang

Let use English: the language of one the best reference I know about management that goes with Agile: Radical Management (see below)

Lots of big companies look for embracing Agile to maximize ROI (Return of Investment) or simply to beat their competitors.

Agile could be a true way to foster innovation. Even you are in strong B2B predictable context with almost no interaction with end users ( keep looking to create an opening for customer interaction and getting more fun) fail fast truly enable you to embrace the highest quality standard.

For sure, as a result that will increase companies benefits and put far more fun into the doers troupes. This sounds magical ?

That is not Magic at all.

The path could be quite difficult, if you come from traditional way of doing business which have its roots early in the 20th century with Frederick Winslow Taylor scientific management which focus on improving the system for mass production. Agile looks for delighting customers. This requests a deep cultural change: A change that is not just about few guys making software (or Hardware) development in a war room fully decorated with colored stickers . It will affect all individuals inside and outside the ‘Agile zone’: indeed, this will affect somehow the entire company. HR, Purchase, Lawyer, Quality Assurance, and all other supporting groups.

Saying that. One frequent question I have is:

Could we transform from waterfall ( or whatever ) to Agile by continuous improvement ( Kaizen)?

Even if tempting to say yes, I  believe the answer is no:

Let me introduce a pure fiction character (a persona) :John


John works in a large company, and has a long record of success as a manager and project manager. He knows very well what is good for business and how to motivate his team.

John is ‘black belt’ in continuous improvement, masters PDCAs and RCAs. Months after months he has introduced many Engineering practice such as CI, TDD, Peer programming, and then automated test reaching huge gain to the system (John Boss estimate that John has a record of about 50% of productivity gain by this continuous improvement). He has also introduced stop and fix allowing maximum of one critical CR at a time.  Then, he got a training on agile-scrum and ask the team to go in training then practice scrum: all ceremony are done, and sticker appear on the wall of a dedicated war room.

John knows about  situational leadership,  So he knows he could rely on few expert: they will be driving the team. On continuous improvement John could still help the team trying things  sprint after sprint. This is not first time John re-organize team to get more efficiency.

John is of course considered accountable by his management. He needs to be able to ask team members (the experts) to take few emergency tasks, or to join some crisis call (John management has always find John staff high skilled professional): John is a pragmatic person.

This was cool… But this was just not working: John notice that no action were taken in retrospective when he is out even if some stories were not done as « committed ». This  starts to put him under suspicious eyes of a laisser-faire  attitude (actually John style was middle of the road) by his management. And worse, some team member was not really following: One already left because he felt just useless compared to 20% expert who take 80% of the job. After all pareto always apply and all transformations face resistance. This is true for a collection on individuals… not for a team.

Yes, John has failed to really help the teams fully transform from a collection of individuals to into a high performing teams full of connexion between individuals. In fact this was still busy-ness as usual but without John daily expertise in project management, John being best at seeing risks and to provide the gold estimate. His Boss will probably ask him to forget that fancy democratic style and come back to past success soon: predictability is important for almost all businesses, even when uncertainty is high.

Agile really means transfer main operational decision from Management to truly self-organized teams: The doers. Of course you can work to delegate step by step or delegate to expert, but which manager felt comfortable by making the last step (as John thought he did); purely rely on teams and support decision even if you think this is not the right decision. Do not dream, John is seen as the guilty guy if this turn wrong: after all, this is exactly what delegation is about.

What really makes Agile work is « Fail fast and learn early »  towards not only all team members, but through the entire organization. And there is two loops; the daily and the sprint (John start by 4 weeks and hope that continuous improvement will reduce with time). Let me reuse Craig Larman and Bas Vodde image: this really mean  following the baton and not the runners on a relay race.

So Is that just an easy continuous improvement or is it a ticket to hell ?

This is a radical change.

The change really deals with a management change.  it deals with going from Top down to bottom up. Which mean that management will change hands… and not only management need to transform themselves, teams need too. Doers cannot effectively learn the minimum needed management skills especially if no trust or mutual respect is not in place: In early description of agile, John introduce fun with the Pig and chicken  story.  John loves practicing self-derision presenting himself as the chicken.  Issue was that John is still considered as a pig and by the way he is committed.

Does that mean going to agile is a big Bang: No either.

The right question is not How much but How many?

John Bill and Big Bang_NEW

By chance, Bill a VIP of John’s company, see how competition now deliver significantly faster with better quality. Those competitors has no secret. On the opposite they are absolutely transparent. They named themselves Agile Company . Bill met some Agile Gurus, and understood that this could be done within a few month for his few thousand organization. After all, Bill see Scrum is just a popular lightweight process and Bill know his company has adopted far more difficult and heavy boring things in just few months. This include John engineering practices coming from XP an other agile ‘methods’: let’s train everybody and start doing that … BIG …. BANG……  Big Bang

Big Bang mean asking  a huge group of people to go Agile within few days months or even years. Some companies succeed in but many fails for 2 reasons:

  1. This ruins the  small batch rule ( Mathematically proven to reduce cycle time and increase predictability under uncertainty): Sun Tzu explains in Art of War  that one should attack enemies when half of them have crossed the river by foot. So why getting that exposure for a long time?
  2. Even in small batch agile suppose teams go through Tuckman stage.  Expert, and Champion will probably start directly in Norming, but agile is not reserved to only few high potential. (Do not confuse that at the end Agile allow you to raise almost all people to expert, that is not the cause but the consequence) . So you will need a minimum transaction time with enough coaches. Your Bottleneck will be the number and the quality of the coaches.

All of a sudden, Bill remember Don Reinertsen book ( See article on Prinicple of product development flow ), « Is not it just another queuing case. Work in Process limit will just work ? »


Here come Lara: Lara

Back to John. John got coaching from Laurent who explained him that his role is no longer to interact in the value chain but to observe, support and help on demand.  As Captain Marquet ( see reference section) he only got the ultimate button which is not the deadly shot but the right and duty to re-engineer teams in a slow and smooth pace.

John took the decision to use that tool once: he hires Lara, as scrum master. In fact his former scrum master agreed: He was actually very happy to come back to his expert role (he has never really gone out of it anyway). Lara was trained by Jeff sutherland and she succeeded to get buy in from the team to trial a one week sprint ( instead of 4) and adopt lots of radical practices and metrics Jeff is teaching to whom is wise enough to understand the fundamental reason behind it. As this start to be a success. John now could help other teams and spend most of his time peering with other manager. He has discovered that coaching one’s own team is very difficult and start coaching other teams instead.

John and Lara work starts inspiring other and they ignite an organics change.If it works for them why not for us ?

Bill works closer with coaches on defining a set of very limited Kpis even if he always take more seriously what he see in his Go and See practice and give examples of fail fast and learn: Yes Bills gets wrong few time, reorganized and rearrange some roles, bringing HR talent in the game. He also change few coaches and personally often recall the sometime forgotten right side of the agile manifesto.

Success does not happen in days or month, but first transformed business already started beating their competitors. By the way this first business is supported by a quite new named leaders who’s name is …. John.


So excellence in managers is not an option. Of course coaches are needed to make collection of individual becoming a team faster. Having to coach both teams and management at the same time will make coaching companies very rich and will probably let you half way a long time. And remember art of war, being half way is a nice opportunity.. for your foes.

Luckily, If you have transformational management in place, I can bet you will beat your competitors. But if you truly understand radical management, this would a consequence of your real and consistent goal with suits with delighting the customer.

The good news is that transformational management could probably be learned by continuous improvement…. As time is the 21th century paradigm, is that the fastest way ?

References :

How Great Leaders Serve Others: David Marquet at TEDxScottAFB: Captain Marquet from United States’ Submarine Force, completely turned around the submarine, which went from being « worst to first. » thank you to Laurent Sarrazin from Rupture(21  to push that link.

Stephen Denning : ISBN-13: 978-0470548684 The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century

Donald G. Reinertsen ISBN-13: 978-1935401001 The Principles of Product Development Flow: Second Generation Lean Product Development

Charles A. O’Reilly, Jeffrey Pfeffer: ISBN-13: 978-0875848983 Hidden Value: How Great Companies Achieve Extraordinary Results with Ordinary People : 

Hidden Value

Craig Larman and Bas Vodde Lean primer

Dave Rooney blog   ( I have found that so nice I want to believe since Agile might also mean bad agile):

You like it ? join on Twitter : @colibir21th @ycharrei

Coacher une équipe Agile

Coacher une équipe agile. Guide pour les ScrumMasters, les chefs de projets, les managers… et leurs équipes

Véronique Messager ISBN-13: 978-2212134148

Coacher Une Équipe Agile - Guide À L'usage Des Scrummasters, Chefs De Projets, Managers - Et De Leurs Équipes ! de Véronique Messager

Pourquoi ce Livre:

Il existe de nombreux ouvrages sur agile et sur le coaching, écrit en langue anglaise et parlant d’expérience anglo-saxonne. Je pense par exemple à Agile Coaching de Rachel Davies et Liz Sedley.  Avoir un livre en Français et fort de quinze années d’expérience d’accompagnement d’équipes projet et d’organisations en phase de transition agile, permet de prendre un vrai recul sur ce qu’est le métier de coach agile en France.

Pour quoi

Si vous cherchez un livre sur telle ou telle pratique agile ou agile à large échelle, passer votre chemin. Il y a tant d’ouvrage sur ce sujet, qu’il est rafraichissant de prendre cela seulement sur le coté le plus fondamental d’agile: l’humain. Cela me rappelle en cela The 5 dysfunctions of a team de P.Lencioni dont Véronique reprend la fameuse pyramide.

L’environnement est connu, les mécanismes de changement sont rappelés notamment sa dimension émotionnelle trop souvent négligée par nous autres ingénieurs.

Après avoir expliqué la posture (position basse) du coach, et les différences qui existent entre un coach un enseignant ou un mentor, Véronique nous propose des cas concrets tellement réalistes qu’on reconnaitrait presque tel ou tel.

En effet ce livre contient énormément d’outils pratiques, et donc se lit soit couverture à couverture, soit se consulte à dessein. Sans doute les deux.

Évidemment après la lecture, on ressent l’envie d’expérimenter les outils de ce livres.  Par exemple la méthode des six chapeaux, Pyramide de Dilts, Code SACRE…

Une seule petite frustration, Véronique nous présente ici, entre autres, un outil tel que la Process Communication (issu de l’analyse transactionnelle) tout en nous mettant en garde contre son utilisation par des coachs non certifiés, ce que l’on comprend.  Néanmoins cela permet de savoir que cela existe.

Il parait clair que Véronique maitrise à merveille son métier de coach. D’ailleurs Véronique donne également des formations sur le coaching et offre à cette occasion un bref coaching personnalisé.

Une chose est sur, le métier de coach n’est pas un métier compliqué (prédictible) mais complexe (Imprédictible).




Et si l’on parlait d’équipe virtuelle

L’équipe co-localisée est dans le principe et les valeurs du manifeste Agile:  « Les individus et leurs interactions plus que les processus et les outils »  et « La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. »

Donc, quand cela n’est pas possible, doit on pour autant renoncer à Agile et revenir au passage de relais à base de documentation un contrôle centralisé, truffé de métrique pour limiter la casse, et attendre le Big Bang final ?

Fort heureusement non, ce papier nous donne quelques clés:

Voici un résumé:

Pourquoi a t on de plus en plus d’équipe virtuelle?

Johan Chambers CEO de Cisco estime que 1,3 milliard de travailleurs feront partie d’équipes virtuelles dans le monde. Le PDG de Cisco, ajoute : « les équipes virtuelles vont globalement transformer chaque gouvernement et entreprise dans le monde. Toute entreprise qui ne suit pas ne survivra pas ».

Ce développement mondial a été facilité par une convergence de facteurs:

– entreprises (fusions massives, rachats, partenariats)
– économiques (récession mondiale),
– technologiques (plates-formes de collaboration basées sur du cloud peu coûteux)
– l’environnemental (réchauffement climatique).

Les équipes virtuelles offrent des avantages très attrayants, y compris: les frais de déplacement réduits, réduction de l’empreinte carbone, proximité du client.

Cependant, il y a un fossé immense entre les attentes de la direction et les résultats réels. Dans une étude mondiale , 27% des équipes virtuelles ont été jugés non optimum.  Une autre étude portant sur 70 équipes virtuelles a révélé que seulement 18% de ces équipes virtuelles d’affaires sont vu comme un succès. L’Essentielle soit 80% des équipes virtuelles sont bien inférieures à la performance attendue: Le coût financier est énorme en terme de perte de productivité , de respect des délais , de démotivation , et du manque d’innovation induit.

Il y a plusieurs causes connexes: manque de formation en leadership d’équipe virtuel , dissonance interpersonnelle et culturelle , et contraintes technologiques:  Sans surprise, 19  dirigeants sur 20 disent qu’ils ont éprouvé des difficultés avec la gestion d’équipes virtuelles. En dehors des contraintes technologiques , par exemple la disponibilité partielle d’Internet,  ils citent les différences de fuseau horaire (par exemple 15 heures entre Tokyo et Winnipeg) . Cependant , le plus grand défi provient d’une mauvaise communication humaine et de nombreux malentendus tant interpersonnels que culturels . Comme établi par de nombreuses études, le travail d’équipe virtuelle est bien plus difficile à initier. Par exemple : • 81 % des employés disent qu’une mauvaise communication est la cause de l’échec inter-équipes • 68 % des employés ayant expérimenté le travail en équipes virtuelles ont connu des dysfonctionnement. • Moins de 33% des entreprises offrent un cadre de formation adéquate…

Les équipes virtuelles ont en fait, tous les défis des équipes traditionnelles, mais pratiquement aucun des avantages . En outre , l’expérience de l’équipe virtuelle est plutôt accélérée compte tenu de la courte durée de la plupart des projets . Par exemple , les stades (1965 Bruce Tuckman) de formation et de lancement d’équipe ont tendance à se produire maintenant simultanément en équipe virtuelle alors qu’il est admit qu’elles sont importantes pour une équipe co localisée.

Cette recherche montre en outre que de nombreuses organisations réutilisent les mêmes lignes directrices et meilleures pratiques que pour leurs équipes co-localisées et estime que cela suffit . Évidemment , rien ne fonctionne  aussi simplement . Les équipes virtuelles et les équipes co-localisé sont aussi différentes que des pommes et des oranges. Les dirigeants qui le reconnaissent sont ceux dont les équipes réussissent le mieux ….

Malgré le lien étroit entre la formation et la performance de l’équipe virtuelle, de nombreuses organisations ne font pas cet investissement . Un autre mauvaise pratique est de choisir les membres de l’équipe basée uniquement sur leurs compétences techniques sans tenir compte des attributs clés tels que leurs compétences interpersonnelles .

Pire, des recherches antérieures indiquent qu’une culture de collaboration affecte la façon dont les membres de l’équipe interagissent et travaillent ensemble, et que cela empêche la créativité de l’équipe. Cette étude explore un des fondement de la créativité de l’équipe, à savoir, l’intelligence émotionnelle … L’intelligence émotionnelle favorise la confiance de l’équipe. A son tour, la confiance favorise une culture de collaboration ce qui améliore la créativité de l’équipe.


Cela confirme donc les principes du manifeste Agile. Ce qui suit n’est donc qu’un contournement parfois nécessaire de ces principes tout en respectant les valeurs qui sont derrières ces principes, notamment la confiance et l’engagement collectifs.

Que faire si l’on ne peux pas avoir une équipé co-localisé?

Nemiro (2004) a identifié onze compétences pour le travail en équipe virtuelle efficace. La plupart sont liées à l’intelligence sociale et émotionnelle:

Travailler sur une prise de conscience de soi-même et la façon dont vous interagissez avec les autres;
• Développer et pratiquer les compétences qui améliorent la communication;
• Renforcer la capacité de communiquer efficacement à travers les cultures;
• Résoudre les conflits efficacement malgrès l’eloignement physique voire linguistique et culturelle.
• Renforcer des compétences en résolution de problèmes et prise de décision
Gérer le stress parce que les horaires de travail virtuels sont souvent 24/7;
• Améliorer la gestion du temps et des compétences de productivité personnelle; ( Work in Process par exemple)
• Développer les compétence d’encadrement les connaissances des mécanismes de la motivation (Cf Dan Pink) et l’autonomie;
• Utiliser les compétences de réseaux (politiques) pour développer les idées;
• Améliorer la gestion des connaissances, la collecte de données, et l’accès à l’information sur les compétences; et
Développer des moyens de promouvoir les carrières des personne évoluant en équipes virtuelles.

Outils: une des conclusions de ce rapport est que les équipes virtuelles n’utilisent pas ou peu d’outils type ice breaker. Voici quelques suggestions:

Annexe: the third wave Of Virtuak Work by Tammy Johns and Lynda Gratton, Harvard Business Review:


Libérer l’entreprise : se réinventer pour mieux innover

Libérer l'entreprise : se réinventer pour mieux innover

Ce format court donne un bon exemple d’entreprise libérée en France.

Il explique comment IMA technologie, société d’assistance à distance a choisi de se démarquer de ses concurrents. IMA technologie est dans un marché où la compétition du bas coût est très agressive. Pour garder l’emploi en France ( Région de Nantes ), il a fallu opérer un pivot vers des prestations haut de gamme qui justifient les coûts plus élevés.

Christophe Colignon, Directeur opérationnel d’IMA technologie à choisi pour cela une solution originale: libérer l’entreprise. Ce livre raconte par des témoignages en quoi cela a apporté en terme de résultats tout en donnant quelques aperçus des difficultés.

C.Colignon suit ainsi un courant de pensée dont l’un des piliers, Isaac Getz, prône une idée apparemment étrange de l’abandon du management. En fait, il me semble que ce qu’explique ce livre est non un abandon pur et simple mais d’une transformation du rôle du manager vers des rôles d’animateurs ou de coachs. Il explique également la réduction des rôles purement transverses à ce qui est strictement nécessaire. Le livre explique enfin en quoi cela ne peut se faire qu’avec l’appui sans faille et l’exemplarité du plus haut point de décision.

Attention, il ne s’agit pas de laisser-aller. Même (J’aurai tendance même à écrire: surtout) dans l’entreprise libérée, les performances sont mesurées, par contre, ce sont celles relatives au service donné au client (et dans un centre d’appel, on veux bien croire que ce n’es pas un vain mot). L’idée est donc bien d’impressionner ce client. Ce qui change par rapport à une approche courante, c’est que personne n’est jugé sur ces métriques. Ce qui compte c’est de s »améliorer.

L’entreprise libérée réinvente également en permanence ses services pour rester compétitive. La différence est que l’invention se base sur les idées des personnes qui font le travail. Si tout le monde est d’accord sur ces principes chères au Lean (cf Toyota way), le mettre réellement en œuvre n’est pas si courant.

Cela rappelle à l’évidence les idées de  Robert k GreenLeaf à l’origine de la philosophie de management du servant leadership ou l’incontournable ouvrage de Vineet Nayar : Les employés d’abord, les clients ensuite. Disons que, si cela n’était pas évident, cela s’applique aussi en France et en temps de crise il me semble qu’il s’agit d’un message rafraichissant et visionnaire.

Quelques références:

Il était une fois la révolution

La qualité logicielle ne se réinvente pas si souvent et une fois encore cette révolution nous vient de l’open source.

Qualité rime trop souvent avec douleur. Cette douleur n’est pas liée à la contrainte très compréhensible mais par les métriques sensés les mesurer qui sont abstraites et parfois totalement détachées du travail de celui qui contribue pourtant à cette métrique (voir qui a encore changé le système métrique dans ce blog)

Pourtant, je ne connais ni un ingénieur ni un manager ni aucun autre professionnel qui aime faire un travail de mauvaise qualité.

Alors pourquoi ces pans entiers de copier-coller dans le code de la part de ceux qui en plus ont parfois le mauvais goût d’échapper au revue de code que tout développeur fait ( à moins que ce ne soit une programmation en binôme).

J’adore agile et scrum, mais l’idée que les décisions de bout en bout soient prises rapidement par un groupe d’experts omniscients (qui connaissent 100% du code), ne me semble pas fonctionner sur un projet de plusieurs milliers de personnes. (Mais je suis preneur de témoignage qui me prouveront le contraire)

Donc, comment un directeur d’un projet de plusieurs milliers de personnes peut prendre une bonne décision, sentant sur sa nuque le souffle chaud des CFO et CEO de son organisation, ou dans le meilleurs des cas la pression du client certes compréhensif mais pressé. A t il connaissance de l’ensemble des forces et faiblesses en présence (SWOT) ? Même en admettant qu’il soit le champion de son projet, comment sa décision engagera les futures évolutions du produits ?

Au pire  après quelques projets de moins en moins réussis, l’organisation peut étre amenée à  abandonner des produits entiers car incapable de fournir les évolutions demandées dans des coûts et donc des délais comparables à la concurrence.

Et surtout quel est le rapport entre le travail d’un de ces milliers de développeurs et les métriques désastreuses que lui indiquent le service assurance qualité, ou ce rapport accablant des test systèmes, arrivé 6 mois après la bataille ( Au moins en phase de transition de Waterfall vs Agile). Cela revient à la question, comment donner le pouvoir de décider à une équipe scrum sans mettre en péril le besoin de bout en bout d’un énorme projet?

C’est ce que permet SQALE sous licence creative commons   (Software Quality Assessment based on Lifecycle Expectations). 

L’idée est aussi simple que de quantifier  (en €) la dette technique comme on le fait pour la création de valeur ou pour le cout des développements.

Rappelons ce qu’est la dette technique: le code est un capital, une partie de ce code rapporte des intérêts (Le product Owner de scrum est là pour augmenter cette fameuse valeur), mais l’intégralité de ce code a un coût d’entretien lié à sa maintenabilité qui représente la dette.

L’avantage de la dette technique est de parler au développeur qui en grande majorité n’aime pas intervenir sur un code qui ‘sent mauvais’, à condition une fois de plus d’en comprendre les règles ( qui sont au moins transparentes dans SonarQube )

SQALE peut être instrumenté par l’outil Open source SonarQube.

Pour expliciter rapidement comment cela marche, je me réfère au site de Sonarqube:

Et pour en montrer sa simplicité conceptuelle, le mieux reste de se balader à l’intérieur de l’usine logicielle Nemo,.

Nemo est une instance publique de Sonar couplée à  Maven, Hudson, Nexus et Subversion.

Un click sur nemo permet de voir les statistiques de haut niveau :


Depuis ces statistiques un simple click permet d’aller au détail.

Ainsi en descendant selon le découpage du projet on va pouvoir aller jusqu’à …. la ligne de code concernée.

Et ce n’est pas tout, SonarQube permet de représenter la dette technique grâce donc à la méthodologie SQALE .

Sans entrer dans le détail, SQALE se base sur des règles personnalisables. Exemple :

rules nemo

L’outil est modulaire et devra être adapté en fonction de la technologie (depuis SOC jusqu’au Interface Homme Machine en passant par les applications ), du langage ( les projets en JAVA, sont une fois de plus, les plus chanceux), et surtout de l’adhérence de l’entreprise au fait que la qualité est plus facile à obtenir en s’appuyant sur des cycles de plus en plus courts. (Point Commun à Lean engineering, agile développement Extreme programming, et Artisanat logiciel et surement d’autres cultures d’entreprise tout aussi efficaces).

Définir les régles de dette techniques peut êtte difficile, s’il n’existe pas de standard à grande échelle. Il est une fois de plus fondamental de ne pas chercher le consensus, mais de travailler les objections (à la méthode sociocratique).

Bien que fondamentale, la mise en place de l’outillage n’est pas la plus grosse difficulté, mais d’instaurer un éco-système favorable à gérer ce type changement (voir rupture douce) .

Une fois mise en place, une telle usine logicielle laisse les équipes se focaliser sur la valeur et la qualité du code tandis que le management se focalise sur la vision et le maintien d’un environnement motivant, celui qui encourage la différenciation par l’innovation.

Ce management d’excellence pourra également tenir le niveau d’obstacles en dessous du seuil admissible (une autre sorte de dette technique) ( voir Les employés d’abord, les clients ensuite… de Vineet Nayar)

référence :

Guide de Survie à l’Adoption ou Transformation Agile

Un livre simple et court à lire absolument pour toute transformation vers plus d’agilité

Plus d’information sur agile-lean-et-compagnie:


Le livre est disponible en version PDF gratuite à l’url suivante: