Entreprise Agile

Entreprise Agile

Ces dernières années, un certain nombre d'entreprise voit échouer leur politique de développement logiciel, et en conséquence admire les modèles "émergeant" qui mettent en pratique l'agilité.
Après des années à vouloir se débarrasser de l'informatique, car trop coûteux, demandant trop de compétences changeantes, des plans de formation coûteux, les sociétés ont adoptés pour la plupart le mode forfait qui consiste à se débarrasser du projet et après un long effet tunnel découvrir un produit ne correspondant pas à leur attente.
Le coût d'achat du projet a bien été réduit, par contre le coût global, sans parler des dérives calendaires, ne sont rarement remontés dans les statistiques.
La honte de l'échec.

Les sociétés, face au mécontement de leur métier, face aux challenges de la concurrence, essayent de revenir à un mode plus collaboratif, et reprendre la main sur leur projet.
Mais après 20 ans, les personnes ont oublié comment travailler, et on retrouve sur les projets, une grande lacune dans la rigueur des spécifications, des tests, des recettes, des cas d'usages.
Les sociétés de service quant à elle, ont prospéré en vendant des profils qui ont comblé cette perte de compétence, le signe AMOA (assistance à maitrise d'ouvrage) est là pour en témoigner.

Les directeurs informatiques enjoignent leur équipe à travailler en agile pour améliorer la réussite de leur projet.
Mais en pratiquant une politique de l'autruche, et en occultant le constat que je fais ci dessus, qui restent des généralités, et sont bien en dessous des problèmes rencontrées par l'entreprise.

L'agilité n'est pas une baguette magique.

La recommandation que je ferai est de lancer un audit processus et méthode dans votre entreprise pour déterminer quelles sont les réelles problématiques que votre entreprise rencontre dans la livraison de ses services.
Peut être que l'agilité peut être une réponse en effet.

On parle beaucoup de transformation digitale. Il faut aussi parler de transformation agile. C'est une conduite de changement à mener.
Vos prestataires sont tous prêts à délivrer plus ou moins bien (convenons en), votre projet en agile (SCRUM par exemple). Par contre, vous, êtes vous prêts à en subir le cadre?

A mon sens, il y a plusieurs transformations à opérer, qui sont à des strates différentes, et qui sont des populations plus ou moins résistantes.
La strate la plus simple à convertir est la strate la plus opérationnelle.

1ere strate : le métier

A votre métier, si vous lui dites, qu'ils auront des demos régulièrement, une pleine visibilité sur ce qui est produit et quand, et qu'en plus ils pourront être impliqués dans le lotissement des fonctionnalités, j'ai peine à croire qu'ils résisteront à cet appel agile.
Je ne dis pas que c'est simple. Ils auront besoin de cadre, de comprendre la structure, d'être rigoureux.
La transparence affichée en terme de vélocité, est aussi une contrainte, qu'ils doivent assimiler. Le timebox comporte une productivité max, et ils doivent être en mesure de prioriser leur backlog, et ne pourront pas pousser des choses en plus au delà de la capacité.
La backlog doit rester fourni, et doit être prête dans le cadre temps fourni. Ils épuisent la capacité de prod de l'équipe, si les éléments ne sont pas prêts, ou s'ils arrivent au fil de l'eau.
Ils doivent fournir des cas d'usage, et doivent participer aux tests dans la structure temps imposé.
C'est un contrat bi partite. L'équipe produit au mieux, s'adapte sans cesse, pour donner satisfaction, et se concentre sur la valeur métier, mais le cadre de fourniture des besoins doit être respecté.

2e strate, les équipes transverses, et les équipes en adhérence.

L'une des difficultés des équipes est de réussir à se synchroniser avec les autres équipes (exploitation, intégration, architecture, .... ou projet en adhérence).
Ces équipes sont souvent pilotés par des jalons, des délais, et l'incertitude ne fait pas partie de leur quotidien.
Bien souvent, le rythme des équipes agiles est souvent un rythme soutenu, avec des livraisons fréquentes. Les équipes transverses ont souvent du mal à suvire le rythme et à s'adapter.
Les outils, les hommes ne sont pas préparés aux changements.
C'est un verrou difficile à déverouiller la plupart du temps, car ils ont souvent un poids important dans l'organisation, et demandent aux autres de s'adapter et pas l'inverse.
Il est possible de conduire un changement dans ces équipes également, en proposant une mise en place de Kanban IT, par exemple, et de mettre en place un diagramme cumulé de flux.
Ce diagramme permet de montrer quels sont les goulots d'étranglement en terme de traitement du livrable, et de pouvoir déclencher des actions de fluidification.

3e strate le pilotage & les managers

Pendant 20 ans, la bataille s'est mené sur l'interprétation de la bible cahier des charges, et de son implémentation complète, et sans réserve.
Aujourd'hui, en agile, le projet se mène en coresponsabilité, et arriver en bout de projet avec la spécification initiale n'est plus un but en soi.
Le management par la terreur n'est plus adapté, il faut changer le mode de travail, et surtout le reporting induit par ce nouveau mode de travail.
Quels sont les bénéfices d'un projet agile? Est ce que cela n'est pas cela qu'il faut mesurer au final?
Je serai très vigileant sur la définition des KPIs à mettre en oeuvre. Ma première recommandation est que le projet étant en coresponsabilité, les KPIs doivent pouvoir adresser tous les acteurs du projet.
On challenge le prestataire, mais on challenge aussi les équipes en interne.
Les kpis les plus souvent demandés, sont autour de la qualité et de la vélocité.
Ce sont des kpis issus de l'ancien mode de fonctionnement.

Je ne parlerai pas réellement de vélocité, mais je suivrai plutôt un indicateur lié à la prédictabilité de l'équipe. On pointe du doigt une notion qui me paraît plus essentiel, que la vitesse pure de l'équipe.
J'aimerai voir la capacité d'agilité du client : est il à niveau dans ce qu'on attend d'un backlog (définition des US de qualité, à temps, priorisé). J'aime aussi ajouter une notion, qui permet de déterminer la vie du backlog.
Finalement, un backlog figé (en quantité et en priorité) représente aussi un échec de l'agilité, ou une application abusive de la méthode, alors qu'un waterfall suffirait.
J'aimerai voir la satisfaction client (métier). Est ce que ce qui a été demandé a été développé? Est ce que l'expérience utilisateur est à niveau? Est ce que le sprint apporte un niveau de valeur métier suffisant?
Il est envisageable d'avoir une notation permettant de valoriser, au delà de nos attentes.
La qualité doit être envisagé sur plusieurs niveaux : qualimétrie, couverture de TU, régressions, bug utilisateur, non respect de l'US.

Les managers des chefs de projet doivent donc se fier à de nouveaux indicateurs, et la consommation de budget doit être surveillée, mais doit relever d'une surveillance ratio budget/valeur apportée.
Il ne doit pas être envisagé seule, ou sur la création de telle ou telle fonctionnalité. Il faut avoir en tête investissement et retour sur investissement.

On ne peut pas imaginer de demander à des équipes de changer de manière de travailler, si les "surveillants" ne changent eux même pas d'habitude, et d'attitude.
Il est illusoire de penser d'effectuer un changement de culture aussi profond, en ne demandant qu'à la "strate" opérationnelle de modifier sa manière de travailler.