La Scrum Night 3 chez Google in images (2/2)

Je vous avais laissé à la pause de la Scrum Night

ScrumNight3-cocktail2

Il est temps de reprendre la seconde série d’ateliers. Celle-ci dure une heure, la tranche précédente était de 2 heures.

La fleur de Lotus ou comment redynamiser vos équipes

Yann Poles (prononcer : Polèce) nous proposait une nouvelle technique d’animation de rétrospectives déjà présentée à Grenobles il y a très peu de temps : la fleur de Lotus, technique devant aider la pensée créative.

Le maître de séance en pleine action…

ScrumNight3-fleurlotus2

Les participants également !

ScrumNight3-fleurlotus6

Franchissez la porte, et vous verrez qu’ici on parle de Shrek !

ScrumNight3-fleurlotus8

Mythes et réalités d’une équipe auto-organisée

Ce n’était pas réellement un atelier que nous proposait Myriam Roux, mais plutôt un retour d’expérience. Qu’à cela ne tienne, cela a visiblement intéressé une large audience.

Myriam nous parle de son vécu en tant que coach au sein de la cellule de transformation agile de la Société Générale.

ScrumNight3-rex-myriam4

Beaucoup de questions après la présentation.

ScrumNight3-rex-myriam11
ScrumNight3-rex-myriam10

La présentation de Myriam est accessible en ligne ici. Le thème de cette présentation est aussi celui de sa contribution au “blue book” dont j’avais déjà évoqué la disponibilité sur lulu.com

Perdus dans le désert

Dragos Dreptate nous embarque dans une aventure fort sympathique qui débute par le crash de votre avion où meurent pilote et co-pilote (mais pas les hotesses heureusement). J’ai bien surveillé, mais apparemment les partcicipants n’ont pas fini par se manger entre eux…

Cet exercice est focalisé sur la communication au sein de l’équipe (2 équipes de 4 personnes), afin de prendre les meilleures décisions et en priorisant ses besoins.

Salut, Dragos !

ScrumNight3-perdus4
ScrumNight3-perdus13

Toujours aucun survivant de sacrifié ?

ScrumNight3-perdus12

Marshmallow challenge

Ce grand classique des agiles games nous était une fois de plus proposée ce soir-là. Un binôme représentant le French SUG s’est courageusement alignée. Dignement menée par the Pres’ ! Euh… je ne suis pas resté pour l’annonce des résultats …

ScrumNight3-marshmallow2

Le team “French SUG” …

ScrumNight3-marshmallow4

Picture in picture in …

ScrumNight3-marshmallow7

Jérôme Guenver, le G.O. du Marshmallow Challenge !

ScrumNight3-marshmallow9

Pour ceux qui ne connaitraient pas encore l’exercice, voici une présentation qui pourra vous éclairer.

This is the end

Ainsi s’achève cette nouvelle “Scrum Night”.

ScrumNight3-the-end1

Les plus courageux se sont retrouvés au pub. Pour moi, c’était direction “home sweet home”. Je n’ai plus 20 ans !

Vous retrouverez aussi le compte-rendu d’Arnaud Villenave sur le Blog de Cellenza.

La Scrum Night 3 chez Google in images (1/2)

Cette 3ème édition de la Scrum Night, comme la seconde se déroulait chez Google, près de l’Opéra. Pour la dernière fois d’ailleurs, le géant du Web déménageant courant décembre rue de Londres. Donc, bienvenue chez …

ScrumNight3-google

Accueil et cocktail

Il était heureux que nous ayons prévu l’accueil et le speach de bienvenue (ainsi que le traditionnel cocktail) au début, car les arrivées se sont poursuivies jusqu’à 19h00.

Notre président dans son exercice favori

ScrumNight3-speach-xavier

Le public attentif aux paroles du boss. Bonjour Emeline !

ScrumNight3-speach-emeline

Construisez votre magazine avec Kanban !

L’association Métis emergence nous proposait de jouer à ce jeu qu’elle a créé, avec l’aide de quelques membres de l’association. Vous pourrez en savoir plus sur Kanbanzine ici. Voici le résultat … en images.

ScrumNight3-kanbanzine3

Le plateau de jeu

ScrumNight3-kanbanzine2

Just have fun !

ScrumNight3-kanbanzine-n4

Lean Lego Game

Imaginé par Thoughwork en 2009, ce jeu a pour but de nous faire prendre conscience des principes Lean. Nathaniel Richand animait cette session très dynamique.

ScrumNight3-lego11

Le matériel

ScrumNight3-lego3

Les participants en pleine action ! Le temps est compté …

ScrumNight3-lego9

Pour ceux qui veulent en savoir plus, voici une description du jeu, ainsi que la présentation du jeu par ses créateurs.

Qui a peur du contrat agile ?

Bruno Paul nous présentait cet atelier d’échange autour des problématiques du contrat agile : quels en sont les pièges et comment créer l’entente entre les acteurs dans un contexte qui ne facilite pas cela.

ScrumNight3-contratagile2

Ambiance studieuse à cet atelier.

ScrumNight3-contratagile3

Take the Win Win Wave

Pierre Neis nous a une nouvelle fois gratifié d’un atelier particulièrement dynamique … et coloré : Take the win win wave !

Pierre Neis qualifie ce jeu de “kickoff pour une formation Personal Kanban”. L’atelier consiste tout d’abord en la construction d’une “value stream map” de votre journée, du lever au coucher.

Si ensuite on distribue une valeur (ou un “fun”) de 1000 sur la totalité du flux, comment améliore la journée afin d’optimiser le fun ?

ScrumNight3-winwinwave-neis1

La création de la chaine de valeur

ScrumNight3-winwinwave2

Debrief…

ScrumNight3-winwinwave6

A bientôt…

La première série d’ateliers se termine, le temps de souffler un peu et nous reprendrons la seconde série sous peu. Pour nous, la suite de notre safari photographique est pour demain !

La Scrum Night II @ Google (en images)

Ce 22 Mai s’est déroulé une nouvelle édition de la ScrumNight chez Google !

Mobiliser des animateurs d’ateliers en ce mois de Mai très riche en évènements n’était pas chose facile. Mais suffisamment d’entre eux s’étaient mobilisés pour nous permettre de proposer un programme plus qu’alléchant.

Bienvenue et bon appétit !

J’avais quelque craintes quand à l’affluence dans les locaux de l’avenue de l’Opéra. Nous avions limité les inscriptions en conséquence, faisant hélas pas mal de frustrés. Nous avons réussi à avoir … ce qui s’est avéré être le bon nombre !

La soirée a débuté par un cocktail et de brefs mots d’accueil de Xavier Warzee et de Martin Görner, notre hôte chez Google.

Untitled

Je dois dire que les petis fours proposés par Google étaient somptueux ! En quantité et n qualité. Une fois n’est pas coutume, je me suis calé derrière l’une des tables afin d’attaquer de manière systématique les différents présentoirs durant les mots de bienvenus.

Visiblement cela n’a pas échapé à certains !

Disons toutefois que je n’étais pas seul sur l’affaire …

Untitled

Les sessions !

Je me suis un peu promené durant cette première session. Je me suis rendu tour à tour au Kanban Pizza Game animé par Dragos Dreptate et Luc Dages.

Untitled

Untitled

De son côté Alex Boutin nous a gratifié de son excellent “Big Payoff” que j’avais essayé à Agile Games France il y a peu. En fait, Alex a même improvisé et enchainé sur un second jeu qu’il avait avec lui : “Joli Tableau” pour s’ajuster au timing ! Je reviendrais sur ce point.

Untitled

D’autres ateliers avaient lieu pendant cette première période, les artistes et spécifiers (animé par Cédric Chevalerias), ainsi que le Business Value Game animé par Nicolas Laurent, épaulé au pied levé par Jérôme Guenver (merci Jérôme !)

J’avoue avoir passé beaucoup au “Robot Crash battle” animé avec Brio par Arnaud Villenave ! Des Robots en lego, programmés en Java depuis dces portables s’affrontent lors de combat. Chacune des 3 équipes dispose de 10 minutes pour programmer son Robot. J’ai posté il y a quelque jour une vidéo d’un de ces combats. Arnaud s’est fait u malin plaisir de changer les règles au cours des itrations : combats à deux, puis à trois, réduction du temps d’itération, pénalité en cas de dépassement et pour finir : interversion des programmes des différentes équipes ! L’une des équipes a même eu droit à une mise à jour Windows au milieu de son itération (qu’elle a d’ailleurs remporté).

Untitled

Comme vous pouvez le voir, les équipes ont vraiment fait vraiment travaillé avec acharnement !

Untitled

Lors de la seconde session, j’ai participé à l’atelier de Lan Levy : Scrum Master: qui es-tu ? Quels sont tes défis ? Bien qu’un peu raccorcis, il a donné de bons échanges. Par contre, je n’ai pas de photos à vous montrer de cette période.

En conclusion

Une excellente soirée avec des animateurs de qualité et une communauté toujours encline à participer activement. Visiblement les participants étaient extrêmement contents de leur soirée.

J’étais un peu inquiet des contraintes horaires qui nous étaient imposées, mais elles ne se sont finalement pas montrées pesantes.

Je pense qu’il est maintenant temps de faire évoluer cette formule. J’espère que nous aurons des propositions et des discussions en ce sens sur IdeaScale ! Avoir deux Scrum Night par an est peut-être aussi un peu lourd, en tout cas sur Paris. Personnellement j’aimerais une Scrum Night plus ambitieuse, mais une seule sur Paris. Par ailleurs Grenoble, Bordeaux et peut-être d’autres villes aimeraient aussi avoir une Scrum Night, pensons-y !

Petite confusion aussi au niveau de l’agenda: nous étions convenu d’un timing initial au bureau, avons communiqué avec les animateurs sur la base de ce timing et fianlement c’est un timing différent qui a été affiché. Les ateliers de la première session ont eu un peu de battement (ou de la créativité et de l’improvisation dans le cas d’Alex) tandis que ceux de la seconde session se sont trouvé trop contraints. Nous devons corriger cela !

A bientôt !

C’est certainement notre dernière grosse activité sur Paris d’ici l’été. Nous aurons je l’espère une Scrum Beer (ou deux) et peut-être un Scrum Picnic si la météo est avec nous.

Il va nous falloir commencer à reflêchir à ce que nous projetterons à partir de la rentrée. Il se profile à l’horizon 2013 un évènement de plus grande ampleur que ce que nous avons fait jusqu’à présent : le Scrum Gathering ! Nous devons voir comment nous pourrons assumer cela ainsi que des évènements plus “locaux”.

Scrum Night chez Google : appel au vote des animations !

La Scrum Night chez Google approche ! Nous avions lancé un vibrant appel pour des animations d’ateliers le 19 Avril. Celui-ci a été entendu : 15 propositions d’ateliers ont été postées sur IdeaScale.

Les propositions d’atelier sont maintenant fermées ! Elles sont aujourd’hui au nombre de 15. Un grand merci à tous ceux qui se sont lancés pour proposer une animation !

Mais il reste encore une chose à faire : voter, et vous avez jusqu’au mardi 15 Mai au soir pour cela !

Attention, certains ateliers n’ont été proposés que récemment, cela se reflète dans le niveau de leur vote. Mais tout peut changer maintenant : vous n’avez été que peu nombreux à vous exprimer jusqu’à présent. Il est temps de faire connaitre votre avis.

Ne votez pas pour trop de sessions. L’agenda n’est pas encore défini, mais vous n’aurez probablement l’opportunité de n’assister qu’à deux ateliers lors de cette soirée. En limitant vos préférences disons aux 3 ateliers qui attirent le plus votre intérêt, vous améliorez vos chances de les faire sortir du lot !

Pour épicer le tout, IdeaScale propose un bouton “en désaccord”. Alors c’est vrai que l’on a souvent des scrupule à faire cela. Mais c’est le jeu, et c’est votre super-pouvoir de permettre non seulement de faire progresser les sujets que vous appréciez mais aussi de faire baisser ceux que vous n’aimez pas (ou simplement que vous ne souhaitez pas voir) !

Les votes obtenus par les différentes animations seront un élément déterminant dans le choix de ce qui sera retenu dans l’agenda définitif de la soirée !

Attention, le temps passe vite, ne remettez pas à plus tard ce que vous pouvez faire dès maintenant :

Rendez vous sur IdeaScale pour voter !

FrenchSUG@Google

Avant-propos

J’ai mis du temps a écrire ce compte-rendu. Ce genre de travail est toujours plus long qu’on ne s’y attend en premier lieu. Anne gabrillagues m’a devancé de presqu’une semaine et a rédigé un excellent compte-rendu que vous retrouverez sur le blog Ippon. Anne est également présente sur Tumblr.

Dans le même ordre d’idées, je vous recommande aussi la lecture du Blog de Jean-Charles Meyrignac. Nous différons sur l’analyse de certains points et c’est d’autant plus intéressant, d’autant que le post est d’excellente qualité !

Google, c’est toujours un peu l’actualité en permanence. Si la présence de Petra Cross en France attire notre attention sur la place des femmes chez Google, je vous recommande aussi l’article sur Marissa Mayer sur IEEE Spectrum.

Vous retrouverez des photos de l’évènement sur Meetup. Place aux orateurs !

L’évènement

Le Scrum User Group Français était accueillis ce 17 Avril par Google, pour nous faire partager la pratique de l’agilité dans leurs équipes de développement. Un accueil excellent par ailleurs, avec beaucoup de gentillesse de la part de notre hôte, Martin Görner et un petit déjeuner offert. Nous étions certainement un peu serrés dans les locaux de l’avenue de l’Opéra, mais il faut dire que cet évènement a créé un engouement sans précédent, nous avions élargi le plus possible le nombre de places disponibles, mais malgré cela, toutes les places sont parties en une journée créant une liste d’attente assez conséquente sur Meetup.

Martin Görner

Après un (rapide) mot d’ouverture de votre serviteur, Martin Görner nous a servi en guise d’introduction un portrait savoureux d’une équipe de développement sur la base des personnages d’héroïc fantasy ! Avec dans l’ordre:

  • Les Barbares, à savoir l’équipe de développement.
  • Le Clerc, l’ancien qui a la connaissance et la sagesse.
  • Le Mages, capable d’opérer une magie que lui seul sait faire … mais qu’hélas aussi lui seul détient !
  • Le Maître, celui qui enseigne à l’équipe, diffuse sa connaissance et sa sagesse.
  • Les Amazones (si, si) Symbole de la diversité de l’équipe.
  • La Bête, celui qui va mettre dans vos projets un nouveau langage chaque jour. On n’en veut pas.
  • Le Scout, qui va explorer des territoires inconnus,
  • Le “dragon rider” qui comprend les aspects métier complexes.

Petra Cross : Behind the day to day at Google

Petra Cross en Bref

Petra travaille chez Google depuis 7 ans. Elle a débuté sa trajectoire sur le moteur de recherche, avant de rejoindre l’équipe GMail. Depuis cette année elle fait partie de l’équipe Google Wallet localisée à San Francisco.

Les équipes Google en quelques faits

  • L’engagement des membres des équipes ? “Achieve mission ! Whatever we’re doing !”
  • Les équipes: 10000 développeurs, répartis dans plus de 40 bureaux à travers le monde.
  • 20 “check in” par minutes
  • 50% de la base de code est modifiée chaque mois.

Les rôles

  • VP (vice-president) : Un par grand domaine de Google: Search, Social, etc…
  • Engineering Director 
  • Engineering Manager : Il gère les ressources et les personnes. Il n’opère pas de “micro-management”, mais opère selon le principe du “servant manager” cher à nos principes agiles.
  • PM (Product Manager) : C’est la personne qui a la vision client sur un projet. Il joue en gros le rôle du PO de Scrum
  • SWE (Software Engineer) : Ce sont les développeurs.
  • SWE / TL (Team Leaders) : Ce sont des développeurs comme les autres, mais ils jouent le rôle d’interface avec les autres équipes et avec le PM quand c’est nécessaire. Leur rôle est de faire gagner du temps aux autres développeurs en leur épargnant des tâches annexes. Il sont plus ou moins l’équivalent du Scrum Master de Scrum. Petra a joué ce rôle au sein des équipes Google Mail.
  • SET (Software Engineer in Tests) : Ce sont des développeurs dont le travail est spécifiquement focalisé sur l’intégration continue et les tests unitaires.
  • TE (Testers) : Leur travail est spécifiquement dirigé vers l’écriture de tests d’acceptante.

Chaque Engineering Manager gère un ensemble d’équipes formés typiquement de 6 personnes : 5 SWE et 1 SWE/TL. Les équipes ne sont pas complètement fixes dans le temps, le manager crée un peu de mouvement entre les équipes. On eut dire que ce concept se rapproche quelque peu des Feature Teams de Scrum.

Au niveau de l’agencement des locaux, Petra nous a montré quelques photos des locaux de San Francisco. Outre son propre poste simplement situé près d’une fenêtre donnant directement sur le Golden Gate Bridge, on voit que les développeurs sont regroupés en de larges open-spaces. Chaque poste de travail comporte typiquement une station de travail, souvent un PC fonctionnant probablement sous Linux, équipé de 2 écrans 24 pouces, et un portable qui peut être un MacBook ou un PC. Certains disposent l’affichage de leurs écrans 24’’ verticalement !

Le workflow du développement

Le développement est plutôt “orienté Kanban”, bien qu’il ne semble pas y avoir de limite de WIP explicite. C’est ce que Petra nomme “Features Development as a Queue”. Le workflow est le suivant:

  1. Idée
  2. Décliné en Feature
  3. Planifié
  4. En cours de travail
  5. En revue de code
  6. En test
  7. En beta test “Canary”
  8. En production Live !

Les développeurs sont responsables de la qualité du code qu’ils poussent dans le gestionnaire de version. Le code intégré dans l’intégration continue doit être totalement testé par le développeur qui le considère LGTM (Looks Good To Me).

Le Release Manager  a la responsabilité de prendre régulièrement un snapshot de code qui a passé l’étape “tests” et de le mettre à disposition en “canary build” pour 2 jours, afin que ces évolutions soient pleinement testées en situation réel par des beta testers. A l’issu de ces 2 jours, si le build est accepté, il passe en production !

Ce que Google cherche à faire avec son processus

C’est essentiellement gagner en efficacité, en:

  • Raccourcissant ce temps de cycle
  • Travaillant rapidement
  • En ne développant que ce qui a réellement besoin de l’être !

Ce que Google ne cherche pas à faire :

  • Echouer
  • Gaspiller de l’argent

Le processus de développement est en fait très largement “Kanban”, mâtiné d’itérations, comme on le verra bientôt.

Les User Stories sont définies et écrites par le PM. Sans que cela soit explicitement définit dans Scrum, les deux processus se rapprochent ici. Le PM évalue la taille de ses stories en utilisant des “PM points”. Les  users stories sont découpées en tâches par le PM et le Tech Lead. Oui, vous avez bien lu: l’équipe n’est pas directement impliquée (en tout cas pas en premier lieu) dans le découpage en tâches !

L’équipe fait ensuite, lors des planning meeting, l’estimation des tâches. Le PM n’est pas présent au planning meeting. Les tâches sont estimées par l’équipe, avec le teck lead. Le critère retenu est celui que nous connaissons bien avec Scrum: savoir quand la tâche est “done”. Si ce critère ne peut être clairement déterminé, c’est au Tech Lead de retravailler la tâche avec le PM. J’y vois une faiblesse du processus qui génère du délais dans ces cas, délais qui pourraient être éliminés simplement par la présence du PM lors des planning meetings ! Mais peut-être que ce problème ne se pose que très rarement ?

Tout cela est bien entendu géré. Mais plutôt que d’utiliser un outil de gestion de projet, c’est une simple feuille de calcul (Google Spreadsheet, bien sûr) qui est utilisée. Elle est divisée en 2 onglets :

  • L’onglet “PM” : Utilisé pour lister les users stories.
  • L’onglet “équipe” dans lequel on retrouve le découpage en tâches.

Les User stories suivent aussi un cycle de vie de haut niveau:

  • Icebox: C’est le congélateur. Les US qui ne seront pas prises dans les 2 ou 3 prochaines semaines sont simplement stockées ici sans être analysées plus avant. Pas question de perdre du temps sur des fonctionnalités dont on est pas sûr qu’elles seront implémentées un jour ! Implicitément cela en dit long sur la façon dont Google gère la notion de roadmap : il n’y a pas de roadmap ! Il y a bien une Vision, mais celle-ci n’est pas déclinée en roadmap / releases ! Le congélateur sert à garder trace des idées, à permettre de les exhumer quand ou si on veut les réaliser à un moment donné.
  • Backlog : Seules 2 ou 3 US sont prises dans une itération de 2 semaines (il n’y a pas de durée standard d’itération chez Google, cela est ajusté par équipe). Tout ce qui n’est pas pris pour cette prochaine itération retourne au congélateur. Le PM et le Tech Lead priorisent les tâches lors du travail de découpage.
  • En cours: Il n’y a pas de “limite de WIP” sur les tâches comme il y en a de manière formelle avec Kanban. En pratique, chaque développeur aura au maximum 3 tâches en cours. il peut être amené à prendre une tâche supplémentaire quand:
    • Il est bloqué ou que sa tâche est en cours de revue.
    • Il ressent la besoin de changer pour éviter la saturation !
  • Terminé et vérifié.

En pratique !

Les équipes ont pas mal de l’attitude sur la façon de gérer leur matière première, c’est à dire les tâches. Pour l’équipe GMail, par exemple, c’est l’utilisation d’un tableau de tâches qui a été retenue, chaque “swimlane” représente une des étapes de progression de la tâche.

Le planning meeting est traditionellement court, de l’ordre de 20 minutes pour des itérations d’une ou deux semaines (et on estime toujours un peu plus de tâches que ce qui peut être pris dans l’itération) ! La seule chose qui y est faite est réellement l’estimation des tâches, car leur découpage a déjà été opéré précedemment par le PM et le Tech Lead, comme je l’ai dit précédemment. On ne cherche pas à y reconstruire de “big picture”, on prend juste les tâches les unes après les autres…

L’estimation est faite en points, selon une échelle de Fibonacci modifiée. Le fonctionnement du planning meeting est globalement très codifié:

  • On ne donne pas d’avis ou d’impression sur la tâche du genre: “c’est difficile”, “ça va être facile”, etc.. 
  • On est seulement autorisé à poser des questions fermées auxquelles le Tech Lead peut répondre par “oui” ou par “non”.
  • Il y a un ordre strict de parole !

Un chose importante à noter est que si le planning meeting rythme le travail en permettant d’alimenter le flux de travail, cela ne stigmatise pas le début ou la fin d’un cycle de travail: il est courant d’avoir un reste de tâches ou des tâches en cours au moment du planing meeting !

Comme avec Scrum, les tâches ne sont pas attribuées. On prend les tâches dans l’ordre de priorité qui a été défini. Cela signifie qu’une personne nouvelle sur un sujet prendra plus de temps ou demandera de l’aide pour mener à bien sa tâche. Cela n’est pas considéré comme un handicap, mais comme un aspect positif: les équipes Google ne souhaitent pas créer des ilots de connaissance !

Le peer review est systématique, alors que le pair programming ne l’est pas (il peut être pratiqué occasionnellement). Chaque tâche de revue de code est systmatiquement de la plus haute priorité : débloquer ses pairs est considéré comme l’apport le plus important que l’on puisse faire !

Le daily standup n’est pas pratiqué par de nombreuses équipes ! Cet aspect est également laissé au grée de l’équipe. Par exemple:

  • L’équipe GMail pratique le planning meeting, mais pas le stand-up
  • L’équipe Google Wallet fait des stand-up, mais n’a pas de planning meeting.

Petra par ailleurs ne semble pas fan du daily meeting.

Les rétrospectives sont pratiquées de diverses manière mais sont extrêmemnt courtes

  • Si la rétrospective est effectué chaque semaine, sa durée sera d’environ 15 minutes.
  • Pour une rétrospectives mensuelle, on comptera 1 heure.

Une rencontre mensuelle se tient avec le l’équipe, le PM et le directeur de l’ingénierie pour dresser les grandes lignes de ce qui est à venir.

Et l’environnement ?

Les développeurs bénéficient de beaucoup de liberté par rapport aux outils qu’ils peuvent utiliser. Beaucoup utilisent Eclipse, ils peuvent alors bénéficier de l’aide d’une cellule dédié à cet outil.

Pour ce qui est des outils d’intégration:

  • Git est utilisé pour la gestion de version au niveau des développements.
  • Perforce est utilisé par le Release Manager et les équipes de test, pour travailler en terme de “change set”.
  • L’environnement d’intégration continu (désolé, je ne sais pas ce qu’il y a derrière) est standardisé entre les différentes équipes Google à travers le monde.

Ainsi, si chaque développeur peut bénéficier du confort d’un ensemble d’outils qu’il connait, le passage d’une équipe ou même d’un site à un autre est facilité par des outils de travail en équipe qui sont eux standardisés !

En conclusion

Google est-il agile ou non ?

La réponse à cette question ne semble pas avoir d’importance pour eux. Sans doute ont-ils raison !

Ma réponse serait oui, non en regard des pratiques, mais de la mentalité. Tel que l’a dit Petra en début de présentation, c’est “achieve mission, whatever it is !”.

Google suit-il Scrum : non ! Bien que certaines pratiques soit très proches. Encore une fois , cela semble d’une importance secondaire. L’axe prédominant est clairement Kanban, l’importance est sur le flux et l’efficacité de celui-ci, les cérémonies qui vont autour sont réduite au maximum. Cela est aussi probablement dû à la très grande maturité des équipes de développement.

Deux aspects de moyenne ou faible maturité agile m’ont surpris :

  • Une stratification assez importante des fonctions PM / Tech Lead, avec par exemple un découpage en tâche dans lequel l’équipe n’est pas impliqué, et l’absence du PM lors du planning meeting, le travail ayant été “mâché” par le PM et le Tech Lead. Le but semble être de gagner en efficacité et d’éviter de faire perdre du temps à l’équipe ! Mais on perd sur l’aspect participatif et l’implication de l’équipe…
  • Le cycle de release : s’il est plutôt court, on reste en deça des pratiques devops ! Je me serais attedu sà ce que devops fasse partie de l’ADN de Google !

Google a adopté un processus ad hoc, pragmatique. Il est agile de mon point de vue, car focalisé sur l’efficacité, la mis en ligne fréquente et aussi rapide que possible des fonctionnalités développées. Il est très “lean” par nature, avec un focus particulier sur le flux et l’élimination du gâchis (tout ce qui ne participe pas à la création de valeur).