En ce moment, plein de sujets me trottent dans la tête, mais aucun dans un état abouti et clair. Alors je vous les livre tels quels 😉 Un de ceux qui contribuent à cette situation c’est le bon Michael O. Church, un bloggeur et développeur américain plutôt connu et assez grande gueule sur l’état du management dans l’industrie logicielle et particulièrement dans la Silicon Valley (qui on le rappelle, sur certains aspects est le modèle de ce qui fera dans quelques années dans le reste du monde).

Je recommande des perles comme son très bon réquisitoire pour le craftsmanship, sans jamais dire le mot, un point brillant sur les dynamiques en jeu lors d’un recrutement et comment les retourner en sa faveur, ou dernièrement une critique assez acerbe de l’Agilité, telle qu’elle est couramment implémentée ainsi que dans ses fondements, dans le contexte de l’entreprise vue par le prisme MacLeod/Gervais/Rao (que je recommande d’une telle force que vous ne pouvez pas ne pas l’avoir lu).

Sur ce dernier sujet les arguments sont valables, même si on sent qu’il n’a jamais vraiment eu la chance de participer à un projet SCRUM qui fonctionne correctement (en même temps c’est plutôt rare…). Mais j’accroche quand même bien avec son idée que l’agilité répond à un problème, la bonne allocation du travail aux productifs (les développeurs au sens large), qu’on pourrait peut-être complétement éviter.

Réaction des coachs agiles à cet instant précis de l’article

Sa solution c’est de renverser le problème, soit l’Open Allocation, qui veut qu’on n’assigne pas les projets aux développeurs, mais que les développeurs choisissent eux-mêmes les projets auxquels ils veulent contribuer. Ce n’est pas une utopie puisqu’il existe déjà un exemple d’implémentation, Valve (PDF), l’un des éditeurs logiciel les plus innovants du moment. Notez en passant que ça n’est pas sans détracteurs.

Le but devient alors de passer du Politics-Driven-Development (Waterfall) au Business-Driven-Development (via l’agilité) jusqu’à l’Engineering-Driven-Development (avec l’Open Allocation). Ça peut paraître extrême, mais vu l’état actuel de l’industrie, il va certainement falloir tirer vers cet extrême pour ramener la situation à l’équilibre.

J’aime beaucoup ce courant de pensée, qu’il illustre en disant qu’on ne doit pas laisser le contrôle d’un avion aux passagers (BDD), mais bien au pilote (EDD).

J’aime l’élégance de l’idée (et très égoïstement, la liberté que cela pourrait m’apporter) mais j’ai encore du mal à la réconcilier avec une réalité business. Parce que les passagers, ceux qui payent, doivent quand même bien choisir la destination du vol, et cette contrainte doit bien s’imposer à l’organisation d’une façon ou d’une autres. D’autant plus que dans son exemple de réussite, Valve, les développeurs sont également des joueurs (donc clients), on est donc dans un cas particulier pour lequel l’EDD = le BDD.

Prise de décision chez Valve – un processus communautaire

Dans le fond tout ça rejoint quand même bien les pratiques recommandées du lean, qui pousse à la mise en place d’équipes alignées sur les streams de valeur client plutôt que les habituels silos fonctionnels : Manufacturing, HR, Marketing, Sales, Direction Technique, IT… Les équipes sont de plus rendues autonomes dans la prise de décisions locales et inscrites dans des cycles d’amélioration continue. Elles sont pluridisciplinaires, managées par les moyens plutôt que les objectifs, ce qui leur permet de retrouver un réel sens métier dont découlent les performances (et pas l’inverse).

Imaginez une société de retail, qui fabrique et vend des vêtements et souhaite avancer sur les sujets Internet of Things et vêtements connectés. Quelle meilleure équipe à mettre en place que celle dédiée à une population clientèle très précise (sportifs?), sur un besoin très précis (tracking de la performance personnelle à la fitbit/jawbone), composée du chef de produit (marketing), d’un ingénieur d’étude de l’usine de fabrication, d’un kiné, d’un vendeur magasin, d’un contrôleur de gestion, du community manager concerné, de développeurs web, app, back office, embarqué… On met tout ce petit monde au même endroit, et là vous l’avez la petite société dans la société, avec un PnL propre, une responsabilisation face au produit, et une grosse envie de réussir.

Tout ça on aime. Pas de débat. La question c’est plutôt : comment constituer ces équipes ? L’Open Allocation dans ce cas, ce serait d’avoir les chefs de produit qui pitchent les idées aux différents contributeurs, afin de les recruter et constituer l’équipe. Mais pour que les idées soient sexy il faut déjà que les contributeurs soient intéressés par le contexte métier. Si aucun développeur ne court, voir personne ne fait de sport, comment motiver les gens à rejoindre l’équipe ? Sommes nous alors plutôt devant un problème de recrutement ? Autrement dit, les développeurs de l’IT de Décathlon doivent-ils être des sportifs ?

Voilà, pas vraiment de conclusion, juste plusieurs idées qui s’imbriquent et qui commencent à apporter une image de l’entreprise qui pourrait se matérialiser dans un futur proche, et dans laquelle il ferait bon vivre… 😉