Revenons aux origines d’AGILE
Au départ, des projets pilotes de petite envergure ont été testés avec succès suivant cette méthodologie. La direction a donc décidé d’implémenter cette méthode de travail à grande échelle et l’a présentée comme une étape logique dans l’évolution de BELFIUS, le but étant d’être armé pour faire face à notre environnement concurrentiel et accélérer notre transformation vers une banque moderne.
AGILE, ses collaborations transversales et sa mise en parallèle avec les valeurs de la banque : challenging, esprit d’entreprise, engagement, orientation client, transparence et authenticité.
Au fil des mois, différents témoignages alarmistes se sont faits connaître. Nous avons donc réalisé cette enquête sur AGILE afin de mieux appréhender les problèmes sous-jacents, déceler des pistes de réflexion et soumettre à la direction des propositions concrètes d’amélioration.
Vous avez été très nombreux à nous revenir avec des avis circonstanciés :
MERCI.
Mais que révèle votre vécu ? Vous trouverez ci-après les réponses que vous avez formulées dans cette enquête.
Qu’en a retenu le SETCa-BBTK ?
Une méthode chronophage, souple pour des projets de petite taille mais inadaptée à l’environnement bancaire, trop floue, où on ne sait plus qui fait quoi, qui doit prévenir qui, qui est responsable de quoi, des équipes qui se replient sur leur domaine, source de problèmes pour les projets « omnichannel », des collaborateurs qui ne se sentent plus responsables, une multitude de rôles avec une structure à simplifier d’urgence, des tâches administratives devenues trop lourdes et générant une surcharge de travail due aux réunions incessantes, certains responsables hiérarchiques qui ne tiennent pas compte des imprévus (maladie, congés, …), beaucoup de paroles en l’air, des post-it collés partout, des analyses de besoins non finalisées ou à peine entamées, des projets qui surgissent et dont on n’a jamais entendu parler, des collègues démotivés qui cherchent d’autres fonctions hors AGILE, des changements permanents au sein des projets, un manque de clarté dans les priorités qui changent continuellement, où certaines équipes travaillent en fonction de leurs propres priorités, où tout est morcelé, sans vue d’ensemble, …
On peut bien entendu, comme dans toute nouvelle organisation que l’on met en place, mettre en avant les maladies de jeunesse, le départ de coaches, le fait que tout ne soit pas encore implémenté et que des ajustements doivent encore être réalisés pour expliquer les imperfections d’Agile. Manifestement, cette méthodologie, appliquée à notre échelle, porte plutôt en elle les germes de son propre échec.
Que demande le SETCa-BBTK ?
Sur base des résultats de l’enquête, nous demandons d’arrêter l’implémentation de cette méthode de travail inadaptée. Revenons à l’ancienne méthode de travail. Les projets pilotes qui ont servi à l’implémentation d’AGILE n’ont pas été suffisamment représentatifs de la complexité des projets habituels de la banque.
Pour toute question ou demande d’information complémentaire, vous pouvez envoyer un mail à feedback@red4you.org ou vous adresser directement à l’un de nos délégués.
Contexte et questions-réponses
- Depuis quand travaillez-vous en Agile ?
| Moins de 6 mois | 28% |
| 6 mois à 1 an | 11% |
| Plus d’1 an | 61% |
- Quel est votre rôle dans Agile ?
Les différentes fonctions existantes sont représentées au niveau du résultat, qu’il s’agisse d’Epic Owner, d’Enterprise Architect, …
- Avez-vous reçu une formation sur le concept Agile, comment ça fonctionne … ?
97% des collaborateurs impliqués en Agile ont reçu une « formation ». Le ressenti des collègues est plutôt de préciser qu’il s’agissait d’une information que d’une formation réelle et pratique, qu’il s’agissait d’une formation générale et non adaptée à la banque.
- Avez-vous reçu cette formation dans votre langue maternelle ?
Les avis sont mitigés. 54% des collègues ont reçu cette formation dans leur langue maternelle. Vu la technicité de cette méthode de travail, elle aurait dû être donnée systématiquement dans la langue maternelle de tous les collaborateurs.
- Les explications étaient-elles claires et suffisantes ?
67% des collègues répondent que NON ! Les remarques reçues sont essentiellement :
- Formation théorique mais pas réaliste
- Les consultants ne connaissent manifestement pas la réalité bancaire
- L’implémentation ne correspond pas aux explications formulées en juin 2017
- …
- Disposez-vous d’une documentation détaillée par rapport aux projets dans lesquels vous êtes impliqué(e) ?
68% des collaborateurs se plaignent de l’absence de documentation et qu’il faut chercher l’information soi-même dans Target Process (pas évident, perte de temps, …). Le stockage des projets repris dans un SharePoint facilitait la recherche d’informations, ce qui n’est plus le cas.
- Estimez-vous que cette méthode soit souple et facile à implémenter ?
Non à 90 % !
Les commentaires vont tous dans le même sens :
- Souple pour des projets de petite taille, pas au niveau d’une banque
- Méthode qui prend énormément de temps
- Trop floue. On ne sait plus qui fait quoi, qui doit prévenir qui, qui est responsable de quoi …
- Trop de découpages dans des équipes multiples
- Crainte de voir favoriser des tâches détaillées au détriment d’une vue globale des systèmes
- Décalage entre la vue du Management (via Target Process) et la réalité du terrain
- …
- Est-ce que cette méthode a permis d’améliorer la collaboration entre collègues ?
Non à 81 % ! Bien au contraire.
Tout semble plus complexe, plus formel, donc les collègues n’ont plus le temps de communiquer.
Ils se replient sur leur domaine et c’est très problématique pour les projets « omnichannel ».
Les gens ne se sentent plus responsables. Il n’y a plus un vrai chef de projet (Business ou IT) qui tire/suit/coordonne l’ensemble.
- Dans le cadre d’Agile, exercez-vous plusieurs fonctions ?
Oui à 40 %.
Comment est-ce possible ? Manque d’effectifs ?
Il est difficile pour un collaborateur d’assumer différents rôles.
- Comprenez-vous le rôle de chacun ?
Non à 66 %. Les commentaires sont éloquents :
- Agile est une méthode théorique mais difficile à implémenter dans la pratique bancaire
- Il y a trop de rôles
- Structure à simplifier d’urgence
- On ne comprend pas toujours bien les rôles de chacun. Où commence le rôle d’un tel et où se termine-t-il ?
- La disparition du rôle de chef de projet est un problème car il n’est pas vraiment repris dans la nouvelle organisation alors qu’il reste nécessaire
- Au final, qui est responsable de la livraison d’un projet, qui doit prendre une initiative en cas de problème, …
- Au sein d’un même domaine, quel est le périmètre d’action d’un rôle ? Cela peut varier d’un domaine à l’autre, ce qui génère d’autres problèmes en cas de projets transversaux…
- …
- Est-ce que la manière d’utiliser cette nouvelle méthodologie est uniforme dans chaque domaine ?
Non à 86 %.
Chaque division donne le sentiment de travailler à sa manière. La banque est trop grande que pour utiliser une méthode de travail uniforme. Ce qui est bon pour l’un n’est pas forcément bon pour l’autre.
- Cette méthode permet-elle de compenser un éventuel manque d’effectifs ?
Non à 96 %.
L’impression est plutôt juste l’inverse : cette méthode de travail remplace par l’administration la réelle valeur ajoutée qu’un collègue peut apporter à sa fonction. Ces tâches administratives sont devenues trop lourdes et génèrent une surcharge de travail due aux réunions, Backlogs, les Sprints, … Cette méthode demande trop de temps par rapport à tous les projets, petits et/ou grands projets.
- Votre hiérarchie tient-elle compte des effectifs réels pour avancer dans les projets ou les planifier ?
Non à 64 %.
La hiérarchie ne tient pas compte des imprévus (maladie, congés, …) ni de la courbe d’apprentissage particulièrement longue. L’enquête révèle également que la hiérarchie n’a plus matériellement le temps ni les moyens de suivre ses collaborateurs.
- La banque a développé le Little Big Room Planning (LBRP). Est-ce que vous êtes ainsi mieux préparé(e) pour assister au Big Room Planning ?
Non à 73 %.
Les remarques formulées sont diverses :
- Les analyses sont réalisées au niveau programme sans savoir s’il y aura des ressources suffisantes pour les développer au niveau Scrum. Vu que tous les Scrum Teams n’ont pas la même charge de travail, cela devient compliqué
- Un autre problème est d’avoir les informations. Aussi longtemps que les collaborateurs ne les ont pas, il est assez difficile d’apporter une plus-value sérieuse dans chacun des Big Rooms … qui monopolisent des ressources durant des journées entières
- …
- Lorsque vous vous présentez à un Big Room Planning (BRP), avez-vous une vue claire sur le projet à développer ?
Non à 78 %.
Le BRP est qualifié par certains de « Big Souk » : beaucoup de paroles en l’air, des post-it collés partout, des analyses de besoins non finalisées ou à peine entamées, des projets qui surgissent et dont on n’a jamais entendu parler, …
- Est-ce que les plannings fixés dans le BRP ou le LBRP reflètent la réalité ?
Non à 81 %. Les remarques principales sont toujours les mêmes :
- Il est difficile d’évaluer le temps nécessaire pour faire aboutir un projet quand on a qu’une vue limitée sur ledit projet … ou pas de vue du tout
- Comment tenir compte des malades, des retards de développements dans d’autres projets liés, …
- Des ressources IT sont dédiées à des projets stratégiques et les spécialistes travaillent sur d’autres projets : en résumé, ce sont des backups qui font le travail …
- La direction ne tient pas compte des activités de maintenance, de support, des compétences et expertises de chacun, …
- Les priorités changent constamment, il n’y a plus de filtre pour accepter de nouvelles demandes en cours de développement, …
- Cette méthode permet-elle de motiver plus facilement les collaborateurs par leur implication ?
Non à 93 %.
Ce pourcentage génère d’autres difficultés : un certain nombre de collègues cherche une autre fonction en dehors de la sphère d’AGILE vu
- Les changements permanents et les tâches différentes au sein des mêmes projets
- Plus personne ne semble responsable de rien. Le sentiment est qu’il n’y a plus vraiment d’équipe de projet concentrée autour d’un objectif clair
- Certains se réfugient derrière les procédures pour fuir leurs responsabilités
- Manque de clarté dans les priorités qui changent en permanence et dans le contenu du rôle de chacun, …
- …
- Cette méthode est-elle plus simple pour échanger l’information entre les équipes et faciliter le dialogue ?
Non à 92 %.
Les raisons formulées sont diverses :
- AGILE ressemble à un grand marché où tout le monde parle en même temps et où on perd des informations
- On ne sait pas toujours quel Scrum Team gère un projet
- Chaque équipe fonctionne en fonction de ses propres priorités. Il est donc difficile d’évaluer l’impact d’un projet dans différents domaines
- L’information circule de façon insuffisante/incomplète
- …
- La multitude des réunions liées à Agile vous pose-t-elle problème dans la réalisation de vos tâches ?
Oui à 77 %.
Pourquoi ? Une perte de temps importante pour une efficacité réduite.
- Est-ce que vous pouvez parler librement à votre hiérarchie des problèmes rencontrés ?
Oui à 86 %.
Cependant, certains collègues, qui soulignent certaines incohérences, sont contraints de donner une image positive sous peine de paraître « non réceptifs aux changements »…
- Votre hiérarchie tient-elle compte de vos remarques ?
Non à 58 %.
La hiérarchie directe semble impuissante et il semble difficile de comprendre qui décide de quoi. De plus, la hiérarchie directe est parfois compréhensive mais n’est nullement impliquée avec la hiérarchie fonctionnelle liée à AGILE. Enfin, plus on monte dans la hiérarchie et moins les remarques sont appréciées.
- Est-ce que les coaches « Agile » apportent des réponses concrètes à vos problèmes ?
Non à 88 % … et, de toute manière, les coaches d’ACCENTURE ont terminé leur mission dans la banque … Que pouvait-on leur reprocher ?
- Ils ne parlent que de théorie mais ne tiennent pas compte de la spécificité de Belfius
- Ils se contredisent régulièrement : chacun y va de sa vision d’AGILE
- Ils s’en tiennent à une méthode qui n’est applicable que dans d’autres contextes
- …
- Avez-vous une vue claire de ce que votre hiérarchie attend de vous ?
Non à 47 % … alors qu’une ligne de conduite claire à 100 % paraît évidente …
- Avez-vous une vue claire des plannings liés à vos projets ?
Non à 75 %.
Les remarques le plus souvent formulées sont :
- Un planning est fixé sur 3 mois … et puis peut changer plusieurs fois en quelques jours …
- Chacun pouvant modifier le planning et la communication étant lacunaire, plus personne ne sait si un planning est réalisable ou pas
- Il faudrait quasiment chaque jour aller voir si quelque chose n’a pas été adapté au niveau du planning
- Lorsqu’un projet a des impacts sur plusieurs domaines, il est difficile d’avoir une vue claire sur le planning de projets liés dans d’autres équipes
- Il est difficile de faire admettre que tout n’est pas tenable quand les charges dépassent les capacités
- Pour des projets qui impactent différentes équipes, il est quasiment impossible d’avoir une vue globale sur les différents plannings vu que chaque équipe fonctionne suivant ses priorités
- …
- Est-ce un avantage de travailler en « sprints » ?
Non à 84 %.
Les principales explications formulées sont :
- Des sprints sont adaptés pour de petits projets ciblés. Pour des projets transversaux, AGILE peut être assimilé à un gigantesque Spaghetti
- Diviser le travail en groupes de 3 semaines le rend a priori gérable et clair. Cela a aussi des inconvénients majeurs : les équipes se concentrent sur ces 3 semaines mais c’est un laps de temps assez court. Certaines tâches sont régulièrement reportées aux sprints suivants et les releases ne peuvent plus être respectés
- La gestion des différentes versions d’applications et l’organisation des tests deviennent trop lourdes et stressantes (multiples versions : Release, Mobile, Exceptional Release, Builds, …)
- Il est difficile de concilier les sprints et les releases (P)
- Manque de souplesse et difficilement possible d’aboutir à des projets que l’on peut délivrer et tester sur un Sprint
- …
- Cette méthode permet-elle d’accepter les changements fréquents dans un projet de manière plus supportable nerveusement ?
Non à 95 %.
- La charge de travail a-t-elle augmenté avec l’implémentation d’Agile ?
Oui à 80 %.
Les raisons sont diverses :
- Combinaison des rôles et transfert de tâches IT vers le Business
- Temps perdu en réunions, temps passé à chercher les informations en Target Process
- Manque d’informations et de temps (Agile = Just in time, Just enough !)
- Tracasseries administratives
- …
- L’outil « Target Process »
| OUI | NON | |
| Facile à utiliser | 39% | 61% |
| Prend du temps | 67% | 33% |
| Donner un aperçu des projets et des timings | 25% | 75% |
| Permet de mieux gérer son temps | 15% | 85% |
| Permet de gagner du temps | 4% | 96% |
| Source de stress | 62% | 38% |
Ces résultats sont interpellants. Les commentaires reçus sont entre autre :
- Une tâche en plus à réaliser dans le suivi journalier
- Un symptôme de l’inadéquation de cette méthode de travail
- Très compliqué pour s’y retrouver
- Les lignes de conduite ne sont pas toujours très claires et ne sont pas nécessairement les mêmes à tous les niveaux. Target Process donne une image virtuelle d’une réalité parfois différente au niveau des plannings notamment
- La forme est plus importante que le contenu
- …
- Cette méthode permet-elle de satisfaire le client plus rapidement tout en assurant la qualité du produit livré ?
Non à 95 %.
- Cette méthode permet-elle de suivre plus efficacement l’évolution d’un projet ?
Non à 79 %.
Les principaux commentaires sont les suivants :
- Le suivi via le Steering et PMT de l’ancienne méthode de travail était plus efficace pour des projets transversaux
- Facile de s’y perdre dans les centaines de stories qui changent en permanence
- Tout est morcelé, il n’y a plus de vue d’ensemble ni de vue sur les plannings
- Vu le nombre de « NO GO » … la réponse est évidente
- …
- Est-ce que cette méthodologie vous démotive et vous incite à changer de fonction ?
Oui à 52 %.
- Selon vous, existe-t-il des services impactés par Agile qui ont été « oubliés » ?
Près de 50 % des collègues répondent OUI.
Il s’agit de projets liés aux domaines suivants : Legal, Compliance, Pricing Derogation, l’infrastructure PI², la comptabilité, la communication, la distribution PCB …
- Avez-vous le sentiment que cette méthodologie est efficace dans votre job ?
Non à 92 % en raison des pertes de temps dans des réunions improductives, des rôles multiples de certains, des plannings irréalistes, …
- A comparer, préfériez-vous votre ancienne méthode de travail ou Agile ?
L’ancienne méthode pour 92 % des collègues. Pourquoi ? Le travail actuel n’est pas adapté à la méthode AGILE : trop d’inconnues, pas assez d’informations pour planifier correctement le travail à effectuer, des sprints non adaptés et trop courts, …
- Données diverses
SEXE : 73 % d’hommes pour 27 % de femmes
STATUT : 70 % de cadres pour 30 % d’employés
ANCIENNETE CHEZ BELFIUS
| Moins de 1 an | 1% |
| 1 an à 5 ans | 2% |
| 6 ans à 10 ans | 2% |
| 11 ans à 20 ans | 23% |
| 20 ans à 25 ans | 29% |
| 25 ans à 30 ans | 17% |
| Plus de 30 ans | 27% |
AGE
| 20 à 30 ans | 2% |
| 30 à 40 ans | 5% |
| 40 à 45 ans | 22% |
| 45 à 50 ans | 23% |
| 50 à 55 ans | 24% |
| 55 à 60 ans | 19% |
| 60 ans et + | 6% |
JE DIRIGE UNE EQUIPE
| OUI | 7% |
| NON | 93% |
OCCUPATION
| Temps plein | 82% |
| Entre 80% et 100% | 16% |
| Moins de 80 % | 2% |
DIVISION
| Auditeur général : | Van Thielen Luc | 0% |
| Communications & Customer Experience : | Debeerst Mieke | 0% |
| Digital & Data : | Van Mol Geert | 12% |
| HR & Building Management : | Gillon Camille | 0% |
| Innovation Technology : | Devis Patrick | 38% |
| PCB : | Gyselinck Dirk | 2% |
| RCB : | Onclin Olivier | 38% |
| Chief Risk Officer : | Collin Marianne | 5% |
| CFO – Head of ICM : | Vankelecom Johan | 1% |
| AUTRES | 4% |