Devoxx 2012 – 7 things to make good team great

Le paradis du développeur : l’endroit où il se trouve, dans une équipe qui déchire et où il réalise des produits qui déboîtent ! Mais comment faisons-nous une équipe de ce calibre ? Et les produits d’excellence, d’où viennent-ils ?

L’agilité est à la mode. Les équipes se mettent à faire des itérations, suivent les cérémonies scrum (daily meeting, rétrospective). Mais est-ce une clé pour obtenir une bonne équipe ?

Que font les entreprises pour motiver un développeur ? Elles mettent du budget sur la table et essayent de proposer un salaire que personne n’oserait refuser. Mais le salaire seul est-il motivant ?

C’est  là que les problèmes commencent.

Une entreprise met elle-même des barrières implicites entre le développeur et sa motivation. Vous êtes à l’aise avec votre IDE (pour vous c’est LE meilleur IDE, le genre d’outil qui vous fait gagner des minutes voir des heures de jour en jour). Malheureusement pour vous, ici, on utilise plutôt l’autre IDE (oui, le même qui vous donne des boutons quand vous le lancez).

Vous utilisez une bibliothèque de Mock qui résout tous vos problèmes ? Dommage : elle n’a pas été certifiée par l’équipe d’architecte.

La motivation est partie, le produit risque d’en pâtir, même si le salaire est bon.

Que faire pour changer cette situation ? Mener une révolution et se mettre tous les gens à dos ? Répéter qu’on n’est pas content et devenir le “jamais content” de service ?

Il y a peut-être une autre voie.
Sven Peters nous présente celle trouvée chez Atlassian, la société derrière les produits Confluence, Jira, Bitbucket, ou encore SourceTree – et je suis sûr que vous avez déjà utilisé au moins une fois un de leurs produits…

…mais revenons sur la voie choisie par Atlassian, basée sur 7 concepts. Certains peuvent paraître basiques, ou évidents, mais revenir aux fondamentaux ne fait jamais de mal. D’autres semblent plus complexes à mettre en œuvre. Pour rendre visible cela, Sven note ces propositions avec une note sur la faisabilité (facile à faire !) et l’impact sur la motivation (si vous avez envie d’abattre des montagnes par la suite). Cela n’engage que lui et peut être variable selon votre projet, surtout sur le plan de la faisabilité : certaines actions peuvent être simples à mettre en place chez vous, et d’autres un petit peu plus compliquées.

It’s flowtime ! (Faisabilité : 4/5 – motivation : 2/5)

Vous êtes en pleine session de programmation, vous visualisez l’interaction complexe entre les classes, vous approchez de la solution à un problème et on vient vous interrompre : “pourquoi le bouton est rouge dans l’application ?”

La solution de votre problème vient de s’envoler, votre réflexion est à refaire….

Comment faire pour éviter ce genre d’interruption ? S’enfermer dans un bureau ? C’est une solution, mais chez Atlassian, les bureaux sont un open space géant. Pas de pièce pour s’isoler…par contre, pas de problème pour s’organiser des plages de temps sans interruption. Pendant 14h et 16h, aucune interruption n’est permise : les gens sont concentrés sur ce qu’ils font, l’open Space est même plus silencieux.

Mais si quelqu’un a une question sur cette plage de temps ? Une personne dédiée devient le point d’entrée pour les questions et se chargera d’y répondre.

Feed your brain (faisabilité 5/5 – motivation 3/5)

Cette semaine, vous avez utilisé le framework interne pour résoudre un problème, non sans mal. La semaine dernière, vous utilisiez le framework pour résoudre un autre problème. La semaine prochaine, vous utiliserez toujours le même framework. Mais il n’existe pas autre chose de plus efficace pour résoudre vos problèmes ? Le projet d’à côté, il utilise quoi ?

Pour répondre à ces interrogations, il va falloir provoquer des rencontres pour échanger sur des nouveaux sujets. Comme par exemple, mettre en place des “coding sessions”, ou encore des “Brown launch bag” : des présentations informelles sur la pause du midi (et donc peu coûteuses à mettre en place).

Appreciation made public (faisabilité 2/5 – motivation  3/5)

Quand il y a un problème, dans certaines organisations, on n’hésitera pas à vous rappeler très fort qu’il y a un problème. Le contraire est moins vrai. On ne félicite pas toujours une équipe pour avoir réussi, malgré certaines difficultés. Pourquoi ne pas faire passer le message que le boulot a été bien fait ? Chez Atlassian, pour faire passer le message, ils ont mis en place un système de “I like it” interne : un développeur peut féliciter une autre équipe. Ça fait toujours plaisir.

Report robot (faisabilité : 2/5 – motivation 4/5 )

La création de rapports sur des indicateurs est très consommatrice en temps. En plus, Sven précise qu’ils mesurent beaucoup de choses chez eux (nombre de build fails jusqu’à des métriques RH). Bref, beaucoup de données. Pour minimiser le temps dépensé à créer ces rapports, leur création a été automatisée. Maintenant, il faut que les gens puissent voir ces rapports. Pour ça, ils ont mis en place des “informations radiators”. Sur des écrans TV sont projetées les dernières métriques que tout le monde peut voir juste en marchant dans les couloirs. Plus besoin d’aller sur l’extranet, chercher le document, chose que les gens font de moins en moins au fil du temps.

Eat your own dogfood (faisabilité : 2/5 – motivation 5/5 )

“Mais le client utilise notre produit n’importe comment !”, “il comprend pas comment le soft marche !”, “j’en ai marre de travailler avec des clients si bêtes !”. Le problème c’est le client, ou peut être votre projet, non ? Utilisez-vous votre projet juste 5 minutes par jour le temps de faire vos tests, ou l’utilisez-vous une journée – comme votre client ? Si votre réponse est la première assertion, le problème est peut-être que vous ne connaissez pas le produit que vous produisez. Pour mieux le connaître, faite comme Facebook qui redirige en interne http://facebook.com sur la dernière version en développement du site. Essayez de tester votre produit sur le terrain, là où il sera utilisé. Apple le fait aussi : vous vous souvenez quand ils ont perdu un prototype de leur iPhone 4 dans un bar ? C’était un test terrain (d’aller dans le bar, pas de perdre le téléphone). Attention, ça peut faire mal au début de se prendre des critiques en direct : il n’y a plus de barrière entre vous et le client. Mais vous comprendrez sûrement mieux pourquoi votre client n’est pas content…

Do a special day (faisabilité 5/5 – motivation 3/5)

On dit toujours : Il fait tirer le pansement d’un coup, ça fait moins mal. “Do a special day”, c’est la même intention : provisionner un jour complet à la tâche que vous ne voulez pas faire (“je le ferai plus tard…”) ou que vous ferez mal. C’est une journée dédiée à faire votre documentation, par exemple. Même si ce n’est pas la tâche la plus passionnante, il faudra y passer. Vous savez que ce n’est qu’un mauvais moment à passer, un petit peu comme le dentiste.

Experience Time (faisabilité 4/5 – motivation 5/5)

Attlasian met en avant la motivation à partir de l’innovation.  Pour mettre en place tout cela, des idées sont exprimées sur un tableau blanc et les équipes se forment naturellement autour de ces idées. Ensuite, une fois par trimestre, une journée complète (ship it day) est consacrée pour la réalisation de ces idées avec pour objectif d’obtenir quelque chose de montrable à la fin, tant pis pour la qualité du code et la documentation. A la fin de la journée tout le monde se rassemble pour voter pour la meilleure idée.

Problème : L’idée est peut être la meilleure du monde mais le code peut être de qualité médiocre, etc. Pour rendre cette idée en produit, avec du code maintenable, un petit peu comme chez Google, ils ont 20% de temps accordé pour travailler sur du “hors projet” et donc la remise à niveau de leurs idées.

Résumons… On se retrouve avec une liste de concepts intéressant, mais comment les mettre en place chez soi ?

L’un après l’autre.

C’est une mauvaise idée de vouloir tout mettre en place d’un coup. Essayez juste un concept, en prenant en compte que ça ne marchera pas forcément du 1er coup, et qu’il faudra faire quelques adaptations pour que ça colle à votre équipe. Ensuite, n’ayez pas peur d’essayer de nouvelles choses…mais une seule chose à la fois 😉

Annexe :

Bio : Sven est un ‘software geek’ ambassadeur pour Atlassian en Allemagne. Il développe des applications Java EE depuis plus de 12 ans et a dirigé des petites équipes en utilisant les méthodologies Lean. Sven apprécie le code source bien écrit et lisible et se soucie de la motivation des développeurs.

http://svenpet.com/slides/

http://www.slideshare.net/mobile/jaxlondon2012/how-to-make-good-teams-great-sven-peters

http://www.officesnapshots.com/2012/07/20/atlassian-san-francisco-office-innovation-community-design/

Source de l’illustration: Atlassian

Nombre de vue : 36

COMMENTAIRES 1 commentaire

  1. […] l’année dernière à Devoxx pour prodiguer les bonnes méthodes utilisées chez Atlassian : 7 things to make good team greats – un ensemble d’astuces pour que votre équipe passe d’une équipe compétente à […]

AJOUTER UN COMMENTAIRE