Discussion :

[Amine Horseman]

Jusqu'à quand les entreprises gêneront-elles le développement agile ?
L'organisation au sein de celles-ci serait beaucoup trop rigide

Dans son article intitulé « Apporter l’Agilité à toute l'organisation », Jeff Gothelf, le dirigeant de l’équipe de designers de TheLadders et Web Trends, critique le fonctionnement des entreprises d’aujourd’hui, qui utilisent les méthodes de développement agile, mais continuent de gérer leurs équipes avec rigidité.

Selon lui, avec les méthodes agiles, nous sommes en mesure de déployer des produits rapidement, optimiser le travail des équipes, accélérer les prises de décisions et mesurer les écarts au jour le jour pour éviter de perdre du temps dans le développement de fonctionnalités inutiles. Cependant, l’organisation interne du personnel, des fonds, des récompenses et des rémunérations doit aussi se mettre dans le même niveau d’agilité, pour ne pas perturber le potentiel d’exécution de l’équipe de développement.

Les processus de recrutement de personnel dans les entreprises d’aujourd’hui par exemple suivent tous un schéma identique, et le fait de dresser des profils de personnes pour ne recruter que les éléments qui correspondent à tel ou tel profil pourrait poser problème. En effet, les sociétés doivent toujours rechercher les créatifs non-conformistes. Ce genre de candidats qui ne correspondent à aucun profil. Ce sont ces généralistes bricoleurs multifacettes qui poussent toujours les chefs d’équipes à repenser leurs produits ou services. Et le problème, c’est que c’est difficile de les distinguer de la masse dans un entretien ou dans un test de connaissances.

Mais les détecter et les embaucher n’est pas la seule difficulté. Il faudra aussi savoir comment les garder dans l’équipe et les inciter à travailler, car selon Jeff Gothelf, « la compensation financière n’est pas le principal facteur de motivation pour ces personnes ». En effet, elles cherchent souvent à créer quelque chose de significatif dans leur travail, d’où la nécessité de repenser les stratégies de récompenses et de rémunération du personnel.

Aussi, il faudra changer les processus de prise de décisions dans le niveau entrepreneurial. Ces décideurs qui essaient toujours de couvrir les risques pour rassurer les investisseurs sont souvent très lents à réagir face au feedback des clients. « Faire des erreurs ne doit pas être un crime capital. Au lieu de cela, les erreurs devraient être rapidement analysées et de nouvelles informations devraient être intégrées dans la prochaine série de tactiques ».

En parlant de tactiques, « les équipes ne devraient pas être la préoccupation des gestionnaires ». Ces derniers devraient plutôt se concentrer sur les progrès réalisés et ne plus opter pour des stratégies qui favorisent la prévisibilité et la sécurité au détriment de l’agilité.

Comme conclusion, l’auteur de l’article préconise qu’on doive changer la façon dont nous gérons les entreprises, et ceci pour favoriser : la réactivité dans les prises de décisions, l’agilité dans les modes de financement et la création d’un environnement d'apprentissage continu alimenté par la connaissance du client et son feedback.

Source : Harvard Business Review

Et vous ?

Qu’en pensez-vous ?

[Bousk]

Qu’en pensez-vous*?

Qu'Agile c'est juste le mot-clé du moment pour faire hype/in et se mettre en avant pour se vendre.
Demander aux entreprises de gérer l'humain ? Trop compliqué, elles préfèrent gérer des chiffres et ressources.

[el_slapper]

Je serais moins langue de vipère que Bousk, mais force est de reconnaitre que la majorité des démarches agiles en entreprise n'ont d'agile que le nom.

De plus, si celà est tout à fait adapté comme discours aux éditeurs de logiciels, ça me parait branlant chez un banquier, par exemple. Le banquier préfèrera 10 médiocres qui avancent peu mais sans faire de vagues plutôt qu'un super qui fera 3 fois plus à lui tout seul, mais prendra des initiatives incontrôlées. L'image du créatif, chez un banquier, c'est Jérôme Kerviel. Ce qui n'est pas une image très positive...

a compensation financière est pas le principal facteur de motivation pour ces gens

Là, par contre, je suis d'accord à 100% . Je connais un ingénieur système de très haut niveau qui a changé de boite pour un boulot moins intéressant et pas à la hauteur de son talent, qui a perdu 800 euros mensuels dans l'affaire, tout ça pour qu'on lui foute la paix et qu'on le laisse bosser tranquille.

Mais là encore, ça ne s'applique pas à tous les profils de boite. Là ou un haut niveau de contrôle est nécessaire, peut-être vaut-il mieux le laisser partir pour avoir quelqu'un de plus malléable. Hélas pour nous ça n'est pas notre cas.

[Sodium]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

[dfiad77pro]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Y'a une nuance à avoir tout de même quand on voit que certaines entreprises mettent 6 mois à mettre en production un correctif de bug sur un appli non critique, c'est inadmissible. ( je parle d'un correctif très simple, pour un bug gênant pour l'utilisateur)

Bon la suite de mon post est un peu stéréotypée

Certains processus justifiés il y'a 15 ans ne le sont plus forcément maintenant.

Le développement a évolué, les tests aussi.
Y'a des chercheurs qui ont bossés sur des technos d'intégration, des technos productives....

Trop d'intermédiaire tue la productivité et l'implication du développeur :


Ingénieur de DEV ---> Manager --- > Chef de projet SI --> MOA --> Chef de projet Métier --> Métier

Cette chaîne de communication ( cyclique) est bien réelle et même simplifiée ( et non issue d'une SS2I, donc en interne) ...
Ce qui fait que presque aucune information n'arrive rapidement au DEV ( et encore par fois elle se perd) à par un dossier de SPEC qu'il faut renvoyer 200 fois (
Et ils te prétendent faire de l'agile...

Ce genre de chaîne à rallonge donne aucun pouvoir à l’ingénierie de développement !

Ce n'est pas faire preuve de prudence que de ne pas changer les process caduques !

Et là je sens les arguments du genre : "T'est trop jeune , t'a pas d’expérience et de recul".

Je rappel qu'à 27 ans on commence a se sentir vieux lorsqu'on voi certains commerciaux de SS2I qui font du recrutement à moins de 24 ans !

Certes, mais alors :
- pourquoi les seniors sont t'ils fortement touchés par le chaumage, c'est eux qu'on devraient embauché ?
- pourquoi grand nombre de développeurs perdent leur passion et ne touchent plus une ligne de code ?

[Saverok]

A la fois, je partage l'analyse de l'article et même temps, je le trouve très / trop sévère
Il n'est pas évident de tout changer d'un coup

La conduite du changement, ça vous dit quelque chose ?

Tout ne peut pas être changé d'un coup, il faut y aller petit à petit
L'agilité, plus qu'une méthode, c'est un état d'esprit et ça prend beaucoup plus de temps à changer qu'une "simple procédure"

Quand je propose de l'agilité à mes clients, la première question qu'on me pose est "est-ce que ça ne va pas faire exploser le budget ?" et celle qui vient juste après est "est-ce qu'on tiendra les délais ?"
D'expérience, avec l'agilité, on se retrouve souvent avec un projet moins complexe (moins de fonctionnalités, des actions plus simples et plus directes) avec une meilleure qualité et une meilleure adhérence de la part des utilisateurs pour un budget presque identique.
Faire comprendre aux clients qu'ils auront moins mais mieux n'est pas évident
C'est une démarche qui prend du temps

Au niveau de la gestion RH, c'est la même chose, l'adaptation prend du temps
En agile, la hiérarchie est gommée et les développeurs sont fortement impliqués dans la conception et l'évolution du projet
Il est évident qu'ils ne peuvent plus être managés comme avant (et ce n'est pas un mal, bien au contraire)

Au niveau de la nécessité d'avoir des créatifs, je ne suis pas d'accord
Je pense surtout qu'il faut des gens avec un grand sens critique et cela requière de l'expérience, du vécu
L'agilité réclame une équipe majoritairement senior car la conception et le dev sont intimement liées et cela nécessite de l'expérience pour le mettre en oeuvre et le frontal client quotidien implique de bien comprendre les demandes, les besoins et les envies du client non seulement pour leur donner corps mais aussi pour les devancer et être force de proposition pour les enrichir et il n'y a que le vécu qui permette cela.

Un "créatif" risque de brouiller le client plus qu'autre chose
Sans oublier que lorsqu'il y a plusieurs "créatifs", ils ont tendance à se tirer la bourre plutôt que d'avancer dans le même sens
D'expérience, les "créatifs" n'ont à intervenir que lors de l'expression du besoin ensuite, le seul qui reste est le "product owner" autour de qui la construction du projet va se faire

[Traroth2]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Désolé, mais c'est juste n'importe quoi, ça.

[Invité]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Les deux derniers points correspondent tellement à mon ancien ... patron

[Washmid]

[B]
[...]
Les processus de recrutement de personnels dans les entreprises d’aujourd’hui par exemple suivent tous un schéma identique, et le fait de dresser des profils de personnes pour ne recruter que les éléments qui correspondent à tel ou tel profil pourrait poser problème. En effet, les sociétés doivent toujours rechercher les créatifs non-conformistes. Ce genre de candidats qui ne correspondent à aucun profil. Ce sont ces généralistes bricoleurs multifacettes qui poussent toujours les chefs d’équipes à repenser leurs produits ou services. Et le problème, c’est que c’est difficile de les distinguer de la masse dans un entretien ou dans un test de connaissances.

Mais les détecter et les embaucher n’est pas la seule difficulté. Il faudra aussi savoir comment les garder dans l’équipe et les inciter à travailler, car selon Jeff Gothelf, « la compensation financière n’est pas le principal facteur de motivation pour ces personnes ». En effet, elles cherchent souvent à créer quelque chose de significatif dans leur travail, d’où la nécessité de repenser les stratégies de récompenses et de rémunération du personnel.
[...]

Un :
- "créatif non conformiste", ou "généraliste bricoleur multifacettes"
- qui ne recherche pas l'argent mais la "création"
- qui a tendance à change de boulot comme de chemise
- qui a tendance à être mal vus par la hiérarchie parce qu'ils passe beaucoup (trop) de temps à suggérer (ou "proposer", "critiquer", "râler" suivant le point de vue)

En psychologie, ça fait furieusement penser à un zèbre, c'est à dire plus ou moins 2% de la population. Bref, bonne chance aux recruteurs

[brulain]

Effectivement, il n'est pas simple ni facile de rendre un parpaing agile.

[Serge Mazille]

Sodium :

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Mouais... C'est très généralisé tout ça... J'imagine que tu as eu de mauvaises expériences, mais associer 'Manque de compétences techniques' et créativité c'est

Washmid :

En psychologie, ça fait furieusement penser à un zèbre, c'est à dire plus ou moins 2% de la population. Bref, bonne chance aux recruteurs

C'est exactement la réflection que je me faisais

[Sodium]

Mouais... C'est très généralisé tout ça... J'imagine que tu as eu de mauvaises expériences, mais associer 'Manque de compétences techniques' et créativité c'est

Les faibles compétences entraînent un manque de recul sur ce que l'on ignore d'un domaine. Cela conduit à une surestimation de ses compétences / compétences des collègues et une méconnaissance des obstacles techniques.

[Saverok]

Les faibles compétences entraînent un manque de recul sur ce que l'on ignore d'un domaine. Cela conduit à une surestimation de ses compétences / compétences des collègues et une méconnaissance des obstacles techniques.

Oui, mais où est le rapport avec la créativité ?

On peut être créatif et compétent
L'un n'empêche pas l'autre

Mon côté manager de projet fait que je recommande du grand classicisme dans le développement.
Un code trop "original" est souvent complexe à lire et difficilement maintenable.
Pour le code, mieux vaut faire simple et clair car le code continue de "vivre" une fois le projet terminé (TMA).

[LSMetag]

D'un autre côté, les recruteurs, pour la plupart, ne cherchent que des profils conformes, maléables. Je fais partie de ces profils anti-conformistes, plutôt créactifs et réactifs, donc les objectifs sont de satisfaire et se satisfaire.

Même quand on parle d'agillité, dans presque tous les cas, on se retrouve avec un système rigide avec plein d'intermédiaires et en effet des mois s'écoulent entre la proposition de correctif que tu as fait, sa mise à l'ordre du jour, et surtout sa livraison au client.

Il n'y a que dans une seule entreprise où j'ai fait du vrai agile. Seulement, c'était une SSII qui faisait à la fois de l'interne et de l'assistance technique. J'ai fait 3 mois d'interne, c'était bien, mais dès que je suis arrivé en clientèle, de nouveau la rigidité.

Je ne peux faire de l'agile que quand c'est moi qui gère des projets annexes, où je dialogue directement avec la source du besoin et les utilisateurs. On me fait une demande approuvée par celui qui énonce le besoin, je la note et je la fais si ça n'empêche pas d'être dans les délais. Sinon j'explique.

Et pour les bugs, normalement, on ne doit jamais te dire QUAND et SI corriger un bug. Tu le signales au chef, on le note dans le bugtracker, quelqu'un le prend en charge dès qu'il peut et puis c'est tout ! Pareil pour une erreur dans les spécifications ou une demande incongrue. Tu discutes directement avec l'auteur du besoin et ton supérieur pour comprendre le pourquoi du comment et ajuster si nécessaire.

Evidemment tu rends compte de tout à ta hiérarchie.

Après j'imagine qu'il faut avoir les pieds sur Terre pour pouvoir bosser en agile car ça implique de faire rapidement dans sa tête un autochiffrage réaliste et de gérer son temps de façon autonome.
Mais pour moi, ce qui compte avant tout, c'est la satisfaction du client. Donc la qualité à la livraison. Si je dois bosser 40h au lieu de 35 pour livrer ce qui est demandé, sans bug, et dans les temps, moi ça ne me gêne pas.

J'ai lu plus haut qu'on pouvait assimiler un mec créatif et agile à quelqu'un qui faisait du code compliqué. Mais le rôle du développeur c'est aussi d'anticiper les besoins futurs et de facilité leur mise en oeuvre. Donc un code conci et efficace, bien commenté et malléable.

C'est la proximité et le dialogue avec les utilisateurs que j'apprécie. Alors quand on se tape des MOE et MOA pour un simple bug et ne parlons jamais à l'utilisateur, c'est très énervant. Surtout qu'après on nous engueule si on a corrigé le bug sans autorisation, même s'il n'y a aucun effet de bord.

Je me qualifie d'électron encadré. C'est à dire que je suis autonome et assure une qualité optimale pour le besoin, en dialoguant avec mon supérieur direct et les sources des besoins.

Je ne trouve jamais ça et je suis alors frustré et démotivé. Résultat, je crée ma propre start-up où je pourrai m'épanouir comme je l'ai décrit ci-dessus.

[gangsoleil]

Mon côté manager de projet fait que je recommande du grand classicisme dans le développement.
Un code trop "original" est souvent complexe à lire et difficilement maintenable.
Pour le code, mieux vaut faire simple et clair car le code continue de "vivre" une fois le projet terminé (TMA).

Etre classique dans le développement ne veut pas dire qu'on n'a pas des idées pour améliorer les choses, ou que l'on ne propose pas du hangement, ce qui est le cas ici si je comprends bien.

Pour moi, le coté créatif, c'et celui qui regarde la machine à café qui est en cours de dev, et qui dit "Et si on ajoutait des modules optionnels simples à brancher qui pourraient faire tout et n'importe quoi ?". C'est comme ça que tu te retrouves avec des machines à café qui proposent des potages à la tomate, et ça se vend.

Et ce côté là n'empèche pas de faire les choses dans les règles de l'art en interne : je suis le premier à gueuler contre les imaginatifs du code, ceux qui savent mieux que le langage comment parcourir une chaîne de caratères (vécu). Et pourtant, je suis le premier à vouloir proposer de nouvelles idées, de modifier certaines choses, tout en restant réaliste : ce n'est pas parce que c'est mal écrit que ça ne fonctionne pas, et vice-versa.

[LSMetag]

Etre classique dans le développement ne veut pas dire qu'on n'a pas des idées pour améliorer les choses, ou que l'on ne propose pas du hangement, ce qui est le cas ici si je comprends bien.

Pour moi, le coté créatif, c'et celui qui regarde la machine à café qui est en cours de dev, et qui dit "Et si on ajoutait des modules optionnels simples à brancher qui pourraient faire tout et n'importe quoi ?". C'est comme ça que tu te retrouves avec des machines à café qui proposent des potages à la tomate, et ça se vend.

Et ce côté là n'empèche pas de faire les choses dans les règles de l'art en interne : je suis le premier à gueuler contre les imaginatifs du code, ceux qui savent mieux que le langage comment parcourir une chaîne de caratères (vécu). Et pourtant, je suis le premier à vouloir proposer de nouvelles idées, de modifier certaines choses, tout en restant réaliste : ce n'est pas parce que c'est mal écrit que ça ne fonctionne pas, et vice-versa.

Parfaitement. Je n'ai aucune honte à utiliser un goto qui me renvoie 10 lignes plus tôt et m'épargne 30 lignes de codes. Ca reste plus lisible, dès lors que c'est commenté. Après évidemment, le goto est à éviter, mais il faut peser le pour et le contre. Si tu as besoin de te déplacer de quelques ligne 1 fois, et que ça permet d'avoir un code simple, c'est pas grave, celui qui maintient sera même plutôt content.

[Traroth2]

Les faibles compétences entraînent un manque de recul sur ce que l'on ignore d'un domaine. Cela conduit à une surestimation de ses compétences / compétences des collègues et une méconnaissance des obstacles techniques.

Et donc ? Ca rend créatif, ça ? Ou quoi ?

[vohufr]

Sodium, s'il n'y avait pas de créatifs, on avancerai pas. Car ces gens que tu dénigres completement font avancer/changer les choses.
Sans eux, l'informatique serait très loin de ce qu'elle est car le fait de ne pas se donner certaines contraintes (ce que tu appelles "avoir du recul") permet d'ouvrir de nouvelles perspectives. Et ces gens ne sont pas forcément si nul que tu veux le faire croire.

Qui sont ces créatifs ? Dennis Ritchie, Bill Gates, steeve Jobs, etc... (tu n'oserais sans doute pas affirmer que les 2 premiers manquent de technique ?) Et c'est pourtant bien le 3ème qui a exploité son ami Wozniak très technique pour changer le monde de l'informatique). Et je dis ça en étant totalement anti-apple !

ll faut des gens très technique, et il faut des créatifs ! Les deux se complètent !

Ta façon de cloisonner les gens est totalement injustifiée et à la limite de l'intolérance. Et pour faire comme toi, de la psyko à 3 sous, on pourrai croire que certaines de ces personnes t'ont fait du tord. Peut être même t'ont volé des places que tu convoitais...

[pcdwarf]

Je n'ai peut-être pas une expérience fantastique en la matière mais toutes les personnes que je connais qui m'ont parlé d'Agile dans leur boite comme d'une révolution, on fini par admettre 6 mois ou 1 an plus tard qu'en fait il s'agissait de LaRache...

[dfiad77pro]

Je n'ai peut-être pas une expérience fantastique en la matière mais toutes les personnes que je connais qui m'ont parlé d'Agile dans leur boite comme d'une révolution, on fini par admettre 6 mois ou 1 an plus tard qu'en fait il s'agissait de LaRache...

La plupart des entreprises qui m'ont dis ça ne faisait pas du vrai AGILE, mais un mix d'agile avec leur process à eux...

Généralement la programmation en binôme ne se pratique pas dans ces cas là...