5 onmisbare business intelligence trends voor 2020

Met Lean naar Scrum

 

 

 

In de afgelopen jaren zijn talloze bedrijven voor het ontwikkelen van software overgestapt van projectmatig werken op Scrum. Scrum is een proces framework waarmee efficiënt en klantgericht software kan worden ontwikkeld. Scrum wordt geassocieerd met Lean. Lean is een methode om te komen tot een efficiënt, op de klant gericht proces. Scrum kan daarom gezien worden als een geleand software-ontwikkelproces.

Veel bedrijven hebben, om bepaalde praktische problemen op te lossen, een eigen variant van Scrum geïmplementeerd. Daarbij wordt afbreuk gedaan aan bepaalde uitgangspunten van Scrum, met vaak een negatieve impact op de efficiency of de klantgerichtheid. Wat daarbij opvalt, is dat veel bedrijven daarbij uitgaan van een Scrum-proces en vervolgens kijken hoe dat passend gemaakt kan worden op de organisatie, in plaats van dat er gekeken wordt hoe het bestaande software-ontwikkelproces Lean gemaakt kan worden. Men redeneert dus vanuit een oplossing, in plaats vanuit het oorspronkelijke probleem. 

Een interessante vraag is daarom waar je op uit zou komen als je wel start bij het probleem, door het Lean-traject te doorlopen voor het software-ontwikkelproces. Kom je dan automatisch bij een Scrum-achtig proces, of kan je ook tot een andere oplossing komen?

Met Lean naar Scrum: de uitgangspunten

Om de Lean methode toe te passen op het software-ontwikkelproces, wordt in dit artikel uitgegaan van een fictief groot bedrijf. Dit bedrijf is opgesplitst in twee delen: Business en IT. De afdelingen van de business voeren het primaire proces uit en gebruiken daarbij software die door IT geleverd wordt. 

Elke afdeling aan de business kant heeft een manager die verantwoordelijk is voor een deel van het business proces. Die manager maakt afspraken met IT over het beheer van de software die wordt gebruikt en over wijzigingen op die software. De manager heeft geen eigen budget voor grote wijzigingen. Daarvoor moet hij een aanvraag indienen bij de project portfolio board van het bedrijf. 

Voor het managen van deze grote wijzigingen wordt de Prince2 projectaanpak gebruikt. De manager van de business vervult daarbij de rol van executive (opdrachtgever). De dagelijkse leiding van het software-ontwikkelproject is in handen van een projectmanager. 

De Lean methode bestaat uit vijf fases (principes genoemd):

  • Waarde
  • Waardestroom
  • Flow
  • Pull
  • Perfectie

In dit artikel worden deze vijf fases doorlopen voor het fictieve bedrijf.

Waarde

n de fase Waarde wordt de scope afgebakend, wordt bepaald wie de klant is en wat de eisen voor het product zijn. Als scope beperkt men zich in dit voorbeeld tot de grote wijzigingen die projectmatig worden uitgevoerd. Het proces voor kleine wijzigingen wijkt te veel af om die mee te nemen. Dat proces start conform Prince2 met het indienen van een projectmandaat door de opdrachtgever, en eindigt met geïmplementeerde software en een formele afsluiting in de vorm van een goedgekeurd ‘end of project report’. 

Het resultaat van een proces moet waarde hebben voor de klant. ‘Klant’ kent meerdere definities. In dit voorbeeld wordt de klant gedefinieerd als de persoon die om het product vraagt en ervoor betaalt: de manager van de business. Hij zal conform Prince2 de rol van executive (opdrachtgever) vervullen. De eindgebruiker is met deze definitief geen klant, maar is wel een stakeholder. De project portfolio board is ook geen klant, omdat hij geen opdracht geeft, maar alleen het budget beschikbaar stelt aan de manager.

De eisen aan het product zullen bij elk project anders zijn. Maar in alle gevallen hecht de klant aan een product dat zo snel mogelijk en zo goedkoop mogelijk wordt opgeleverd. En dat dat voldoet aan de afgesproken en verwachte kwaliteit.

Klant en scope bij Scrum

Scrum onderkent het begrip ‘klant’ niet. Er is wel een product owner, maar die maakt onderdeel uit van het team. Het Scrum-proces begint al met het verzamelen van de wensen (de ‘backlog’) door de product owner en het bepalen van de prioriteit van die wensen. De product owner is degene die daarmee bepaalt wat het ontwikkelteam gaat realiseren, vergelijkbaar met de manager in het voorbeeld. Alleen valt in het voorbeeld die processtap buiten scope, en bij Scrum erbinnen. Daarom lijkt het erop dat de stakeholder die wensen aanlevert, door Scrum als klant wordt gezien. 

Het Scrum-proces heeft ook een andere afsluiting. Het eindigt bij het opleveren van een ‘potentieel releasebaar product’; de daadwerkelijke implementatie valt buiten scope. Volgens Scrum is het aan de product owner om het product na het einde van de sprint te implementeren of niet, maar daar is geen processtap voor gedefinieerd. 

Waardestroom

n de tweede fase van de Lean methode, de Waardestroom, wordt het actuele proces uitgewerkt in een schema. Dit kan bijvoorbeeld in de vorm van een VSM (value stream mapping), die in vereenvoudigde vorm in dit artikel wordt gebruikt. 

Bij VSM wordt onderscheid gemaakt tussen de informatiestroom (bovenin) en de productiestroom (onderin). In deze informatiestroom zit de opdracht van de klant. Deze wordt doorvertaald naar de opdracht aan de productiestroom, en naar opdrachten aan de leverancier. De dagelijks aansturing wordt niet in het schema opgenomen. 

De productiestroom bestaat uit de processtappen die daadwerkelijk iets doen met het product dat wordt geleverd. Elke keer dat een tussenproduct wacht op verdere bewerking of besluitvorming, ontstaat er voorraad. Deze is in het schema door middel van een driehoek weergegeven.

Informatiestroom

Bij het software-ontwikkelproces in het voorbeeld bestaat de informatiestroom uit het opstellen van de verschillende beslisdocumenten en de besluiten daarover. Deze stroom begint met het besluit van de portfolio board over het mandaat dat door de executive is opgesteld. Daarna volgt een projectbrief en een PID. Na beiden moet een formeel besluit genomen worden door zowel de stuurgroep, waar de executive de voorzitter van is, als de project portfolio board. In het onderstaande schema (figuur 1) zijn omwille van de overzichtelijkheid die twee besluiten samengevoegd, maar in de praktijk zijn dat twee verschillende stappen, met een voorraad ertussen.

Aan het einde van het project volgt het opstellen van het end of project report (inclusief de lessons learned) en de decharge. Deze zijn ook bij de informatiestroom getekend.

Productiestroom

Na goedkeuring van de PID kan de daadwerkelijke productie beginnen. De goedkeuring is ook de trigger om de leverancier een opdracht te geven, bijvoorbeeld om projectleden te leveren. De productiestroom bestaat uit het ontwerpen, het ontwikkelen van de software, de nodige tests en het implementeren. Voor het gemak is er vanuit gegaan dat elke stap wordt uitgevoerd door een ander team en dat de volgende stap pas begint als de vorige is afgerond (waterval methode). Tussen de stappen ontstaat daardoor een voorraad. Het oplossen van bevindingen die tijdens de test gevonden worden, en de hertest die daarna nodig is, zijn voor de overzichtelijkheid niet ingetekend.

In een Lean-traject wordt het model uitgebreid met wachttijden, voorraadgrootte en doorlooptijden. Deze zijn weggelaten omdat die waardes voor het doel van dit artikel niet relevant zijn.

 

Flow

De derde fase is Flow. Hierbij wordt gekeken welke van de processtappen daadwerkelijk waarde toevoegen voor de klant en welke niet. De processen die geen waarde toevoegen, worden gezien als verspilling. Deze worden indien mogelijk geschrapt of geminimaliseerd. De processen die waarde toevoegen worden zo veel mogelijk vereenvoudigd en gestandaardiseerd.

Criterium om te bepalen of een processtap waarde toevoegt, is of het voor de klant meerwaarde heeft; dus of hij bereid is daarvoor te betalen. De beslisdocumenten en de besluitvorming daarover, leveren in principe geen waarde op voor de klant in de zin dat hij er geld voor over heeft. De tests leveren ook geen waarde op. De klant wil wel een goedwerkend product, maar hoe de leverancier dat borgt, maakt hem in principe niet uit. 

Kortom, om optimaal waarde toe te voegen, moet het opstellen van beslisdocumenten, de besluitvormingsactiviteiten en de tests worden voorkomen of geminimaliseerd. Het ontwerp, de softwareontwikkeling en de implementatie moeten worden vereenvoudigd en gestandaardiseerd. 

De informatiestroom

Om de besluitvormingsactiviteiten te minimaliseren, is de eerste stap om te kijken of het aantal niveaus van besluitvorming niet kan worden teruggebracht. In dit voorbeeld wordt besloten de project portfolio board te schrappen en worden met de manager aan het einde van het jaar afspraken gemaakt over het software-ontwikkelbudget voor grote wijzigingen voor het volgende jaar. Het hogere management kan dan nog steeds sturen, maar alleen op hoofdlijnen conform de reguliere rapportage en controlelijnen en niet op basis van beslisdocumenten van het project.

Tweede stap is het terugbrengen van het aantal beslisdocumenten (mandaat, projectbrief, PID en end of projectreport) en het verkorten van tijd die het kost om de documenten op te stellen. Een belangrijke besparing in de doorlooptijd kan bereikt worden door de planning niet volledig tot in detail uit te werken voor het volledige project. Dat betekent wel dat het risico op tegenvallers later in het project groter wordt. Om dat risico te mitigeren kan worden besloten dat projecten voortaan worden opgedeeld in deelproducten die elk op zichzelf eigen toegevoegde waarde hebben. Als gaandeweg het project blijkt dat de kosten te hoog worden, kan besloten worden het project voortijdig te stoppen, en zijn in ieder geval delen van de baten gerealiseerd. Prince2 biedt al de mogelijkheid om de executiefase te splitsen, maar daar wordt niet altijd gebruik van gemaakt.

Nog verder doorredenerend wordt besloten om het fenomeen ‘fases’ los te laten. Deze worden binnen Prince2 begrenst door een begin- en einddatum. Alle activiteiten binnen die periode vallen daarbij onder het faseplan. Er wordt gekozen deelproducten als de te managen eenheden te zien. Deze kunnen achter elkaar worden uitgevoerd, maar elkaar ook gedeeltelijk overlappen of zelfs geheel parallel lopen. 

In dit voorbeeld wordt gekozen om het project te managen middels twee beslisdocumenten: een overall plan van het hele project dat wordt geüpdate bij de start van elk deelproduct, en een detailplan per deelproduct. Het overall plan komt in plaats van de projectbrief en de PID. Elk detailplan, met het bijgewerkte overall plan, moet worden goedgekeurd door de stuurgroep.

De informatiestroom bij Scrum

Ook Scrum gaat er vanuit dat wensen met een grote impact (vaak ‘epics’ genoemd) zijn op te delen in deelproducten die elk afzonderlijk waarde toevoegen (vaak ‘user stories’ genoemd). Scrum gaat echter wel uit van fases (sprints), met een vaste doorlooptijd, van 2 tot 4 weken, waarbij een aantal van die deelproducten in hun geheel gerealiseerd worden. 

De beperkte tijdsduur van een sprint stelt eisen aan de grootte van de deelproducten. Daarom komt het geregeld voor dat de toegevoegde waarde te beperkt is om het deelproduct te implementeren. Zo heeft een inlogscherm wel toegevoegde waarde, maar zal het toch niet gebruikt worden als de rest van de applicatie nog niet klaar is.

Scrum heeft verder een eigen manier om de kosten in de hand te houden, namelijk door te werken met vaste teams. Zij gaat er namelijk vanuit dat de ontwikkelingen aan een applicatie continu door gaan tot de applicatie ‘end of life’ is. Er is dus voor een lange tijd werk, en dan is een vast team efficiënter dan telkens nieuwe projecten met een wisselende bemensing. 

Voor het management is het voordeel dat de kosten van te voren vast staan. De besluitvorming kan dan beperkt blijven tot de keuze van de wensen die als eerste moeten worden opgepakt. Nadeel is wel dat men niet tijdelijk kan opschalen of afschalen als daar aanleiding toe is.

De productiestroom

Nu besloten is om het project op te delen in deelproducten, richt men zich in ons voorbeeld op de productie van zo’n deelproduct. Hierboven is aangegeven dat men de ontwerp-, ontwikkel- en implementatie-activiteiten wil optimaliseren. De testactiviteiten wil men voorkomen of minimaliseren. Er wordt gestart met het laatste. 

Er wordt vanuit gegaan dat het niet mogelijk is om software foutloos te programmeren. Een test blijft dus nodig, maar tests kunnen wel geautomatiseerd worden. Doordat het project wordt opgedeeld in deelprojecten, die afzonderlijk getest worden, zal er ook vaker getest moeten worden en zal een goede automatische regressietest zich terugverdienen. 

Voor het optimaliseren van processen zijn verschillende mogelijkheden, zoals het samenvoegen van activiteiten, standaardiseren of automatiseren, het verkorten van de fysieke afstand tussen de activiteiten en het beperken of wegnemen van de voorraden tussen de activiteiten. Het meest optimale proces is volgens Lean de ‘one-piece-flow’, waarin het product in één keer, zonder wachttijden (voorraden), de verschillende stappen doorloopt. 

Ten aanzien van het software-ontwikkelproces zien we dat het ontwerp en de softwareontwikkeling steeds meer naar elkaar toe groeien. Veel ontwikkeltools bieden hulpmiddelen om schermen te ontwerpen, code te structureren en de rekenregels te definiëren. Zelfs op een voor een eindgebruiker begrijpelijke manier. Een apart ontwerp met schermontwerp en uitgeschreven rekenregels is dan niet nodig. 

Bij test-driven development, waarbij je vooraf je testgevallen definieert, groeien ook de ontwerp- en testactiviteiten naar elkaar toe. Men besluit de verschillende disciplines samen te voegen in één team. Ze werken daarin parallel aan hetzelfde deelproduct, in plaats van na elkaar. Daardoor verdwijnen de voorraden tussen de oorspronkelijke stappen. Met de introductie van automatische installatie van software, wordt ook het implementatieproces verbeterd. De andere aspecten van de implementatie (communicatie, training, datamigratie e.d.) blijven wel nodig. 

De productiestroom bij Scrum

Scrum gaat uit van dezelfde uitgangspunten: een multidisciplinair team realiseert de deelproducten binnen de fase (sprint). De teamleden worden echter geacht binnen het team meerdere rollen te kunnen vervullen, en heten daarom allemaal hetzelfde: ontwikkelaar. 

In een sprint pakt het team meerdere deelproducten op, die niet aan elkaar gerelateerd hoeven zijn. Hoeveel deelproducten ze oppakken hangt af van hoeveel ze er af denken te krijgen in die sprint. Een ander belangrijk verschil met het resultaat van het voorbeeld Lean-traject is dat er hier wel twee voorraden kunnen ontstaan. Namelijk als deelproducten voor het einde van de sprint al klaar zijn, en na de sprint als de product owner besluit het deelproduct niet gelijk te implementeren. 

Pull

Na de fase Flow, volgt de vierde fase: Pull. Tijdens deze fase wordt gekeken hoe het proces dusdanig georganiseerd kan worden dat het productieproces start op basis van een concrete vraag van de klant, met zo weinig mogelijk voorraden. 

De klant trekt als het ware het product door de productiestraat (‘pull’). Dit in tegenstelling tot ‘push’, waarbij op voorraad wordt geproduceerd en de processtap de halffabricaten als het ware naar de volgende processtap duwen, of die ze op dat moment nodig heeft of niet. Een belangrijk aspect bij pull is het proberen de vraag zo gelijkmatig mogelijk te krijgen. Een sterk fluctuerende vraag moet namelijk worden opgevangen door voorraden of door flexibele capaciteit, wat inefficiënt is.

In ons voorbeeld was er al sprake van pull. Softwareontwikkeling gebeurde reeds op basis van een concrete wens van de opdrachtgever. Het nivelleren van de vraag is lastiger. De manager in ons voorbeeld heeft een groot wijzigingsverzoek en dat heeft hij niet elk jaar. Hij begrijpt echter wel het belang van een vaste bezetting voor de duur van het project. Hij zal daarom accepteren dat niet alle deelproducten tegelijk starten en de werkzaamheden gelijkmatig over de periode worden verdeeld. 

Echter, het tijdelijk uitbreiden van het team of het hebben van meerdere parallelle teams, wordt niet uitgesloten. Ook het tijdelijk of parttime inzetten van medewerkers voor specifieke werkzaamheden, is geen probleem. Verder wordt aan het pull principe voldaan door bij elke start van een deelproduct rekening te houden met de wensen en prioriteiten op dat moment.

Pull bij Scrum

Ook Scrum gaat uit van het pull mechanisme. Ten opzichte van het voorbeeld is de mogelijkheid om in te spelen op gewijzigde wensen groter, doordat er na elke sprint de mogelijkheid is de prioriteiten aan te passen. Deze sprints zullen zoals gezegd korter zijn dan de realisatietijd van een deelproduct in ons voorbeeld. Scrum gaat echter niet uit van het egaliseren van de omvang van de vraag, maar van het egaliseren van de omvang van het aanbod. Doordat er een vast team is, is het niet mogelijk in de spelen op pieken en dalen van de vraag. 

Perfectie

In de laatste fase van de Lean methode, Perfectie, wordt gekeken naar het continue verbeteren van het proces.

In Prince2 zit de evaluatie aan het einde van het project. De lessons learned die daar worden opgesteld zijn voor het project zelf niet meer bruikbaar (dat is al afgerond). Door het opdelen van het project in deelproducten, kunnen de lessons learned nu wel meegenomen worden in de planning en de realisatie van het volgende deelproduct. Deze lessons learned worden daarom niet apart met de stuurgroep besproken.

Perfectie bij Scrum

Bij Scrum wordt na elke sprint een ‘review’ en een ‘retrospective’ gehouden. Bij de review wordt met de stakeholders gekeken naar het product in plaats van naar het proces. De review kan leiden tot wijzigingen in de wensenlijst of de prioritering. Tijdens de retrospective kijkt het team hoe het ontwikkelproces verbeterd kan worden. Deze verbeteringen worden vervolgens gelijk geïmplementeerd.

Met Lean naar Scrum: de samenvatting

Na het uitvoeren van het Lean-traject ziet de VSM van het systeem-ontwikkelproces van het voorbeeld er als volgt uit:

De vergelijkbare VSM van Scrum is opgenomen in figuur 3. Het bijwerken van de backlog en het uitvoeren van refinements worden in Scrum niet als activiteiten (‘events’) gezien, maar worden wel genoemd. Zoals al eerder aangeven, wordt in Scrum de implementatie niet genoemd. Voor de volledigheid zijn die wel opgenomen.

De overeenkomsten tussen het voorbeeld en Scrum

Het proces na het Lean-traject uit het voorbeeld en het Scrum-proces hebben een groot aantal overeenkomsten:

  • Decentrale en korte besluitvorming, met eenvoudige mogelijkheid tot bijsturing;
  • Opdelen in deelproducten met toegevoegde waarde;
  • Uitvoering in multidisciplinaire teams in plaats van een team per discipline.

De verschillen tussen het voorbeeld en Scrum

Tussen het geleande proces uit het voorbeeld en Scrum, zitten ook een aantal verschillen:

  • De scope van het Lean-traject was een grote wijziging die normaal in een project wordt uitgevoerd, die per definitie eenmalig is. Scrum onderkent geen projecten, maar gaat uit van een continue stroom aan wijzigingsverzoeken. Scrum maakt ook geen onderscheid tussen grote en kleine wijzigingen.
  • Het uitgangspunt in het voorbeeld was dat de opdrachtgever de klant is. Scrum spreekt niet van klanten, maar ziet de opdrachtgever (in de vorm van de product owner) als onderdeel van het team, en ziet het verzamelen en prioriteren van alle wijzigingsverzoeken binnen de scope. De stakeholders die input leveren, kun je daarbij zien als klant.
  • In het voorbeeld wordt de planning opgesteld door een projectmanager en neemt de manager besluiten. Bij Scrum bepaalt de product owner de prioriteit en neemt het team als geheel besluiten over wat er in een sprint gerealiseerd kan worden (op basis van de prioriteit en de beschikbare capaciteit). Die product owner ontleent daarbij zijn bevoegdheid niet aan zijn plaats in de hiërarchie, zoals de manager, maar aan zijn rol. 
  • Het uitgangspunt in het voorbeeld was dat een deelproduct ook daadwerkelijk geïmplementeerd wordt en op zichzelf toegevoegde waarde heeft. Bij Scrum heeft elk deelproduct wel toegevoegde waarde, maar niet noodzakelijk op zichzelf. Bovendien worden er verschillende deelproducten samengevoegd in een sprint. Er ontstaan daardoor twee voorraden: de deelproducten die voor het einde van een sprint worden afgerond, en de deelproducten die na het einde van een sprint niet gelijk geïmplementeerd worden.
  • In het voorbeeld wordt per deelproduct gepland. Deze kunnen naast elkaar worden gerealiseerd en kunnen ook verschillende doorlooptijden hebben. Bij Scrum wordt altijd voor een vaste periode (sprint) gepland. Er worden in blogs verschillende argumenten genoemd waarom Scrum vasthoudt aan een vaste, korte periode. Zo zou een korte periode voor teamleden beter te overzien zijn en leiden tot meer focus.
  • In het voorbeeld is de teamgrootte niet constant, al wordt daar wel naar gestreefd. Bij Scrum is hij wel constant. 

Bovengenoemde verschillen worden grotendeels verklaard door de aannames en keuzes die in het Lean-traject zijn gemaakt. Er hadden ook andere aannames gedaan kunnen worden, of andere keuzes gemaakt. In het voorbeeld zijn een aantal ingrijpende wijzigingen in het proces opgenomen. In de praktijk zouden die mogelijk niet allemaal in één Lean-traject worden gerealiseerd. Scrum gaat op een aantal punten echter nog verder dan het voorbeeld, zoals het opnemen van alle wijzigingen in scope, het samenvoegen van alle rollen binnen het ontwikkelteam en het loslaten van planningen. Op andere vlakken maakt Scrum gewoon een andere keuze, zoals het gebruik van fases met een vaste lengte. 

Met Lean naar Scrum: de conclusie

De conclusie is dat bij het uitvoeren van een Lean-traject op het software-ontwikkelproces vele keuzes worden gemaakt. Elke keuze heeft voor- en nadelen. Zowel met betrekking tot het resultaat als tot de haalbaarheid binnen de organisatie. Het resultaat van het traject is afhankelijk van die keuzes. Een Scrum-proces is slechts één van de mogelijke resultaten. De uitgangspunten van Scrum zijn op sommige punten zo verschillend ten opzichte van traditioneel projectmanagement en de watervalmethodiek, dat dit framework ongetwijfeld niet na één Lean-traject ontstaan is, maar dat daar verschillende slagen voor nodig waren.

Scrum is echter geen doel op zich. Een geleand proces is het doel. Als Scrum binnen een organisatie (nog) niet past en er te veel concessies moeten worden gedaan, is het dus wellicht beter om een Lean-traject uit te voeren en daarbij keuzes te maken die beter passen binnen de organisatie, dan om Scrum aan te passen aan de organisatie en daarbij mogelijk de voordelen teniet te doen.

 

 

Accedis B.V.
T 023 562 7555

Adres:
Siriusdreef 43
2132 WT Hoofddorp


twitter   linkedin

Routebeschrijving

  Privacyverklaring