Agile fait référence aux méthodes dites Water fall où tout était planifié longtemps d’avance. Avec une méthode agile, tu peux revoir tes priorités à chaque sprint et t’adapter aux changements dans les besoins. C’est certain que si vous passez d’un processus ad hoc vers scrum, tu auras l’impression de perdre en flexibilité, mais tu gagneras en productivité.

Ici, je pense que cela dépend des projets. Certains projets n’ont pas le scope nécessaire pour justifier de “scrumer” alors que d’autres sont tellement imposants qu’on ne sait pas trop comment les prendre. Je suppose qu’on manque encore un peu de pratique…

Je me rends compte qu’il y a vraiment un “hype” que je ne voyais pas autour des méthodes agiles!

Le danger que je vois c’est que la notion de SPRINT ne sert plus à rien étant donnée que le délai entre les sprint pour la R&D deviens imprévisible. Sinon on peut le planifier sans problème, on ajoute le délai qu’il faut à l’interieur du sprint. L’idée est justement de mesurer à intervalle régulier fixe, une même équipe pour un même projet (les trois paramètres d’un projet : temps, équipe et contenu).

En réalité, si c’est des éclairs de génies et que ce n’est pas prévisible ni planifiable. Alors dans ce cas là ca deviens un coût fixe intrinsèque au projet qui va uniquement affecter la vélocité en la diminuant. Ce qui est super correct, en réalité ca va représenter la vitesse d’avancement réelle de l’équipe qui se donne à des activités d’R&D lors de la réalisation des User stories. Ca fait partie de l’effort de réalisation réelle de chaque tâche.

Pas besoin de trouver une valeur aux SPIKES et aux CHORES ils n’en n’ont effectivement pas aux yeux du « client » c’est un travail jugé nécessaire par l’équipe sans aucune valeur ajoutée fonctionnelle au produit. Ca fait partie du coût fixe d’un développement logiciel et ca affecte directement la vélocité.

Finalement, je n’ai pas besoin de dire qu’il faut rester critique, vous le faites déjà très bien

Au plaisir, Georges Saad
[focusintelligence.ca]
[blog.focusintelligence.ca]

Le problème avec ces SPIKES et CHORE est qu’ils doivent être planifiés d’avance et être vendus à l’équipe et au PO lors du planning. Hors, lorsque l’on a un éclair de génie, en général on veut l’attaquer rapidement et surtout on ne connait souvent pas le résultat que ça va donner donc c’est pas toujours facile de vendre la tâche au planning surtout au PO. Faire le lien entre toutes nos tâches et leurs valeurs, ça peut être épuisant!!

Une solution simple à ce problème est de laisser un peu de temps libre entre les sprints aux développeurs pour qu’ils puissent travailler sur une idée qui leur tient à coeur. Ensuite, une fois que le concept a été un peu approfondi, c’est généralement plus facile de voir si l’idée vaut la peine d’être poursuivie et si elle vaut la peine d’être “prise” lors du prochain plannng.

C’est peut-être pas scrum mais tant que ça marche, moi ça me va

En ce qui concerne « Le livre dit de faire ca », lors de mes formations j’utilise plutôt le terme « approche » plutôt que méthodologie pour justement éviter l’encapsulation des idées. Mon conseil, serait définitivement de ne pas faire ce que vous trouvez inutile. Le premier principe du Lean est « Eliminate Waste ». Si une activité n’a pas de valeur ajoutée, éliminez-là . Si lors des rencontres, certaines personnes sont aliénées et marginalisées peut-être qu’ils ne devraient pas être à cette rencontre. Restez critiques…

Pour ce qui est de l’innovation, le principe des SPIKE et celui des CHORE existe justement pour ces raisons là . Lors de vos sprint, planifier des activités d’innovation, de découverte et de recherche, il n’y a aucune limitation pour ca…

Bonne continuité et afin de rester au faits de la communauté Agile à Québec, la communauté Agile de Québec (www.agilequebec.ca) offre de belle conférence mensuellement. Au plaisir de s’y rencontrer…

Georges Saad
[focusintelligence.ca]
[blog.focusintelligence.ca]

J’aime ta citation :”Chez DuProprio, Scrum n’est pas une méthodologie agile. C’est une méthodologie de développement réfléchi…”

Quand on se lance en méthodologie Agile, il faut réfléchir comment on va le faire. Il y a beaucoup de livres, de sites de références et même des experts (comme moi). Mais, la meilleure des solutions, c’est la solution que l’équipe a besoin.. !

Comme je dis souvent ..! Il faut trouver la recette qui nous (l’organisation, l’équipe) pour faire des méthodologies Agiles.

Il faut avoir la sagesse, de prendre ou non, ce qui est recommandé.

Je suis heureux de voir, et ce même si ce je ne vous ai pas conseillé directement, que ce je préconise depuis si longtemps porte afin ces fruits quelque part.

Quelqu’un m’a déjà dit, si tu crois fermement à une idée, sème-là au vent. Si elle est bonne, elle poussera sans ton aide quelque part.. !

Donc, mon idée.. N’était pas si folle que ca ..! car, tu m’a démontré.. quelle a données des fruits.. Même si je n’ai rien fait pour cela ..!

Bravo, et surtout continuez d’avoir une méthode agile intelligente.. et surtout bien pensée ..!

Bruno

Le plus difficile je crois ce situe au niveau des développeurs qui sont partagés entre le sprint et d’autres responsabilités. Surtout ceux qui comme moi étaient habitués à plus de liberté de mouvement et qui, trop souvent, faisaient pencher la balance des priorités d’un projet vers un autre…