Quels critères d’acceptances pour les projets agiles ?

Il est fréquent que dans les plans de transition agile figure des « critères d’acceptances » pour fixer si tel ou tel projet au sein de l’entreprise… pourra être géré (ou non) en agile. Par exemple, j’ai vu récemment, les critères suivant pour qu’un projet puisse être géré en agilité :

  • les requirements sont flous ou manquent de clarté ou de detail
  • le Product Owner peut liberer 80% au moins de son temps a l’equipe
  • l’architecture doit être mature

Peu importe si ces critères sont justifiés ou non, ce qui est gênant c’est qu’on confond « critère de selection » et « contrainte d’application ».

Critère de sélection n’est pas contrainte d’application

Le problème est que ces critères sont définis à partir d’une culture et d’un cadre d’une organisation traditionnel. Si j’applique l’agilité sur ce projet dans mon organisation traditionnel, ça fait quoi ? mais justement … on veut faire de l’agile ou pas? ?

Disons qu’il est naturel de vouloir se fixer un cadre pour répondre aux projets : « ton projet ne corresponds pas, tous les risques sont cumulés pour appliquer correctement l’agilité »… Disons que tout n’est pas si simple.

Faisons une métaphore, imaginez que vous désirez vous rendre autonome dans vos déplacements de tous les jours… acheter une voiture ! oui certes mais vous n’avez pas le permis et en plus vous n’avez pas beaucoup d’argent !

Que faire … Tout d’abord passer son permis…! ça parait légitime car c’est investissement sur la durée, quasi indispensable… et ensuite acheter une voiture. Si vous n’êtes pas fortunés vous allez certainement acheter à crédit (surtout la première).

Si vous aviez à faire votre choix par rapport à des « critères d’acceptances », comment cela aurait-il fait changer votre projet ? ça se serait certainement passé autrement, car vous auriez eu :

  • critère no 1 : le véhicule doit se conduire sans permis
  • critère no 2 : l’investissement du véhicule doit être très léger et correspondre à mon pouvoir d’achat

Pourquoi ce n’est pas cohérent ? car ces critères se basent sur votre capacité organisationnelle, financière, technique, culturelle actuelle. En plus tout le monde le sait les voitures sans permis coutent plus chère :-O

En fait il faut prendre en compte le changement nécessaire pour accéder à ce nouvel outils (formidable). Comme tout nouvel usage, il s’agit de prendre en compte les nouveaux modes organisationnels, et ainsi le nouveau paradigme cible. C’est ainsi que le changement de l’agilité s’opère.

Une fois le permis acquis et le financement obtenu, les nouveaux critères pourraient être :

  • ne pas prendre une voiture trop puissante (car le funki’conducteur risque de rouler trop vite.)
  • prendre un diésel (car le conducteur effectue de longues distances régulièrement)
  • etc..

Je peux exprimer cette incohérence sur un autre axe : imaginez un chef de projet qui désire savoir si son projet peut être agile … vous passez votre moulinette agile et tout est négatif. Vous lui dites « impossible!, le PO n’est pas disponbile, les règles métiers sont compliqués, le projet est important, la technologie est cobol, … tout ça n’est pas très adéquat pour l’agilité. Mais si ce chef de projet a vraiment besoin de l’agilité ?  priorisation de la valeur, livraison fréquente … en dehors des contraintes structurel qui peut l’empêcher ? pourquoi ne pourrait on pas opérer ce projet en agilité ?

L’application de l’agilité sur un projet doit se baser sur des attentes et non sur des contraintes

Disons qu’il faudra plutôt mesurer l’attente, la motivation et pourquoi pas la capacité au changement de l’équipe à passer au nouveau mode opérationnel agile. ça serait plutot des critères subjectifs qu’objectifs ? certainement ! De toute façon il s’agit de comprendre l’agilité par l’équipe concernée et de déterminer elle-même si elle cela va lui apporter de la valeur.

L’application de l’agilité s’inscrit dans un décalage organisationnel, culturel, humain & technique, du coup nos critères habituels (issus d’un paradigme traditionnel) ne sont pas valables. Il s’agit de se fixer dans le contexte cible agile, et ensuite on vérifie si on peut atteindre cet objectif. 

Bref .. Enter the matrix! :

Voici quelques idées (que je n’ai jamais appliqué tel quel). Un projet peut aborder l’agilité, si :

Attentes : 

  • Le besoin en exploration/expérimentation fonctionnelle est forte
  • Il y a un fort besoin de valeur opérationnelle rapide
  • Il y a un fort besoin de réduction des risques techniques
  • Il y a un fort besoin de piloter le projet par la valeur

Motivation:

  • le responsable de projet maitrise les principes agiles et est très motivé à initier l’agilité
  • Le manifesto et la philosophie agile sont compris et appliqués

Capacité au changement :

  • Le product owner / le scrum  master / responsable ont les capacités de faire face aux difficultés hierarchiques et politiques lié au changement
  • Le travail en collaboration, en communautés au sein de l’entreprise sont déjà utilisés.

Si vous avez des idées.. ?

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s