Si c’est écrit dans le livre, c’est que cela doit être vrai. La scène se passe dans une Banque. Vous faîtes partie d’une équipe de développeurs sur une application de gestion.
L’équipe se réunit chaque matin. Le Scrum Master pose 3 questions. Ensuite la journée commence. Les estimations du « reste à faire » sont mises à jour. Le Scrum Master met à jour les indicateurs. A midi il y a des frites. Une journée normale, dans une entreprise où Scrum est appliqué à la lettre.
Il est 09h05, vous êtes debout, entouré de votre équipe. Le chef de projet, enfin le Scrum Master, passe en revue les troupes. C’est le stand-up meeting, que personne ne sait traduire en Français dans l’équipe. C’est vrai que c’est sympa. Qui a la même chemise qu’hier ? Qui a une tronche de « je me suis couché à 3h en rentrant du ParisJUG…« . Vrai ou pas vrai ?
Vous êtes dans vos pensées. Dur la soirée hier soir au ParisJUG. Arrive votre tour de partager devant le groupe. Le Scrum Master passe la boîte à meuh et c’est à vous de parler.
« Qu’as-tu fait hier Nicolas ? Que comptes-tu faire aujourd’hui ? Et est-ce que tu as des problèmes ? ».
C’est à votre tour de parler donc.
Vous avez envie de dire que vous avez perdu 2 heures hier car le gestionnaire de version ne marchait pas. Vous avez envie de parler de ces clients qui changent tout le temps d’avis. Mais non, à peine quelques minutes pour faire le point. On se dépêche car après y’a café-baby. Scrum est utilisé ici comme un outil de management. La vision produit ? Le product owner n’est jamais là. Les équipes colocalisées ? Cela ne marche pas avec la politique de service et d’achats de votre entreprise. Les Achats, ces gourous qui gèrent la journée homme du développeur entre 2 commandes de papier toilette et d’un toner laser… Priez saint-TJM pour nous.
Dites-moi que vous avez vécu au moins une fois cette scène. Allez, double-combo, dîtes-moi aussi que même, le Scrum Master ça a été moi un jour…
Pourquoi en sommes-nous là aujourd’hui ?
Pourquoi ? Et bien car comme dans beaucoup d’entreprises, vous subissez de l’Agilité par le Management. Certes, avant c’était pire… enfin c’est ce que tout le monde raconte. En 2014, toute l’entreprise est passée à Scrum ou au Lean, ou à une méthode XBZ32 super sympa. Or le souci, c’est que l’Agilité n’est pas une méthode de management. Ce n’est pas une façon de mener le développeur au pâturage pour qu’il broute du code.
J’attends le « next », le prochain mouvement, la technique ultime qui permettra peut-être de délivrer des logiciels de qualité, en respectant les coûts et un agenda. Nous devrions certainement nous inspirer de ce que font d’autres industries, comme le jeu vidéo par exemple. Le monde de l’application de gestion a encore du travail à faire.
Cependant,ne pensez-vous pas que la gestion d’une équipe de développeurs est une activité différente de celle de la gestion d’un projet ?
Chaque équipe devrait avoir un responsable d’équipe (Team-Leader) et un responsable du projet (le Chef de Projet). Je l’ai vécu et expérimenté, et cela fonctionne plutôt bien. Le Chef de projet est plus un ministre des affaires étrangères. En charge du budget, de la diplomatie avec les autres équipes, il passe son temps à faire le lien avec les clients, tout en s’assurant que l’équipe suit un plan discuté et accepté. Le responsable technique, disons plutôt le Team Leader, est au côté des Développeurs. D’ailleurs c’est un développeur qui code, aide en apportant son expérience, s’assure de la qualité technique et protège son équipe. Il peut aussi coacher des Architects, ce n’est pas incompatible. Dans ma vision, c’est une personne un peu plus expérimentée, qui sert d’abord l’équipe de développement. Voyez ce rôle comme le capitaine d’une équipe de foot. [Le gars/la fille] porte un brassard, il assumera les décisions de l’équipe, et il contribue activement au développement.
Le chef de projet s’apparente plus à l’entraineur. Il n’est pas question qu’il code. Et d’ailleurs, selon moi, il n’est pas nécessaire qu’il ait un bagage technique aussi poussé que le team-leader. Ses rôles de gestionnaire, de coordinateur et de diplomate sont vitaux pour l’équipe et le projet. Il s’assure que l’équipe possède toutes les informations et les moyens techniques pour développer et livrer un logiciel. Il peut aussi avoir un rôle hiérarchique ou de manager. Les entretiens annuels par exemple, passeraient par lui.
Tout ceci ne demande pas de certification Scrum. Elle demande d’abord et avant tout des profils précis, qu’il faut être capable d’identifier sur le marché. Revoyez vos équipes, et pensez à ce double-profil : Team Leader et Chef de Projet.
Et vous, c’est comment chez vous ?
Très bon article 🙂
Par contre je pense que tu parles de ton expérience à RFS non ?
L’agilité devient anti-productive dés lors que certains en font une doctrine ! Ce qui va à l’encontre de l’essence même de l’agilité (http://agilemanifesto.org/iso/fr/)…
a+
Philippe
Chez nous on a une organisation assez particulière. Chaque développeur est son propre team-leader, et nous avons un Team-leader un peu a part qui est en même temps VP Engineering de la boite et se charge d’assurer que le travail de chaque « team-tout-seul » est cohérent avec le reste et va dans le même sens en termes de priorités. On ne fait pas de « daily stand-up » mais un « weekly skype-up meeting ». Accessoirement ça se fait sur 16 fuseaux horaires, ce qui peut être assez fun.
Ca peut paraître un peu le boxon, mais ça marche pas mal, car l’archi est également pensée dans ce sens (micro-services).
Le secret c’est d’un part l’autonomie de chacun (ce qui suppose un minimum d’expérience, ça ne pourrait donc pas s’appliquer partout) et surtout beaucoup de confiance, ce qui est ahma la clé de l’agilité, et sans doute une raison pour laquelle elle échoue à s’implanter dans des structures très manageriales à la Francaise.
@Yannick : non, plutôt BNP et la BDF en l’occurence
Dans l’équipe où je suis il y a un chef de projet qui a et donne à l’équipe la vision produit : ce qui est un grand luxe dans un projet ! Il y a aussi une équipe très sensible à ce qu’elle délivre et demandeur de feedbacks. Kanban a été instauré par l’équipe et non par le management mais reste un support pour l’équipe et pas un outil de monitoring pour le management. Le Bon Sens est aussi une méthodologie utilisée et ça marche plutôt bien :-).
C’est partout pareil non ? 🙂
Résumé : lorsqu’une entreprise croît, son organisation se complexifie naturellement (meilleur moyen à court terme de gérer la croissance d’une entreprise : processus / qualité). Ceci amène une centralisation des décisions (ceux qui pensent les processus) puis un besoin de fiabilité, censé limiter les risques (de ceux qui exécutent) et donc des strates de management (dès qu’un goulot d’étranglement se créé on rajoute un niveau hiérarchique histoire de bien s’assurer de l’exécution de la stratégie). La rigidité qui en résulte rend l’entreprise inapte à innover (car trop optimisés pour ses propres processus) : du coup on fait appel aux deux leviers que sont les acquisitions et l’appel aux prestataires (quand ce n’est pas pour se payer de la flexibilité ; on oublie le recrutement : les plus talentueux préfèrent bosser dans boites qui leur laisse de la latitude). L’appel à la prestation créé encore plus de rigidité (normal faut contrôler ce que le prestataire fait … on sait jamais, il n’est de la maison). Etc. etc. etc.
Alors oui, chaque nouvelle technique (Scrum, Lean, etc.) est utilisée pour ce qui plait : l’apport de productivité, car ils optimisent la systémique interne. L’étape ultime étant la suppression du métier en question 🙂
Du coup on fait du Scrum histoire de faire joli, se déclarer « hype » (sur un malentendu ça peut en attirer certains). Alors à parler d’apporter un peu de bon sens, voir rajouter une ressource, un rôle de chef de projet dans l’ensemble. Hors propos ! 🙂
Bon article qui dresse à mon sens est représentatif de la situation dans laquelle se trouve beaucoup d’entreprise sont passées à l’agile sans utiliser le patrimoine interne sur la gestion de projet.
Du cou on repart sur une courbe d’apprentissage de 0….
L’agilité (mais surtout pas scrum) reste une bonne méthode de dev mis entre les mains d’un vrai chef de projet qui l’utilise en fonction de son besoin.
On a trop l’impression que les projets servent la méthode 🙁
C’est ce que j’appelle l’effet « 01 Informatique »,
Je n’y comprends rien dans les méthodes,
Je l’ai lue dans 01 informatique une sucess story sur l’agilité
je fonce et tout ce qui m’alerte sur les dangers sont des réfractaires au changement
En tout cas merci, ça fait plaisir de voir ce genre d’article, on se sent moi seul 🙂
Super billet.
C’est comment chez nous ?
Même contexte business, nous somes de proches voisins mais c’est « autre chose ».
Nous ne sommes pas agiles pour un sou, on n’a même pas de tests unitaires techniques au niveau du code de 200+ interfaces de flux de données. Vous vous doutez bien de la tête du chef de projet fonctionnel quand on lui dit que ses « utilisateurs clés » doivent tout retester… oui, même les écrans non touchés « pour être sûrs ».
Certes, notre méthode de management n’est pas « La RACHE » bien que l’on s’y retrouve en partie mais elle n’a pas évolué, toujours aussi archaïque qu’en 2000 quand on était avec une techno de primates pour faire passer des ordres « à haute criticité ».
Mais ça fonctionne et c’est à cause de nous: le « best-effort » a son prix mais finalement il fonctionne toujours visiblement.
Alors que cela soit SCRUM, Lean, Chose ou Machin, je pense qu’effectivement, cela reste une histoire de bon sens comme tu le décrit parfaitement dans ta proposition.
Christophe.
Petit aparté: des événements à-la-Devoxx sont génialissimes: on y rencontre des gens engagés, qui croient en ce qu’ils font, qui font bouger les choses avec des technologies sympas plus ou moins avant-gardistes et montrent que l’on peut « s’amuser sérieusement ».
On y rencontr des gens que l’on « connaît » via Twitter, on y voit des frameworks de tests qui ont bien évolués, des outils de qualité qui permettent d’aider le dévelopeur, des méthodes de travail qui semblent sympas à mettre en oeuvre et, surtout, on y voit un myriade de choses qui pourrait nous aider à évoluer.
J’y allais de temps à autre mais moins ces dernières années car quand la grande majorité des développeurs « silencieux » rentre à l’usine (moi, entre autres), elle y déprime pendant 3 semaines avant de reprendre le cours des Choses.
Alors, pourquoi donc rester dans cette usine ? Pour essayer de faire bouger le Mammouth.
Peut-on faire bouger le Mammouth ? Assurément, du moins, j’en suis persuadé mais ça devient quand même dur.
A quel prix ? Impossible à évaluer.
Avec quelle énergie ? Impossible à évaluer. Perso, mes batteries sont bientôt à plat.
En conclusion, comme dans tous les domaines, il y a toujours ailleurs du meilleur comme du pire 😉
C’est un peu la même chose, évidemment.
Je pense qu’il faut arrêter de tirer sur l’ambulance. Nous (développeur), pouvons considérer qu’Agile tel qu’on nous le vend n’est plus une approche qui nous permet de mieux réaliser notre métier. Les consultants et managers ont cassé notre jouet. Passons à autre chose : nous n’avons pas besoin d’une étiquette pour porter des valeurs, principes et bonnes pratiques.
Moi aussi, j’ai hâte de voir quelle sera la prochaine trouvaille.
Au départ, je reconnais que l’idée de diffuser les pratiques dans les sphères managériales pour en permettre l’adoption était bonne. Adopter le cosmétique, c’est simple et fun. Mais changer complètement d’état d’esprit ? Les seules questions qui vaillent pour tous ces gens restent « c’est quoi ton RAF ? » et « pourquoi ton estimation / chiffrage est fausse (sic) ? »
Je me permets d’ajouter ce lien vers le blog de Dave Thomas sur le sujet qui a déjà pas mal tourné.
Chez nous c’est:
– collective ownership sur le code autant qu’on peut
– un dev qui fait scrum master à mi-temps (et qui a envie de le faire, point important)
– un dev senior qui fait Tech Lead
– un product owner qui gère le backlog des tâches
– pair programming/code review et TDD obligatoire
– 40% des tâches sont dédiés à la technique (refacto de code, poc de nouvelle frameworks/idée)
– BYOD (Bring Your Own Device). 80% de l’équipe sous IntelliJ. Quelques irréductibles sous Eclipse. Tous est root de sa machine
Les recrutements sont fait par les devs. La décision finale d’embauche revient à toute l’équipe de dev.
KISS
Pour ma part, je ne pense pas avoir le niveau de sagesse requis pour déterminer ce qu’on « devrait avoir ». Par contre dans ce process, si le team leader est abruti et le CP est un idiot, je ne pense pas qu’il sauve grand chose.
La technique ultime n’est-elle pas de comprendre qu’il n’y a pas de technique ultime ? Ma croyance dans les réponse ultimes est limitée. A part 42, bien entendu !
En fait même avec la dualité Lead Tech / Chef de projet, tu peux encore avoir pas mal de soucis : il n’y a encore pas assez de confiance dans l’équipe technique voire même pire, le cdp ex-développeur a tendance à orienter le technique dans le sens qu’il connai(ssai)t et qui est (forcément) obsolète. Mais comme c’est lui qui a le pouvoir de décision (à tort) on a tendance à se reposer sur lui et ses décisions.
Le résultat constaté c’est que c’est vraiment dépendant des personalités de ces deux personnages clés ET de leurs relations…
Excellent. Problème surtout franco-français à mon humble avis.
L’agilité, ni méthode, ni culture : état d’esprit ?
En France, le « management » (j’en fus) la perçoit comme un truc « maaaagique ».
« Si c’est écrit dans le livre, c’est que cela doit être vrai. »
Bonne intro, je pense qu’on a tous souffert au moins une fois de ce genre de phrase…
Comme en politique, si on peut éviter les extrémistes ça se passe toujours mieux, malheureusement au boulot on ne choisit pas toujours
La gestion d’équipe/de projet/le management/les process… tout ce genre de chose qui sur le papier sont formidables sont quasi systématiquement mal utilisées en entreprises (et encore plus dans les banques).
C’est une des constantes formidables de la vie en entreprise.
Il vaut mieux en rire, mais parfois la claque démange. 😉