Pages

Tuesday, October 16, 2012

Scrum distribué : yes we can!

On parle beaucoup de Scrum, beaucoup en bien et beaucoup en mal. Scrum, ça fait parler les gens :-)

Du côté de ceux qui croient en Scrum, On (oui je me mets dedans évidemment) est tous a peu près d'accord sur le fait que Scrum, ça marche bien bien dans des contextes locaux où tout le monde est dans la même pièce. Les outils liés à Scrum sont d'ailleurs orienté pour fonctionner localement avec le fameux tableau blanc, des murs de post-its partout.

A chaque fois qu'on parle de Scrum distribué, tout le monde s'arrête de respirer. Ceux qui ne croient pas en Scrum se mettent à rire et même ceux qui croit en Scrum ont dû mal à croire que ça puisse marcher.
"Quoi ton PO n'est pas dans la même pièce que l'équipe!"


On pourrait d'ailleurs distinguer deux types de distributions :
  • distribution partielle : l'équipe est locale mais est distante du product owner

(scrummaster, team member, team member, ...) | (product owner)


Ce modèle fait penser à un modèle "offshore agile" (les extrémistes de Scrum sont déjà en train de s'étouffer car j'ai osé associer ces deux mots :-))

  • distribution totale : tout le monde est distribué
(scrummaster) | (team member) | (team member) | (...) | (product owner)

Comment ça, ça ne peut pas marcher?

Il se trouve que je travaille actuellement dans une équipe qui fait du Scrum totalement distribué et ça fonctionne plutôt pas mal...

Comme je suis sympa, je vais même vous dire quels sont les facteurs qui font que ça marche dans notre cas :

facteur n°1 : Des profils costauds



L'ensemble de l'équipe est constitué de "profils costauds". C'est à dire des gens intélligents, passionnés,  avec de l'expérience, autonomes, impliqués, communiquant et sachant prendre les bonnes décisions avec le minimum d'informations.

Ok, je pourrais presque arrêter l'article là. On pourrait peut être même faire du "waterfall" et peut être que ça marcherait :-). 

En tous cas, c'est un des facteurs de réussite de Scrum distribué : choisir et être exigent sur les profils qui feront partis de l'équipe. L'idée dans ce cas est de plutôt partir à la chasse, chercher des gens connus  plutôt que de publier des offres de missions sur Monster.

On dit souvent que le problème se trouve souvent entre la chaise et le clavier :-). Le développement logiciel est avant tout une histoire de personnes.

Tout découle donc de là. Si on a les bonnes personnes, on avance dans le bon sens... Ca parait évident mais il faut simplement parfois le dire (même si ça peut choquer un peu).

facteur n°2 : par défaut, on fait confiance



Une attitude qui n'est pas toujours facile à avoir dans les entreprises en france. Je ne sais pas à quoi c'est dû et je ne vais d'ailleurs pas essayer d'y répondre. En revanche, je constate que souvent "par défaut tu n'as le droit de rien faire, pour ne pas faire de bêtise".  Il apparait toujours dangereux de responsabiliser les gens alors que je trouve que c'est une des clé de la réussite. C'est vrai que c'est toujours dangereux quand les gens se responsabilisent, se mettent à réfléchir, prennent des initiatives ;-)

Pour en revenir à notre Scrum distribué. Le premier jour où j'ai commencé cette mission, j'ai eu tout mes accès (même certains auxquels je n'avais pas besoin), par défaut je pouvais tout faire, par défaut "j'avais les droits", par défaut on m'a fait confiance. Quand on est tout seul dans son bureau à distance, sentir cette confiance est un facteur de réussite pour faire du Scrum totalement distribué. Evidemment, c'est plus facile grâce au facteur n°1.

facteur n°3 : Des outils fiables


Comme tous le monde est distribué, il faut de bons outils pour communiquer. Ils sont ultra présents pour donner l'impression de proximité.

Nous utilisons alors :

  • Skype pour faire du chat : plusieurs espaces de discussion sont à disposition (tout le monde, juste mon équipe,...), 
  • Skype aussi pour les communication audio et video.
  • Netviewer pour faire du partage d'écran.
  • les mails pour laisser des traces.
En terme de forge logiciel, nous utilisons :
  • une solution VPN plutôt stable (quand le VPN tombe, il est remonté dans la 1/2 heure).
  • une version de redmine modifiée à la sauce Scrum.
  • Subversion comme gestion de sources.
  • Hudson comme serveur d'intégration continue.
Bref, du très classique mais qui fonctionne avec une gestion des utilisateurs plutôt simples.

Le manifeste Agile dit : "Individuals and interactions over processes and tools". Dans le cas d'un scrum distribué, il faut justement des outils pour mettres en avant les individus et les interactions ;-).

facteur n°4: Un product owner super héros


D'habitude, je n'aime pas les super héros en informatique car en général ça se traduit par si le super héros n'est pas là, on ne peut rien faire. Comme c'est de toute façon le cas lorsqu'on fait du Scrum avec un product owner, ça ne me dérange pas ;-). 

Un des facteurs clé de succés est d'avoir un Product Owner qui sache clairement ce qu'il veut. Je ne dis pas qu'il ne peut pas se tromper car Scrum est fait pour ça. En revanche, c'est clairement lui qui doit donner les directions à chaque Sprint et être le guide de l'équipe sur ce qui est à produire.

Il faut qu'il ait totalement confiance en son équipe encore plus quand celle-ci est distribuée. Evidemment, c'est plus facile grâce au facteur n°1.

facteur n°5 : Des réunions incontournables tous ensemble

Un des facteurs clé de succès qui fait que notre Scrum totalement distribué fonctionne est qu'il y a malgré tout des éléments incontournables qui se font localement tous ensemble.

Nous avons des sprints de 3 semaines et nous nous rencontrons pendant 1 à 2 jours pour effectuer de manière intense :
- la fin d'un sprint : démo et retrospective
- le début d'un nouveau sprint : sprint planning, planning poker, ...

C'est assez dense et pour ne rien oublier, en général on "plan the plan" (on planifie le plan) :




Certes cela fait perdre du temps et donc de l'argent car tout le monde voyage pour se retrouver dans un même lieu. En revanche cela en fait ensuite gagner. Faire ce type d'échange de façon distribués prendrait plus de temps que le temps perdu à se regrouper et serait moins efficace.

Une fois de plus le développement logiciel est avant tout une histoire de personnes. Si les personnes se connaissent "IRL" tout devient plus facile.




Ces rencontres tous ensemble sont aussi l'occasion de construire et d'entretenir un esprit d'équipe, de parler d'autres choses que les projets et de pourquoi pas aller manger un bon fish&chips ;-)



Ce qui marche moins bien

Il y a évidemment des choses qui fonctionnent moins bien.

Daily Scrum trop long :

Nous effectuons tous les matins un daily scrum distribué via skype + partage d'écran netviewer du ScrumMaster pour que tout le monde ait le "focus" sur les mêmes choses. Une des problèmes assez récurrents est qu'il est vraiment difficile de le timeboxer. Le DailyScrum a tendance a durer longtemps.

Papier vs Logiciel de ticket

Nous travaillons de manière distribué avec un système de ticket "numérique" alors que nous nous rencontrons et travaillons sur des post-its localement durant les sprints planning.
La préparation du sprint planning prend alors un peu de temps de préparation pour passer de la version, numérique à la version papier. De la même manière la mise à jour du système de ticketing est juste long et ennuyant...

Sprint planning parfois un peu court

Nous avons parfois du mal à tout boucler lors de nos sprint planning, nous devons dans ce cas le terminer de façon distribuée.

 Pour conclure

Je vous propose une fois de plus mon humble retour d'expérience sur le sujet. Un simple retour d'expérience d'un Scrum distribué qui fonctionne.

Attention :  Ca ne veut surtout pas dire :

  • que si vous faites exactement la même chose, ça marchera
  • que si vous faites différemment ça ne marchera pas

3 comments:

Unknown said...

Intéressant comme retour d'expérience.

Je suis en phase avec ta remarque :
On pourrait peut être même faire du "waterfall" et peut être que ça marcherait :-).

Pour avoir travaillé en waterfall et en scrum je pense que le facteur des personnes est le plus important.
Que ce soit en scrum ou en waterfall un projet qui fait intervenir les personnes compétentes a toutes les chances d'aboutir.
Vu le nombre de projets qui se font en scrum parce que c'est à la mode mais sans les bons moyens, on n'est pas à l'abri que scrum soit à l'avenir décrié comme l'est aujourd'hui le waterfall.

Nicolas Géraud said...

Allez, j'ose :
un projet avec un utlisateur qui sait ce qui veut, des gens compétents et qui se font confiance (et à qui ont fait confiance), de bons outils, à toutes les chances de réussir, même avec un beau cycle en V et une MOA/MOE.

Pour tes collègues, c'est aussi une première ce type de mission ?

Jérémy Sevellec said...

@Nicolas, Je suis d'accord avec toi et c'est un peu ce que je dis dans le facteur n°1 : c'est une histoire de personne et on pourrait même peut être faire du waterfall (= cycle en V) que ça marcherait peut être ;-)

Pour la la plupart des collègues, ils me semblent que oui mais je ne leur ai pas demandé.