Agile, est-ce pour moi ?

Il y a toujours beaucoup de préjugés auprès des gens lorsqu'on veut leur parler de se lancer ou simplement adopter les méthodologies Agiles. Souvent leur premier réflexe est de répondre que les méthodologies Agiles ce n'est pas pour eux.

Combien de fois, un programmeur ou un analyste, m'a faites cette affirmation! Je ne le compte plus.

Donc, essayons de réfléchir à qui s'adresse ces approches Agiles.

Est-ce qu'ils ont raison ? Dans les faits, leur analyse n'est pas tout à fait fausse. Car, leur affirmation est souvent relatif à la dérivation SCRUM des approches Agiles.

Donc, affirmer que SCRUM n'est pas pour soi. Cette affirmation n'est pas fausse. Il existe plusieurs méthodes qui dérivent des principes du manifeste Agile. Chacune d'entre elles adresse à une série de problèmes. Certaine sont plus adapté à la gestion projet (la gestion des livraisons), ex : SCRUM. Mais, il en existe plusieurs autres.

Il faut choisir selon le contexte de notre environnement ou tout simplement de son travail à effectuer ! Par exemple, si nous sommes une ou deux personnes, sur un projet. Il n'est pas nécessaire d'utiliser Scrum (Scrum demande une équipe de 5 à 9 personnes) . Cette équipe n'a pas besoin d'une gestion complète de projet. L'utilisation d'une approche qui lui permettrait de produire une meilleure qualité du code et qui automatiserait certaines tâches routinières. Je crois, serait plus approprié. Il pourrait utiliser des approches comme Test Driven Developpement (TDD) et BDD (Behavior Driven Developpement) pour définir les différents besoins qu'ils doivent couvrir dans l'application développement.

Prenons, un autre exemple. Une petite équipe (5 à 9 personnes) de développement qui cherche à construire une application commerciale (Software in boxe). Cette fois-ci, le besoin est différent. La simple utilisation des 2 méthodes précédemment citées (TDD et BDD), ne suffit pas. L'ajout d'une méthode de gestion de projets ou des livraisons comme SCRUM ou SCRUMBAN pourrait intéressant.

L'utilisation des méthodologies Agiles, dans ses projets, est accessible à tout le monde. Que nous soyons chargés de projet, Analystes ou même programmeurs. Il suffit de prendre la méthode qui correspond à notre besoin.

Donc, lorsqu'on m'affirme que les méthodologies Agiles ne sont pas pour eux. Ils ne peuvent pas utiliser ou appliquer, les méthodologies Agiles. Il faut (et au besoin se faire aider) prendre le temps de trouver la méthode qui nous convient. Et si on ne trouve pas, dans une seule méthode, ce qui nous convient. Il ne faut jamais hésiter d'en prendre une comme base, ex scrum (si nous sommes une équipe) et la complémenter avec une autre selon le besoin qu'on veut couvrir.

Donc, affirmées que les méthodologies Agiles ne sont pas pour nous, signifie seulement que la connaissance ou l'analyse des approches Agiles qu'on a faites sont insuffisantes. Comme dans toutes choses, il faut prendre le temps d'analyser, de se documenter.

Aujourd'hui, demain et dans l'avenir, les méthodologies Agiles sont là pour rester. Donc, nous devons s'y préparer ! Chacune sa méthodologie et les projets agiles iront encore mieux !

Mes petites résolutions Agiles pour l’an 2010.

Quelle belle tradition que sont les résolutions du Nouvel An. J’ai eu donc l’idée de vous partager aujourd’hui quelque une de mes résolutions pour ce Nouvel An. Mais, surtout un pour une année que j’espère où les méthodologies agiles prendront encore plus la place qui lui revient.

La première, nous (Moi, mon organisation, vous, tout le monde) à parler avec le plus de justesse possible des méthodologies Agiles. Quand nous voulons être une référence, il faut toujours vérifier ses affirmations et les baser sur la vérité, une vérité vérifiable.

La deuxième, dépassé plus que la simple formation. Travailler avec les gens pour les accompagner à s’accaparer les méthodologies. Je crois que pour les méthodologies Agiles, prend la place qu’elles méritent. Les gens doivent s’accaparer un peu comme leur langue maternelle.

La troisième, accompagner les gens ainsi que leur organisation, dans leurs choix et leurs transitions vers les méthodologies Agiles. Si vous le ne savez pas encore, choisir d’effectuer ce virage n’est pas une chose facile. Donc, les gens ont besoin de notre aide, mais surtout de notre accompagnement.

La quatrième, continué, continué à expliquer, mais surtout à ÉCOUTER les gens qui s’intéresse aux méthodologies agiles. Comme dit le bon vieux proverbe, on a deux (2) oreilles et une bouche. Donc, on doit écouter deux (2) fois plus !

Et une petite dernière, essayez juste un instant de penser différemment, de pensée Agile.

En terminant, permettez-moi de nous souhaiter à tous une bonne et heureuse année, mais surtout très Agile.

Agile, de Haut jusqu’en bas, et Droite à Gauche.

Beaucoup d’organisation qui se lance dans les méthodologies Agiles, oublie un facteur important dans leur adaptation de ces nouvelles approches.

Beaucoup d’organisations qui démarrent un petit projet pilotent en Agile dans une équipe de développement. Oublie souvent, trop souvent, l’impact que cela peut avoir sur leur organisation.

Tout passage Agile, même au sein d’une petite équipe de développement aura un impact sur l’organisation tout entier.

Traditionnellement, les équipes de développement étaient dynamiques. C'est-à-dire qu’à tout moment, et souvent selon besoin momentané de l’organisation, être totalement réorganisés ou restructurés. Aux files du besoin ou des changements de l’organisation, les membres de l’équipe peuvent changer ou être remplacés durant la vie du projet. Mais, l’une des règles importantes en Agile, c’est justement l’intégrité de l’équipe. Normalement, il est très souhaitable que l’équipe reste intègre du début jusqu’à la du projet.

Donc, cela a un impacte direct sur la gestion des ressources disponibles. Chaque membre s’engage en tant qu’individu et aussi à titre de membres de l’équipe à livrer une série de composantes. Donc, s’il manque une ou plusieurs personnes dans l'équipe, l’engagement ne peut plus tenir !

Le second impact, est la disponibilité de la personne qui joue le rôle de product owner (méthodologie Scrum). Cette personne est aussi importante que tous autres membres de l’équipe. Il n’est jamais facile de libérer cette personne à cause de son expertise et sa connaissance du domaine d’affaires de l’entreprise.

Mais pour acquérir cette expertise, ça veut dire aussi qu’il occupe une place importante au sein de l’organisation. Donc, il occupe une fonction qui peut-être difficile à redistribuer ou à replacer.

Le dernier problème qu’il est difficile de réaliser avant sa mise en place. C’est la livraison fréquence et surtout beaucoup plus rapide de morceaux d’applications fonctionnelles. C’est bien beau sur le papier, mais en pratique, il apprendre à le gérer ces livraisons fréquentes. Avoir une application à tester tous les 6 à 12 mois, les organisations sont habituées. Mais, en avoir a testé, tous les 2, 4 ou 6 semaines, ce n’est pas la même chose.

Comme vous le voyez, se lancer dans un processus de mise en place des méthodes Agiles, impacte bien de haut et bas, et de droite à gauche l’organisation.

Bien entendu, l’impact pourra varier d’une organisation à une autre, mais l’expérience m’a démontré qu’elle dépassera l’équipe qui l’implémentera dans son projet de développement. Mais, une chose est sûre, il y aura un impact plus grand que seulement que dans l’équipe de développement.

Je sais vous aller dire que je prêche pour ma paroisse. Mais, je vous recommande de vous joindre une personne d’expériences, une personne qui a tant de l’expertise technique en méthodologie Agile. Mais, qui a aussi de l’expérience en contexte organisationnel. Autrement dit-on bon mélange entre l’expertise organisationnelle (monde des affaires) et l’expertise en implémentation des approches Agiles.

En terminant, rappelez-vous que vous faisiez des affaires avant l’implémentation des méthodologies Agiles et que vous devriez en faire encore après !