L’agilité chez Google

Grace à French Scrum User Group, j’ai participé à mon premier meetup, un scrum breakfast sur l’agilité chez Google animé par Petra Cross, une employée de Google San Francisco qui a travaillé sur des projets d’envergure, notamment Gmail. Google pratique très largement l’agilité et Petra vient nous expliquer comment. Il est intéressant de voir le nombre de points communs avec nos usages en France, mais aussi quelques différences. Compte-rendu.

Cette réunion tombe à point nommé, car je présente moi-même le lendemain un apéro sur l’Agilité chez Vision IT Group. Mes slides sont bien évidemment faits et validés de longue date, mais il est intéressant de confronter ce que j’ai écrit et ce qui s’est dit lors de cette conférence.

Après avoir raconté son histoire au sein de Google, Petra introduit la conférence par un nombre faramineux : 70 milliards de dollars sont perdus chaque année aux États-Unis par des projets qui ont été abandonnés. Avec cet argent, on pourrait faire décoller 100 navettes spatiales, fabriquer et déployer 24 satellites GPS, fabriquer un Boeing 777, et il restera même quelques milliards… chaque année !

La faute ? À une gestion de projets interminables entraînant retards et surcoûts monstrueux, au point de faire abandonner ces projets après des dépenses pharaoniques. Ils appellent cette gestion de projet « Waterfall », les chutes d’eau. J’utilise plutôt le terme de méthode traditionnelle ou cycle en V. Mais l’image des chutes d’eau est éloquente : l’eau ne va que dans un sens, elle ne revient jamais en arrière. On ne se remet jamais en cause.

La solution ? Réduire les coûts en accélérant les mises en production et en servant aux clients des produits continuellement de qualité. C’est justement ce à quoi s’emploie l’agilité. C’est ce que pratique Google au quotidien.

Je ne vais pas m’étaler sur les différents rôles existant chez Google ni sur le fait que la hiérarchie est assez plate, ni non plus sur le fait qu’il est préférable d’avoir plusieurs équipes de petite taille (cinq personnes idéalement) plutôt que de grosses équipes. Je ne vais pas non plus revenir sur les différentes cérémonies existantes dans l’agilité. Petra a été très claire sur ces sujets, mais je l’ai déjà évoqué dans de précédentes analyses d’expert, et c’est également le cœur de la présentation que je réalise demain. Rien d’original jusque-là.

En revanche, quelle ne fut pas ma surprise lorsqu’elle a évoqué différentes méthodes Agiles, dont Scrum, une méthode qu’elle ne connaît pas ! Sa définition de Scrum est d’ailleurs assez intéressante : une méthode pour les chefs de projet. Le débat devient tout de suite intéressant. Voilà une personne qui pratique l’agilité, mais pas Scrum. Là où moi, je pratique plutôt Scrum.

Ce n’est pas au niveau des cérémonies que cela change. Elles y sont toutes : daily scrum, planning poker, sprint planning, démo, rétrospective. Je suis juste interpellé par la faible durée de la rétrospective : un quart d’heure par semaine s’il y a rétro hebdo, ou une heure par mois. Quand je vois que nos rétros dépassent allègrement les deux à trois heures par mois, je reste perplexe.

En revanche, l’organisation de ces cérémonies est quelque peu modifiée. S’il fallait supprimer une cérémonie, elle supprimerait le daily scrum qu’elle ne juge pas indispensable. Les autres sont au contraire impératives. Lorsqu’elle est arrivée sur le projet Mobile Wallet, l’équipe ne pratiquait que le daily scrum, mais pas les autres cérémonies, notamment pas de chiffrage. Dès son arrivée, elle a très vite corrigé le tir. Le chiffrage est indispensable. Sans chiffrage, pas d’agilité !

D’ailleurs, le chiffrage se fait à deux niveaux : au niveau des histoires puis au niveau des tâches. Le chiffrage des histoires est réalisé en présence du product manager et des team leaders, les référents techniques de l’équipe. Une réunion de préparation au sprint planning est réalisée pour revoir les priorités court-terme. Le découpage en tâches et son chiffrage est fait par une partie de l’équipe. Il est limité à quatre personnes. Jusque-là, j’avais plutôt entendu dire que le découpage et le chiffrage était fait par l’équipe entière.

Autre point de différence avec la méthode Scrum, l’équipe ne s’engage pas sur le sprint. Les itérations sont d’une semaine, mais il n’est pas garanti qu’à la fin de l’itération, toutes les tâches seront finies. C’est plutôt l’inverse.

La colonne « À faire » est alimentée de tâches à réaliser pour les trois prochaines semaines. Chaque tâche a ensuite sa propre vie : « En cours » pour sa réalisation, « En revue » pour sa validation. L’état suivant est une spécificité Google : « En soumission ». C’est à ce moment-là que les développements sont prêts à être mis en production. Un vérificateur est chargé de s’assurer que tous les prérequis Google sont satisfaits. La tâche passe ensuite en « qualification ». Très rapidement, elle va se retrouver en production, indépendamment des autres, là où nous ne la mettrions qu’en recette ou en pré-production. L’astuce ? Elle n’est déployée que sur 2 % des utilisateurs. À l’échelle de Google, c’est plus efficace que n’importe quel tir de performances. C’est à ce moment qu’est validée la bonne tenue de la fonctionnalité en charge. Des administrateurs surveillent tous les indicateurs de charge. Une fois que tous les risques sont levés, la fonctionnalité est déployée sur 100 % des utilisateurs.

Autre petite différence : avant le backlog, ils ont une zone qu’ils appellent « Ice box ». Cela permet de stocker et congeler les bonnes idées qui seront peut-être les fonctionnalités du futur. Elles restent là en attendant que le backlog en cours soit épuisé.

La notion d’équipe est également très intéressante. Comment faire des équipes de cinq personnes dans un projet aussi gigantesque que Gmail ? Il suffit de créer une équipe par fonctionnalité. L’intégration de Gmail à Google Plus et la gestion des dossiers intelligents sont donc réalisées par deux équipes différentes qui travaillent toutes sur la même application. La vocation de ces équipes est de ne vivre que pendant la durée de réalisation de la fonctionnalité. Elle sera ensuite dissoute pour permettre la formation d’une autre équipe en charge d’une autre fonctionnalité. Une pratique très agile !

Autre élément important pour le bon fonctionnement d’une équipe : la présence d’une Amazone. Une femme développeur dans une équipe change totalement le comportement de l’équipe et la rend plus dynamique et donc plus efficace. Il faut bien sûr qu’elle soit au niveau de l’équipe.

Google, c’est 10 000 développeurs qui pratiquent quasiment tous l’agilité. Les équipes ont toutes à disposition le kit de développement Google basé sur Eclipse et Git. Les développements sont réalisés en Java, avec ou sans Android, mais également en Python. Le moteur d’indexation et les autres tâches critiques sont développés en C++. Le JavaScript n’est pas directement utilisé puisqu’ils ont un moteur de transformation Java en JavaScript. Chaque développeur est équipé d’un PC avec deux écrans 24 pouces. Certains les mettent en position portrait pour une performance optimale.

Petra nous a permis de voir deux ou trois photos de ses bureaux, des open-spaces bien sûr, et elle était très fière de nous montrer la vue du sien : une vue plongeante sur le Golden Gate Bridge.

Merci à Petra de nous avoir fait vivre à l’heure de Google, une société en général si secrète. Un intervenant n’a pas résisté à poser la fameuse question : que faites-vous des 20 % de temps libre que vous offre Google pour faire ce que vous voulez ? Après avoir confirmé que chacun faisait ce qu’il voulait, tant que c’était « Google related », elle nous a précisé que cette présentation faisait partie de ces 20 %. Mais c’est bien sûr !

Une fois encore, merci à Petra car, bien que la présentation ait eu lieu entièrement en anglais, son accent très léger et ses explications très claires m’ont entièrement fait oublier qu’elle utilisait une langue que je ne pratique pas tous les jours.

Pour terminer, merci à French Scrum User Group de m’avoir permis de participer à cet évènement et rendez-vous à la Scrum night du 22 mai chez Google qui est malheureusement déjà complète pour ceux qui ne sont pas encore inscrits.

Voyez la page consacrée à ce Scrum Breakfast sur meetup.

Vous pouvez regarder la vidéo de sa présentation, réalisée en Tchécoslovaquie en octobre 2011, avec sensiblement les mêmes notions que celles présentées à Paris.

Un autre point de vue sur cette réunion exprimé par Jean-Charles Meyrignac, très polémique.

Un compte rendu tardif (27/04/12), mais très complet et très détaillé d’Anne Gabrillagues, que je vous conseille fortement.

Vous pouvez également lire mes autres articles sur l’agilité et la gestion de projet.

Franck Beulé
Chef de projet Agile, expert des technologies de l’Internet et en ergonomie du Web

Mots clés : , , , , , , ,

  1. […] 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 […]

  2. THAVONEKHAM Vincent le 18.04.12 à 00:31

    Super, merci pour ce compte rendu très détaillé.
    Présentation très intéressante au coeur de Google France.
    Dommage qu’une matinée passe aussi vite !

  3. Ludovic PEROT le 18.04.12 à 00:31

    Bonjour,

    Il me semble bien qu’ils sont 10 000 développeurs chez google.

    Cordialement,
    Ludovic.

  4. franck le 18.04.12 à 00:31

    Oups coquille. J’ai mis à jour le nombre de développeurs. Merci Ludovic.
    J’ai aussi rajouté le lien vers le compte-rendu de Jean-Charles Meyrignac, plus polémique.
    N’hésitez pas à faire des commentaires et à me communiquer les autres erreurs. Je mettrais à jour l’article en conséquence.

  5. David Bourguignon le 18.04.12 à 00:31

    Merci Franck pour ce compte rendu exhaustif. Un petit rectificatif : d’après mes notes, je crois que Google c’est plutôt 10.000 développeurs… 🙂 L’effectif total à la fin de l’année 2011 était de 32.467 employés pour un chiffre d’affaire 2010 de 29,32 milliards de dollars (source : Wikipedia en français). Ceci nous donne un ratio de près d’un million de dollars par employé, un chiffre confortable.

  6. Olivier Rochier le 18.04.12 à 00:31

    Merci pour ce compte rendu exhaustif !

    Une petite chose me dérange néanmoins… Je suis assez perplexe sur le parallèle qui est fait entre l’amélioration de l’efficacité de l’équipe et la nécessaire présence d’une « Amazone » qui serait « au niveau de l’équipe (sic) « . Martin Görmer l’a évoqué lui aussi lors de sa présentation.

    Je ne peux m’empêcher de trouver le concept étrange dans ce qu’il envisage. Pourriez-vous expliciter un peu plus ?

    Cordialement

  7. franck le 18.04.12 à 00:31

    Olivier, c’est l’opinion de Google qui a été transmise. Je trouve l’idée intéressante et l’ai partagée avec plusieurs collègues qui sont tous interpellés et perplexes.

    J’en profite pour vous signaler une mise à jour en fin d’article. J’ai rajouté un lien vers le compte rendu d’Anne Gabrillagues qui est très complet bien qu’arrivé tardivement. Je vous le conseille.

Ajoutez un commentaire