C’est votre 10eme itération, vous êtes en plein stand-up et Roger le nouveau ne sait toujours pas quel post-its prendre. Il faut dire que Roger n’arrête pas de vous demander quelle tâche de développement il doit prendre aujourd’hui.

Vous êtes tech –lead sur un nouveau projet et vous recherchez un nouveau framework de test en Javascript.

Vous êtes RH, et vous êtes en train de rédiger une fiche de poste pour ce curieux métier qu’est le « product owner ».

Vous êtes responsables produit d’une grande assurance et on vous demande de rédiger un backlog.

Vous avez envie d’en parler, venez le 27 Septembre à l’Apéro Agile !

Autour d’un verre, nous discuterons de l’état de l’Agile, de carrière, de pratiques, de techniques et de vos réussites.
Que vos équipes soient déjà Agiles, que vous soyez vous même praticien de longue date, ou que vous souhaitiez vous mettre à l’Agile prochainement, venez partager avec d’autres pratiquants vos problèmes du quotidien afin de les résoudre ensemble.

Pour venir à l’apéro agile, inscription ici.

Suggestion d'articles :

1. Apéro Agile, le retour !
2. Octo présente cinq sessions dans le cadre de la conférence Agile France
3. OCTO chez Google !

Dans ce billet, nous nous basons sur un expérience vécue de mise en place d’une méthodologie (Scrum) sur un projet de développement, pour analyser un piège qui, selon nous, guette toute organisation désireuse de s’améliorer via l’adoption d’une méthodologie : le piège de l’Artefact.

Le piège

Un jour, un homme décide qu’il veut devenir moine. Il accepte alors de s’astreindre à certaines règles de vie, à une discipline. Il revêt également un habit qui le fait apparaître comme moine aux yeux de tous.

L’organisation qui souhaite devenir Agile, ISO, CMMi ou “Force Pure” (non, ne cherchez pas “Force Pure” sur Google : nous utilisons ici ce terme pour désigner une méthodologie ou une certification quelconque) accepte de s’astreindre à certaines règles de fonctionnement, à une discipline. Elle produira des artefacts qui pourront notamment servir à démontrer aux observateurs son respect de ces règles, à prouver qu’elle “est” ce qu’elle prétend être.

Pour valider le fait qu’un homme est un moine, ou qu’une organisation est Force Pure, l’observateur extérieur aura donc un moyen fort simple à sa disposition : il lui suffira d’en analyser l’habit. Nous le savons pourtant : “l’habit ne fait pas le moine”.

La société X veut devenir Agile

La société X a vu dans l’Agile un moyen d’être plus performante, plus réactive, plus efficiente. Pour ce faire, les organisations Agiles sont parées d’un arsenal de pratiques, d’outils, et de divers signes visibles. Afin d’obtenir cette parure, elle fait appel à un consultant Agile.

Beaucoup d’organisations suivent le cas de la société X et choisissent différentes méthodologies afin d’atteindre différents buts :

• Démontrer leur maturité et leur capacité à délivrer un service de haute qualité,
• Améliorer leur capacité à produire des composants ISO à moindre coût,
• Diminuer le time to market.

Place à l’artefact

La DSI de la société X s’est lancée. Le consultant Agile l’aide dans sa mise en place des pratiques et outils qui vont bien. Sur un premier projet, les rôles sont distribués : Product Owner, Scrum Master, Tech Lead, développeurs.

Le backlog est un tableau Excel à 9 colonnes. Un outil de tests fonctionnels automatisés est mis en place. Comme l’a suggéré le consultant Agile, l’équipe projet a collé des feuilles sur les murs pour faire un taskboard, acheté des post-its et affiché des burn-up charts. Toujours sur les conseils du consultant, des rituels ont été mis en place : stand-up, bilans d’itération, rétrospective…

Quelques semaines plus tard, la mécanique est en place, l’habillage est complet. Le consultant Agile est remercié, la société X est maintenant sur les rails du succès grâce à sa parure de Scrum et XP.

Y’a un truc qui coince…

Pourtant, quelque chose cloche.

Le produit livré présente des défauts de qualité. A la fin de chaque itération, les parties prenantes du projet discutent la pertinence de ce qui a été développé. Les développeurs sont frustrés car leur travail finit souvent à la poubelle.

Voilà quelques phrases que l’on entend typiquement dans les couloirs ou pendant les réunions sur le projet “agile” de la société X :

• “Prioriser, oui, mais bon… De toutes façons l’important c’est de tout faire !”
• “Vous traitez ça comme vous voulez (bug, story, whatever), mais ça doit être en production demain !”
• “Bon, la rétrospective, on la fait ou pas ?”
• “C’est vrai qu’on a changé le périmètre de l’itération en plein milieu, mais en même temps un projet ça vit, et on est agile !”
• “OK, ce que tu as codé c’est pas exactement ce qu’on voulait, mais bon… Je te valide la story, et puis tu corriges ça dans la foulée ?”
• “Oui, bon, l’Agile c’est gentil, mais c’est surtout un truc de développeurs !”
• “Ca marche pas ! – C’est vrai que ça nous semblait bizarre mais bon c’est ce que l’on nous a dit de faire.”

Sous l’habit, la vraie nature

En effet, nombre d’artefacts sont en place et semblent attester d’un respect de la méthode. Mais en fouillant d’avantage, on se rend compte que tout n’est pas si simple…

Taux de couverture du code par les tests unitaires : 82%.
Mais que teste-t-on ? Ces tests sont-ils pertinents ?
Le problème ici est que l’on pense avoir une bonne pratique, on a mis en place un indicateur, les chiffres sont positifs, mais ils ne révèlent pas la qualité des tests effectués. La qualité du test est difficile à mesurer. Pour pallier ce problème, on peut conserver cet indicateur mais changer nos pratiques de développement en passant à TDD (construction du test puis écriture du code permettant de satisfaire au test).

Binômage entre développeurs.
Oui, on a binômé sur le projet. Mais avec le temps, la pratique a disparu. En cause : pas le temps de binômer, il faut produire, et puis l’on considère que chaque membre de l’équipe est suffisamment monté en compétence…
En effet, on aura tendance à penser que l’on produit plus de valeur à deux derrière deux machines, qu’à deux derrière une seule machine…
Puisque dans ce dernier cas, la productivité en terme de lignes de code produites par développeur serait mécaniquement divisée par deux ! Néanmoins, la pratique du binômage (actif) facilite la propriété collective du code, améliore le design applicatif et améliore la précision des estimations.

Stand-up meeting, 10h00, tous les jours.
L’ensemble de l’équipe participe au rituel du stand-up meeting, chacun communique sur ce qu’il a fait la veille, ce qu’il va faire, et quels sont ses blocages. C’était en tous cas le cas au départ.

• Au fur et à mesure, le format dérive et les participants se contentent de remonter l’avancement du sujet sur lequel ils travaillent. Avec l’érosion de la pratique du binômage, on se spécialise sur des pans de l’application : à chaque itération, on travaille sur les mêmes sujets et on ne s’intéresse plus au travail des autres.
• Les problèmes ne sont plus communiqués, car on a peur d’être jugé. Ce n’est pas toujours évident de dire “je suis bloqué, je n’y arrive pas, pouvez-vous m’aider ?”
• L’équipe n’a pas prévenu de son retard la dernière fois, alors on veut s’assurer qu’elle va bien tenir les délais cette fois-ci… Le stand-up meeting prend alors des allures de point de suivi de l’avancement, pendant lequel la MOA ne cessera de rappeler “On est très attendu là-dessus, il faut vraiment que ça livre !”…

Au final, l’absence de relation de confiance a dégradé l’utilité du rituel : synchroniser l’équipe et lever les points de blocage.

Des User Stories et des spécifications Fitnesse.
On alimente les équipes de développement en User Stories. Mais on préfère les exprimer sous forme d’algorithmes ou de conceptions détaillées parce que l’on considère que les développeurs n’ont pas les compétences nécessaires ou la responsabilité du design de l’application. Les équipes fonctionnelles n’expriment plus des besoins et dérivent, elles expriment des solutions.

Que s’est-il passé ?

On se rend compte qu’on a transformé la méthodologie pour de mauvaises raisons : peur du changement, incompréhension de l’objectif de la pratique…

La société X a voulu devenir agile, mais veut avoir :

• des concepteurs, garants de la conception applicative,
• des développeurs garants de la production de lignes de code,
• des qualifieurs garants de la qualité de l’application.
• …

On a ajouté de la structure organisationnelle avec des chefs pour chaque équipe, dont les objectifs divergent…

La démarche Agile prône une équipe auto-organisée, responsable, unifiée… L’organisation précédemment décrite va à l’encontre de ce principe et ne favorise pas un climat de confiance nécessaire pour le bon fonctionnement de l’équipe. Un retour aux valeurs de l’Agile est nécessaire.

Certains des artefacts sont là, le projet semble agile. Mais visiblement, le process, lui, est bafoué. Les pratiques sont réaménagées, parfois détournées de leur objectif initial : améliorer la productivité, la qualité, l’efficience de notre organisation.

Quelques pistes pour ne pas se faire piéger

Pour ne pas être pris dans le piège de l’artefact, voici quelques idées qui peuvent aider :

1) En début de projet, l’équipe définit son objectif, et le révise régulièrement

2) L’équipe se forme à la méthodologie qu’elle a retenue

3) Des rétrospectives sont conduites de manière régulière et non négociable

4) En rétrospective, l’animateur pose les questions suivantes :

- “Y’a-t-il des pratiques qui vous semblent inutiles, inadaptées ou améliorables ?”
- « Y’a-t-il de nouvelles pratiques à adopter ? Qu’en attend-on ?
- “Vous avez travaillé avec différentes personnes depuis la dernière rétrospective ; comment ces collaborations auraient pu être améliorées ?” (= rendues plus efficaces)

Les réponses à ces questions orienteront l’ajustement de la méthode aux besoins de l’équipe. Ce travail doit être fait sous le contrôle d’un garant de la méthodologie qui veillera à ce que ces ajustements servent réellement l’objectif de l’équipe.

5) L’équipe met en oeuvre les nouvelles pratiques

6) Lors de la rétrospective suivante, on repart au point 4

Conclusion

Il ne faut pas perdre de vue que l’utilisation d’une méthodologie ou l’obtention d’une certification, quel-qu’elle soit, n’est pas une fin. Transformer son entreprise, adopter une nouvelle méthodologie, est un moyen permettant de répondre aux enjeux poursuivis par celle-ci. Il ne suffit pas d’endosser les artefacts de la méthodologie pour garantir l’atteinte de ses objectifs. Le but du moine n’est pas d’être reconnu comme tel aux yeux de tous, c’est de se rapprocher de son Dieu. Aussi, Saint Jérôme nous précise : “ce n’est pas à l’habit qu’on reconnaît le moine, mais à l’observation de la règle et à la perfection de sa vie.”

On a envie de dire “c’est du bon sens”, et c’est vrai. Encore faut-il savoir en faire preuve…

Note : cet article aurait également pu s’intituler “J’ai 250g de farine, 200g de beurre… Je ne peux pas rater mon gâteau.”

Suggestion d'articles :

1. Jeudi, l’Agile Tour fait escale à Paris
2. OCTO, 1ère place au palmarès Great Place to Work® des entreprises où il fait bon travailler

• Demander à chaque participant de donner son rôle sur le projet et ses attentes pour cette rétrospective
• Les noter sur une feuille de paperboard
• Demander au groupe s’il y avait d’autres membres qui ne sont pas présents, importants sur le projet, et leur rôle

L’animation du recueil des événements importants peut se dérouler de la façon suivante:

• Demander à chacun de noter les événements importants du projet pour lui avec les consignes d’écrire en majuscule un seul événement important par post-it: « Quels ont été les événements importants pour vous sur ce projet ?
• Demander à chaque participant d’aller présenter les post-it qu’il a écrit. La consigne pour les autres est de poser des questions de clarification. En fonction, le post-it peut être réécrit pour être plus lisible pour les autres
• Demander ensuite aux participants si d’autres événements leur viennent à l’esprit à partir de ce que chacun a présenté: « Avez-vous d’autres événements qui vous viennent à l’esprit ? »
• Nettoyer la timeline et permettre aux participants de bien l’avoir à l’esprit: « Y’a t-il des événements en doublon ? », « Selon vous, est ce que les événements sont bien positionnés dans le temps ? »
• Redemander aux participants si un événement important a été oublié: « Y’a t-il un événement important qui a été oublié ? »

Conseil d’animation:

• Dans l’étape 1, vous pouvez demander aux participants de trouver 10 événements importants pour leur donner un défi et solliciter leur mémoire. Cette étape se fait en silence pour permettre plus facilement la remémorisation
• Les étapes 3,4,5 permettent « d’ancrer » la timeline dans l’esprit des participants et de solliciter leur concentration grâce à une répétition
• N’hésitez pas à demander aux participants si les post-it sont lisibles et à demander de les refaire sinon (qualité first !)
• Si vous avez des graphiques projets (burndown chart, velocity chart), il peut être pertinent de les afficher à côté de la timeline

La deuxième partie correspondant à la construction du sismographe d’énergie:

• Demander à chaque participant de prendre individuellement un temps de réflexion sur comment était son niveau d’énergie au cours du projet et visualiser la courbe
• Demander à celui qui souhaite, de commencer à tracer sa courbe d’une couleur et de mettre son prénom ou trigramme
• Puis au suivant

Une fois terminé la construction de la timeline et du sismographe, il est alors possible de retirer quelques apprentissages utiles pour d’autres projets.

Exploiter la timeline

L’exploitation de la timeline peut se faire de la façon suivante:

• Inviter les participants à se lever et parcourir la timeline silencieusement pendant quelques temps et une fois qu’ils sont prêts d’aller s’asseoir
• Faciliter une discussion autour de ces questions:
  • Quels sont les événements qui vous ont marqués ?
  • Qu’est ce qui vous surprend sur la timeline ?
  • Qu’est ce que vous a révélé la construction de cette timeline ?
  • De quels éléments souhaitez vous discuter avec le reste du groupe ?
• Après cette discussion, demandez au groupe de se répartir en 3 sous-groupes, chacun répondant à une des questions suivantes sur une feuille de paperboard en s’appuyant sur la timeline et le sismographe:
  • Qu’est ce que nous avons bien réussi ?
  • Qu’est ce que nous pouvons améliorer ?
  • Quelles recommandations pouvons nous faire à une nouvelle équipe projet qui démarre ?
• Demandez à ce qu’un rapporteur de chaque sous-groupe vienne présenter le travail
• Les autres peuvent poser des questions de clarification
• Une fois que le rapporteur a terminé, demandez aux autres participants s’ils ont d’autres choses à ajouter, les noter le cas échéant
• Passer aux autres questions

En clôture de la rétrospective, il est possible de poser deux questions à chaque participant:

• Où en êtes vous par rapport à vos attentes ?
• Quelle est la chose que vous gardez en tête et que vous allez amener dans vos prochains projets ?

Il est important de passer du temps dans la construction de la timeline pour permettre à l’équipe de se remémorer les moments importants du projet car parfois la rétrospective ne se fait pas toute de suite après la fin du projet. Il peut arriver qu’après un atelier comme celui-ci que les personnes aient l’impression d’avoir passé un bon moment et qu’à peine sorties de la salle elles oublient ce qu’elles ont pu dire. La projection dans le futur de chaque participant en clôture est une bonne pratique pour permettre aux personnes présentes de partir au moins avec quelque chose qu’elle pourra réutiliser par la suite. La synthèse écrite est faite en général par l’animateur et doit être bien sûr envoyée à tous les participants et stockée dans l’outil de Knowledge Management de l’entreprise afin de permettre une réutilisation de l’expérience acquise.

Suggestion d'articles :

1. Animer des rétrospectives d’itération
2. Comment mieux prioriser en projet agile
3. Quels sont les types de tests que l’on utilise sur un projet agile ?

La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: « À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». Ritualiser cet événement permet de mettre en place un processus d’amélioration continue. Même si parfois, l’équipe a l’impression qu’il ne s’est rien passé, il s’est passé quelque chose, le plus important étant de garder cet espace de prise de recul.

Couramment, deux types de rétrospectives sont faites dans les projets agiles: les rétrospectives d’itération et les rétrospectives de release/projet. Cet article parlera des rétrospectives d’itérations et présentera 2 outils simples, le Keep Drop Start et la note d’itération.

Pour une rétrospective d’une itération de deux semaines, il est recommandé de faire une rétrospective de 2 heures, pour une itération d’une semaine, 1h.

Keep Drop Start

L’outil le plus simple utilisé pour une rétrospective d’itération est le Keep Drop Start:

Couramment, chaque participant  est invité à noter en gros et majuscule sur des post-it les choses qui lui viennent sans se brider pour chaque partie:

• Ce qui fonctionne bien, ce qu’il faut garder (Keep)
• Ce qui fonctionne moins bien, ce qu’il faut supprimer (Drop)
• Ce qui reste mystérieux
• Ce qui fonctionnerait bien si…, ce qu’il faudrait faire (Start)

Conseil d’animation:

• Si vous sentez le groupe bloqué, vous avez toujours une personne qui a plus d’idées que les autres, demandez lui de dire à voix haute quelques-unes de ces idées et d’aller les afficher
• Si personne n’a d’idées, guider les participants sur des thématiques: « réfléchissez à l’estimation, les réunions, le code, à ce qui pourrait-être améliorer ? » et tant qu’à faire sur ce que vous avez observé vous-même pendant l’itération
• L’important dans l’animation de la rétrospective est que l’équipe prenne conscience par elle-même de ses points de blocages
• Je vous conseille de finir par un vote collectif (vote par bâton ou gommette) sur les 5 grandes idées / actions pour l’itération car cela permet de mobiliser l’équipe et il est irréaliste de croire qu’une équipe puisse faire plus de 5 actions d’amélioration en 2 semaines, au moins au début
• Au bout d’un moment (3/5 itérations), vous pouvez inviter un membre de l’équipe à l’animer à votre place pour favoriser la prise d’initiative et dans l’idéal l’animateur tourne

Pièges à éviter:

• En tant qu’animateur de la réunion, vous voulez que l’équipe sorte absolument avec un plan d’actions, vous voulez alors à la place de l’équipe et donc vous la déresponsabiliser. Parfois la prise de conscience suffit à ce que les choses ne se reproduisent pas

La note d’itération

La note d’itération peut aussi être utilisée si vous avez moins de temps et pour changer. Changer d’outil peut être stratégique car il peut permettre de sortir des habitudes prises par l’équipe.

Pour la note d’itération, vous pouvez utiliser ce processus inspiré de l’approche orientée vers les solutions:

• Demandez à chacun de positionner son niveau de satisfaction de l’itération sur une échelle de 1 à 7
• A partir du niveau estimé (Ex: 4), posez la question: « Qu’est ce qui fait que tu as mis 4 ? »
• Puis posez la question: « Qu’est ce qu’il faudrait pour avoir seulement 5 (4+1) ? »

Conseil d’animation:

• Commencez par les plus discrets et silencieux car ils ont souvent une bonne perception de la situation mais ils n’ont pas souvent la parole et ne la prennent pas
• Déléguez l’écriture sur le tableau blanc à un membre de l’équipe
• Comme vous êtes dans une approche circulaire, au bout de la 3ème ou 4 ème personne, les idées commencent à devenir identiques, vous pouvez alors inviter les prochains à annoncer ce qui est différent de ce qui a déjà été dit

Pièges à éviter:

• Discuter/Contredire ce que dit un participant, ceci aurait pour effet de brider ce que pourrait dire la personne

De rétrospectives en rétrospectives

Je constate souvent que les équipes agiles oublient ce qui s’est passé dans les rétrospectives précédentes, une sorte de perte de mémoire qui fait que rien ne se passe hormis le fait que tout reste pareil. La rétrospective est alors une sorte de bureau des plaintes où chacun exprime ses peurs, ses reproches, pour que tout fonctionne comme avant. Sommes-nous dans une approche d’amélioration continue ? pas si sûr.

En tant qu’animateur, que faire avec ça ?

• Attendre. Pas d’actions, pas de réactions dans une rétrospective, ce n’est pas si grave quand cela arrive 1 ou 2 fois. Laisser l’équipe dans son jus a du bon pour la responsabiliser
• Demander au groupe quelles sont les actions qui avaient été décidées la dernière fois
• Se focaliser sur une action et aller chercher chaque étape en détail
• Faire un atelier pour sortir l’équipe du rituel rétrospective et faire un travail de fond
• Questionner le groupe sur les avantages pour lui de faire une rétrospective ou mieux avec une approche paradoxale: quels seraient les bénéfices de ne plus faire de rétrospective ?
• Provoquer le groupe: « Je pense qu’il est temps d’arrêter de faire des rétrospectives » accompagné d’un silence en espérant une réaction et qu’un leader va émergé… c’est un peu du quitte ou double

Il est courant de croire que la rétrospective est le seul moment où l’on puisse faire de l’amélioration continue. Dans la réalité, il est possible d’introduire des feedbacks de 10 minutes en fin de chaque réunion pour habituer l’équipe à se responsabiliser sur son fonctionnement.

L’amélioration continue est une approche de petits pas qui visent à ancrer un niveau supérieur dans une roue dentée. Il est clair que parfois cela ne suffit pas, même pire cela renforce le non changement d’une équipe, il faut alors envisager d’autres façons de faire, en rupture, qui demandent beaucoup plus de doigté car déstabilisantes pour une équipe.

Suggestion d'articles :

1. Animer une rétrospective projet
2. L’artefact ne fait pas le moine
3. Espace détente

(Charles est un coach agile. Daniel est un développeur dans un projet agile. Un vendredi à 18h30, l’heure de la bière).

Charles: Alors comment va votre projet ?
Daniel: Hmm. Y a des hauts et des bas. Jusqu’ici on avait une courbe de vélocité en progrès, et puis là, soudain, le trou d’air. Le client nous refuse 4 scénarios sur les 7 prévus dans l’itération… C’est logique d’ailleurs, ses tests de recette ne passent pas.
Charles: Qu’est-ce qui a changé ?
Daniel: Difficile à dire. On n’a pas de problème majeur, plutôt des tas de petits soucis qui s’accumulent depuis des semaines. Du coup le manager nous revoit lundi pour mieux comprendre ce qui se passe. Il nous a dit “votre courbe de vélocité, je n’y crois pas”.
Charles: Il a raison.
Daniel: Bah voilà. Merci pour l’encouragement. A la tienne.

Charles: Tchin! Tu me dis que la courbe de vélocité progresse et aussi que vous avez des tas de petits soucis qui s’accumulent depuis des semaines. Qu’est-ce que vous mesurez sous le terme “vélocité” ?
Daniel: Simple: c’est la somme des points des scénarios utilisateurs terminés par l’équipe à la fin de chaque itération.
Charles: Et ces points, comment vous les attribuez ?
Daniel: Je ne t’apprends rien: on fait un planning poker en début d’itération.
Charles: Comment ça se passe en ce moment le planning poker ?
Daniel: Eh bien.. Gérald, tu sais, celui qui est arrivé le mois dernier, n’estime pas comme nous. Par exemple il vote 5 sur un scénario , en nous expliquant : “Il y a deux contrôles et une validation en base, c’est grosso modo la même complexité que l’écran xyz, qui était estimé aussi à 5”. Alors que pour réaliser ce scénario, on doit monter de version le framework LycwXml 2.3, et c’est coton, vu l’état du code existant, En plus, en l’absence de Jean-Mi, c’est Gérald, qui débute, qui va faire. C’est plutôt un scénario a 25 points en fait.
Charles: Je vois. Comment ca c’est terminé ?
Daniel: Le scrum master a fini par trancher: “Allez, disons 21. Comme ça, ça vous fera une bonne vélocité.”
Charles: Oups!

Daniel: Tu penses que le scrum master n’aurait pas dû intervenir ?
Charles: J’en sais rien. Ce qui me frappe, c’est qu’on dirait que vous essayez d’avoir une bonne vélocité.
Daniel: Bah c’est le but, non? Une bonne vélocité, ça signifie que l’équipe fait bien son boulot.
Charles: Tu veux dire que si elle augmente, c’est que l’équipe travaille mieux, c’est ça ?
Daniel: Exactement.
Charles: Et quand elle diminue, c’est que l’équipe fait moins bien son travail ?
Daniel: Euh. C’est que l’équipe à des problèmes pour faire bien son travail.
Charles: Et donc, dans ce scénario à 21 points, rappelle-moi ce qui entrait en ligne de compte dans l’estimation ?
Daniel: Comme je t’ai dit: la montée de version du framework, l’état du code existant, l’absence de Jean-Mi.
Charles: Des problèmes, en quelque sorte.
Daniel: En quelque sorte.
Charles: Voilà. Vous essayez d’avoir une bonne vélocité, tout en intégrant les problèmes dans l’estimation. Si on va par là, plus vous avez de problèmes, plus vos scénarios comptent de points…
Daniel: Tu aurais un conseil, là ?

Charles: Eh bien, estimer le scénario comme l’a fait ton collègue, sur la base des fonctionnalités, en le comparant éventuellement à des scénarios précédents du même acabit, me paraît une bonne idée.
Daniel: Mais ça ne nous dit pas forcément le temps qu’il faudra effectivement passer sur ce scénario.
Charles: Exact, c’est une estimation “idéale” ou en “vitesse de croisière”. C’est pourquoi on la fait en points et non en JxH. Ce qu’on estime c’est la complexité fonctionnelle du résultat, et non l’effort à fournir.
Daniel: Et comment on estime l’effort à fournir, dans ce cas ?
Charles: Inutile.
Daniel: Je ne comprends plus.
Charles: Vous êtes 3 développeurs, donc par déduction vous consommez 15 JxH par itération. Ce n’est pas une information. Les points que vous collectez en fin d’itération, c’est de la quantité de fonctionnalités produites, et non de l’effort fourni. Donc ce qui doit entrer dans l’estimation, ce sont des points de complexité fonctionnelle, et non des efforts à fournir. Tu comprends ?
Daniel: Ca marcherait mieux avec un exemple.

Charles: Imagine une équipe qui développe des écrans de saisie. Les écrans sont estimés à 5 points. A l’itération 1 l’équipe produit 2 écrans; sa vélocité est de 10. A l’itération 2, elle gagne en assurance et arrive à produire plus vite; sa vélocité est passée à 15.
Daniel: Ok.
Charles: A l’itération 3, elle est impactée par un changement portant sur du code qui a été copié/collé. Elle doit factoriser son code. Sa vélocité repasse à 10. A l’itération 4, elle trouve une librairie d’expressions régulières qui lui évite de coder à la main les contrôles de saisie. Elle produit alors 6 écrans, soit 30 points.
Daniel: En gros, dès qu’elle s’outille, sa vélocité s’améliore.
Charles: Pas forcément: à l’itération 5, elle découvre un nouveau framework d’écran de saisie qui lui permettrait d’économiser encore plus de temps et de lignes de code. Elle l’installe, le configure, se forme. Sa vélocité tombe à 0.
Daniel: Ouch!
Charles: A l’itération 6, elle a le framework en main et produit 10 écrans par itération! Sa vélocité passe à 50 points. Etc. Les chiffres sont schématiques, mais ce que cet exemple montre, c’est que lorsque l’équipe rencontre des problèmes, la vélocité baisse, lorsqu’elle les résoud, sa vélocité augmente. Ce qui change, c’est la vitesse de l’équipe, pas la richesse fonctionnelle des écrans.
Daniel: Je crois que je comprend ce qui se passe chez nous. On a arrêté d’estimer seulement la taille des scénarios, et on a introduit dans l’estimation nos difficultés à les réaliser.
Charles: D’où le fait que votre vélocité augmentait artificiellement…
Daniel: …jusqu’au plongeon.
Charles: Bon réveil!

Daniel: Il y a quand même un truc qui ne va pas dans cette façon d’estimer..
Charles: Sûrement. Tout ceux qui l’ont adopté ont d’abord rencontré des problèmes et des réticences.
Daniel: Comment prendre en compte les tâches purement techniques dans le planning game, comme par exemple, installer des outils ou faire un gros refactoring ?
Charles: A la fin des estimations, on se pose la question de l’engagement: “combien de scénarios pouvons-nous embarquer dans cette itération ?” Les développeurs peuvent dire : “dans l’itération précédente notre vélocité était de 25, on pourrait donc théoriquement réaliser tous les scénarios estimés, mais vu qu’on a des outils à installer et un gros refactoring à faire, on ne les produira pas tous.”
Daniel: Et si le client insiste pour les avoir tous ?
Charles: Il peut le vouloir mais ce n’est pas forcément ce qui arrivera. Il faut peut être négocier…
Daniel: …mais au moins on négocie le périmètre par rapport à ce que doit faire l’équipe, et non la complexité des scénarios.
Charles: Tu as tout compris. C’est la différence entre engagement et estimation.
Daniel: Laisse, la bière est pour moi.
Charles: Puisque tu insistes!

Suggestion d'articles :

1. Domain Driven Design : des armes pour affronter la complexité
2. 5 minutes pour : Monter en complexité, Approche TDD / Tests en PHP, PHP & Ajax

« Et après avoir enregistré la livraison, on voit que le stock du produit… n’est pas mis à jour… »

Une application pas assez stabilisée, des scénarios déroulés de manière trop hasardeuse, un démonstrateur peu familier de l’application… l’ »effet démo » devrait alors être rapidement invoqué pour justifier les comportements inattendus et autres « stacktraces » présentés à l’écran devant un auditoire au mieux interloqué, au pire moqueur.

Pourtant, cet effet et les moments de solitude qui en découlent peuvent être maîtrisés avec peu de préparation. Au travers d’un cas réel, nous vous proposons dans cet article de parcourir les principales astuces vous permettant de sécuriser une démonstration et de combattre l’effet démo qui, un peu à la manière du « Plouf« , s’instille sournoisement dans les habitudes d’une équipe. Le cas pris pour exemple de cet article est un projet mené sur un mode « Scrum ». Cependant, le principe de la démo reste valable hors de ce contexte.

Vous trouverez en pièce jointe une checklist synthétisant les vérifications à faire afin de mettre toutes les chances de votre côté.

Le besoin

Temps fort d’un projet informatique (Scrum en particulier), la démonstration rassemble, pour quelques heures, l’ensemble des acteurs du projet autour de la même table et permet de partager le travail effectué. Il s’agit d’un moment privilégié à ne pas rater et, ce, dans tous les sens du terme :

• Au sens de la participation tout d’abord : reconnaissance du travail de l’équipe et entretien du lien avec les équipes délocalisées
• …mais aussi et surtout au sens de la réalisation : en effet, à ce moment du projet, l’application était en pleine construction. Sécuriser les démonstrations devenait nécessaire car :
  • La succession de démonstrations chaotiques depuis plusieurs sprints…
  • …entraînait un manque de visibilité sur l’avancement…
  • …entraînant à son tour une perte de confiance du « Product Owner » et du management…
  • …ainsi qu’une lassitude des équipes de développement

Le besoin était donc de rassurer l’ensemble des acteurs sur le projet et montrer clairement ce qui fonctionnait.

Que montrer ?

Il est courant, au début d’un projet, d’avoir le sentiment de ne rien pouvoir montrer. Mise en place du « socle technique », montée en compétences sur le métier et les différents outils… les raisons sont souvent nombreuses pour justifier l’absence de matière concrète.

D’autre part, les cas d’utilisation des applications de gestion requièrent parfois peu d’interaction avec l’utilisateur, rendant l’exercice de démonstration d’histoires moins… démonstratif.

Dans ce cas, on pourra se tourner vers la présentation de pages de tests exécutables telles que FitNesse ou GreenPepper.  Au-delà de l’aspect tests, ces outils ont l’avantage de rendre visible le fonctionnement de code sans IHM. Dans un premier temps, des pages concernant des briques « techniques » telles que, classiquement, les couches DAO, pourront convenir.

Une fois le rythme de croisière atteint, la construction du contenu de la démo se fait à partir du Jira du projet (ou autre backlog). Sur notre projet exemple, nous nous basions sur les stories validées au cours du sprint voire, si elles étaient suffisamment stables, sur les stories non validées mais terminées. Nous nous assurions cependant que, dans le cadre des scénarios envisagés, elles étaient valides !

La préparation

Contenu des scénarios

Les stories/fonctionnalités sélectionnées sont ensuite instanciées afin de donner naissance à des scénarios proches d’une histoire réelle. Ces scénarios sont de préférence organisés de manière logique pour le sponsor du projet (par exemple, référencer un produit avant de le vendre !).

Une fois les scénarios décidés, ils doivent être écrits afin de laisser place le moins possible à l’improvisation le jour de la démo. Ils seront « relativement détaillés« , le niveau de détail dépendant de la confiance dans l’application. De très détaillés pour les fonctionnalités délicates et/ou nouvelles (ex : « Saisir 12 POINT 34 dans le prix de vente du produit »), ils pourront devenir assez sommaires pour des fonctionnalités de base d’un projet avancé et stable (ex : « Créer une commande de deux produits »). Ne pas hésiter non plus à identifier clairement les pièges connus (ex : « Ne PAS cliquer sur ‘OK’ »)…

Rôle du « Responsable de démo »

La multiplication des équipes fait que, naturellement, plusieurs personnes peuvent être amenées à présenter. Dans une situation « de crise » telle que celle subie par notre projet exemple, les premières démonstrations ont été prises en charge par une seule personne, le temps que les présentations se rationnalisent. Cela a permis de mettre en place le process avant réappropriation complète par le client. Ce « responsable de démo » se charge alors de dérouler les scénarios et prend en charge la préparation de la démo à l’aide de la checklist attachée à cet article

Impacts des déploiements automatiques

Nous avons parfois terminé le lundi soir en ayant déroulé et enchaîné avec succès les scénarios mais, le mardi matin, les comportements étaient tout différent… Cela était dû aux déploiements automatiques qui avaient mis à jour l’environnement sur lequel la démonstration allait être effectuée. Ils avaient été oubliés dans l’excitation de la préparation ! Tirez-donc parti de nos oublis et pensez aux tâches automatiques :)

Le déroulement

A ce stade, le contenu de la démo est figé et les acteurs connaissent leur texte ! Il n’est plus envisageable d’ajouter un dernier scénario qui aurait été terminé tard le soir précédent…

Impliquer les équipes délocalisées

Faire participer l’ensemble des équipes à la démonstration est important ; l’exercice est un peu plus complexe lorsqu’on travaille avec des équipes délocalisées. Nous avons utilisé deux outils pour maintenir le lien avec les équipes situées en Europe de l’Est et en Asie : Skype pour l’audio et Mikogo pour le partage d’écran. Cela permet de partager les manipulations du démonstrateur. Attention, cependant, à la réactivité de la connexion réseau qui peut conduire à une démonstration illisible pour vos correspondants !

Respecter les scénarios !

Dans l’euphorie de la présentation, l’improvisation peut prendre le dessus. La démarche peut sembler très scolaire, mais s’astreindre à suivre ligne à ligne chaque étape du scénario et à indiquer chacune comme étant réalisée évite de solliciter des fonctionnalités non prévues de l’application (et donc de faire émerger des bugs potentiels). Réaliser la démonstration à deux (l’un présente, l’autre contrôle) sécurise également le bon déroulement du scénario. On perd bien sûr en spontanéité, mais sur notre projet exemple, l’utilisation d’un déroulement aussi contraint n’a pas duré plus de deux ou trois démonstrations. La stabilité de l’application et la maturité des démonstrateurs augmentant avec le temps, nous avons progressivement allégé le process.

Un exercice de communication

La démonstration est un exercice de communication : ne pas hésiter à expliquer le fonctionnel en illustrant de use cases de la vraie vie, car toutes les personnes du projet ne connaissent pas forcément le domaine/vocabulaire de tous les composants de l’application. Ne pas hésiter non plus à masquer les détails techniques : ils pourront être abordés si des questions en offrent l’occasion.

A ce titre, on respectera également les règles relatives à toute présentation en public :

• limitation du nombre de démonstrateurs : 2 ou 3
• s’assurer que tout le monde voit les manipulations du démonstrateur et l’entend : mouvement de souris lents et connexion avec les équipes délocalisées notamment
• énoncer l’histoire avant de dérouler le scénario permet à l’auditoire de comprendre
• rythme et temps passé
• etc

Impacts et effets collatéraux

Dans des projets possédant plusieurs équipes dédiées à des composants distincts, c’est un très bon moyen d’améliorer la connaissance de tous les acteurs projets sur les aspects fonctionnels du produit. Même sans savoir comment en mesurer l’impact immédiat sur le projet, on peut sans trop de mal imaginer qu’on est plus à même de prendre des décisions adéquates lorsqu’on possède une meilleure connaissance de son environnement !

Même si cet article a pris pour exemple un projet Scrum, la réalisation d’une démo régulière et les lignes directrices de sa préparation présentées ci-dessus ne sont bien sûr pas spécifiques au mode Scrum ! Vos équipes, votre sponsor ne pourront vous être que reconnaissants de présenter leur produit !

Dissocier démo et fin de sprint ?

Nous avions choisi de suspendre les déploiements automatiques de l’environnement de développement pour éviter des éventuelles régressions. Mesure radicale, au grand dam des testeurs qui se retrouvaient ainsi presque 24h sans voir l’application évoluer.

On peut imaginer d’un autre côté dissocier démo et fin de sprint : en faisant une image de l’environnement de développement à la fin du sprint pour la transférer sur un environnement de démo, il serait inutile alors de geler l’environnement de dev le temps de la démo.

Avez-vous pu expérimenter cela dans vos équipes ? Quel(s) retour(s) en avez-vous retiré ?

En conclusion, une démonstration réussie n’aura que des bénéfices sur le projet. Dans le cas du projet pris comme exemple pour cet article :

• L’état du projet a été visible de tous : chacun a pu voir ce qui fonctionnait
• Le product owner était rassuré sur le contenu fonctionnel du projet
• L’émulation créée a été sensible immédiatement
• Chacun a pu faire reconnaître son travail publiquement par l’équipe

Enfin, même si cet article a pris pour exemple un projet Scrum, la réalisation d’une démo régulière et les lignes directrices de sa préparation  présentées ci-dessus ne sont bien sûr pas spécifiques au mode Scrum ! Vos équipes, vos sponsors ne pourront vous être que reconnaissant de présenter leur produit.

Suggestion d'articles :

1. Animer des rétrospectives d’itération

UPDATE : Cette formation se déroulera finalement le 12 et 13 mai

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

Le « Test Driven Development » est une pratique de développement issue d’eXtreme Programming, dont le but consiste à améliorer la productivité et la qualité des développements en écrivant les tests avant l’implémentation d’une fonctionnalité. Ceci permet de construire conjointement et justement le logiciel ainsi que sa suite de tests de non-régression. Le principe du TDD est le suivant: écrire un test qui échoue, écrire du code pour que le test fonctionne, remanier le code écrit, puis recommencer.

Nous vous proposons une formation de deux jours pour pratiquer le TDD, par le biais de différents ateliers de programmation.

La prochaine session aura lieu le 12 et 13 Mai. Inscrivez-vous sur notre site dédié à la formation : http://formation.octo.com/methodologie/tdd/inscription-tdd

OCTO étant un organisme de formation, ce stage peut être pris en charge par le DIF.

Programme

1ère journée

• Présentation de TDD, premier atelier de programmation collectif
• Présentation Acceptance Test Driven Developpement (ATDD), puis deuxième atelier de programmation collectif
• Bilan de cette première journée

2ème journée

• Premier atelier pour apprendre comment continuer à pratiquer TDD, même avec des frameworks complexe (type Spring et Hibernate)
• Présentation des problématiques de code « legacy », et atelier de programmation collectif pour apprendre à tester ce genre d’application. Le code étudié pourrait être le vôtre ! Contactez nous deux semaines à l’avance pour en savoir plus.
• Bilan de cette deuxième journée

Suggestion d'articles :

1. Formation TDD le 24 et 25 Octobre
2. Formation au Test Driven Developpement le 5 et 6 juillet : Apportez votre Code !
3. Formation Silverlight Tour à Paris – 22, 23 et 24 Novembre

Afficionados de méthodes agiles, voici venue iDailyScrum : une application mobile spécialement conçue pour vous aider à améliorer vos daily Scrums tout en leur conférant un côté plus fun !

En combinant un chronomètre et l’outil de management préféré du consultant OCTO, j’ai nommé la « Boite à Meuh », iDailyScrum vous rappellera sans ménagement lorsque le temps de parole est dépassé ou lorsqu’une conversation privée vient polluer votre stand-up.

iDailyScrum est disponible gratuitement sur iPhone et WindowsMobile.

Suggestion d'articles :

1. OCTO partage ses bonnes pratiques dans le livre Partageons ce qui nous départage
2. OCTO Talks! disponible sur l’AppStore !
3. Partageons ce qui nous départage : le livre est sorti !

Les méthodes agiles recommandent la colocalisation des acteurs (i.e. une localisation physique dans un même bureau) pour une meilleure communication, une meilleure collaboration et globalement une équipe ou un processus projet plus performants. Par exemple Ken Schwaber dans The Enterprise and Scrum :

« High-bandwidth communication is one of the core practices of Scrum… The best communication is face to face, with communications occurring through facial expression, body language, intonation, and words. »

Que disent les sciences de ce sujet aujourd’hui âprement discuté dans la communauté agile et ô combien toujours délicat à mettre en œuvre dans les faits ?

Ce principe de colocalisation fait débat dans la communauté agile, maintenant que les méthodes agiles, en passe de devenir « mainstream », sont déployées bien au-delà de « petites » équipes colocalisées.
Même dans le cas d’équipes « colocalisables » dans les faits, on mesure la distance de la coupe aux lèvres lorsque les organisations doivent faire le pas et que les obstacles se dressent, notamment :

• une remise en cause délicate des frontières organisationnelles dès lors que des acteurs de différents silos sont amenés à partager au quotidien un même espace de travail (ex : MOA/MOE/marketing/intégration/exploitation…);
• des demandes d’aide pour le moins fastidieuses vis-à-vis des tout puissants « services généraux » ;
• un impact sur l’ensemble des acteurs projet, au-delà de la population des développeurs, seule astreinte aux nouvelles disciplines comme le pair programming, TDD ou l’intégration continue.

Les multiples réticences à la mise en place d’équipe colocalisées ou le débat au sein de la communauté agile doivent nous inciter à étayer notre discours plus solidement que « c’est une bonne pratique agile qui est indispensable/facultative » ou « la colocalisation/non-colocalisation a bien/mal marché dans nos projets précédents ».

A cette fin, les très nombreuses études scientifiques dans ce domaine sont une source quasi jamais explorée dans les communautés agile et lean. Par exemple, la psychologie sociale, discipline hautement empirique ou des disciplines plus spécialisées comme le domaine du Computer Supported Collaborative Work (CSCW), ont accumulé depuis plus de 30 ans les expériences, études et publications sur l’efficacité de la communication et de la collaboration en fonction de la distribution physique des membres de l’équipe.

Un résultat classique : la courbe d’Allen

Thomas Allen, professeur au MIT et auteur de l’ouvrage de référence Managing the Flow of Technology en 1977, a étudié la probabilité de communication au sein d’une équipe en fonction de la distance.

Le profil de la « courbe d’Allen » est une décroissance exponentielle dont on peut extraire quelques points représentatifs :

• au-delà de 9 mètres, il y a moins d’une chance sur 10 pour que 2 acteurs communiquent une fois dans la semaine ;
• il y a deux fois plus d’échanges pour 2 acteurs séparés de 10 mètres que pour 2 acteurs séparés de 20 mètres.

Par exemple, 2 acteurs situés dans deux bureaux même proches (disons à 20 m) auront 2 fois moins d’échange que 2 acteurs à 10 m de distance sur un même plateau.

Et chez vous ?

• Quels sont vos 3 interlocuteurs privilégiés ? A quelle distance sont-ils de vous ?
• Dans vos équipes projet, quelles sont les distances entre des interlocuteurs proches dans la chaîne de valeur (par exemple : marketing=>MOA=>MOE=>intégration=>exploitation) ?

Oui mais l’email, l’instant messaging, la vidéo ?

Les moyens de communication modernes (email, IM, vidéo conférence) largement déployés depuis les premiers résultats de Allen ont-ils remis en cause l’importance de la distance ?

Pas vraiment… voire c’est tout le contraire qui apparait au fil des études puisque la probabilité d’interaction par ces nouveaux moyens de communication est corrélée à la distance. Ainsi, Allen dans son ouvrage récent (2008), The Organization and Architecture of Innovation :

« We do not keep separate sets of people, some of which we communicate in one medium and some by another. The more often we see someone face-to-face, the more likely it is that we will telephone the person or communicate in some other medium. »

Google, encore Google…

Une étude à grande échelle basée sur un marché de prédiction et menée dans les centres de Google, confirme les résultats classiques de Allen.

Un des auteurs de l’étude, Justin Wolfers, commente les résultats de l’étude :

« Sitting within a few feet of a workmate has a big effect. (Our data includes the exact GPS coordinates of each person’s desk, as well as their previous desks.)
Beyond this, sitting on the same floor as someone barely has any effect.
[…]
The overwhelming importance of “micro-geography” was quite striking, particularly as this is the sort of organization in which Instant Messaging and e-mail (plus blogs and wikis) might have otherwise suggested the death of distance. »

Eric Schmidt, CEO de Google, n’a pas attendu les résultats de cette étude pour souligner l’importance de la colocalisation. Pour preuve la 3ème règle (« Pack them in ») des Google Ten Golden Rules.

« The best way to make communication easy is to put team members within a few feet of each other. The result is that virtually everyone at Google shares an office. This way, when a programmer needs to confer with a colleague, there is immediate access: no telephone tag, no e-mail delay, no waiting for a reply. »

A cet égard, le modèle Google et sa confirmation par l’étude expérimentale éclaire d’autant plus nos propres contextes IT :

• Les employés Google ont a leur disposition tous les outils de communication technologiques possibles et imaginables (faisons l’hypothèse qu’ils savent les utiliser correctement) ;
• Le métier de Google ressemble de près ou de loin au métier de nos équipes projets (i.e. concevoir et construire vite et bien de nouveaux produits IT) ;

Effet de la distance sur la collaboration, le mensonge et la recherche de compromis

Les résultats évoqués jusqu’ici concernent la probabilité de communication en fonction de la distance. D’autres études en psychologie sociales se sont attachées à mesurer les effets de la distance sur la propension à collaborer, tromper son interlocuteur ou trouver efficacement des compromis.

Ainsi, dans l’étude Why Distance Matters :

« First, the data strongly indicates that the geographic distance between collaborating and previously unacquainted partners matters. The ability to persuade another and the willingness to initially cooperate decrease with distance while deception of another person increases with distance. »

Au passage, cette étude balaie aussi l’espoir parfois mis dans des outils technologiques plus « riches ». Ainsi, la qualité de la collaboration, la propension au mensonge et aux compromis, sont sensiblement les mêmes que les acteurs utilisent un simple « instant messaging » ou la vidéo conférence.

Conclusion

Les résultats cités dans ce post dépassent le cadre des méthodes agiles ou même du développement logiciel : tous les « jeux » collaboratifs, créatifs et innovants (notamment tous les types de « new product development ») retireront énormément de la co-localisation.

Les disciplines scientifiques comme la psychologie sociale peuvent nous fournir des résultats expérimentaux probants à la fois dans le débat au sein de la communauté agile mais surtout comme argument de poids dans la mise en place d’équipe colocalisées. Le lecteur intéressé par les détails des protocoles et des données expérimentales recueillies pourra se reporter aux études pointées tout au long du post.

Suggestion d'articles :

1. Devons-nous changer de paradigme pour le développement d’applications informatiques?
2. Espace détente
3. Et si nous définissions simplement le Cloud Computing !

« Scrum sans itérations ? » un concept étrange que d’imaginer une méthode itérative sans itérations … Et pourtant nombre de blogs de l’écosystème agile présentent Kanban, un processus par définition non itératif, comme une évolution intéressante pour les projets Scrum.

L’objectif de cet article est donc d’illustrer comment ces deux approches, d’apparence contradictoires, peuvent se compléter pour le plus grand bonheur de nos utilisateurs ! L’article s’adresse à des lecteurs déjà sensibilisés à Scrum, si vous ne connaissez pas ce kit méthodologique, Wikipedia est un bon point d’entrée.

Quelques illustrations de cet article ont été récupérées de l’excellent blog de Henrik Kniberg.

Les limites de Scrum

Lorsqu’une équipe devient mature sur l’utilisation de Scrum (et ceci peut prendre du temps !) elle commence à en discerner les limites. Pour ma part, voici celles que j’ai pu constater après quelques années de Scrum sur différents projets, et surtout les solutions que nous avons trouvé à l’époque pour y remédier.

• La première frustration était l’impossibilité de changer le backlog de Sprint lors du Sprint. « It’s not a bug, it’s a feature » me direz-vous ! En effet il s’agit d’une mesure destinée à protéger les équipes de développements des changements de dernière minute nuisant à la productivité globale. Néanmoins, que deviennent ces fonctionalités cruciales qui devraient VRAIMENT rentrer en cours de sprint ? Il y a des chances qu’elles prennent la file d’attente … dommage ! On finit donc par autoriser des arbitrages sur le contenu du sprint en cours de sprint (du type : je remplace une user story par une autre) [1]
• Et à l’inverse, si une fonctionnalité ne peut pas « rentrer » en cours de Sprint, elle ne peut pas non plus être livrée en cours de Sprint : il faut attendre la fin de l’itération pour rendre la fonctionnalité disponible aux utilisateurs. Quand bien même la fonctionnalité utile est terminée au bout de deux jours de Sprint, il faudra atteindre la fin pour la livrer. Cette fois, la solution apportée par l’équipe projet fut de faire des livraisons intermédiaires en cours de sprint (toutes les semaines, puis toutes les demi-semaines) [2]

Un cas extrême où la rigidité des sprints mène à des gaspillages ("Travail partiellement fait" au sens Lean)

• A ce stade, rares sont les équipes qui n’ont pas eu l’initiative de raccourcir la durée de leurs itérations à une ou deux semaines. Se pose alors la question du rythme soutenable : la flexibilité est là, mais la cadence élevée des rituels projets (les rétrospectives par exemple) plombent la vélocité et le moral de l’équipe. Nouvel aménagement au processus : on choisit de ne tenir les rétrospectives qu’une itération sur deux [3]
• Une autre évolution apportée par l’équipe de développement fut d’intégrer les activités MOA au sprint [4]. En effet depuis peu les développeurs ne partent plus des user stories mais de spécifications exécutables, rédigées en binôme avec un MOA.
• Enfin l’équipe s’est rendue compte qu’à chaque évolution majeure de l’architecture de déploiement (nouveau composant, nouveaux fichiers de configuration, nouveaux flux à ouvrir …) la mise en production peut être problématique et se solder par un retard de quelques jours. Qu’à cela ne tienne, désormais à chaque livraison jugée sensible un développeur sort du Scrum pour binômer avec un membre de l’exploitation [5]

Après réflexion on se rend compte qu’aucune de ces situations n’était vraiment insoluble. Après micro-ajustements successifs nous avons réussi à contourner l’ensemble de ces limitations. Mais cherchons maintenant à tirer un enseignement de ces améliorations en identifiant les signaux faibles qu’elles portent et en les amplifiant :

• En amplifiant le signal [1], nous imaginons un projet où les responsables produit peuvent réarbitrer à volonté la liste des user-stories en développement.
• Le signal [2] nous apprend que nous souhaiterions pouvoir livrer toujours plus souvent des incréments logiciels toujours plus petits.
• L’amélioration [3] témoigne du besoin de décoreller totalement les rituels qui rythment la vie du projet des cycles de développement et de livraisons de fonctionnalités.
• Amplifier les signaux [4] et [5] illustre notre volonté d‘élargir l’équipe de développement à tous les acteurs impliqués dans la livraison d’une nouvelle fonctionnalité.
• Pour finir le signal [5] nous apprend que l’on peut minimiser les goulets d’étranglement en réaffectant les membres de l’équipe projet d’une activité à une autre.

Et devinez quoi ? Combiner ces signaux amène tout droit notre équipe vers un processus de type Kanban.

Kanban à la rescousse

kanban est une pratique Lean. Avant d’aller plus loin, je vais tenter de définir ces termes.

Tout d’abord le Lean Management est la vision industrielle de Toyota qui prône :

• Un amaigrissement (lean) perpétuel des processus par chasse aux gaspillages. Ces optimisations contribuent à l’amélioration continue des standards de l’entreprise.
• Une vision globale de l’objectif de l’entreprise. Le Lean va donc favoriser la recherche de l’optimum global (tandis que la quête d’optima locaux peut parfois être contre-productive).

Je ne m’attarde pas sur les autres valeurs Lean qui ne servent pas directement mon propos, mais je vous encourage à lire cet article.

Quant à kanban (avec une minuscule), il s’agit d’un outil de gestion des chaines de production créée par Toyota en respect des valeurs Lean. Lorsque l’on parle de kanban on parle de « flux tiré » : le principe étant que dans une chaine de production, après avoir traité un élément, chaque étape demande à l’étape précédente de lui fournir un autre élément à traiter, quelque soit la taille du stock de pièces qui lui reste à traiter. Cela crée un flux de demande qui remonte le flux de création de valeur, depuis la demande client jusqu’à la première étape du processus.

Ce schéma illustre l'utilisation de tickets kanban pour limiter l'encours : s'il n'y a plus de tickets disponibles dans la phase "Allocate" le processus est bloqué. Signe qu'il faut améliorer le processus pour récupérer un ticket plutôt que d'augment le flot de demandes.

De cet outil inventé par Toyota est né Kanban (avec une majuscule), une méthode agile

• De visualiser la chaîne de valeur dans son ensemble : de la demande initiale jusqu’à la livraison (on retrouve bien le principe Lean d’optimisation globale). Et ceci afin de minimiser le temps de cycle (le temps que mets un élément à parcourir toute la chaîne).
• De limiter l’encours (ou WIP, Work In Process) par distribution de tickets Kanban. Pourquoi limiter l’encours ? Car il s’agit de la meilleure manière d’optimiser le temps de cycle. Si ce point précis vous interpelle, je vous suggère de lire cet article sur la loi de Little.

C’est super ces principes industriels, mais on peut revenir à Scrum et au développement logiciel ?

Ok, établissons maintenant un parallèle entre Scrum et Kanban :

• Scrum est centré sur les activités de développement et ne permet pas d’avoir une vision globale de la chaîne de valeur. On se rend compte que les activités en amont de la chaîne (comme la rédaction de user stories) ou en aval (comme la mise en production de livrables logiciels) sont totalement exclues du périmètre de Scrum.
• Il est difficile en Scrum de mesurer et d’optimiser le temps de cycle. Et ceci à cause même des itérations
• En revanche la vélocité de sprint Scrum correspond bien au concept de limitation de l’encours : le nombre de fonctionnalités en entrée d’un sprint correspond aux nombre de fonctionnalités traitées lors du dernier sprint.

Donc j’arrête Scrum et je mets à Kanban ?

Non car Kanban n’est pas à proprement parler une méthodologie de développement logiciel : Kanban est beaucoup moins prescriptif que Scrum et est donc beaucoup plus difficile à appliquer en partant de zéro.

A mon sens, il faut considérer Kanban comme une évolution possible de certains projets Scrum atteignant des limites « aux frontières » des sprints. Voici pour moi la transition d’un projet Scrum en Kanban :

• Les débuts et fin de sprint de moins en moins marqués conduisent à la suppression des itérations. En revanche le rythme trouvé par la dynamique des sprints est conservé : stand-ups, rétrospectives, brainstorms …
• Le tableau Scrum (qui devient un tableau Kanban) voit ses activités étendues : de la définition du besoin à la mise en production.
• Le process est continuellement alimenté en nouvelles demandes (dans la limite de l’encours) et non plus seulement au début de chaque itération. De plus le tableau Kanban n’est plus jamais réinitialisé.
• Le rythme de vie de l’équipe (les rituels projets : stand-ups meetings, rétroscpectives) est décorellé du cycle de développement et de livraison
• Les incréments logiciels livrés sont désormais des fonctionnalités unitaires (des MMF). Ceci n’emêche pas d’organiser le regroupement des MMF au sein de releases cohérentes

Comparaison de calendriers Scrum et Kanban : si les itérations ne sont plus là, l'esprit itératif y est toujours !

Je vous encourage vivement à jeter un oeil sur ce strip qui illustre de la meilleure de manière comment un tableau Kanban vit (pour votre compréhension le chiffre en haut des colonnes indique l’encours maximal pour une activité : ici pas plus de 2 tâches en développement en simultané)

Non vraiment allez voir ce strip avant de poursuivre la lecture de l’article, c’est très pédagogique :)

De l’agilité à monter soi même

En conclusion j’ai repris ce titre d’une session de Laurent Bossavit qui me parle particulièrement.

De nombreux blogs ont déjà rabâché le fait de ne pas sectariser l’utilisation de Scrum plutôt que XP mais plutôt d’habilement mêler les pratiques de l’un dans le process de l’autre. De la même manière je pense que le passage à Kanban doit uniquement être une source d’inspiration pour des projets agiles (Scrum ou non) qui atteignent aujourd’hui des limites que les seules pratiques agiles ne peuvent résoudre.

Quels bénéfices attendre d’une Kanbanisation de votre projet ? Principalement :

• Une identification et une résolution plus aisée des gaspillages et des goulets d’étranglement
• Une flexibilité accrue et une capacité d’arbitrage plus importante
• Au final, un débit de livraison plus élevé

Mais attention, la mise en oeuvre de Kanban est exigeante et requiert des équipes déjà particulièrement matures sur les valeurs lean et les pratiques agiles. Voici à mon sens quelques unes des qualités exigées pour se lancer dans l’aventure Kanban :

• Une grande rigueur dans le suivi des rituels projets, notamment stand-up-meetings et rétrospectives.
• Une capacité à embarquer et à impliquer au plus tôt tous les acteurs participant à la chaîne de valeur logicielle.
• Une capacité à apprendre de l’existant pour améliorer les standards. Par exemple Kanban ne préconise pas les activités à suivre ni les encours à fixer : expérimentez, apprenez et améliorez !
• Sensibilisation au principe lean « build quality in » qui consiste à ce qu’une tâche soit réalisée en une fois avec la qualité maximale (avec tests unitaires, documentation …) sans que l’on ait à revenir dessus. En Kanban, lorsqu’une fonctionnalité est terminée, elle est livrée (tandis qu‘une itération fournit une sécurité de quelques jours)
• Gestion de configuration logicielle éprouvée. Etes vous capable avec votre gestion CVS ou Subversion de livrer vos fonctionnalités indépendamment les unes des autres ?

Alors … saurez-vous franchir le pas de faire du Scrum sans itérations ?

Pour aller plus loin

Je vous ai déjà matraqué de liens tout du long de cet article, néanmoins voici quelques lecture intéressantes pour approfondir le sujet :

• Implementing Lean Software Development, de Mary et Tom Poppendieck
• Kanban vs Scrum, un livre blanc signé Henrik Kniberg
• http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
• http://leansoftwareengineering.com/ksse/scrum-ban/
• Le blog de David Anderson (référence et instigateur de la méthode)
• Le groupe de discussion Yahoo
• Le site de la federation des initiatives « WIP oriented »

Suggestion d'articles :

1. La faute à Scrum
2. Compte-rendu de la soirée d’inauguration du French Scrum User Group
3. Installer Scrum sur une organisation existante