Un petit retour sur le Scrum Breakfast: l’Agilité chez Google avec Petra Cross.
Toutes les opinions exprimées dans cet article n’engagent que moi.
Merci aux organisateurs de la FSUG pour l’organisation de cet événement !
Autant le dire tout de suite, je n’ai pas perdu mon temps, mais j’ai été déçu par cette présentation, qui était purement formelle et décrivait un process.
Pour plus d’informations sur le process, lisez cet article de Franck Beulé.
Comme d’habitude, ce qui est le plus important n’est pas ce qui a été dit, mais ce qui n’a pas été dit.
Je dois avouer que je n’y suis allé que pour apprendre comment ils appliquaient la règle des 20%, parce que j’en parle dans ma présentation sur la Créativité Agile, oui Franck, c’est moi qui ai posé la question !
Lean, Kanban, XP mais pas Scrum
Petra Cross a décrit l’agilité chez Google.
Les équipes chez Google utilisent Lean avec du Kanban, rien à redire, ils l’ont poussé à l’extrême.
Au niveau XP, ils ne font pas de pair-programming, mais du pair-review, ce qui fonctionne bien quand on n’a que de bons programmeurs.
Ils n’utilisent pas Scrum, et je suis d’accord avec Petra sur le fait qu’il s’agit plutôt d’une méthodologie pour chefs de projet.
Point important: leurs réunions sont pensées pour prendre le moins de temps possible.
Mais est-ce que Google est vraiment agile ?
Relisons les valeurs du manifeste:
Ces expériences nous ont amenés à valoriser :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
Les points 2) et 4) ont été mis en avant tout au long de la présentation, mais les points 1) et 3) beaucoup moins.
Au contraire, Petra a beaucoup parlé de processus et d’outils, et pas du tout de clients.
Les individus et leurs interactions plus que les processus et les outils
Il me paraît évident que les interactions humaines sont un des points faibles de Google.
Des standup meetings de 15 minutes optionnels et une heure de rétrospective par mois montrent à quel point ils considèrent l’interaction humaine comme un gaspillage, dans le sens Lean.
Et, comme tout gaspillage, il faut le réduire et ne se focaliser que sur le travail.
Je rappelle que nous passons plus d’un tiers de notre vie à travailler.
Aux US, il faut toujours être au top, positif, dynamique, motivé, etc…
Malheureusement, cela ne fonctionne pas aussi facilement !
Pourquoi ? Parce que l’être humain n’est pas une machine.
Programmer est une activité intellectuelle exténuante.
La motivation n’existe pas en quantité infinie (surtout si elle est extrinsèque).
L’être humain, surtout dans nos domaines créatifs, se pose des questions et a besoin de réponses.
Google ne semble pas laisser de place à la remise en cause, notamment en encourageant l’individualité plutôt que l’esprit d’équipe, et en favorisant la rotation des équipes, ce qui induit un comportement de fuite dès qu’un problème humain apparaît (je change d’équipe dès que j’ai un problème).
Les conflits ne seront jamais résolus si on ne se donne pas le temps de travailler dessus, et l’esprit d’équipe peut faire défaut.
Je rappelle que le but de notre vie n’est pas de travailler mais d’être heureux, et si le travail peut nous aider à le devenir, alors profitons-en !
La collaboration avec les clients plus que la négociation contractuelle
Le deuxième point faible de Google est justement la collaboration avec les clients.
Google considère que les clients sont un gaspillage.
Pour réduire ce gaspillage, il n’y a simplement aucune interaction avec le client.
Dans mon cas, je suis aussi développeur, et l’interaction avec les clients représente plus de 60% de mon temps de travail, mais c’est ce qui donne de la valeur à mon travail.
Des mauvaises langues prétendent que les produits de Google sont les utilisateurs eux-mêmes.
De toutes façons, les produits fournis par Google sont gratuits, alors le client n’a pas à se plaindre !
Les 20%
Un des slogans de Google est que les employés travaillent sur ce qu’ils veulent pendant 20% de leur temps de travail.
A titre informatif, 3M utilise la règle des 15% depuis plusieurs décennies.
J’ai demandé à Petra comment elle appliquait les 20%, et j’avoue que j’ai beaucoup aimé sa réponse qui m’a surpris: elle présentait la conférence grâce à ses 20%.
Mais elle m’a aussi confirmé plus tard que peu de gens utilisaient ces 20%.
Selon moi, les 20% utilisés pour du personal branding, c’est un peu limite, puisque ça n’apporte rien à la société, mais comme les employés travaillent d’arrache-pied, c’est une bonne soupape de sécurité pour réduire le turn-over.
Conclusions
Tout d’abord, je ne crois pas que leur façon de travailler soit applicable à une autre société. Tenter de faire comme Google serait une erreur.
J’ai compris que la règle des 20% permet aux développeurs de réduire leur stress, parce que leur travail est très stressant.
De vrais problèmes humains restent non résolus, et Google devra les affronter un jour ou l’autre. La rétrospective est traditionnellement le lieu pour les aborder.
En fin de compte, je ne pense pas que Google soit agile.
Psychologie Agile 
Bonjour Jean-Charles,
Article intéressant, notamment cette remise en perspective des principes Agile. En revanche, ayant aussi participé à la présentation de Petra, je trouve que tu extrapoles bcp lorsque tu affirmes
« Google ne semble pas laisser de place à la remise en cause, notamment en encourageant l’individualité plutôt que l’esprit d’équipe, et en favorisant la rotation des équipes, ce qui induit un comportement de fuite dès qu’un problème humain apparaît (je change d’équipe dès que j’ai un problème).
Les conflits ne seront jamais résolus si on ne se donne pas le temps de travailler dessus, et l’esprit d’équipe peut faire défaut. »
ou encore « il me paraît évident que les interactions humaines sont un des points faibles de Google.
Des standup meetings de 15 minutes optionnels et une heure de rétrospective par mois montrent à quel point ils considèrent l’interaction humaine comme un gaspillage, dans le sens Lean.
Et, comme tout gaspillage, il faut le réduire et ne se focaliser que sur le travail. »
A moins que tu ne disposes d’autres éléments que ceux communiqués lors de cette réunion?
Généraliser à l’ensemble d’une boite de plus de 20,000 employés quelques impressions ressortant d’une seule présentation formelle me parait un peu hasardeux…
— Nicolas
J’avoue que j’ai lu quelques articles avant d’avancer mon opinion:
http://www.latribune.fr/technos-medias/internet/20120116trib000678207/comment-google-manage-ses-salaries-sur-excel.html
décrit l’environnement ultra-compétitif chez Google.
Si tu as lu Deming, tu dois comprendre les méfaits de la compétitivité et des entretiens annuels.
Personnellement, je viens du jeu vidéo (j’en ai fait 18 ans), et je connais très bien ce genre de système, où les employés se donnent à fond pour le prestige et pour leur propre ambition, et partent une fois leurs illusions perdues.
Petra travaille à Google depuis 7 ans, donc elle a travaillé avec plusieurs groupes.
La façon dont elle a présenté la façon de travailler chez Google était:
– regardez les super locaux où je travaille (plusieurs fois, donc ça devait être important pour elle)
– on est tous entassés, mais regardez le pont, il est trop beau !
– daily scrum ? pourquoi perdre 15 minutes ?
– rétro en 15 minutes: qu’est ce qui ne va pas, qu’est ce qu’on peut améliorer ? (tiens, ça me rappelle nos premières rétrospectives, ça donne trop envie de parler des problèmes de fond, non ?)
– cotation ? allez hop, 2 minutes, pas plus
– pair-programming ? ha non, on est trop bons, on fait ça tout seuls. Et puis, le pair-review permet de vérifier si mon collègue est bon.
Je ne me souviens pas d’avoir entendu parler de démo ou de fin d’itération.
Clairement, quand on est centré sur la performance et sur le process à ce point, c’est qu’on se fiche pas mal de la relation humaine.
Franchement, j’y suis allé pour voir comment Google appliquait les 20% (suite au livre de Dan Pink), et pour confirmer cet article:
http://www.journaldunet.com/diaporama/0610-livregoogle/3.shtml
en fait, les 20% servent à acheter la paix sociale, je n’avais pas envisagé cette solution !
Enfin, je te recommande cet article, qui montre que le process n’a pas trop changé depuis 6 ans:
http://steve-yegge.blogspot.fr/2006/09/good-agile-bad-agile_27.html
Merci Jean-Charles pour cette excellente analyse. Au-delà du cas de Google, voici une piste de réflexion intéressante : comment les moyens de production, les produits, et le modèle économique d’une entreprise, influencent les relations humaines au sein de l’organisation.
Merci, mais nous ne voyons pas le problème sous le même angle.
Pour moi, c’est l’individu qui prime.
Comment, en tant qu’individu, puis-je changer l’organisation ?
C’est effectivement un autre angle, et une autre question, qui reste complémentaire de la première… De belles réflexions en perspective. Encore merci pour ce billet et ces commentaires stimulants !
Pingback: Franck Beulé, expert des technologies de l'Internet et en ergonomie du Web » Blog Archive » L’agilité chez Google
J’adhère totalement à tes propos. J’y étais également et j’ai été un peu déçu par les propos tenus. J’ai ressenti la même chose que toi en me disant que ça ne marcherait jamais ailleurs sur bien des points…
Avant de publier mon article, je me demandais si j’étais le seul à avoir perçu tout cela (je suis un vieux développeur maintenant).
Merci de confirmer que je ne suis pas le seul !
Globalement d’accord avec ton point de vue Jean-Charles.
En revanche, dire que « Google considère que les clients sont un gaspillage » me semble totalement au-delà de ce que Petra Cross nous a présenté.
En tant que Software Engineer ou Tech Lead elle a simplement mis l’accent sur ce qu’elle connaît le plus: l’équipe de développement. Cela ne signifie pas que les Product Managers chez Google ne font pas correctement leur travail de collecte et d’écoute auprès des utilisateurs.
Tony, tu as probablement raison, mais cela fait 7 ans qu’elle travaille chez Google, donc elle a déjà vu beaucoup d’équipes travailler. Avec Agile, les silos disparaissent. Tout le monde fait un peu de tout.
De plus, je dois ajouter que je suis allé la voir à la fin du ScrumBreakfast, et je lui ai demandé comment soumettre un bug ou une suggestion à Google.
Elle a commencé à bafouillé, et expliqué que c’était un problème chez Google, et finalement, elle m’a conseillé de laisser un message sur les forums.
Je pense qu’elle doit confondre avec les newsgroups google, je ne crois pas que Google ait un forum.
Enfin, je ne crois pas que ce soit un problème des PM chez Google, mais plutôt un problème de culture.
Pas si sûr justement que les silos disparaissent avec l’organisation qu’elle a décrit. Au contraire, j’ai compris qu’il y avait des frontières assez marquées entre les « engineers » et les product managers + reste du monde. Elle n’a probablement pas beaucoup franchi les frontières en question, même si elle était, en tant que tech lead en contact avec les PM.
Il ne faut pas oublier non plus que culturellement les américains sont peu promptes à aller voir (et encore moins remettre en cause) ce qui se fait dans les services voisins. Ils sont spécialistes de leur domaine mais pas multi-domaines.
Pingback: Agile un peu, beaucoup, ou pas du tout ? - A la Poursuite du Code en Rouge