Les directions informatiques (DSI) doivent s’adapter aujourd’hui à un monde volatile, incertain, complexe et ambiguë : les situations évoluent de manière imprévisible, de nouvelles technologies ou réglementations peuvent surgir à tout moment et modifier brusquement l’environnement, les interactions entre systèmes se multiplient augmentant le risque d’erreur.

Dans ce contexte d’incertitude extrême, les DSI doivent donc trouver de nouveaux modes de fonctionnement plus flexibles et plus efficaces pour soutenir l’entreprise face à la concurrence.

Pour répondre à cet impératif, certaines se tournent vers une nouvelle forme d’organisation, l’organisation agile. Cette énième transformation consiste le plus souvent à s’appuyer sur un framework agile comme Safe par exemple ou à copier-coller ce que d’autres on fait. Ainsi il est fréquent de voir le modèle Spotify appliqué dans des contextes très éloignés de l’écoute musicale sur internet. Ce changement majeur pour la DSI est mené, généralement, par des coachs agiles rompus à la méthode Scrum et aux outils de facilitation en tout genre. Des équipes autonomes pluridisciplinaires émergent emmenées par des Product Owners et des Scrum Masters (dont le métier est plus de « energizer » les équipes plutôt que de s’intéresser aux pratiques d’ingénierie logicielle et à la qualité du code). Le travail est cadencé au rythme des cérémonies voulues par la méthode : standup meeting, sprint planning, rétrospectives… L’effort de coaching se porte principalement sur l’adhésion des collaborateurs à la nouvelle organisation du travail, sur la collaboration et sur les relations interpersonnelles. Ainsi, la réussite de la transformation se mesure-t-elle à la capacité de chacun à respecter les principes de la méthode et à les mettre en œuvre de manière autonome.

Et quid de la satisfaction client,
de la qualité du code et du respect des délais ?

Mais est-ce suffisant pour obtenir des résultats concrets ? C’est à dire des résultats montrant une meilleure santé de l’entreprise : des clients satisfaits, une augmentation de la qualité délivrée, une réduction significative des délais de production, des coûts maîtrisés, des salariés épanouis…

Le problème est que cette nouvelle transformation ne diffère pas tellement des autres. Les collaborateurs changent de bureau, d’équipe, de contexte applicatif et l’intitulé de leur poste est adapté au nouveau paradigme. Quant à leur travail, fondamentalement il reste le même. Les cartes sont rebattues, mais finalement où est le véritable changement ? Est-ce que cette transformation permet de mieux comprendre le client, de mieux répondre à ses attentes ? Est-ce que les collaborateurs sont plus au fait des plaintes exprimées par les utilisateurs de leurs applications ? Est-ce qu’une attention particulière est portée aux pratiques d’ingénierie (code, architecture, réseau, sécurité…) ? Y-a-t-il un lien clairement identifié entre les attentes des clients, l’ingénierie et la performance de l’entreprise ?

Se lancer dans une transformation agile ne peut donc se limiter à un énième changement d’organisation et à l’application d’une méthode. Pour répondre à l’accélération des changements, la transformation se doit de développer un système d’apprentissage permettant aux collaborateurs :

1 – de développer une compréhension très fine des attentes de leurs clients ;

2 – de voir très rapidement les obstacles qui les empêchent de satisfaire ces attentes ;

3 – de développer des compétences en résolution de problèmes, individuelles et collectives, pour améliorer la situation par eux-mêmes.

Il s’agit dès lors de s’intéresser précisément à la qualité du code, son architecture, sa maintenabilité, sa performance, de chercher à comprendre dans quelle mesure les interfaces utilisateur répondent parfaitement au besoin des clients, et s’assurer que le système est suffisamment sécurisé pour protéger les données sensibles par exemple.

Les auteurs du Manifeste agile  écrivaient en 2001 en préambule :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Ces fondements inscrits il y a 17 ans ont malheureusement disparu des pratiques de ceux qui déploient aujourd’hui une forme d’agilité à grande échelle.

Comment revenir aux fondamentaux ?

En recherchant inlassablement à mieux comprendre ses clients et en soutenant l’esprit kaizen à tous les niveaux pour améliorer ses processus et ses pratiques de développement au sens large, obstacle après obstacle, la DSI développe l’expertise de ses collaborateurs et améliore sa capacité à :

1 – concevoir les produits demandés par les clients et les utilisateurs ;

2 – livrer à l’heure les fonctionnalités demandées avec un très haut niveau de qualité ;

3 –  produire des architectures logicielles sécurisées de plus en plus flexibles s’adaptant extrêmement rapidement aux conditions versatiles du marché.

Grâce à cette nouvelle capacité d’apprentissage, la DSI va contribuer de plus en plus efficacement à la compétitivité de l’entreprise en s’adaptant toujours plus rapidement aux nouvelles conditions afin de fournir de meilleurs produits ou services en temps et en heure (du code de qualité, sécurisé et robuste).

 

“Donner du sens” fait partie des bonnes pratiques managériales lean et agile que l’on recommande aujourd’hui. Si l’on en parle autant, c’est bien qu’il s’agit moins d’une évidence qu’il n’y parait. Quels bénéfices y a-t-il à donner du sens ?

J’en vois quatre :

1. Améliorer le moral :
   Savoir que mon travail a de l’importance pour quelqu’un a un impact immédiat sur l’intérêt que je lui porte et l’envie que j’ai d’y retourner le lendemain. La personne la plus désespérée que j’ai rencontrée en entreprise était un contrôleur de gestion : il s’était rendu-compte que le rapport hebdomadaire dont il avait la charge n’était lu par … absolument personne*[1].
2. Elargir le champ de la liberté de pensée et d’action :
   Quand ce qui a du sens est clair, il est plus facile d’analyser son travail, d’y trouver des endroits où une amélioration serait pertinente, de réduire des activités sans intérêt, d’identifier des innovations potentielles, etc…
3. Faciliter la relation :
   Se sentant légitime sur le domaine du sens, il est possible de sortir de son silo, qu’il soit minuscule ou immense, pour entamer une discussion constructive avec d’autres ! A partir du moment où chacun a les idées bien claires sur ce qui est important et sur comment se définit le succès, il est bien plus facile d’expliquer pourquoi une question mérite d’être abordée ou une proposition écoutée.
4. Réussir  :
   Enfin, chacun peut trouver des idées d’amélioration légitimes et, tout aussi légitimement, les mettre en oeuvre dans son domaine.

Lire la suite « A la rubrique “donner du sens”, trouver les mots pour le dire » →

Nous avons le plaisir et l’honneur d’annoncer la parution de « User stories : 50 clés pour raconter les besoins utilisateurs » la traduction française du livre de Gojko Adzic Fifty Quick Ideas to improve your User Stories !

Nous sommes fiers d’avoir traduit cet ouvrage et d’avoir porté le projet avec l’éditeur français Eyrolles. Lire la suite « Sortie du livre de Gojko Adzic : « Fifty Quick Ideas to improve your User Stories » en français ! » →