LEAN SOFTWARE D EVELOPM ENT
IMP LEMEN TA TIE VAN EE N LEA N APPROACH IN EEN SO FTWARE D EVE LOPMEN T TEA M
door:
Bert Bouwknegt
Universiteit van Groningen
Faculteit Economie en Bedrijfskunde, AOG
8-11-2016 Master Thesis
2016
Tjalk 13 7944RP Meppel +31 (0)6 460 14 115 bert@bertbouwknegt.nl Studentnummer: S2172747
V1.0
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 2
VOORWOORD
Na een reis van 5 jaar kan ik nu eindelijk stellen dat mijn ambitie om de universitaire studie Business Administration af te ronden tot een eind is gekomen met als laatste resultaat deze Master Thesis. Het traject om zover te komen heb ik een aantal malen onderschat, daar waar het volgen van colleges en het doen van tentamens relatief gezien vlot verliep en het leek of het afronden van de studie nog een formaliteit zou zijn, is het schrijven van deze thesis een forse uitdaging geweest. Toch kijk ik met voldoening terug op deze periode.
Het opstarten van het schrijven van deze thesis was uitdagend en tijdrovend. Naast de vele veranderingen bij Achmea, waar de thesis is geschreven is, veranderde er voor mij persoonlijk ook veel. Gedurende de studie werd mijn werkgever door een fusie Achmea, veranderde mijn werklocatie van Amersfoort naar Zwolle, kreeg ik er een kleine 15.000 nieuwe collega’s bij en heb ik de uitdaging van een nieuwe baan aangenomen door van projectleider de stap te maken naar teammanager van een software ontwikkelteam. Zonder de support van velen was het schrijven van deze thesis niet moeilijk maar onmogelijk geweest.
Mijn voormalige werkgever Agis en mijn huidige werkgever Achmea wil ik bedanken voor de kans en ondersteuning om een universitaire studie te mogen doen en een onderzoek te kunnen uitvoeren op de werkvloer. In het bijzonder wil ik Agnes van Daal bedanken die me op het idee heeft gebracht deze studie te gaan doen, en Marijn Wegh die me in het laatste half jaar een behoorlijke duw gegeven heeft om de thesis af te gaan ronden. Mijn team, wil ik bedanken voor de mogelijkheid om ze als “experiment” te mogen gebruiken hoewel ze dat niet wisten. De heer J.C. Wortmann (Hans) van de Rijksuniversiteit Groningen wil ik bedanken voor de supervisie op het onderzoek en de heer J.A.C. Bokhorst voor de tweede beoordeling. De heer Wortmann heeft me ondanks lange tussenpozen en het 3 keer opnieuw starten succesvol door het proces van schrijven van een thesis geholpen en me steeds van waardevolle feedback voorzien.
Als laatste wil ik mijn gezin en in het bijzonder mijn vrouw Lydia bedanken. Niet alleen gedurende de laatste fase van afstuderen, maar gedurende mijn hele studie ben jij in me blijven geloven en hebt me gemotiveerd wanneer dat nodig was.
Iedereen die deel uitmaakte van mijn reis wil ik bedanken en ik wens u, de lezer, veel plezier met het lezen van deze thesis.
Bert Bouwknegt Meppel, 2016
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 3
SAMENVATTING
Doel: Om antwoord te kunnen geven op de vraag naar steeds flexibelere en bedrijfszekerdere systemen, waarbij de gevraagde snelheid van opleveren niet ten koste gaat van de kwaliteit, wordt recent Lean IT toegepast bij het ontwikkelen van software. Een van de gedachten achter Lean is het continue verbeteren van processen, uiteraard kan het ontwikkelen van software ook continu verbeterd worden. Het doel van deze studie is het onderzoeken of de succesfactoren van Lean software development in een case study van invloed zijn op het resultaat. Verder is onderzocht wat de resultaten zijn van het invoeren van een aantal Lean methodieken in een Software development team.
Opzet: Om dit onderzoek te kunnen starten is er een literatuuronderzoek gedaan naar Lean in het algemeen en de toepassing van Lean concepten in een IT voortbrengingsketen in het bijzonder. Daarna is met kwalitatieve methoden onderzocht welke succesfactoren van invloed zijn geweest bij een Lean IT implementatie en wat de uiteindelijk resultaten van die implementatie waren.
Methoden: Het onderzoek is uitgevoerd tijdens de implementatie van Lean methodieken in een Software development afdeling van Achmea. Kort na de implementatie zijn interviews gehouden met de medewerkers en is onderzocht welke succesfactoren volgens deze medewerkers van invloed zijn geweest op de uiteindelijke resultaten van de implementatie. Verder zijn er tijdens een veld experiment een tweetal interventies gedaan in het proces van ontwikkelen van software die volgens literatuur van invloed zijn op de kwaliteit van software. Voor en na de interventies zijn metingen gedaan om te onderzoeken wat het effect van deze interventies is geweest op de genoemde kwaliteit. Om dit te kunnen doen zijn de gegevens van 15 projecten van zowel voor als na de interventies onderzocht, de uitvoering van die projecten lag tussen 2013 en 2016.
Resultaten: Van een tweetal in de literatuur genoemde succesfactoren wordt in deze case study vastgesteld dat deze niet van invloed waren op het uiteindelijke resultaat, voor 6 andere succesfactoren geldt dat wel. Het aantal defecten dat gevonden wordt in de geleverde software daalt na de interventies met Lean methodieken in de Software development afdeling. Ook verschuift het moment dat defecten worden opgemerkt naar een eerder moment in het proces van ontwikkelen van software. De productiviteit van het Software development team laat een verbetering zien na de invoering van Lean methodieken gemeten in het aantal uren dat per functiepunt wordt besteed aan de ontwikkeling van software.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 4 Conclusie: Er kan worden geconcludeerd dat een aantal van de succesfactoren die in de literatuur worden genoemd ook in deze case study van invloed zijn geweest op het resultaat van het invoeren van Lean methodieken op een software development afdeling. Verder kan worden geconcludeerd dat de resultaten van het invoeren van deze methodieken van positieve invloed zijn op de kwaliteit van de geleverde software en de fase waarin defecten in software worden gevonden. Hoewel de productiviteit van het software development team is gestegen na de invoering van Lean methodieken kan niet vastgesteld worden dat deze invoering debet is geweest aan de productiviteitsstijging.
Kernwoorden: Lean software development, Software process improvement, Kwaliteit.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 5
Inhoud
Voorwoord ... 2Samenvatting ... 3
Inleiding ... 7
1.1 Software ‘Lean’ ontwikkelen ... 7
1.2 Achmea ... 8
1.3 Probleem- en vraagstelling ... 8
1.4 Structuur van de Thesis ... 9
2 Theoretisch kader ... 11
2.1 Lean ... 11
2.2 Lean software development ... 13
2.3 Succesfactoren voor Lean software development ... 17
2.4 Kwaliteit van software ... 19
2.5 Conceptueel model ... 20
3 Onderzoeksopzet ... 22
3.1 Methode van onderzoek ... 22
3.2 Datacollectie ... 23
3.2.1 Respondenten ... 25
3.2.2 Veld experiment ... 25
3.3 Data analyse ... 25
3.4 Kwaliteit van onderzoek ... 27
3.4.1 Validiteit ... 27
3.4.2 Betrouwbaarheid ... 28
3.5 Beperkingen van dit onderzoek... 28
3.6 Kennisproducten... 29
4 Case Study Microsoft Competence Center AB Suite Achmea: resultaten ... 30
4.1 Achmea en Lean ... 30
4.2 Succesfactoren van Lean software development ... 31
4.2.1 Creëer een Lean Team... 32
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 6
4.2.2 Zorg voor goede communicatie tussen medewerkers en tussen teams ... 32
4.2.3 Commitment van het Management ... 32
4.2.4 Ondersteuning en Training van medewerkers ... 33
4.2.5 Zorg voor een goede taak specificatie ... 33
4.2.6 Laat resultaten zien - Monitor de werkstroom ... 33
4.2.7 Selecteer de juiste verspilling op om te lossen, begin klein ... 34
4.2.8 Monitor het proces ... 34
4.2.9 Overzicht interviewresultaten ... 35
4.3 Veld experiment: Interventies ... 36
4.3.1 Creëren van cadans en continue flow ... 36
4.3.2 Visualiseren van de werkstroom en Monitoren van processen ... 37
4.3.3 Projecten uitgevoerd voor en na de interventies ... 39
4.3.4 Overzicht en analyse veld experiment ... 41
5 Conclusie en aanbevelingen: Lean Software Development ... 45
5.1 Conclusies ... 45
5.2 Toekomstig onderzoek ... 46
6 Referenties ... 47
Bijlage 1: Topiclijst interviews ... 50
Bijlage 2: Onderzochte projecten ... 53
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 7
INLEIDING
1.1 Software ‘Lean’ ontwikkelen
In de huidige moderne wereld is software niet meer weg te denken. Veel bedrijven leunen voor hun succes en winstgevendheid op software en geautomatiseerde processen. Andere bedrijven bestaan zelfs alleen bij de gratie van software, zoals Facebook en Google. Dienstverlenende bedrijven zoals zorgverzekeraars zijn voor het uitvoeren van een strategie van operational excellence afhankelijk van goed werkende geautomatiseerde processen.
Ondanks het belang van software in de wereld, is het voortbrengingsproces van software niet altijd succesvol te noemen. De voorbeelden van mislukte softwareprojecten bij overheid en bedrijfsleven zijn legio. Vaak worden deadlines overschreden, lopen de kosten uit de hand en voldoet het uiteindelijk opgeleverde product niet aan de verwachtingen. Een sprekend voorbeeld daarvan is de OV chipkaart.
Om antwoord te kunnen geven op de vraag naar steeds flexibelere en bedrijfszekerdere systemen, waarbij de gevraagde snelheid van opleveren niet ten koste gaat van de kwaliteit, wordt recent Lean toegepast bij het ontwikkelen van software. Een van de gedachten achter Lean is het continue verbeteren van processen. Uiteraard kan het ontwikkelen van software ook continu verbeterd worden. Hoe pas je echter Lean toe als het niet gaat om fysieke producten in een productieproces, maar om onbewuste kennis (tacit knowledge) van leden van een software development team dat een ontastbaar product bouwt.
Er is veel geschreven over software development methodieken, in een onderzoek naar publicaties rondom software development in combinatie met Lean werden alleen al meer dan 10.000 artikelen gevonden (Pernståla et al, 2013). Toch is er nog steeds ruimte onderzoek te doen naar de succesfactoren en barrières van het implementeren van Lean in een software development team en of Lean daadwerkelijk positief bijdraagt aan het succes van software development projecten. Met de resultaten van dit onderzoek wordt meer kennis verkregen hoe Lean toegepast kan worden in een software development team en of Lean IT daadwerkelijk leidt tot een beter resultaat.
In dit hoofdstuk wordt kort ingegaan op de achtergrond en het onderwerp van dit onderzoek.
Daarnaast wordt ingegaan op de doelstelling, probleemstelling en de onderzoeksvragen.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 8 1.2 Achmea
In Nederland is Achmea een van de bekendste verzekeraars met merken als Zilveren Kruis, Avero, Agis, Centraal Beheer en FBTO. Het verkopen van verzekeringen is het eerste waar je aan denkt bij Achmea, het complexe landschap van merken, producten en wetgeving dat ondersteund moet worden met grotendeels zelf ontwikkelde software is uiteraard veel minder bekend. Omdat Achmea als bedrijf een product is van vele fusies en overnames, is er sprake van een veelheid aan systemen en processen, in recente jaren is een begin gemaakt met het rationaliseren van dat systeemlandschap, waarbij het samenvoegen van systemen en het uitfaseren van oude systemen grote aandacht krijgt. Voor de toekomst van IT bij Achmea is gekozen voor het vereenvoudigen van architectuur, waarbij systemen en processen overgaan naar een aantal standaardcomponenten zoals SAP en Microsoft Producten als Sharepoint.
Achmea IT is zich ervan bewust dat de rol van IT nog steeds toeneemt, en voorwaardenscheppend is voor een zich continu verbeterende klantgerichte organisatie waarbij snel inspelen op behoeften in de markt ondersteund moeten kunnen worden met de juiste IT oplossingen.
1.3 Probleem- en vraagstelling
Binnen Achmea is de laatste jaren op verschillende afdelingen “Lean” ingevoerd om processen te ontdoen van onnodige ballast en de performance continu te kunnen verbeteren. Achmea heeft daarvoor het programma SENS opgestart. SENS (Samen Effectief Naar Succes) is een combinatie van Lean en het centraal stellen van de klant. Achmea IT is een van de laatste organisatieonderdelen waar deze zogenaamde “SENS-golf” wordt uitgerold. Zoals Lean anders is voor een kantooromgeving in vergelijking tot een productieomgeving, zo anders is Lean voor een Software Development Team ook. Er liggen geen fysieke producten op voorraad bijvoorbeeld zoals in een industriële productieomgeving, of een stapel te verwerken polis aanmeldingen op een administratieve afdeling.
Achmea IT is vastbesloten om ook het ontwikkelen van software Lean te maken. Ontwikkelingen op de markt volgen elkaar snel op, de roep om efficiëntere processen en besparingen op IT uitgaven wordt steeds groter. Maar hoe maak je een software development afdeling Lean, wat zijn de succesfactoren en zijn er methoden om het resultaat van het invoeren van Lean IT te meten. Dit onderzoek vindt plaats ten tijde van het invoeren van Lean op een software development afdeling van Achmea IT, de resultaten kunnen worden gebruikt om de invoering van Lean IT op deze en andere software development afdelingen van Achmea IT te ondersteunen en te verbeteren. Het invoeren van een Lean aanpak in software development is
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 9 een onderwerp dat de aandacht heeft in de wetenschappelijke literatuur , (Pernståla et al, 2013).
In die brede discussie over software development en Lean en Agile principes is nog steeds ruimte om onderzoek te doen naar succesfactoren van Lean en de bijdrage die Lean kan leveren aan de performance van een software development afdeling. Dit onderzoek wil een bijdrage leveren aan het wetenschappelijke begrip van Lean software development.
Om de bovenstaande doelstelling te realiseren, is de volgende probleemstelling gedefinieerd:
“Op welke wijze kan Lean IT bijdragen aan de kwaliteit en performance van een software development afdeling en kunnen de resultaten daarvan gemeten worden.”.
Om deze centrale vraag te kunnen beantwoorden moeten een aantal deelvragen beantwoord worden:
1. Wat wordt verstaan onder Lean en hoe sluit Sens van Achmea daarop aan.
2. Hoe wordt Lean toegepast in IT Software Development, wat zijn de factoren die zorgen voor een succesvolle implementatie van Lean IT.
3. Is invoering van Lean IT van invloed op de performance en kwaliteit van een software development team.
4. Hoe kunnen de resultaten van het invoeren van Lean in een software development team meetbaar en zichtbaar gemaakt worden.
Om antwoord te geven op deze vragen, wordt in dit onderzoek een literatuurstudie gedaan om de eerste twee deelvragen te kunnen beantwoorden. Voor het beantwoorden van deelvragen 3 en 4, wordt onderzoek bij Achmea gedaan in de vorm van een case study, gecombineerd met veld experiment, waarbij de onderzoeker onderdeel is van een team dat Lean IT gaat implementeren bij een software development afdeling.
1.4 Structuur van de Thesis
In dit hoofdstuk wordt de thesis geïntroduceerd en wordt kort ingegaan op Achmea, de onderneming waar het onderzoek wordt uitgevoerd. Verder wordt de probleemstelling gepresenteerd gevolgd door de onderzoeksvragen. In hoofdstuk 2 wordt de theoretische achtergrond van dit onderzoek beschreven. Lean in het algemeen en Lean in IT omgevingen worden achtereenvolgens besproken. Het volgende hoofdstuk, hoofdstuk 3, zet uiteen welke onderzoeksmethode gebruikt is voor deze thesis. Hoofdstuk 4 beschrijft de case study die uitgevoerd is bij Achmea en geeft inzicht in de implementatie van Lean IT in een software development team. Tevens worden de gevonden resultaten geanalyseerd, waarna in hoofdstuk 5
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 10 de conclusie en het antwoord op de onderzoeksvraag wordt gepresenteerd. Ook wordt in hoofdstuk 5 ingegaan op de beperkingen van dit onderzoek en mogelijkheden voor toekomstig onderzoek.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 11
2 THEORETISCH KADER
In dit hoofdstuk wordt Lean besproken, er wordt gekeken naar de originele vorm van Lean, maar ook naar het gebruik van Lean in IT voortbrengingsketens.
2.1 Lean
De filosofie achter Lean is afgeleid van het Toyota Production System (TPS) dat door Toyota tussen 1948 en 1975 werd ontwikkeld (Ohno, 1988) en werd ingezet bij de productie van auto’s.
Door het gebruik van de Lean principes lag de productiviteit in Japan een factor twee hoger dan in het Westen en de kwaliteit was vele malen (factor 100) beter dan in het Westen (Womack et al, 1990). In de jaren 90 werd TPS bekend onder de naam Lean Manufacturing (Holweg 2007).
De centrale gedachte achter TPS was het leveren van een hoge kwaliteit tegen lage kosten met snelle doorlooptijden in het productieproces. Geïnspireerd door de successen van Toyota passen veel organisaties een vorm van Lean management toe op hun dagelijkse processen om verspilling te elimineren en inefficiëntie uit productiesystemen te halen. Hoewel in eerste instantie Lean bedacht is vanuit industriële productie, worden tegenwoordig Lean technieken ook toegepast in andere branches, zoals verzekeringsmaatschappijen, ziekenhuizen, overheden en IT-afdelingen (Kindler, 2007).
De term “Lean proces” heeft in de loop der tijd vele definities gekregen, Shah en Ward(2007) definiëren een Lean proces als een geïntegreerd sociaal-technisch systeem met als hoofddoel het elimineren van verspilling door het verminderen of minimaliseren van variabiliteit. Volgens andere onderzoekers (Abdulmaleka, 2007) omvat Lean productie de identificatie van alle soorten van afval in de waarde stroom van de supply chain en de implementatie van de nodige tools om verspilling te elimineren.
In de Lean filosofie wordt gezocht naar elke vorm van verspilling in de onderneming, worden resources geoptimaliseerd en wordt er een cultuur gecreëerd die toegewijd is aan het identificeren en koesteren van klanttevredenheid. Deze filosofie is gebaseerd op de eerste drie kernprincipes van Lean:
1. Identificatie van klantwaarde:
2. Elimineren van verspilling:
3. Generatie van een soepele productie flow: (Womack et al, 1990)
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 12 Later zijn door dezelfde onderzoekers vijf principes gedefinieerd waarmee ook nu nog Lean production gekenmerkt wordt (Womack, Jones, 2003):
1. Het identificeren van de klantwaarde.
2. Het optimaliseren van de waarde stroom (Value stream mapping).
3. Genereren van een soepele productieflow door het beheersen en het elimineren van afval.
4. Het activeren van de demand pull door het synchroniseren van de klantenvraag en informatiestroom.
5. Continue verbetering van alle producten processen en diensten.
Womack en Jones (2003) Stellen dat waarde wordt toegevoegd door te doen wat noodzakelijk is om te leveren wat de klant wil. Het specificeren van de waarde van een product of dienst vanuit het perspectief van de klant is de eerste stap op weg naar het leveren van kwaliteit. Organisaties zijn meestal wel in staat om de producten te leveren die ze al jaren produceren, maar dit kan neerkomen op het produceren van de verkeerde producten en diensten op de juiste manier. Dit is een vorm van verspilling (Womack, Jones, 2003).
Het identificeren van de hele waarde stroom voor elk product of dienst is het tweede principe van Lean. Alle onderdelen van een organisatie moeten werken als 1 geheel. Womack en Jones (2003) gebruiken in hun boek het voorbeeld van een fabrikant van vliegtuigmotoren. Toen de fabrikant de waarde stroom in kaart bracht voor alle typen motoren werd veel verspilling ontdekt. Het produceren van deze motoren kende 4 fasen op verschillende afdelingen, maar deze afdelingen communiceerden niet met elkaar. Door de processen en activiteiten aan elkaar uit te leggen ontdekten ze grote verspillingen en konden bijna direct activiteiten gestopt worden waardoor kosten werden bespaard.
Het derde principe is het creëren van flow, een product of service moet zo snel en soepel mogelijk door het hele productieproces lopen zonder oponthoud. Vanaf het moment dat het proces start tot het eind van het proces moet er sprake zijn van een continuous flow.
Demand Pull is het vierde principe, een organisatie moet het vermogen hebben om precies dat te ontwerpen en te produceren wat de klant wil wanneer de klant het wil. Laat de klant het product vragen in plaats van het pushen van (mogelijk ongewenste) producten richting klanten.
Het vijfde en laatste principe is het streven naar perfectie. Lean is geen eindig project, het is een continu proces zonder einde. Medewerkers van een organisatie moeten streven naar perfectie omdat er altijd mogelijkheden of nieuwe technologieën zullen zijn om de principes verder te
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 13 perfectioneren. Het belangrijkste van dit principe is het ontstaan van het besef dat het bij Lean niet gaat om eenmalige gebeurtenissen of analyses. Het is een continu proces van systematische verandering en verbeteringsactiviteiten van een organisatie. (Womack, Jones, 2003).
Deze principes zijn leidraad voor de eliminatie van afval en de vereenvoudiging van alle productie en ondersteunende processen. Hoewel de bovenstaande principes gebaseerd zijn op een productieomgeving proberen steeds meer organisaties de tools en principes toe te passen in een kantooromgeving.
NB: Het SENS programma binnen Achmea is nauw verweven met Lean. Het programma concentreert zich op de volgende 4 onderwerpen waarbij de aandacht voor KPI’s niet direct een Lean principe is :
1. Klantwaarde (de klant centraal)
2. Medewerkerwaarde (respect voor de mens) 3. Operationele waarde ( Voorkom verspillingen) 4. Financiële waarde (KPI’s)
Een centrale gedachte achter Lean is dat het verbeteren van klantwaarde tot een maximum waarbij verspilling (muda) tot een minimum wordt gereduceerd. Verspilling is alles dat geen waarde toevoegt voor de klant, zodat de klant uiteindelijk precies dat krijgt wat hij of zij wil (niet meer maar ook niet minder). Een andere definitie van verspilling is alles dat een soepele flow van productie in de weg staat (MacDufile, 1997).
Lean is een effectief hulpmiddel om verspilling in productieomgevingen te voorkomen, een ander kenmerk van Lean is het handhaven van een continue flow van producten waardoor je in staat bent om veranderingen in de vraag flexibel op te vangen. Door het minimaliseren van verspilling kan er just in time geleverd worden, verbeteren kwaliteit en productiviteit en worden de kosten per product verlaagd.
2.2 Lean software development
In de voorgaande paragraaf bespraken we Lean in zijn algemeenheid, in deze en de volgende paragraaf werpen we een kritische blik op wat er onderzocht is met betrekking tot Lean in een IT omgeving en wat succesfactoren zijn om Lean in een dergelijke omgeving toe te passen.
Hoewel Pernståla et al, (2013) concludeert dat er ruim wordt gepubliceerd over Lean in combinatie met Software development constateert Jonsson et al (2013) dat het aantal bronnen
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 14 waar naar verwezen wordt met als onderwerp het implementeren van Lean bij Software Development beperkt lijkt. Jonsson et al. (2013) beschrijven in hun literatuuronderzoek dat de artikelen die zij hebben gevonden uiteindelijk gebaseerd zijn op 9 bronnen (veelal boeken) en er in die 9 bronnen 20 concepten/principes gevonden zijn die Lean Software Development definiëren. Overigens wordt er veel over Lean Software Development geschreven in vakliteratuur. Om Lean IT tastbaar te maken wordt in deze paragraaf daarom zowel gebruik gemaakt van vakliteratuur als van wetenschappelijke artikelen. Lean wordt ook steeds vaker toegepast in IT omgevingen, vaak in klantgerichte processen, maar ook in software development (Liefers, 2011).
Bij het ontwikkelen van software worden over het algemeen een aantal stappen doorlopen.
ISO/IEC 12207 Systems and software engineering – Software life cycle processes is een internationale standaard waarin die stappen worden onderkend en beschreven. Hoewel er een diverse methoden zijn waarmee software ontwikkeld wordt, delen die methoden veelal onderstaande stappen of een combinatie daarvan:
Analyse van de problematiek
Markt onderzoek (bouwen of kopen)
Requirements verzamelen (welke functionaliteit moet de software bieden)
Plannen en ontwerpen van de software
Bouwen en documenteren van de software
Testen van de gebouwde software
Deployen van de software (in gebruik nemen)
Onderhouden van de software
Als Lean toegepast gaat worden in een dergelijk Software Development proces, moeten de verspillingsbegrippen vertaald worden naar de software context (Pillai, 2011). De analogie van overproductie in de industriële sector is dan het te vroeg produceren van software. Wachten in een productie proces kan vertaald worden naar het wachten op een review op functionele ontwerpen, of op halffabricaten van andere ontwikkelteams. Een niet waarde toevoegende activiteit kan het wachten op een procesgoedkeuring zijn voor er aan de klant wordt geleverd, defecten in software zorgen voor rework en zijn daarmee ook een verspilling, defecten kunnen ook ontstaan door over engineering van software. Onder over engineering wordt hier verstaan alle toevoegingen in de software die niet bijdragen aan de oorspronkelijk gevraagde functionaliteit. Dat kan bijvoorbeeld te veel functionaliteit zijn. Onderstaande tabel geeft een
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 15 overzicht hoe de 8 vormen van verspilling die gedefinieerd zijn door Lean vertaald kunnen worden naar IT en Software Development.
Tabel 1 Lean Waste voorbeelden voor IT
Type Verspilling Industrie IT
Overproductie Meer produceren dan de klant wil afnemen Te vroeg produceren van software Wachten Tijd verspillen door niet aan een product te
werken
Wachten op reviews, maar ook trage response- en verwerkingstijden van applicaties die wachttijden/
knelpunten in bedrijfsprocessen veroorzaken
Transport en transfer Onnodige afstanden afleggen Onnodig vaak documentatie doorgeven, bijvoorbeeld van analist naar ontwerper, naar bouwer, naar tester.
Overbodige handelingen Producten worden beter gemaakt dan de klant wil
Functionaliteit toevoegen waar niet om gevraagd is.
Bovenmatige voorraad Meer op voorraad hebben dan noodzakelijk Functionele ontwerpen laten liggen om later op te pakken.
Beweging Overbodige bewegingen, zoals het zoeken naar materiaal, gereedschappen, order- mappen en dergelijke
Gebruik van verschillende sjablonen en processen voor ontwerpen binnen 1 afdeling.
Defecten Tijd verspillen door producten te verbeteren die niet aan de specificaties voldoen
Informatiesystemen doen niet wat er bij de specificatie van verwacht werd Slecht functionerende IT-apparatuur, met verstoringen en uitval
Verspilling van talent Niet gebruiken van kennis en creativiteit in je organisatie
sommige IT-medewerkers zijn bijzonder in trek bij de eindgebruikers en 'komen om' in het werk, terwijl voor anderen het tegenovergestelde waar lijkt te zijn
Er zijn ook duidelijke verschillen ten opzichte van Lean in industriële processen. Software wordt typisch ontwikkeld in releases, waarbij elke opvolgende versie vaak defecten van de vorige versie oplost, of er wordt nieuwe functionaliteit toegevoegd. De koper van een auto zal zijn product niet periodiek terug brengen naar de fabriek, voor het oplossen van defecten en het verbeteren van de rijeigenschappen. Een defect in software in de ogen van de klant hoeft niet het gevolg te zijn van fout programmeren in de software, maar kan even zo goed het gevolg zijn van het mis interpreteren van de functionele eisen die de klant aan de software heeft gesteld of van veranderende eisen.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 16 Een ander kenmerk van Lean is het minimaliseren van voorraad, mede omdat eventuele defecten in producten dan ook in de voorraad zitten en er meer producten waardeloos worden voordat het defect ontdekt wordt. Bij het ontwikkelen van software gelden dezelfde principes, fouten in voorraden requirements, ontwerpen en ontwikkelde code kunnen je verassen en je planning in de war schoppen als je ze niet vroeg ontdekt en oplost. Het reduceren van voorraad staat daarbij bijvoorbeeld gelijk aan het reduceren van ongeteste code (Tierney, 1993).
Kwaliteit moet ingebouwd worden is een ander kenmerk van de toepassing van Lean in software development (Poppendieck, 2003). In plaats van het controleren van de kwaliteit van de software aan het eind van het ontwikkelproces van een product moet er gedurende de ontwikkeling van modules en routines al gecontroleerd worden op fouten in het ontwikkelproces. Als die zich voordoen moeten die direct worden opgelost. Bij het invoeren van het Toyota Production Systeem werd bij het ontdekken van elke fout de productie stil gelegd en gezocht naar de grondoorzaak van de fout. Als die was opgelost werd de productie weer opgestart. Ook werd daarbij gezocht naar mogelijkheden om het proces zo in te richten dat een fout zich niet weer voor kan doen. (Poka Yoke). In Software Development kan dat door requirements niet als groot pakket aan te leveren aan de ontwerpers, maar door bijvoorbeeld elk geschreven A4-tje met requirements al te laten beoordelen door ontwerpers. Als er dan een fout wordt gevonden stopt het ontwerpen en gaat de ontwerper met de analist direct aan de slag om de gevonden defecten op te lossen voor ze in het ontwerp of erger in de software tot errors leiden. (Middleton, 2001)
Vroege onderzoeken zoals Hamilton (1999) en Tierney (1993) wijzen uit dat gebruik van Lean principes in een IT voortbrengingsproces mogelijk is. Conclusie van Hamilton (1999) is “Lean principes toepassen verbeterde de doorlooptijd, en overall kwaliteit van een software development proces.” (Hamilton, 1999). Essentie van een Lean IT voortbrengingsproces is productie zonder voorraden, het produceren van kleine hoeveelheden volgens het Just In Time (JIT) principe van Lean. Dit principe geldt voor alle elementen van software development zoals requirements, ontwerpen, ontwikkelde code en testcases, die allemaal continu onderhanden moeten zijn, waarbij iedere keer gestreefd wordt naar zo klein mogelijke eenheden. Net als Middleton (2001) constateert Hamilton dat door kleinere eenheden te gebruiken zoals bijvoorbeeld een pagina requirements voor directe beoordeling effect heeft op de kwaliteit van software development.
De Lean benadering is holistisch en kan ook in een IT voortbrengingsproces worden toegepast.
Door het toepassen van Lean worden fouten en vergissingen snel aan het licht gebracht, waarbij Lean technieken zorgen voor de data die ondersteunt bij de noodzakelijke veranderingen. Door
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 17 dit snelle leren van de organisatie worden medewerkers in staat gesteld om de kwaliteit te leveren die gevraagd wordt. (Middleton, 2001).
Uit bovenstaande blijkt dat de principes van Lean zoals die in een industriële omgeving worden toegepast ook kunnen worden toegepast bij software development. Net als in een industriële omgeving kan er worden gewerkt met een minimum aan voorraden, kan er worden gezocht naar verspillingen om die vervolgens uit te roeien en kan er continu worden gestreefd naar perfectie.
Uiteraard moet begrippen uit de industriële wereld zoals wachttijd en defecten wel vertaald worden naar software development. Verschillen zijn er ook, voorraden zijn in een industriële omgeving bijvoorbeeld veel tastbaarder dan in een omgeving waar software wordt ontwikkeld en continuous flow gaat meer over het proces van ontwikkelen van software dan over het fysiek verplaatsen van grondstoffen en halffabricaten.
2.3 Succesfactoren voor Lean software development
In de voorgaande paragrafen hebben we gezien dat Lean in een industriële omgeving overeenkomsten heeft maar ook verschillen met zich mee brengt in een software development omgeving. Principes zijn de uitgangspunten van Lean, zonder het toepassen van die principes zou gesteld kunnen worden dat er niet Lean wordt gewerkt. Het “uitroeien van verspillingen” is een dergelijk principe, roei je nooit bestaande verspillingen uit dan wordt er niet aan dat principe voldaan. Succesfactoren gaan met name over randvoorwaarden die het invoeren van de Lean principes mogelijk maken en ondersteunen. Zonder support van het management bij het invoeren van de Lean principes zal een dergelijke implementatie waarschijnlijk moeizaam verlopen of zelfs onmogelijk blijken.
In de wetenschappelijke literatuur is op dit moment beperkt onderzoek voorhanden dat specifiek de succesfactoren voor Lean software development onderzoekt. Wel zijn er paralellen te trekken tussen Lean in een kantoor of kennis omgeving en Lean software development. Staats
& Upton (2011) beschrijven een “roadmap” om werk in een kennis omgeving Lean te maken en onderscheiden 6 stappen:
1. Roei verspillingen continue uit.
2. Streef er naar Kennis expliciet te maken.
3. Specificeer hoe er gecommuniceerd moet worden.
4. Gebruik wetenschappelijke methoden om problemen snel op te lossen.
5. Onderken dat een Lean systeem “Work in Progress” is.
6. Laat management en leiders het pad wijzen en initiatief nemen.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 18 Vertaald naar IT omgeving zijn al deze principes valide waarbij het streven om kennis expliciet te maken zelfs nog meer opgeld doet in een IT context dan in een kantooromgeving. Een Lean omgeving creëren is een continu leerproces dat jaren in beslag kan nemen (Staats & Upton, 2011).
Om Lean succesvol te implementeren in een IT omgeving is het creëren van een Lean Team dat bestaat uit medewerkers met verschillende achtergronden in de IT organisatie nodig. Door een multidisciplinair team te creëren ontstaat er de mogelijkheid om kennis met elkaar te delen en vragen te beantwoorden (Bortolotti & Romano, 2012; Chen & Cox, 2012; Nicoletti, 2011). Staats en Upton (2011) en Nicoletti (2011) beschrijven het belang van communicatie. Goede communicatie is nodig voor succesvolle Lean IT, communicatie moet gestructureerd worden rondom de invoering van Lean software development. Door goede communicatie kan een gezamenlijk beeld gecreëerd worden van Lean IT en kunnen stakeholders mee genomen worden in de verandering die ook hun zal raken. Bovendien zullen medewerkers door goede communicatie zich meer betrokken voelen bij het proces. Die betrokkenheid van medewerkers is samen met commitment van het management fundamenteel voor het succes (Bortolotti &
Romano, 2012; Staats & Upton, 2011).
Support van management en medewerkers is niet alleen in de opstartfase van belang, maar ook na de invoering van Lean IT. Managers en medewerkers moeten ambassadeurs worden van Lean IT. Een goede manier om die support te krijgen is het laten zien van resultaten (Nicoletti, 2011). Als medewerkers de impact van Lean IT op hun werk zien zullen ze eerder deel willen uitmaken van dat succes en dus van Lean IT. Niet alle verspillingen in een IT omgeving zijn even geschikt om te verbeteren, daarom is het van belang dat alle medewerkers continu op zoek blijven naar verspilling en deze naar voren brengen. Het gaat dan zowel om grote als om kleine verspillingen (Staats & Upton, 2011). Het introduceren van het 5 maal waarom vragen als tool zorgt er voor dat medewerkers zich blijven afvragen waarom ze taken uitvoeren zoals ze dat doen en worden grondoorzaken van verspilling gevonden.
Visueel maken van werk en werkstromen, bijvoorbeeld door het gebruik van Kanban, zorgt er voor dat er inzicht komt in performance en voortgang, maar ook in obstakels en problemen.
Zoals bij het bespreken van de roadmap van Staats en Upton (2011) al ter sprake is gekomen, zit kennis vaak in hoofden, door blijvend op zoek te gaan naar herhaalbare stukken wordt kennis meer tastbaar. Het specificeren van taken, wie doet wat wanneer en waarom, resulteert in minder defecten, minder rework en verbeterde productiviteit. (Staats & Upton, 2011).
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 19 Monitoren van het totale proces en dat visueel maken is tevens een van de succesfactoren. Door niet alleen te focussen op het onderhanden werk, maar ook zicht te hebben op het totale proces en de effecten van het invoeren van Lean zorgt er voor dat medewerker de verbeteringen inzichtelijk krijgen. Dit kan gezien worden als stap 5 van de originele Lean principes, het perfectioneren.
Tabel 2 Overzicht van de bovengenoemde succesfactoren
Succesfactoren Creëer een Lean Team
Zorg voor goede communicatie tussen medewerkers onderling en tussen teams Commitment van het Management
Ondersteuning en Training van medewerkers Zorg voor een goede taak specificatie Laat resultaten zien
Monitor de werkstroom
Selecteer de juiste verspilling op om te lossen, begin klein Monitor het proces
De hiervoor genoemde succesfactoren zijn gebruikt om een groot deel van de interview onderwerpen en vragen te formuleren, het semi gestructureerde interview bestaat uit vragen over Lean Software Development in het algemeen, vragen over de succesfactoren en vragen over de resultaten. De topiclist voor de interviews kan worden gevonden in bijlage 1. In de topiclijst in de bijlage is een verwijzing opgenomen naar het onderliggende theoretische kader.
2.4 Kwaliteit van software
Rodriguez et al. (2011) identificeren een aantal principes van Lean IT teneinde te kunnen onderzoeken welke van deze principes gebruikt worden in de Finse Software industrie. Van deze principes is door Rodriguez een lijst van meest gebruikte principes onder 408 respondenten van 200 verschillende bedrijven gemaakt. Een aantal van deze principes zijn materieel van aard, Principes als “Continuous flow van small batches” en “Creëren van cadans” worden onder andere gebruikt om softwarekwaliteit te verbeteren en zouden daarmee volgens de literatuur invloed kunnen hebben op de kwaliteit van geleverde software Rodriguez et al. (2011).
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 20
Tabel 3 Lean principes van invloed op kwaliteit Rodriguez et al. (2011)
Gebruik van Lean principes
Focus op het creëren van waarde voor de klant Elimineer verspilling en overbodige activiteiten Creëer een cultuur van continue verbetering Doe het goed in 1 keer
Respecteer mensen
Minimaliseer voorraad en werk in uitvoering Bouw alleen op vraag (pull)
Focus op het optimaliseren van het hele proces, geen sub optimalisatie Continue flow van kleine batches in het ontwikkelproces
Beslis zo laat mogelijk in het proces
Zoek de bron van problemen direct nadat je het probleem hebt ontdekt Zoek tegelijkertijd naar meerdere oplossingen
Creëer vertrouwde relaties met leveranciers Creëer cadans
Kwaliteit is een begrip dat op vele wijzen gedefinieerd kan worden, veelal wordt onder kwaliteit verstaan “het voldoen aan de verwachtingen van de klant” Om kwaliteit meetbaar te maken wordt voor dit onderzoek het begrip streven naar Zero Defects gebruikt, waarbij defects gemeten worden tegen de gedefinieerde specificaties van de te bouwen software. Door het gebruiken van een van de Lean principes genoemd door Rodriguez et al. (2011) zou het aantal defects dat gevonden wordt in gebouwde software lager moeten zijn dan voor het introduceren van dat Lean principe.
2.5 Conceptueel model
Goed werkende software is van steeds groter belang voor ondernemingen. Bovendien worden de eisen die de markt aan dienstverlenende bedrijven stelt steeds hoger voor wat betreft flexibiliteit in productsamenstelling en niveau van service. Ondernemingen moeten snel op veranderende marktomstandigheden kunnen inspelen. De Time to market van nieuwe producten en diensten moet daarbij zo kort mogelijk zijn, automatisering is daarbij van cruciaal belang. Bij het ontwikkelen van software is de gekozen ontwikkelmethodiek van invloed op de snelheid van leveren, maar ook op de kosten en kwaliteit van de geleverde software. In een industriële omgeving kan de invoering van Lean invulling geven aan die behoefte, kan dat ook in een IT voortbrengingsproces.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 21 De centrale vraag in dit onderzoek is: “Op welke wijze kan Lean IT bijdragen aan de kwaliteit en performance van een software development afdeling en kunnen de resultaten daarvan gemeten worden.”.
Om antwoord te kunnen geven op deze centrale vraag, is vanuit het beschreven theoretisch kader een conceptueel model opgesteld, waarbij een tweetal Lean principes betrokken worden die invloed hebben op de kwaliteit van ontwikkelde software Rodriguez et al. (2011).
LEAN Software Development
Creëren van cadans
Continue flow van kleine batches in het ontwikkelproces
Kwaliteit van Software
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 22
3 ONDERZOEKSOPZET
In hoofdstuk 1 is kort ingegaan op de onderzoeksopzet. In dit hoofdstuk wordt de opzet meer in detail besproken. Om te onderzoeken hoe Achmea IT Lean kan implementeren op een software development afdeling en de resultaten daarvan kan meten is een (exploratory) onderzoek van kwalitatieve aard uitgevoerd. We identificeren succesfactoren die door de organisatie geadopteerd kunnen worden, en brengen het resultaat in beeld van interventies. In dit hoofdstuk wordt de opzet en aanpak van het onderzoek besproken met als doel structuur te brengen in het onderzoek. In de navolgende paragrafen wordt eerst de methode van onderzoek toegelicht. Daarna wordt besproken welke gegevens er verzameld worden, en hoe die worden verzameld. Tenslotte wordt ingegaan op de beperkingen van het onderzoek en welke kennisproducten dit onderzoek gaat opleveren.
3.1 Methode van onderzoek
Het type onderzoek dat gekozen is om antwoord te geven op de onderzoeksvragen is een combinatie van een case study en een veld experiment. Een case study is met name geschikt voor het onderzoeken van complexe onderwerpen of objecten, en kan nieuwe inzichten brengen, of kennis toevoegen aan wat al in eerdere onderzoeken aan het licht is gekomen.
In een Case study is er met name aandacht en ruimte voor een gedetailleerde contextuele analyse van een gelimiteerd aantal gebeurtenissen of condities en hun onderlinge relaties. Een definitie van case study onderzoeksmethoden is “Een empirisch onderzoek dat een hedendaags fenomeen binnen haar reële context onderzoekt, wanneer de grenzen tussen fenomeen en context zijn niet duidelijk zichtbaar zijn, en waarin meerdere bronnen van bewijs worden gebruikt.” (Yin, 2013). In een Case study worden vaak de volgende stappen gevolgd om het onderzoek uit te voeren: Definiëren van de onderzoeksvragen, selecteren van de cases die onderwerp zijn van onderzoek, verzamelen van data in het onderzoeksveld, evalueren en analyseren van de verzamelde data en tenslotte rapporteren van de resultaten.
Een Case study is een kwalitatieve onderzoeksmethode, dat wil zeggen dat het niet gaat om het in kaart brengen van cijfers, maar om het verkennen en inzichtelijke maken van een thema of vraagstuk. Bij kwalitatief onderzoek gebruikt de onderzoeker methoden die het mogelijk maken om het onderwerp van onderzoek vanuit het perspectief van de onderzochten te leren kennen.
Het doel is het onderwerp van onderzoek te beschrijven en mogelijk te verklaren. (Boeije, H.
2005). Volgens Babbie (2004, p.271), is een case study de beste manier om een kwalitatief
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 23 onderzoek te doen. Bij kwalitatief onderzoek hoeft er geen sprake te zijn van grote aantallen aan onderzoeksgegevens, waarbij het nadeel kan zijn dat de conclusies niet statistisch gegeneraliseerd kunnen worden. Er zijn echter ook voordelen omdat er ruimte is voor een diepere analyse. Het kwalitatieve deel van dit onderzoek bestaat uit de resultaten van een semi gestructureerd interview, documenten onderzoek en een literatuurstudie.
Additioneel wordt voor dit onderzoek een veld experiment uitgevoerd, een veld experiment is een experiment dat kan worden uitgevoerd in een natuurlijke omgeving van een gegeven situatie en niet in een laboratorium (Harrison, List, 2004). Een veld experiment kan ten opzichte van de onderzoeksvragen gebruikt worden om te onderzoeken wat er kan gebeuren en wat er daadwerkelijk gebeurd (Mook, 1983). Zeker voor antwoorden op vragen over organisatorische onderwerpen kunnen veld experimenten gebruikt worden (Holland, Aarts, & Langendam, 2006).
Tijdens het uitvoeren van het onderzoek bij Achmea zijn resultaten van het literatuuronderzoek toegepast in een software development team als veld experiment. In dit onderzoek is de onderzoeker deel van het team waar Lean methodieken geïmplementeerd worden en observeert de resultaten, de onderzoeker introduceert de Lean methodieken in het team en helpt bij de praktische uitwerking daarvan.
3.2 Datacollectie
Het verzamelen van gegevens voor dit onderzoek start met het onderzoeken van literatuur, om begrippen zoals Lean uit te werken en te plaatsen in de context van de het onderzoek. Omdat het doel van het onderzoek is te onderzoeken hoe Lean in een IT voortbrengingsproces geïmplementeerd kan worden en hoe de resultaten gemeten kunnen worden wordt ook literatuuronderzoek gedaan naar het meten van resultaten van Lean specifiek voor software development.
De bibliotheek van de Rijksuniversiteit Groningen wordt gebruikt als primaire bron van artikelen. Er is gezocht in de databases Business Source Premier, maar ook via Worldcat / SmartCat. Bij het zoeken van artikelen is gebruik gemaakt van de zoekterm Lean en Lean in combinatie met Software Development. Verder wordt ook internet gebruikt (Google Scholar) voor het zoeken van artikelen over het onderwerp van dit onderzoek. Er wordt met name gezocht naar artikelen die de kenmerken van Lean operationeel maken voor software development. Buiten wetenschappelijke artikelen wordt ook professionele literatuur gebruikt voor deze case study. Een kleine 30 artikelen en boek zijn uiteindelijk geselecteerd om te gebruiken voor het uitvoeren van deze case study.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 24 Er is gekozen voor een case study in combinatie met veld experiment om inzicht te krijgen in het real life toepassen van Lean software development. Deze case study wordt gedaan bij Achmea Zorg & Gezondheid, waar op dit moment SENS wordt ingevoerd, een combinatie van Lean en het centraal stellen van de klant. Omdat er op dit moment deze transitie bij Achmea plaats vindt, is er de unieke mogelijkheid om tijdens deze transitie in het kader van het onderzoek al te werken met de uitkomsten van het onderzoek .
Tijdens de case study wordt onderzocht of de factoren van succes zoals die gevonden zijn in de eerdere literatuurstudie ook bij Achmea worden toegepast, en of deze snel toegepast kunnen worden. Daarnaast wordt gekeken naar hoe er in wetenschappelijke en professionele literatuur gekeken wordt naar de implementatiestrategie van Lean software development en wordt onderzocht hoe Lean bij Achmea IT wordt geïmplementeerd.
Tijdens het uitvoeren van een case study zijn er diverse mogelijkheden van datacollectie, zoals interviews, observaties, bestuderen van documenten en gebruik van secundaire data (Bhattacherjee, 2012). Bij een veld experiment is observatie een belangrijke methode van verzamelen van data.
Een de bronnen van data in deze case study zijn interviews. Middels semigestructureerde interviews wordt gesproken met stakeholders om inzicht te krijgen in de mening en ervaringen van betrokkenen bij de invoering van Lean software development. Omdat dit een exploratief onderzoek is, is gekozen voor semi gestructureerde interviews. Bij dit type interview is er ruimte voor de onderzoeker en respondent om vragen uit te diepen, zaken te verduidelijken of vervolgvragen te stellen (Boeije, 2005). Bij deze case study worden tevens documenten als bron gebruikt. Vooral projectgegevens zoals die in Governance producten van projecten worden vastgelegd. Het gaat daarbij om projectplannen, ontwerpen en functionele beschrijvingen, functiepunten, bevindingen registratie, testplannen en resultaten en dergelijke.
Een bron van data bij een veld experiment is observatie, de onderzoeker is gedurende het gehele onderzoek deel geweest van de teams waar Lean Software Development middels het SENS programma van Achmea is uitgerold. De uitrol vond plaats vanaf begin 2014 en omdat Lean thinking nooit stopt, wordt er nog steeds volgens Lean principes gewerkt.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 25 3.2.1 Respondenten
Interviews zijn gehouden met diverse betrokkenen in en buiten de IT organisatie van Achmea die gedurende het onderzoek direct of indirect betrokken waren het implementeren van Lean Software Development. Er is gekozen om diverse rollen in het ontwikkelproces te interviewen om daarmee verschillende perspectieven van de implementatie te krijgen en de succesfactoren te toetsen. Ook is er gekozen om respondenten uit verschillende teams te interviewen om te voorkomen dat er vanuit het perspectief van maar 1 team naar Lean Software development wordt gekeken. Tenslotte is ook een vertegenwoordiger van de afnemer (interne klant) van software geïnterviewd om te toetsen of dat beeld correspondeert met het beeld dat direct betrokkenen van de implementatie hebben.
Tabel 4 Overzicht geïnterviewden
Functie geïnterviewde Afdeling Periode
Teamleider Microsoft CC Team Claims November 2014
Ontwerper Microsoft CC Team Polis November 2014
Software Developer Microsoft CC Team Polis December 2014
Tester Microsoft CC Team Claims Februari 2015
Projectmanager Zilveren Kruis Achmea P&VM Maart 2015
3.2.2 Veld experiment
Het veld experiment met participatie van de observant is gestart in het tweede kwartaal 2014 en eindigde rond juni 2015. Met input komend vanuit het literatuuronderzoek en het uitrollen van het SENS (Lean) programma zijn acties uitgezet in de betrokken teams van de ontwikkelstraat.
De betrokken teams bestaan uit een kleine 55 architecten, ontwerpers, ontwikkelaars testers en 4 teamleiders. Gedurende de uitrol zijn er daily stand ups geïntroduceerd waar de observant deel van uitmaakte en werd er elke week een “keek op de week” gehouden om resultaten met elkaar te bespreken en acties uit te zetten. Omdat continu verbeteren en Lean een nooit stoppend proces is, worden deze bijeenkomsten overigens nog steeds gehouden.
3.3 Data analyse
Het analyseren van data doet zich gedurende een onderzoek veelal voor op een tweetal momenten gedurende een kwalitatief onderzoek. De analyse van data start al bij het begin van het verzamelen van de data en blijft doorgaan gedurende het proces van verzamelen data. De analyse wordt daarna afgerond als alle data verzameld is (Boeije, 2005). Miles en Huberman (1994) beschrijven dat er 3 stappen zijn bij het beoordelen van data in een kwalitatief
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 26 onderzoek: Datareductie wordt gebruikt om data te sorteren, te organiseren, te verscherpen, focus aan te brengen, maar ook data negeren. Alles op een zodanige wijze dat er conclusies getrokken en geverifieerd kunnen worden. In deze case study is datareductie toegepast door het gebruik van een sessie samenvatting van de interviews. De sessiesamenvattingen zijn weergaven van een interview op 1 pagina met daarop de belangrijkste bevindingen uit een interview. Data display wordt gebruikt data te organiseren in matrixen, grafieken en dergelijke omdat het moeilijk is en lang duurt om ongestructureerde data te analyseren. In dit onderzoek is dit gedaan door de bespreking van de succesfactoren in een tabel te zetten. Gedurende de case study zijn een aantal interviews gehouden en uitgewerkt. De uitgewerkte interviews zijn daarna geanalyseerd en is onderzocht of de succesfactoren die in de literatuur gevonden zijn door de betrokkenen ook genoemd worden. Vanuit de antwoorden uit de interviews is een vertaalslag gemaakt naar een drietal categorieën van succesfactoren te weten; randvoorwaardelijk, belangrijk en ondergeschikt.
De gegevens die gevonden zijn bij het onderzoek van documenten worden ook vertaald naar tabellen en grafieken, in dit geval vooral om te onderzoeken of er een trend te ontdekken is cijfers die voorhanden zijn met betrekking tot defects. Conclusie trekken en verificatie is de laatste stap van het analyseren van data. Miles en Huberman (1994) raden aan om bij het starten van het verzamelen van data al na te denken welke betekenis die data heeft, direct te zoeken naar verklaringen en patronen en dergelijke.
Gedurende de periode van het veld experiment is er ook data verzameld. Dit is gedaan door resultaten van projecten te verzamelen die voor en na de interventies zijn uitgevoerd door het software development team. Deze resultaten zijn verzameld in tabellen en grafieken en uiteindelijk geanalyseerd ten behoeve van het trekken van conclusies en het doen van aanbevelingen. De resultaten zijn ook besproken in het team gedurende de “keek op de week”
sessies, vooral na het uitvoeren van de interventies die een behoorlijke impact op de werkwijze van het team hadden.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 27 3.4 Kwaliteit van onderzoek
Om de kwaliteit van onderzoek te kunnen beoordelen kan worden gekeken naar een aantal factoren die die kwaliteit beïnvloeden. Zowel Yin (2013) als Boeije (2005) onderscheiden daarbij validiteit van het onderzoek (intern en extern) en betrouwbaarheid. Valide resultaten sluiten aan bij het te meten concept, bij betrouwbaarheid gaat het er om dat metingen zo min mogelijk af hangen van toeval.
3.4.1 Validiteit
Validiteit valt uiteen in interne validiteit en externe validiteit. Interne validiteit is de mate waarin de gemeten resultaten van een onderzoek ook daadwerkelijk het gevolg zijn van de verandering die is ingezet. Een onderzoek is dus intern valide als de conclusies die getrokken zijn ook daadwerkelijk het gevolg van de verandering zijn, en alle ander mogelijke verklaringen in ogenschouw zijn genomen (Yin, 2013). Volgens Yin (2013) schiet een onderzoeker gauw tekort bij het operationaliseren en meten en is een onderzoeker geneigd een dataverzameling subjectief te benaderen. Voordat het verzamelen van data in dit onderzoek is gestart zijn de meest belangrijke theoretische concepten besproken in het theoretische kader van het onderzoek. Deze concepten worden door het hele onderzoek gebruikt. Validiteit kan worden verbeterd door meerdere bronnen te gebruiken, (triangulation).
In dit onderzoek zijn verschillende methoden en bronnen gebruikt om de interne validiteit te verbeteren. Er is gebruikt gemaakt van een literatuuronderzoek, er is een documentatie onderzocht, er zijn semi gestructureerde interviews gehouden en er is geparticipeerd en geobserveerd tijdens een veld experiment. Bij de interviews zijn daarbij verschillende stakeholders uitgenodigd. Verder is er een koppeling gemaakt tussen de onderzoeksvragen, het theoretische kader en de analyse en resultaten.
Externe validiteit is ook van belang voor het ontwerp van het onderzoek. Het gaat er hierbij om of de resultaten van het onderzoek generaliseerbaar zijn over de grenzen van de onderhavige case study. (Yin,2013). Kunnen er op basis van het onderzoek conclusies getrokken worden over niet onderzochte casussen. Dit onderzoek betreft een single case study, wat een smalle basis is om de resultaten te generaliseren. Wel kan de gekozen onderzoekstrategie gebruikt worden bij andere casussen waardoor resultaten te vergelijken zijn. Ook kunnen de resultaten van het onderzoek dienen als basis voor verder onderzoek naar dezelfde of andere factoren.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 28 3.4.2 Betrouwbaarheid
Met betrouwbaarheid wordt nagegaan hoeveel toevallige fouten er voorkomen in het onderzoek die een impact hebben op de waarnemingen (Yin, 2013). Het doel moet zijn om bias en fouten tot een minimum te beperken. Een betrouwbaar onderzoek is herhaalbaar en geeft iedere keer dat het onderzoek opnieuw wordt uitgevoerd dezelfde resultaten. De betrouwbaarheid van een onderzoek kan worden verbeterd door een systematische benadering van het onderzoek, bijvoorbeeld door standaardisatie van de gebruikte methode van dataverzameling (Boeije, 2005). Hoewel een semi gestructureerd interview zoals het gebruikt is in dit onderzoek enige mate van standaardisatie met zich mee brengt, kan niet worden voorkomen dat vragen niet exact op dezelfde manier aan alle respondenten gesteld worden. In dit onderzoek is gebruik gemaakt van verschillende technieken voor het verzamelen van data, er zijn semi gestructureerde interviews gehouden, en er is document research gedaan. Interviews zijn gehouden onder respondenten die met een verschillende achtergrond en blik naar Lean kijken.
Van de interviews zijn aantekeningen bijgehouden die gebruikt zijn bij de analyse. De documenten die verzameld zijn komen uit verschillende niveaus in de onderzochte organisatie en hebben verschillende achtergronden en doelen. Verder betreft het hier wel een single case study, maar zijn gedurende de looptijd van het onderzoek documenten van meerdere projecten onderzocht en zijn ook documenten onderzocht voor projecten die zijn uitgevoerd voor de introductie van Lean IT. Door deze maatregelen is de betrouwbaarheid van deze case study verbeterd.
3.5 Beperkingen van dit onderzoek
De onderzoeker maakte deel uit van het team waar het onderzoek is uitgevoerd, als observant, maar ook als participant. Dat kan er voor zorgen dat gedurende het uitvoeren van de interviews, de verwerking en analyse daarvan sprake is van een bias. Een andere onderzoeker zou de antwoorden wellicht anders interpreteren of gedurende de interviews dieper ingaan op andere aspecten van de invoering van Lean IT.
Er wordt voor de uitvoering van dit onderzoek slechts één case study uitgevoerd bij één organisatie, daardoor is het niet zonder meer mogelijk om de conclusies van dit onderzoek te generaliseren. Het is mogelijk dat in de context van een andere organisatie dan Achmea de resultaten anders zouden zijn. Uiteraard is het wel mogelijk de methode van onderzoek toe te passen op andere software development projecten. De resultaten van dit onderzoek kunnen in ieder geval niet los gezien worden van de context van het onderzoek.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 29 3.6 Kennisproducten
Na het lezen van dit onderzoek, heeft de lezer een beeld van de toepassing van Lean in een IT voortbrengingsketen. De case study geeft de lezer dieper inzicht in de succesfactoren voor het invoeren van Lean IT. Tijdens de case study wordt met name geobserveerd hoe Lean IT op een software development afdeling wordt geïmplementeerd, waar in de processen ingegrepen wordt en wat voor meetbare resultaten dat oplevert. Achmea krijgt door de uitvoering van dit onderzoek inzicht in de meetbaarheid van Lean IT in een software development team. Verder draagt het onderzoek bij aan het inzicht in de invloed van Lean op het succes van software development projecten.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 30
4 CASE STUDY MICROSOFT COMPETENCE CENTER AB SUITE ACHMEA: RESULTATEN
De resultaten van de interviews met de betrokkenen bij het invoeren van Lean IT worden in dit hoofdstuk weergegeven. Ook worden de gegevens gepresenteerd die onderzocht zijn gedurende het veld experiment en worden projecten voor en na de interventies besproken. De interviews geven antwoord op de vraag of de succesfactoren die gevonden zijn in het literatuuronderzoek ook van toepassing zijn in de onderzochte case. De gegevens van de vergeleken projecten gedurende het veld experiment hebben betrekking op het conceptuele model. In paragraaf 4.3 worden de resultaten en het theoretische kader tegen elkaar afgezet en bediscussieerd.
4.1 Achmea en Lean
Achmea divisie Zorg, waar de case study is uitgevoerd, is de grootste zorgverzekeraar van Nederland met een aantal verzekerden van meer dan 4,5 miljoen en merken als Zilveren Kruis, OZF, Avero, Interpolis en Agis. De totale omzet van de zorgtak van Achmea is 11,1 miljard. In 2014 werd er totaal aan zorgkosten 10,4 miljard euro ingekocht, waarmee Achmea tevens de grootste inkoper van zorg is. Achmea IT is binnen het Achmea concern een zelfstandige divisie die de IT voorzieningen levert aan het hele concern. Streven daarbij is om zoveel mogelijk met generieke oplossingen te werken die in elk business onderdeel van Achmea gebruikt kunnen worden. Een voorbeeld van een generieke oplossing is het gebruik van SAP voor alle financiële stromen in het concern. Door het gebruik van generieke oplossingen is het voor divisies niet nodig het wiel telkens opnieuw uit te vinden, maar kan gebruikt gemaakt worden van technologie en kennis die al beschikbaar is. Ook de IT infrastructuur is generiek ingericht waardoor schaalvoordelen zijn ontstaan voor het beheer daarvan.
Buiten generieke voorzieningen bestaan er ook applicaties die specifiek voor het gebruik in 1 divisie zijn. Voor de divisie zorg is er een specifiek applicatielandschap dat gebruikt wordt voor bijvoorbeeld het administreren van polissen, het inkopen en uitkeren van zorg en administreren van PGB. Dit specifieke landschap is noodzakelijk vanwege de afwijkende wetgeving die in Nederland bestaat met betrekking tot zorgverzekeringen en de administratieve eisen die daaraan worden gesteld.
Het onderzoek is uitgevoerd op een Achmea IT afdeling die exclusief werkt aan het backoffice systeem van de divisie Achmea zorg. In uitzondering op de overige IT afdelingen van Achmea is deze afdeling niet gecentraliseerd, maar werkt vanuit 2 van de 3 zorglocaties in Nederland, te
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 31 weten Leusden en Zwolle. De afdeling Microsoft Competence Center AB Suite (MsCC AB Suite) bestaat in 2015 uit 55 architecten, ontwerpers, ontwikkelaar, testers en 4 teammanagers en werkt nauw samen met de divisie zorg, met name met de afdeling Processen en Verandermanagement, maar ook met de afdeling Support waar het functionele beheer van de zorgsystemen van Achmea is belegd.
Binnen Achmea zorg is in de jaren na het invoeren van de basisverzekering een omvangrijk programma gestart dat als doelstelling het verhogen van de klanttevredenheid, het verlagen van de operationele kosten en het behoud van de medewerker tevredenheid had. Dit programma, Samen Effectief Naar Succes (SENS) maakt gebruik van de principes van Lean om deze doelstellingen te halen. Als een van de latere afdelingen in het programma is het invoeren van Lean op de afdeling MsCC AB Suite gestart in 2014. Tegen de achtergrond van het programma SENS zijn de interviews gehouden met betrokkenen en de Lean interventies in het proces van ontwikkelen van software gedaan tijdens het veld experiment.
Bij het invoeren van de Lean principes vanuit het programma SENS ging het vooral om principes als het signaleren van verspilling, continu verbeteren van product en proces en value stream mapping. Deze principes zijn ingevoerd over het totale werkaanbod door het introduceren van dagstarts, kaizens en VSM sessies en niet slechts voor een aantal projecten.
De interventies die voor dit onderzoek zijn uitgevoerd zijn ook over het totale werkaanbod aan de teams en waren daarmee een grote aanpassing op het proces van ontwikkelen van software in deze teams. Alle lopende en nieuwe projecten kregen daarmee te maken met het uitleveren op vaste releasedata en het verkleinen van werkpakketten zodanig dat deze in het vaste ritme van de teams pasten.
4.2 Succesfactoren van Lean software development
In deze paragraaf worden de resultaten weergeven die verzameld zijn met het interviewen van betrokkenen over de succesfactoren voor het invoeren van Lean IT die beschreven zijn in het theoretische kader in hoofdstuk 2. De interviews zijn gehouden na de uitrol van het programma SENS in 2014 en het daarna invoeren van de interventies.
Elke succesfactor eindigt met een tabel waarin per succesfactor wordt weergegeven of de respondenten deze factor randvoorwaardelijk, belangrijk of ondergeschikt vinden. De succesfactoren “Laat resultaten zien” en “Monitor de werkstroom” zijn samengevoegd aangezien deze in 1 interviewvraag zijn besproken.
Msc BA 19 LEAN Software Development | A.P. Bouwknegt, 2016 32 4.2.1 Creëer een Lean Team
4 van de 5 geïnterviewden gaven aan dat het vormen van een Lean Team dat de regie had bij het invoeren van Lean IT en dat aanspreekpunt was voor vragen en opmerkingen belangrijk is geweest voor het ingevoerd krijgen van de nieuwe werkwijze. Argumenten daarbij waren dat zonder dit team initiatieven voor bijvoorbeeld continu verbeteren en het visualiseren van de werkstroom “sterven in de hectiek van de dag” en “er een klankbord is om ideeën te bespreken”
De enige respondent die dit team van ondergeschikt belang vindt is van mening dat alle verandering moet komen van de werkvloer, de werkvloer wordt door hem meer van invloed op het succes van de invoering geacht dan het Lean Team.
Tabel 5 Succesfactor Lean Team
Randvoorwaardelijk Belangrijk Ondergeschikt Conclusie
2 2 1 Succesfactor bij MsCC
4.2.2 Zorg voor goede communicatie tussen medewerkers en tussen teams
“Communicatie is alles “ gaf een van de respondenten aan. Alle geïnterviewde medewerkers waren van mening dat zonder goede communicatie het invoeren van Lean IT niet was gelukt. Er werd verwezen naar het Lean Team dat veel van communicatie verzorgde, maar ook naar het management dat vooraf voldoende informatie had gegeven over de Lean initiatieven. Het visualiseren van de resultaten op het Obeya Bord werd ook een aantal malen genoemd: “Het bord zorgde er voor dat we op de hoogte bleven van de resultaten, dat creëert draagvlak”
Tabel 6 Succesfactor Communicatie
Randvoorwaardelijk Belangrijk Ondergeschikt Conclusie
3 2 0 Succesfactor bij MsCC
4.2.3 Commitment van het Management
Bijna alle geïnterviewde medewerkers vonden commitment van het management randvoorwaardelijk voor het slagen van invoeren van Lean IT. “Door eerst aan te geven dat we gaan voor Lean IT, en daarna direct de ruimte te geven aan ons om mee te denken met verbeterinitiatieven is er voor gezorgd dat verandering van onderaf is gekomen”. Een andere geïnterviewde gaf aan: “Teammanagers hebben gezorgd dat de randvoorwaarden ingevuld werden, daardoor konden we zelf op de werkvloer ideeën uitwerken.
