Ergonomie, Rails et Architecture de l'information web (2.0)

Vous pensez territoire

Vous marquez votre territoire comme un chien de garde, refusez de partagez pouvoir ou information, et faites un scandale chaque fois que vous n’avez pas été inclus dans un cycle décisionnel. L’innovation vous fait peur, et vous avez tendance à éviter ou étouffer dans l’oeuf toute tentative de changement de l’ordre établi.

Vous êtes inflexible

Vous avez une méthodologie pour tout et n’importe quoi. Tout ce qui n’est pas dans vos livres n’existe tout simplement pas. C’est comme ça que vous avez toujours fait, et vous ne voyez pas pourquoi ça changerait.

Détestez l’incertitude

Dans un projet agile, vous ne saurez bien souvent pas la date de sortie du produit, ou même quelles fonctionnalités seront ajoutées dans la prochaine itération. Vous ne supportez pas cela, et exigez des planning strictes, et des coûts gravés dans le marbre longtemps à l’avance.

Traitez les développeurs comme des ressources

Vous considérez les développeurs comme des ressources uniformes et remplaçables. Après tout, ils sont tous pareils non ? Impossible de leur faire confiance, c’est à vous de faire tous les arbitrages et prendre les décisions importantes à leur place.

Considérez le développement comme un processus linéaire

Vous ignorez purement et simplement les feedbacks négatifs. Au lieu de que les prendre en compte afin d’améliorer le produit, vous vous en tenez à ce qui a été strictement planifié, comme un politicien dans un empire dirigé par des militaires.

J’ai passé plusieurs années sur des projets répondant très exactement à ces traits de caractère, et bien que j’y ai beaucoup appris, ce n’est pas une expérience dont je garde un souvenir impérissable, et je rejoins tout à fait Andy dans sa description. Cette dernière est symptomatique des gros projets lancés par les de grandes entités marquées par l’inertie administrative et la multiplicité des intervenants.

Comme exercice, je vous propose de confronter vous, votre entreprise ou votre structure à l’ensemble de ces points. Si vous répondez “oui” à au moins la moitié des questions, vous n’êtes clairement pas prêt à passer aux méthodes agiles. Afin de comprendre les risques que cela vous fait courir à termes, pourquoi ne pas commencer par lire la thèse de Crozier ? Dans le cas contraire, pourquoi ne tentez-vous pas le passage aux méthodes agiles, si ce n’est pas déjà fait ?