Agile : resultaten van de enquête

mrt 4, 2020

AGILE: hoe het begon

Aanvankelijk werden pilootprojecten op kleine schaal met succes uitgetest volgens deze methodologie. De directie heeft dan ook besloten om deze werkmethode op grote schaal toe te passen en stelde dit voor als een logische stap in de evolutie van BELFIUS. De bedoeling was immers om gewapend te zijn om onze concurrenten het hoofd te bieden en onze transformatie naar een moderne bank te versnellen.

https://my.setca.org/militant/Martin/extra%20iconen-12.png

AGILE, zijn transversale samenwerkingen en de vergelijking met de waarden van de bank: challenging, bedrijfsgeest, engagement, klantgerichtheid, transparantie en authenticiteit.

Na een aantal maanden zijn meerdere alarmerende getuigenissen bekend geraakt. Wij hebben dan ook deze enquête gevoerd over AGILE om de onderliggende problemen beter in te schatten, denkpistes te vinden en de directie concrete voorstellen voor verbetering te doen.

Jullie hebben ons massaal omstandige adviezen gegeven.

BEDANKT!

Maar wat blijkt nu uit jullie ervaringen? Hierna vinden jullie de antwoorden die jullie op deze enquête hebben gegeven.

Wat heeft de BBTK hiervan onthouden?

Een tijdrovende methode, soepel voor kleinschalige projecten maar niet aangepast aan de bankomgeving, te vaag, men weet niet meer wie wat doet, wie wie moet verwittigen, wie waarvoor verantwoordelijk is. Teams plooien zich op zichzelf terug, wat een bron van problemen is voor de “omnichannel-projecten”. Medewerkers voelen zich niet langer verantwoordelijk, er zijn te veel rollen met een structuur die dringend vereenvoudigd moet worden, de administratieve taken zijn te zwaar geworden en leiden tot werkoverlast door de voortdurende vergaderingen. Sommige hiërarchische verantwoordelijken houden geen rekening met onvoorziene omstandigheden (ziekte, verlof, …), er zijn veel woorden in de wind, post-its die overal worden opgekleefd, behoeftenanalyses worden niet afgewerkt of nauwelijks opgestart, projecten waarvan men nog nooit heeft gehoord duiken op, collega’s zijn gedemotiveerd of zoeken andere functies buiten AGILE, er zijn permanente veranderingen binnen projecten, er is een gebrek aan duidelijkheid in de prioriteiten die voortdurend veranderen waarin sommige teams werken in functie van hun eigen prioriteiten, waarin alles wordt versnipperd, zonder overzicht…

We kunnen uiteraard, zoals in elke organisatie die wij opstarten, kinderziekten inroepen, alsook het vertrek van coaches, het feit dat nog niet alles is geïmplementeerd en dat nog aanpassingen moeten worden gedaan om de onvolmaaktheden van Agile te verklaren. Blijkbaar draagt deze methodologie, die op onze schaal wordt toegepast, de kiem van haar eigen mislukking in zich.

Wat vraagt de BBTK-SETCa?

Op basis van de resultaten van de enquête vragen wij dat de implementering van deze onaangepaste werkmethode wordt stopgezet. Laat ons terugkeren naar de oude manier van werken. De pilootprojecten die dienden voor de implementering van AGILE waren niet voldoende representatief voor de complexiteit van de gewone projecten van de bank.

Voor elke vraag of verzoek om bijkomende informatie kun je een mail sturen naar feedback@red4you.org of je rechtstreeks tot een van onze afgevaardigden wenden.

Context en vragen-antwoorden

  • Sinds wanneer werk je met Agile?
Minder dan 6 maanden 28% 28%
6 maanden tot 1 jaar 11% 11%
Langer dan 1 jaar 61% 61%
  • Wat is je rol binnen Agile?

De belangrijkste opmerkingen zijn vertegenwoordigd qua resultaat, zowel voor Epic Owner, Enterprise Architect,…

  • Heb je een opleiding gekregen over het concept Agile, over hoe dit werkt…?

97% van de werknemers betrokken bij Agile heeft een “opleiding” gekregen. Het gevoel van de collega’s is eerder dat gepreciseerd moet worden dat het om informatie ging in plaats van een echte en praktische opleiding, het was een algemene opleiding die niet aangepast is aan de bank.

  • Heb je deze opleiding in je moedertaal gekregen?

De belangrijkste opmerkingen meningen zijn verdeeld. 54% van de collega’s kreeg deze opleiding in zijn moedertaal. Gezien de techniciteit van deze werkmethode, had de opleiding systematisch in de moedertaal van alle werknemers gegeven moeten worden.

  • Was de uitleg duidelijk en voldoende?

67% van de collega’s antwoordde NEEN! De opmerkingen die wij ontvingen waren voornamelijk:

  1. – Theoretische maar onrealistische opleiding
  2. – De consultants weten duidelijk niets over de bankrealiteit
  3. – De implementering stemt niet overeen met de uitleg die in juni 2017 werd gegeven…
  • Beschik je over gedetailleerde documentatie over de projecten waarbij je betrokken bent?

68% van de medewerkers klaagt over het gebrek aan documentatie en dat ze zelf de informatie moeten zoeken in Target Process (niet evident, tijdsverlies,…). De stockering van projecten vervat in een Share Point maakte het zoeken van informatie eenvoudiger, wat nu niet meer het geval is.

  • Denk je dat deze methode soepel en makkelijk te implementeren is?

90% zegt neen!

De commentaren gaan allen in dezelfde richting:

  1. – Soepel voor kleinschalige projecten, maar niet voor een bank
  2. – Methode die enorm veel tijd vergt
  3. – Te vaag. We weten niet meer wie wat doet, wie wie moet verwittigen, wie waarvoor verantwoordelijk is…
  4. – Te veel opdelingen in tal van teams
  5. – Men vreest dat de voorkeur zal worden gegeven aan gedetailleerde taken ten koste van een globaal zicht op de systemen
  6. – Discrepantie tussen de visie van het Management (via Target Process) en de realiteit op het terrein
  • Heeft deze methode de samenwerking tussen collega’s verbeterd?

81 % zegt neen! Wel integendeel.

Alles lijkt complexer, dus de collega’s hebben geen tijd meer om te communiceren.
Ze plooien zich terug op hun eigen domein en dit is zeer problematisch voor de “omnichannelprojecten”.
De mensen voelen zich niet langer verantwoordelijk. Er is geen echte projectleider (Business of IT) meer die het geheel trekt/volgt/coördineert.

  • Oefen je in het kader van Agile meerdere functies uit?

40 % zegt ja.

Hoe kan dit? Personeelstekort?
Het is moeilijk voor een medewerker om verschillende rollen op zich te nemen.

  • Begrijp je ieders rol?

66 % zegt neen! De commentaren zijn veelzeggend:

  1. – Agile is een theoretische methode die in de praktijk evenwel moeilijk te implementeren is in de bank.
  2. – Er zijn te veel rollen.
  3. – De structuur moet dringend worden vereenvoudigd.
  4. – We begrijpen ieders rollen niet altijd goed. Waar begint de rol van de ene en waar eindigt die?
  5. – De verdwijning van de rol van projectleider is een probleem, want deze is niet echt opgenomen in de nieuwe organisatie, terwijl die toch noodzakelijk blijft.
  6. – Wie is uiteindelijk verantwoordelijk voor de oplevering van een project, wie moet een initiatief nemen ingeval van een probleem?
  7. – Wat is binnen éénzelfde domein de actieperimeter van een rol? Dit kan verschillen van het ene domein tot het andere, wat andere problemen veroorzaakt ingeval van transversale projecten…
  • Is de manier om deze nieuwe methodologie te gebruiken uniform in elke gebied?

86 % zegt neen!

Elke afdeling geeft het gevoel op zijn eigen manier te werken. De bank is te groot om een uniforme werkmethode te gebruiken. Wat goed is voor de ene is niet noodzakelijk goed voor de andere.

  • Laat deze methode toe om een eventueel personeelstekort te compenseren?

96 % zegt neen!

De indruk is net het omgekeerde: deze werkmethode vervangt via de administratie de echte toegevoegde waarde die een collega aan zijn functie kan geven. Deze administratieve taken zijn te zwaar geworden en leiden tot werkoverlast als gevolg van de vergaderingen, Backlogs, Sprints,… Deze methode vergt te veel tijd in vergelijking met alle projecten, kleine en/of grote projecten.

  • Houdt je hiërarchie rekening met het effectieve personeelsbestand om vooruitgang te boeken in de projecten of ze te plannen?

64 % zegt neen!

De hiërarchie houdt geen rekening met onvoorziene omstandigheden (ziekte, verlof,…) noch met de bijzonder lange leercurve. Uit de enquête blijkt ook dat de hiërarchie materieel niet langer de tijd noch de middelen heeft om zijn medewerkers op te volgen.

  • De bank heeft de Little Big Room ontwikkeld. Ben je nu beter voorbereid om de Big Room Planning bij te wonen?

73 % zegt neen!

De geformuleerde opmerkingen zijn divers:

  1. – De analyses worden uitgevoerd op het niveau van het programma zonder te weten of er voldoende resources zijn om ze te ontwikkelen op het Scrumniveau. Aangezien niet alle Scrumteams dezelfde werklast hebben, wordt het ingewikkeld.
  2. – Een ander probleem is het beschikken over informatie. Zolang de medewerkers deze niet hebben, is het vrij moeilijk om een ernstige meerwaarde te bieden in elk van de Big Rooms… die resources hele dagen monopoliseren.
  • Wanneer je je in een Big Room Planning (BRP) aanbiedt, heb je dan een duidelijk zicht op het te ontwikkelen project?

78 % zegt neen!

BRP wordt door sommigen ‘Big Souk’ genoemd: veel woorden in de wind, post-its die overal worden opgekleefd, analyses van behoeften die niet afgewerkt of nauwelijks opgestart zijn, projecten die opduiken en waarvan men nog nooit gehoord heeft…

  • Geven de planningen vastgelegd in de BRP of de LBRP de realiteit weer?

81 % zegt neen! De belangrijkste opmerkingen zijn altijd dezelfde:

  1. – Het is moeilijk om de nodige tijd te evalueren om een project af te werken als we maar een beperkt zicht hebben op dit project… Of helemaal geen zicht.
  2. – Hoe kan rekening worden gehouden met zieken, vertragingen in de ontwikkelingen in andere gekoppelde projecten,…
  3. – IT-resources worden toegewezen aan strategische projecten en de specialisten werken aan andere projecten: kort samengevat zijn het de back-ups die het werk doen…
  4. – De directie houdt geen rekening met onderhoudsactiviteiten, met support, competenties en expertise van iedereen…
  5. – De prioriteiten veranderen constant, er is geen filter meer om nieuwe aanvragen te accepteren die in ontwikkeling zijn…
  • Worden de werknemers makkelijker gemotiveerd door hun betrokkenheid bij deze methode?

93 % zegt neen!

Dit percentage veroorzaakt andere problemen: een bepaald aantal collega’s zoekt een andere functie buiten de sfeer van AGILE gezien

  1. – De permanente veranderingen en de verschillende taken binnen dezelfde projecten
  2. – Niemand lijkt nog enige verantwoordelijkheid lijkt te hebben. Het gevoel is dat er geen echt projectteam meer is dat rond een duidelijke doelstelling is geconcentreerd
  3. – Sommigen verschuilen zich achter procedures om hun verantwoordelijkheden te ontlopen
  4. – Gebrek aan duidelijkheid in de prioriteiten die permanent veranderen en in de inhoud van ieders rol,……
  • Is deze methode eenvoudiger om informatie uit te wisselen tussen de teams en de dialoog te vereenvoudigen?

92 % zegt neen!

De geformuleerde opmerkingen zijn divers:

  1. – AGILE lijkt op een grote markt waar iedereen tegelijkertijd praat en waar informatie verloren gaat
  2. – We weten nog steeds niet welk Scrum Team een project beheert
  3. – Elk team werkt in functie van zijn eigen prioriteiten. Het is dan ook moeilijk om de impact van een project op verschillende gebieden te evalueren.
  4. – De informatie wordt onvoldoende/onvolledig doorgegeven.
  • Heb je problemen om je taken uit te voeren door de talrijke vergaderingen voor Agile?

77 % zegt ja.

Waarom? Veel tijdverlies voor een beperkte efficiëntie.

  • Kan je vrijuit de problemen die je ondervindt meedelen aan je hiërarchie?

86 % zegt ja.

Sommige collega’s, die bepaalde incoherenties benadrukken, worden evenwel verplicht om een positief imago te geven, anders worden ze beschouwd als “niet open voor veranderingen”.

  • Houdt je hiërarchie rekening met je opmerkingen?

58 % zegt neen!

De directe hiërarchie lijkt machteloos en het lijkt moeilijk om te begrijpen wie wat beslist. Bovendien is de directe hiërarchie soms begripvol, maar is ze geenszins betrokken bij de functionele hiërarchie gelinkt aan AGILE. Tot slot, hoe hoger je in de hiërarchie gaat, hoe minder de opmerkingen worden geapprecieerd.

  • Leveren de AGILE-coaches concrete antwoorden op je problemen?

75 % zegt neen! neen,.. En sowieso, hebben de coaches van ACCENTURE hun opdracht in de bank beëindigd… Wat kon men hen verwijten?

  1. – Ze praten enkel over de theorie maar ze houden geen rekening met het specifieke karakter van Belfius.
  2. – Ze spreken zichzelf regelmatig tegen: iedereen heeft zijn eigen visie op AGILE.
  3. – Ze houden zich aan een methode die enkel in andere contexten toepasbaar is.
  • • Heb je een duidelijk zicht op wat de hiërarchie van jou verwacht?

47% zegt neen… terwijl een honderd percent duidelijke gedragslijn evident lijkt…

  • Heb je een duidelijk zicht op de planningen verbonden aan je projecten?

75 % NEE.

De vaakst gemaakte opmerkingen zijn:

  1. – Er wordt een planning gemaakt voor 3 maanden.. die meerdere keren kan veranderen op enkele dagen tijd…
  2. – Elkeen kan de planning wijzigen en aangezien de communicatie te wensen over laat, weet niemand of een planning haalbaar is of niet.
  3. – We zouden bijna elke dag moeten gaan kijken of er niets werd aangepast in de planning.
  4. – Wanneer een project impact heeft op verschillende gebieden, is het moeilijk om in andere teams een duidelijk zicht te krijgen op de planning van verwante projecten
  5. – Het is moeilijk om te doen erkennen dat niet alles houdbaar is wanneer de lasten hoger liggen dan de capaciteiten
  6. – Voor projecten die een impact hebben op verschillende teams, is het vrijwel onmogelijk om een globaal zicht te hebben op de verschillende planningen, aangezien elk team volgens zijn eigen prioriteiten werkt.
  • Is het een voordeel om met “sprints” te werken?

84 % zegt neen!

De belangrijkste verklaringen hiervoor zijn:

  1. – Sprints zijn aangepast voor kleine specifieke projecten. Voor transversale projecten kan AGILE worden vergeleken met een gigantische spaghetti.
  2. – Het werk verdelen in groepen van 3 weken maakt het a priori beheersbaar en duidelijk. Dit heeft ook grote nadelen: de teams concentreren zich op die 3 weken maar het is een vrij korte tijdspanne. Bepaalde taken worden regelmatig uitgesteld tot de volgende sprints en de releases kunnen niet meer worden gerespecteerd.
  3. – Het beheer van de verschillende versies van applicaties en de organisatie van de tests worden te zwaar en te stresserend (talrijke versies: Release, Mobile, Exceptional Release, Builds,…)
  4. – Het is moeilijk om de sprints en de releases (P) te combineren.
  5. – Gebrek aan souplesse en moeilijk om projecten af te werken die we kunnen afleveren en testen op een Sprint
  • Kunnen door deze methode de frequente veranderingen in een project beter verteerd worden qua zenuwen?

95 % zegt neen!

  • Is de werklast toegenomen door de implementering van Agile?

80 % zegt ja.

De redenen hiervoor zijn divers:

  1. – Combinatie van de rollen en overdracht van IT-taken naar Business
  2. – Verloren tijd in vergaderingen, tijd doorgebracht met het zoeken naar informatie in Target Processen
  3. – Gebrek aan informatie en aan tijd (Agile = Just in time, Just enough!)
  4. – Administratieve rompslomp
  • De tool « Target Process »
JA NEE
Gemakkelijk te gebruiken 39% 61%
Vergt tijd 67% 33%
Een overzicht geven van de projecten en de timing 25% 75%
Laat toe om je tijd beter te beheren 15% 85%
Maakt tijdswinst mogelijk 4% 96%
Bron van stress 62% 38%

Deze resultaten zijn zorgwekkend. De ontvangen commentaar luidt onder meer als volgt:

  1. – Een taak méér te verwezenlijken in de dagelijkse opvolging
  2. – Een symptoom van de ongeschiktheid van deze werkmethode
  3. – Erg ingewikkeld om je weg hierin te vinden
  4. – De gedragslijnen zijn niet altijd erg duidelijk en zijn niet noodzakelijk dezelfde op alle niveaus. Target Process geeft een virtueel beeld van een realiteit die soms verschillend is, onder meer qua planningen
  5. – De vorm is belangrijker dan de inhoud
  • Kan door deze methode de klant sneller tevreden worden gesteld en blijft de kwaliteit van het geleverde product gevrijwaard?

95 % zegt neen!

  • Laat deze methode toe om de evolutie van een project efficiënter te volgen?

79 % zegt neen!

De belangrijkste commentaar luidt als volgt:

  1. – De opvolging via Steering en PMT van de oude werkmethode was efficiënter voor de transversale projecten
  2. – Het is makkelijk om de weg kwijt te raken in de honderden stories die voortdurend veranderen.
  3. – Alles is versnipperd, er is geen overzicht meer, ook geen zicht op de planningen.
  4. – Gezien het aantal NO GO’s is het antwoord evident.
  • Demotiveert deze methodologie je en zet ze je aan om van functie te veranderen?

52 % zegt ja.

  • Bestaan er volgens jou diensten die een impact van Agile ondervinden en die “vergeten” werden?

Bijna 50% van de collega’s antwoordt JA

Het gaat om projecten verbonden aan volgende domeinen: Legal, Compliance, Pricing Derogation, de PI² infrastructuur, de communicatie, de PCB distributie,…

  • Heb je het gevoel dat deze methodologie efficiënt is in je job?

92% zegt neen wegens tijdverlies tijdens onproductieve vergaderingen, talrijke rollen van sommigen, irrealistische planningen,…

  • Als je kon vergelijken, zou je dan je oude werkmethode of Agile verkiezen?

92% van de collega’s verkiest de oude methode. Waarom? Het huidige werk is niet aangepast aan de AGILE-methode: te veel onbekenden, niet genoeg informatie om het uit te voeren werk correct te plannen, niet aangepaste en te korte sprints,…

  • Diverse gegevens

GESLACHT : 73% mannen tegenover 27% vrouwen
STATUUT : 70% kaderleden tegenover 30% bedienden

ANCIËNNITEIT BIJ BELFIUS

Minder dan 1 jaar 1%
1 jaar tot 5 jaar 2%
6 jaar tot 10 jaar 2%
11 jaar tot 20 jaar 23%
20 jaar tot 25 jaar 29%
25 jaar tot 30 jaar 17%
Meer dan 30 jaar 27%

LEEFTIJD

20 jaar tot 30 jaar 2%
30 jaar tot 40 jaar 5%
40 jaar tot 45 jaar 22%
45 jaar tot 50 jaar 23%
50 jaar tot 55 jaar 24%
55 jaar tot 60 jaar 19%
60 jaar en ouder 6%

IK LEID EEN TEAM

JA7%
NEE93%

TEWERKSTELLING

Voltijds 82%
Tussen 80 % en 100 % 16%
Minder dan 80% 2%

DIVISIE

Algemeen Auditeur: 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%