Agile principes in een maintenance omgeving

Agile principes in een maintenance omgeving versie: 1.0

Opleiding Master in Projectmanagement Academiejaar 2010 - 2011

Vak: Docent:

Student:

Karel Nijs [email protected]

Business Excellence Nathalie Claes

Agile principes in een maintenance omgeving


Inhoudopgave Inhoudopgave ................................................................................................................................ 2 1 Inleiding .................................................................................................................................. 3 1.1 Bedrijf .............................................................................................................................3 1.1.1 Visie, missie en waarden ............................................................................................3 1.2 Team ..............................................................................................................................3 1.3 Hulp................................................................................................................................3 2 Aanpak ................................................................................................................................... 4 3 Huidige situatie ....................................................................................................................... 4 3.1 Beschrijving werking .......................................................................................................4 3.1.1 Aannemen van werk ...................................................................................................4 3.1.2 Release werking .........................................................................................................4 3.1.3 Microplanning .............................................................................................................5 3.2 Probleem ........................................................................................................................6 3.2.1 Beschrijving probleem.................................................................................................6 3.2.2 Vaststellen van de hoofdoorzaak ................................................................................7 3.2.3 Beschrijving van enkele oorzaken...............................................................................8 3.2.4 Belangrijkste oorzaak..................................................................................................8 3.2.5 Geen oorzaken ...........................................................................................................8 4 Onderzoek naar oplossing ...................................................................................................... 9 4.1 Agile principes ................................................................................................................9 4.2 Standpunt van bedrijf......................................................................................................9 4.3 Project vs. maintenance omgeving .................................................................................9 5 Nieuwe situatie ..................................................................................................................... 10 5.1 Context .........................................................................................................................10 5.2 Beschrijving ..................................................................................................................10 5.3 In de praktijk .................................................................................................................10 5.3.1 Voorstudie ................................................................................................................11 5.3.2 Eerdere ervaring .......................................................................................................11 5.3.3 Experiment 1 ............................................................................................................12 5.3.4 Experiment 2 ............................................................................................................14 5.3.5 Experiment 3 ............................................................................................................15 5.3.6 Verdere ontwikkeling ................................................................................................18 6 Evaluatie van het onderzoeksproces..................................................................................... 20 7 Nevenprojecten opgestart ..................................................................................................... 21 8 Gebruikte afkortingen............................................................................................................ 22 9 Bronvermelding..................................................................................................................... 22

2 van 22



1 Inleiding 1.1 Bedrijf Het bedrijf waarvoor ik deze paper geschreven heb, is KBC Global Services NV. KBC Global Services NV is het ICT bedrijf van de KBC Groep NV en staat in voor de ICT infrastructuur, ICT voorzieningen en ICT oplossingen voor de KBC Groep NV.

1.1.1 Visie, missie en waarden De waarden van de KBC Groep NV (de moedermaatschappij van KBC Global Services NV) zijn algemeen bekend als PRO: Professioneel, Respectvol en Open. Deze waarden worden ook uitgedragen door de verschillende niveaus. Je kunt deze waarden terugvinden op affiches binnen het bedrijf, tijdens presentatie van management en werkuitvoering, en je kunt ze zelfs horen tijdens een gesprek in de koffiehoek. De visie en missie van de KBC Groep NV en KBC Global Services NV zijn minder algemeen bekend, maar wel beschikbaar op het intranet.

1.2 Team De teams, of ook pools, waarop de principes toegepast worden zijn OKP Application & Infrastructure Consumer en Provider. Het Consumer team bestaat uit 5 teamleden en is verantwoordelijk voor de applicatielaag van de KBC Online website, de KBC Merchant Banking website en de KBC Online For Business website. Het Provider team bestaat uit 5 teamleden en is verantwoordelijk voor de applicatielaag van de KBC kantorenplatformen, het hoofdkantoorplatform, het intranetportaal, de KBC Corporate Banking website enz. Voor beide teams is er één teamleider (hiërarchische aansturing en evaluaties), Koen Janseghers, en één teamcoördinator (niet-hiërarchische aansturing), Karel Nijs. Om beide teams niet te belasten, wordt het leeuwendeel van de principes van deze paper toegepast binnen het Consumer team. Het Provider team zal minder deelnemen aan de experimenten, maar kan als referentiegroep gebruikt worden. De verdere tekst is dan ook geschreven in naam van het Consumer team. Wanneer er naar het Provider team verwezen wordt, zal de lezer hiervan op de hoogte gebracht worden.

1.3 Hulp De experimenten in deze paper waren niet mogelijk geweest zonder de hulp en steun van mijn diensthoofd, teamleider en teamleden. Van alle rollen was er betrokkenheid vereist op verschillende punten in het proces.

3 van 22



2 Aanpak Deze paper gebruikt de PDCA-cyclus (Plan – Do – Check – Act) om het probleem te beschrijven en aan te pakken. Plan

Het probleem en de gewenste oplossing beschrijven. Dit wordt aangepakt in sectie "3 Huidige situatie".

Do

De nieuwe manier van werken introduceren. Dit wordt beschreven in sectie "4 Onderzoek naar oplossing".

Check

Controleren of de nieuwe situatie een verbetering is en of de gewenste doelstellingen van de Plan fase gehaald worden. Dit wordt beschreven in sectie "5 Nieuwe situatie".

Act

Identificeren van de verschillen en deze proberen op te lossen in een nieuwe PDCA cyclus. Dit wordt beschreven in sectie "5 Nieuwe situatie" en verwezenlijkt met behulp van verschillende experimenten, de evaluatie en de analyse daarvan.

Verder komen er ook enkele elementen terug uit het 8D framework in sectie "3 Huidige situatie". Om de resultaten op te volgen, worden er geen metingen vast gelegd. Wel wordt de werking van het bord geëvalueerd door de leiding en besproken tijdens de poolmeetings.

3 Huidige situatie 3.1 Beschrijving werking 3.1.1 Aannemen van werk De teamleden kunnen op volgende manieren werk voorgeschoteld krijgen (in volgorde van dalende prioriteit): 1. Incidenten (NGO): productieproblemen die via de tweede lijn bij ons terecht komen. De prioriteit varieert hier van 1 (extreem dringend) tot 6 (helemaal niet dringend). Incidenten met prioriteit 4 tot en met 6 worden niet onmiddellijk opgenomen. 2. ECARs: binnenkomende aanvragen voor nieuwe, geplande ontwikkeling. 3. Defects: problemen aan code in ontwikkeling of test. Na de overgang van Acceptatie testen naar Productie mogen er geen defects meer zijn: deze worden dan allemaal incidenten.

3.1.2 Release werking Binnen OKP wordt het verouderde V-model gebruikt voor applicatieontwikkeling. De applicatiecode doorloopt verschillende fases: ontwikkeling, functionele testen, acceptatie testen en productieovergang. De productieovergang is geleidelijk en bestaat uit drie fases: piloten 1, piloten 2 en full park. Voor OKP zijn er zo er vier release momenten per jaar: maart, mei, augustus en oktober.

4 van 22



3.1.3 Microplanning Voor beide teams wordt er door de teamcoördinator een microplanning opgesteld. In deze microplanning staan de taken voor elke teamlid en wordt er tot 3 maanden vooruit gepland (meest ideale situatie). Bij het inplannen wordt er rekening gehouden met de ontwikkelingscyclus beschreven in "3.1.2 Release werking", maar deze work breakdown zit niet in de microplanning zelf. Voor elk teamlid wordt er een buffer van 1 tot 2 mensdagen voorzien voor NGO-taken. De microplanning wordt éénmaal per week op maandag overlopen tijdens de poolmeeting. Hierin wordt de haalbaarheid van de huidige planning afgetoetst en worden de teamleden gewezen op de geplande taken voor de komende week.

5 van 22



3.2 Probleem 3.2.1 Beschrijving probleem IS

Who

Who is affected by the problem? Teamleden, teamleider, projectleider, klanten, teamcoördinator. Who first observed the problem? (internal/external) Teamleider, diensthoofd.

How Often

How Much/ Many

When

Where

Why

What

To whom was the problem reported? Teamcoördinator What type of problem is it? Organisatie, prioriteiten What has the problem? Planning van teamleden What is happening? Deadlines worden niet gehaald Do we have physical evidence of the problem in our possession? Boekingen van de teamleden Why is this a problem? Niet volgen van gemaakte afspraken, veel overwerk Is the process where the problem occurred stable? Ja Where was the problem observed? Op de werkvloer, in de wandelgangen Where does the problem occur? Op de werkvloer

When was the problem first noticed? Altijd geweest When has it been noticed since? Nvt. Quantity of problem? Continu overwerk met pieken tijdens FET en ACC How Much is the problem causing in dollars, people, & Time? What is the trend (continuous, random, cyclical)? Cyclisch tot continu

IS NOT Who is not affected by the problem? Niemand Who did not find the problem? Teamleden

What does not have the problem? Planning van andere domeinen What could be happening but is not? Teamleden melden zelf onduidelijkheid rond taken en prioriteiten What could be the problem but is not? Te veel werk ingepland

Why is it not a problem? Uiteindelijk geraken we er wel

Where could the problem be located but is not? Tijdens de poolmeetings Where else could the problem be located but is not? Bij de FrontEnd domeinen When could the problem have been noticed but was not? Bij de vorige teamleider en dienst

How many could have the problem but don’t? Alle domeinen van de hele afdeling How big could the problem be but is not? Teamleden vallen uit door stress, verloop What could the trend be but is not? Continu

Has the problem occurred previously? Ja

Problem Description - Combine the relevant information, this will be your Problem Description Het actuele probleem wordt geformuleerd als "medewerkers werken aan de 'foute' zaken". 6 van 22



3.2.2 Vaststellen van de hoofdoorzaak Om de verschillende oorzaken te kunnen identificeren, is er een visgraat diagram opgesteld.

7 van 22



3.2.3 Beschrijving van enkele oorzaken Release werking Omdat er vier ontwikkelingsfases en vier releases per jaar zijn, is er een zekere overlap tussen de verschillende releases. Door deze overlap is het vaak moeilijk om de juiste prioriteiten tussen incidenten, ECARs en defects te bepalen. Officieuze vragen, telefoontjes en e-mails Natuurlijk moet deze optie altijd mogelijk zijn, maar momenteel wordt te veel tijd gestoken/verloren in dit illegale circuit van aanpassingen en ondersteuning. Een open landschap als kantooromgeving laat deze mogelijkheid nog eens extra toe. Poolmeeting Wanneer het zeer druk wordt, dreigt de poolmeeting wel eens weg te vallen. Hierdoor wordt de werkelijkheid niet meer afgetoetst en worden de teamleden niet meer gewezen op de geplande taken van de komende week. De poolmeetings kunnen ook van lange duur zijn. Standaard wordt er één uur ingepland, maar in de praktijk blijkt dit vaak uit te lopen tot anderhalf en zelfs twee uur. Softwarepakketten Er zijn veel verschillende organisatorische instrumenten waar de teamleden mee moeten werken: Lotus Notes, Quality Center, Service Center, MisKBC, ... Deze softwarepakketten houden elk apart prioriteiten bij die door de indieners ingesteld kunnen worden. Er zijn verschillende interpretaties van de prioriteiten binnen deze softwarepakketten. Vanuit de softwarepakketten kunnen ook e-mails verstuurd worden en deze worden niet altijd automatisch door het softwarepakket opgeslagen. Hierdoor zijn de verstuurde e-mails niet altijd beschikbaar voor alle belanghebbenden. KPIs Er zijn KPIs binnen de verschillende softwarepakketten voor procesopvolging, maar het belang van deze KPIs is niet duidelijk. Algemeen kan er gesteld worden dat de KPIs niet gehaald worden... en dat dit genegeerd wordt op alle niveaus in de hiërarchie.

3.2.4 Belangrijkste oorzaak Als belangrijkste oorzaak wordt de onduidelijkheid van taken en prioriteiten geselecteerd. Deze oorzaak bestaat zelf uit verschillende oorzaken: - Ieders taken worden ingepland met de microplanning en deze wordt regelmatig doorlopen. - Er worden prioriteiten gesteld op verschillende niveaus in de hiërarchie en door verschillende leidinggevenden tegelijk (ook bekend als "het probleem van meerdere managers"). - Problemen in productie hebben voorrang op al de rest, behalve bij bepaalde prioriteiten (4, 5 en 6) van productieproblemen. - De softwarepakketten hebben aparte en verschillende prioriteiten. Samengevat weten de teamleden gewoon niet meer wat er eerst gedaan moet worden.

3.2.5 Geen oorzaken Onderstaande zaken werden geïdentificeerd als geen oorzaak te zijn voor het gestelde probleem. Microplanning De microplanning is flexibel genoeg om wijzigingen in prioriteiten en tijdelijke blokkeringen op te vangen zolang er geen nieuw werk bijkomt of er ernstige wijzingen zijn.

8 van 22



4 Onderzoek naar oplossing Dit probleem is niet nieuw: er zullen genoeg bedrijven zijn wat met soortgelijke problemen te kampen hebben. Het is dus niet nodig om iets nieuws uit te vinden, maar we kunnen kijken wat de markt aanbiedt. Eén van de nieuwe trends binnen software development is Agile werken. Van deze manier van werken heeft de auteur al eens een paper geschreven en voor de theorie zou ik graag verwijzen naar [02]. In de volgende paragrafen zullen enkele bruikbare principes uitgelegd worden en deze worden aangepast naar de behoeften binnen de OKP teams.

4.1 Agile principes De Agile methodologieën maken gebruik van het iteratieve en incrementele software ontwikkelingsmodel, maar gaan een kortere iteratietijd gebruiken. De doorlooptijd van een iteratie bij de Agile implementatie loopt van één week tot één maand. Een Agile release bestaat uit meerdere iteraties en een Agile project bestaat uit meerdere releases (zie rechts). De planning gaat slechts per deelniveau gebeuren. Deze manier van plannen staat ook bekend als rolling wave planning, en wordt eveneens beschreven en gebruikt in Figuur 1 Agile Project Life Cycle de PMBok. Verder heeft Agile nog maar weinig gemeen met het klassieke watervalmodel. Eventueel kan er binnen een iteratie wel nog met het watervalmodel gewerkt worden.

4.2 Standpunt van bedrijf Ondanks dat Agile werken een groeiende trend is op de ICT markt, werken we binnen KBC Global Services NV vooral nog via het verouderde V-model, een variant van het klassieke watervalmodel. Tot eind 2009 was het officieel niet toegelaten om binnen de OKP en OSD afdelingen op een Agile manier te werken. Binnen het directoraat was er echter nog een afdeling, OKA, die wel al met een Agile implementatie, Scrum, werkt. Sinds 2010 is de OSD afdeling ook bezig met het introduceren van deze manier van werken. Omwille van enkele succesvolle implementaties binnen OSD zijn er Agile ideeën overgewaaid naar onze afdeling, OKP. Je kunt nu bijvoorbeeld al stand-up meetings waarnemen 's morgens in de wandelgangen.

4.3 Project vs. maintenance omgeving De Agile werking leent zich vooral voor projectwerking. Men kan niet zomaar de principes van sprints, burn charts, velocity, product owners en andere binnen een sterk veranderende maintenance omgeving introduceren. Verder hebben de maintenance taken niet altijd de "high uncertainty" en "volatility" nodig voor Agile.

9 van 22



Volgende principes zijn wel eenvoudig toepasbaar binnen een maintenance omgeving: Dagelijkse stand-up meetings

Op de dagelijkse stand-up meetings wordt de huidige status besproken. De projectleden zeggen kort (elevator pitch) waarmee ze bezig zijn en mogelijke problemen die ze ervaren. De problemen worden pas na de meeting meer diepgaand besproken. Op deze meetings is het hele team aanwezig. Het voordeel van deze dagelijkse meetings is dat het hele team upto-date en betrokken is met de ontwikkelingen van de collega’s, een noodzaak bij parallelle ontwikkeling.

Informatieradiatoren

Duidelijk zichtbaar opgestelde bronnen van informatie bruikbaar voor Management By Walking Around (MBWA). De informatieradiatoren bevatten projectvoortgang informatie, huidige problemen, technische ontwerpen, … en hun hoofdfunctie is om in één oogopslag de passant een indruk te geven van het project.

Rolling wave planning

Wanneer het niet mogelijk is om de deliverables al op te delen in werkpakketten, kan dit uitgesteld worden tot de details bekend zijn.

5 Nieuwe situatie 5.1 Context Als tijdelijke oplossing rond het probleem van onduidelijkheid rond taken en prioriteiten was er de afspraak ingevoerd dat alle teamleden op het einde van elke werkdag een overzicht van hun taken naar de leiding doorstuurt. In dit overzicht staat er: - Een overzicht van de taken waar ze gewerkt hadden. - Een korte beschrijving wat er precies uitgevoerd was. - De gespendeerde tijd. - De planning voor de volgende dag. Deze manier in combinatie met de microplanning is geen proactieve manier van werken: problemen met het werken aan de verkeerde taken worden pas te laat geïdentificeerd. Verder hebben de teamleden het gevoel dat ze extra (en onnodig) gecontroleerd worden door de leiding en wordt er kostbare tijd verloren op dagelijkse basis bij het opstellen van deze e-mails. Een voordeel van deze werking via dagelijkse e-mails is dan weer dat de teamleden een moment van zelfreflectie hebben over de invulling van de voorbije dag.

5.2 Beschrijving De nieuwe afspraken, gebaseerd op de Agile principes beschreven in "4.3 Project vs. maintenance omgeving", worden in praktijk gebracht op volgende manier: 1. Er wordt een whiteboard gebruikt om de taken per teamlid aan te duiden. 2. Dit takenbord geeft in één oogopslag de stand van zaken en werkverdeling weer. 3. Op dagelijkse stand-up meetings wordt er met het hele team de stand van zaken besproken.

5.3 In de praktijk Aan de hand van een aantal experimenten door continue verbetering wordt een manier van werken uitgewerkt. De nieuwe manier wordt onmiddellijk in gebruik genomen en de theorie wordt getest aan de praktijk. 10 van 22



Voor deze aanpak heb je een teamleider nodig die open staat voor nieuwe denk- en werkwijzen, en die ruimte toe laat voor experimenteren.

5.3.1 Voorstudie Voor we beginnen met onze experimenten, nemen we deel aan een stand-up meeting van de OSD afdeling en krijgen we een theoretische toelichting van de werking.

5.3.2 Eerdere ervaring Het Provider team had al ervaring met het werken met een informatieradiator (zie figuur). Opzet: -

Er is een whiteboard met een overzicht van defects en incidenten per team. Er is geen indicatie van teamleden of teamsamenstelling. De hoge prioriteiten staan bovenaan het bord. De lage prioriteiten staan onderaan het bord en worden in een andere kleur aangeduid. Er is een aparte zone Done waar de afgewerkte defects en incidenten geplaatst worden. De ECARs, incidenten en defects worden geplaatst op Post-Its met daarop het referentienummer en een korte uitleg.

Werking: - De teamcoördinator plaatst nieuwe defects en incidenten op het whiteboard. - De teamleden pikken ad hoc de defects/incidenten op van het bord. Wanneer het defect/incident van het whiteboard verwijderd zijn, zijn ze in verwerking. - Wanneer de defects/incidenten voltooid zijn, wordt de Post-It door het teamlid in de Done zone gehangen.

Voordelen aan deze manier van werken: 1. De prioriteiten van de defects en incidenten zijn duidelijk in gebruik. 11 van 22



2. Het is duidelijk hoeveel openstaande defects en incidenten er momenteel zijn. 3. Op elke Post-It kan je lezen wat het defect/incident inhoudt. Nadelen aan deze manier van werken: 1. Er is geen overzicht van de werklast per teamlid. 2. Er is geen manier om ECARs op te volgen. 3. Er is een groot whiteboard dat haast niet gevuld is. 4. Er is geen zichtbare status van voortgang. 5. Post-Its die van het bord gehaald worden, kunnen verloren gaan of vergeten worden. 6. Het principe van de informatieradiator komt hier slechts beperkt tot zijn recht: pas bij ernstige problemen (extreem veel defects/incidenten) zal het whiteboard aandacht trekken. 7. Er is geen betrokkenheid van de teamleden. Wanneer we de nadelen bekijken (en dan vooral 1, 2, 4, 6 en 7), kunnen we al vlug besluiten dat deze manier van werking geen oplossing is voor ons probleem.

5.3.3 Experiment 1 Tijdens het opstarten van het eerste experiment bevinden we ons midden tijdens de fase van functionele testen (FET). Omwille van problemen met het halen van de streefdatums ligt de focus volledig op defect en incidentwerking. Er wordt uitzonderlijk niet (of verwaarloosbaar) aan ECARs gewerkt. Opzet: -

We introduceren een whiteboard met een overzicht van defects per teamlid. De teamleden sturen nog steeds dagelijkse e-mails naar de leiding. Elk teamlid krijgt één swim lane. De hoge prioriteiten staan bovenaan het bord. De lage prioriteiten staan onderaan het bord en worden in een andere kleur aangeduid. Er is ongeveer eenmaal per week een stand-up meeting, maar er zit geen regelmaat in.

Werking: - De teamcoördinator voegt nieuwe defects toe aan het bord en verwijderd doorstreepte defectnummers. - De teamleden maken zelf een aanduiding van de status: o Doorstreept = gedaan o H = On Hold o W = Waiting - De projectleiders geven aan de teamcoördinator door welke defects prioriteit hebben (naast de prioriteiten in QC).

12 van 22



Figuur 2 Whiteboard van experiment 1

Voordelen aan deze manier van werken: 1. De teamleden weten waaraan te werken. 2. De werkverdeling is duidelijk: je ziet wie er overbelast is (zie team AGF) en waar het werk blijft hangen. 3. De prioriteiten van de defects zijn duidelijk in gebruik. Nadelen aan deze manier van werken: 1. Er is weer een tweede manier ontstaan om belangrijke defects aan te duiden, namelijk met een rood uitroepteken. 2. Resources kunnen zonder werk zitten (zie teamlid Petr). 3. Het is niet duidelijk met welke defects de teamleden niet meer verder kunnen. 4. Iedereen past het bord aan wanneer hij wil: er is geen dagelijkse gezamenlijke update. 5. Op dit bord kan je geen ECARs, noch incidenten toevoegen. Dit is blokkerend voor bijvoorbeeld Wim, omdat hij vooral via incidenten werkt. 6. Tijdens de stand-up meetings blijft dat defectnummers niets zeggend zijn: we kunnen het bord niet als hulpmiddel gebruiken en zijn verplicht om een PC of print-out te raadplegen. 7. Er is géén manier voor zelfreflectie van de voorbije dag. Omwille van het grote aantal nadelen is deze manier van werken enkel geschikt als tijdelijke oplossing. Vooral nadeel 5 maakt dat dit bord niet meer gebruikt kan worden na de FET periode. Verder is er niet echt een meerwaarde aan dit bord vol met defects: de lijst van defects, prioriteit, toegewezen teamlid en status kan eenvoudig uit de Quality Center tool getrokken worden. Door de teamleden wordt er dan ook opgemerkt dat er enkel overhead is. Voor de leiding is er echter wel een duidelijk overzicht van de werklast.

13 van 22



5.3.4 Experiment 2 Binnen het tweede experiment wordt een nieuwe whiteboard werking geïntroduceerd en starten ook de dagelijkse stand-up meetings. Opzet: -

-

We introduceren een whiteboard met een overzicht van taken per teamlid. De teamleden sturen nog steeds dagelijkse e-mails naar de leiding. Elk teamlid krijgt één vak. De ECARs, incidenten en defects worden geplaatst op Post-Its met daarop het referentienummer en een korte uitleg. Eventuele prioriteiten worden aangeduid op de Post-Its. Incidenten worden met een rode titel geschreven. Herhalende taken worden aangeduid met het recycleersymbool. Er zijn vier algemene zones toegevoegd: o To Do: taken die nog gedaan moeten worden. o Assessment Needed: taken die nog geschat moeten worden. o Parked: geparkeerde taken. o Done: uitgevoerde taken. Taken in het vak van een teamlid worden beschouw als Busy.

Werking: - De teamcoördinator voegt nieuwe taken toe aan het bord in de zone To Do. - De projectleiders geven aan de teamcoördinator door welke taken prioriteit hebben (naast de prioriteiten in SC en QC). - Op een dagelijkse stand-up meeting wordt het bord overlopen. De teamleden geven hier kort toelichting bij de taken. Eventueel worden er aanpassingen gemaakt aan het whiteboard.

Figuur 3 Whiteboard van experiment 2 14 van 22



Voordelen aan deze manier van werken: 1. Deze versie van het bord bevat alle taken: ECARs, incidenten en defects. 2. Er is een duidelijk onderscheid tussen To Do, Busy, Assessment Needed, Parked en Done. 3. De teamleden weten waaraan te werken. 4. De werkverdeling is duidelijk: je ziet wie er overbelast is (zie team Davy D.) en waar het werk blijft hangen (Assessment Needed). 5. Er is een manier voor zelfreflectie van de voorbije dag. Nadelen aan deze manier van werken: 1. Het is niet duidelijk wie er taken parkeert (naar Parked verplaatst) en hoe lang deze daar blijven. 2. Het is niet duidelijk wie er taken voltooid (naar Done verplaatst) heeft. 3. Het is niet duidelijk waar iemand precies mee bezig is. 4. Het is niet duidelijk wie er welke Assessements moet maken. 5. Iedereen past het whiteboard aan wanneer hij wil. 6. Er zitten te veel teamleden op dit bord: Davy N. en Bram zitten in projectwerking en zullen altijd maar twee Post-Its hebben. 7. De overhead van de dagelijkse mails wordt nu duidelijk en de teamleden melden dit ook. 8. De betrokkenheid is laag: tijdens de stand-up meeting update de teamcoördinator het bord. De teamleden moeten (te) lang luisteren naar de anderen en die hun taken & problemen. 9. De vakjes voor elk teamlid zijn te klein (zie Davy D.). Deze versie van het whiteboard duidt al beter de verschillende fases van ontwikkeling aan. Verder is er per teamlid een overzicht van de verschillende soorten taken mogelijk. De grootste problemen met dit bord zijn de onduidelijkheid van de taken in de aparte vakken (To Do, Busy, Assessment Needed, Parked en Done) en de lage betrokkenheid. Samen met enkele kernleden van het team en de teamleider wordt het whiteboard van het tweede experiment besproken en worden er verbeteringen aangekaart. Deze verbeteringen worden aangebracht in het derde experiment.

5.3.5 Experiment 3 Binnen het derde experiment wordt een nieuwe whiteboard werking geïntroduceerd en worden de dagelijkse stand-up meetings verder gezet. De dagelijkse e-mails worden afgeschaft. Opzet: - We introduceren een whiteboard met een overzicht van taken per teamlid en opdeling per fase. - De teamleden sturen géén dagelijkse e-mails meer naar de leiding. - Elk teamlid krijgt één swim lane. - Eventuele prioriteiten worden aangeduid op de Post-Its. - Voor incidenten wordt er met een rode Post-It gewerkt zodat deze meteen opvallen. - Herhalende taken worden aangeduid met het recycleersymbool. - De vier algemene zones zijn er nog, maar enkel de zones To Do en Done worden gebruikt. - Voor assessments wordt er het woord "Ass." op de Post-It geplaatst. - Wanneer beschikbaar wordt er op de Post-Its de totale werklast van de taak geplaatst. - Resources in projectwerking, Bram en Davy N., worden van het bord verwijderd. Werking: - De teamcoördinator voegt nieuwe taken toe aan het bord in de zone To Do. - De projectleiders geven aan de teamcoördinator door welke taken prioriteit hebben (naast de prioriteiten in SC en QC).

15 van 22


-

-


Op een dagelijkse stand-up meeting wordt het bord overlopen. De teamleden geven hier kort toelichting bij de taken. Eventueel worden er aanpassingen gemaakt aan het whiteboard. Tijdens de stand-up meetings worden er streefdatums voor de taken aangeduid.

Om meer betrokkenheid te creëren worden bij de ingebruikname van het bord alle teamleden betrokken. Het bord start leeg en ieder teamlid krijgt zijn stapeltje Post-Its uit het vorige experiment. Vervolgens mogen de teamleden elk om de beurt de Post-Its in de juiste ontwikkelingsfase hangen van hun swim lane. Telkens geven ze ook uitleg aan de groep in de vorm van een elevator pitch. Deze manier van werken heeft onmiddellijk succes omdat de teamleden ten eerst zelf inspraak hebben in de nieuwe vorm van het bord en nu op een interactieve manier het bord kunnen opzetten.

Figuur 4 Whiteboard van experiment 3 - voor gebruik

16 van 22



Figuur 5 Whiteboard van experiment 3 - na de initialisatie meeting

Figuur 6 Whiteboard van experiment 3 – close-up 17 van 22



Figuur 7 Whiteboard van experiment 3 – na twee werkweken

Voordelen aan deze manier van werken: 1. Er is meer betrokkenheid van het team. 2. De dagelijkse stand-up meetings werken; de teamleden komen er nu zelfs spontaan achter vragen. 3. Deze versie van het bord bevat alle taken: ECARs, incidenten en defects. 4. Er is een duidelijk onderscheid tussen To Do, Busy, Assessment, Parked en Done. 5. De teamleden weten waaraan te werken. 6. De werkverdeling is duidelijk: je ziet wie er overbelast is (zie team Wim) en waar het werk blijft hangen (To Do strook). 7. Er is een manier voor zelfreflectie van de voorbije dag. Nadelen aan deze manier van werken: 1. Er is nog testfase tussen Busy en Done: hierdoor weet je niet welke taken er klaar zijn voor testen. 2. Het whiteboard is te klein aan het worden. 3. De stand-up meetings zijn eerste wat schuift bij dringende problemen. 4. Het is niet duidelijke welke taken bij To Do het dringendste zijn. 5. Het is niet duidelijk wat de prioriteit van de verschillende taken is. Er zitten nog te veel gebreken in de huidige manier van werken zoals nadelen 3, 4 en 5. Qua prioriteiten is er nu nog steeds sturing van de teamcoördinator nodig: deze voegt tijdig nieuwe Post-Its toe aan het whiteboard en bij dringende incidenten worden deze (na overleg met de medewerker) meteen in Busy geplaatst.

5.3.6 Verdere ontwikkeling We hebben nu al nieuwe manier van werken die de teamleden bevalt en werkt voor de leiding. Nu moet deze werking verder groeien in maturiteit.

18 van 22



Na verloop van tijd verwachten we volgende resultaten (in volgorde van groeiende maturiteit): - De stand-up meetings vinden dagelijks plaats. Het tijdstip past zich aan de drukte aan. - De teamleden vullen zelf het bord aan. - De teamleden organiseren en leiden zelf de stand-up meetings. De aanwezigheid en het startsignaal van de teamcoördinator of teamleider is niet meer nodig. - De teamleden stellen zelf hun takenlijst op (na macroplanning van de teamcoördinator). Verder zou ik willen opmerken dat elke vorm van opvolging extra werk introduceert bij de teamleden. De informatie op het bord is altijd beschikbaar in de normale softwarepakketten zoals de microplanning, MisKBC, Service Center en Quality Center. Het extra werk heeft hier echter een meerwaarde waar vooral het menselijke aspect in uitblinkt: - Het schept duidelijkheid voor de leiding (MBWA mogelijk). - De teamleden weten van elkaar wie waar mee bezig is en kunnen elkaar helpen. - Er wordt meer betrokkenheid gecreëerd. - De verantwoordelijkheid wordt bij de teamleden gelegd (team empowerment).

19 van 22



6 Evaluatie van het onderzoeksproces Wat kunnen we leren van het gebruikte onderzoeksproces zodat dit in de toekomst beter kan? 1. Aanpak. Tijdens deze studie zijn we te vlug in de Do-fase van het Deming Wheel gegaan: er is te veel gewerkt via trial & error. Er kan tijd gespaard worden door op voorhand het probleem grondig te bestuderen, de root cause(s) vast te leggen, de mogelijkheden uit te werken en het team te betrekken. Ook naar de verschillende types en mogelijkheden van borden kon op voorhand meer onderzoek uitgevoerd worden. 2. Het betrekken van de groep. Het betrekken van de groep in de uitwerking van het laatste bord heeft belangrijke voordelen gehad zoals nieuwe ideeën en meer betrokkenheid. Er moet echter toch opgelet worden dat men niet te zeer democratische beslissingen krijgt. De typische informaticus is schuw ten opzichte van organisatie en administratie, en de oplossing zou te zeer neigen naar een vrijgeleide voor taakindeling. 3. Meten van resultaten. Voor deze studie en experimenten werden er geen metingen gedefinieerd. De evaluatie van de experimenten werd telkens besproken met de leiding en tijdens de poolmeetings. Deze manier van verzamelen van resultaten is sterk subjectief en het interpreteren van impliciete (en soms subversieve) opmerkingen is niet eenvoudig. Het gevaar van de ownership trap loert ook altijd om de hoek en tijdens het uitvoeren van de experimenten is er een waarnemer op afstand nodig.

20 van 22


7 Nevenprojecten opgestart In sectie "3.2.1 Beschrijving probleem" worden verschillende oorzaken geïdentificeerd. Deze tekst behandelt enkel de oorzaak "onduidelijkheid rond taken en prioriteiten", maar ondertussen zijn er parallelle acties opgestart om de andere oorzaken aan te pakken. De beschrijving hiervan valt buiten het bestek van deze paper. Ter volledigheid geef ik hier een beknopt overzicht: Oorzaak

Opgestarte activiteit

Officieuze vragen, telefoontjes en e-mails

Er is een Help Desk procedure geschreven en elke week krijgt één teamlid de niet-zo benijdenswaardige rol van Help Desk. Deze Help Desk verantwoordelijke staat in als eerste lijn voor alle vragen telefoontjes en e-mails gestuurd naar de algemene e-mail inbox.

Te lange poolmeetings

Er zijn nieuwe afspraken gemaakt rond de voorbereiding: alle teamleden bereiden nu de poolmeeting voor zodat de meetingduur verkort wordt.

E-mails verstuurd uit de Er zijn nieuwe afspraken gemaakt rond het expliciet opslaan van de tools worden niet altijd verzonden e-mails. opgeslagen Onduidelijke prioriteiten

Wanneer er prioriteiten gesteld worden of wijzigen, neemt de leiding dit op met de teamcoördinator en worden er geen afspraken met de teamleden zelf gemaakt.

Prioriteiten in verschillende tools

Met de projectleiders is er afgesproken dat de prioriteiten in de Service Center en Quality Center tools strikt gevolgd worden.

Onduidelijke verwachtingen

Er is een document in opbouw wat precies beschrijft wat er van elk teamlid verwacht wordt in kader van nieuwbouw en onderhoud.

Belang van KPIs niet duidelijk

Er wordt een workshop gepland waar de ECAR- en incidentprocessen besproken. In deze workshop gaan we de teamleden apart het proces laten beschrijven en op brown paper de juiste werking aanduiden.


8 Gebruikte afkortingen Afkorting

Omschrijving

OKP

Ontwikkeling Kantoren en Platformen (afdeling)

OSD

Ontwikkling SD (afdeling)

ODK

Ontwikkeling Distributie Kanalen (directie)

OKA

Ontwikkeling Kantoor Applicaties (afdeling)

ECAR

Extra Catalogue Request

A&I

Application & Infrastructure (team binnen OKP)

QC

Quality Center

SC

Service Center

MisKBC

Management Information System for KBC

NGO

Niet-Geplande ontwikkeling

FET

Functionele Test periode

ACC

Acceptatie Test periode

PROD

Productie

9 Bronvermelding Nr Beschrijving [01] Where does Agile not work? http://www.rallydev.com/agileblog/2009/09/where-does-agile-not-work/ [02] GAP analyse: Agile projectmanagement en de PMBok aanpak voor kennisgebieden Project Integration, Scope en Time Management http://www.karelnijs.be/Projects/WhitePaper_Agile_PM_en_PMBok/GAPanalyse_Agile_ en_PMBok.html [03] Kanban Development oversimplified http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html [04] The Software Project Manager's Bridge to Agility, Michele Sliger; Stacia Broderick, 2008 [05] Quality Management for Organizational Excellences, Introduction to Quality, 6th edition, David L. Goetsch, Stanley B. Davis, 2010

Agile principes in een maintenance omgeving

Recommend Documents