Scrum en Lean: dezelfde ingrediënten?

Scrum en Lean komen qua beleving uit dezelfde hoek, namelijk die van optimaliseren, alleen die dingen doen die bijdragen, etc. Maar juist de exacte vergelijking/overeenkomsten waren voor mij een onbekende. Ik ben zelf een actief beoefenaar van Scrum, heb de voordelen ervaren en een aantal valkuilen gezien. Ook de 'aha erlebnis' bij anderen heb ik bij anderen zien en laten ontstaan. Erg leuk om te zien.

Maar ik kon tot voor kort niet uitleggen wat de overeenkomsten tussen Scrum en Lean waren. Hieronder meld ik de ontdekkingen die ik heb gedaan. Mocht ik iets vergeten zijn en er naast zitten, dan hoor ik het graag.

Allereerst de principes. Na enig speurwerk kwam ik tot het volgende rijtje:

• De klant staat centraal
• De waardestroom verbeteren
• Flow in stand houden
• Een pullproductiesysteem, dus vraaggestuurd
• Naar perfectie streven
• Mensen respecteren

Met name vanuit met Scrum ervaring zie ik veel principes in praktijk terugkomen:

• Binnen Scrum bepaald de klant wat er moet gebeuren en in welke volgorde. Dus deze staat zeker centraal. Als team ben je alleen maar bezig met hetgeen de klant vraagt. Dus ook vraaggestuurd.
• Het is belangrijk om de waardestroom te verbeteren, dus onvolkomenheden eruit halen. Bijvorbeeld door de actiepunten vanuit de Retrospective te implementeren. Eigenlijk streven we hierbij dus naar perfectie. En dan maakt het niet uit of het gaat om proces, inhoud of relatie.
• De flow in stand houden doen we vooral door met elkaar te blijven communiceren en afstemmen. In de Daily Standup worden de activiteiten op elkaar afgestemd, verstoringen benoemd en door de Scrum Master weggemasseerd.
• Belangrijkste is mensen respecteren. Je moet het immers samendoen en dit houdt in dat je elkaar respecteert en rekening met elkaar houdt.

Dus qua principes zien we dat tussen Scrum en Lean wel een grote gemeenschappelijke deler zit.

Nog wel even door zoomen op 'waardestroom'. Wat is dit precies? Volgens mij houdt dit in dat je continue waarde probeert toe te voegen door activiteiten te verrichten die:

• ervoor zorgen dat je product of dienst transformeert
• je doet het omdat de klant bereid is ervoor te 'betalen'
• je doet het in één keer goed.

Als ik bovenstaande door vertaal naar Scrum dan zie je dat je continue activiteiten onderneemt die bijdragen (waardestroom verbeteren), je doet het omdat de klant het wil (die staat centraal, vraagt erom en wil ik dus voor 'betalen') en we doen het in één keer goed.

Kenmerk van Scrum en Lean is het woord continue, dus een cyclische beweging die iedere keer opnieuw begint. Als we naar beide manieren van werken kijken zie we dat beide een cyclisch proces hebben die bestaat uit stappen, namelijk:

Stappen binnen Scrum (ervan uitgaande dat we een goede product backlog hebben:

1. Sprintplanning: Een aantal user stories wordt uit de backlog gehaald, inhoudelijk doorgenomen, ingeschat en uitgewerkt
2. Sprint: de werkzaamheden vanuit de Sprint backlog worden opgepakt en uitgevoerd
3. Sprintreview: het resultaat van de Sprint wordt aan de klant en rest van de wereld getoond
4. Implementatie: bij akkoord kan het resultaat worden uitgerold (bijvoorbeeld naar productie)

Stappen binnen Lean (ook hierbij ervan uitgaande dat een lijst met verbeterpunten hebben:

1. Plan: Een verbeterpunt wordt opgepakt
2. Do: Een verbeterpunt wordt ontrafeld, verbeteracties worden opgezet
3. Check: Op kleine schaal wordt gecontroleerd of het daadwerkelijk tot verbetering gaat leiden
4. Act: Bij een positief resultaat worden de verbeteracties in de organisatie/proces geimplementeerd

In onderstaande figuur is de vergelijking in de vorm van een tabel weergegeven. Hierbij is ook aandacht besteed aan de start van een traject op basis van Scrum of Lean.

Beide manieren van werken gaan dus uit van een overzicht of lijst met wensen/verbeteringen. Bij Scrum gaat het om features van een product of dienst. Bij Lean om issues die niet goed lopen in het proces/organisatie. Ook is het zo dat als het bij 3 (Check/Sprintreview) tegenvalt, dan kan in een volgende cyclus gesleuteld worden om wel een positief resultaat te verkrijgen.

Ook de omstandigheden qua werken zijn volgens mij overeenkomstig:

• Scrum: ik heb ervaren dat als je in staat bent het team qua locatie bij elkaar te zetten, dat samenwerking hier maximaal tot uiting kan komen. Ook qua tijdsduur (periode van 1 - 4 weken) en de daaruit rollende cadans qua sprints is een feit.
• Lean: In de literatuur die ik gelezen heb wordt geadviseerd om de mensen samen te laten komen en in de vorm van workshops de verbeterpunten op te pakken en uit te werken. Ook kom je bij Lean waves tegen. Feitelijk golven van verbetering in een vaste frequentie (cadans).

Dus eigenlijk kun je stellen dat inderdaad (zoals reeds bedacht en bekend) Scrum en Lean sterk aan elkaar gelieerd zijn en dat ze eenzelfde structuur en werkwijze kennen. Veel overeenkomstige ingrediënten.

Een groot verschil zit volgens mij in de volwassenheid: Lean is reeds langgeleden bedacht en in de loop van de tijd voorzien van een goed gevulde gereedschapskist. Scrum is nog vol in ontwikkeling, maar zal ook naar verloop van tijd een goed gevulde gereedschapskist gaan krijgen. Het zou mij niet verbazen als ook de gereedschappen goed uitwisselbaar zijn (en dan vooral van Lean naar Scrum uiteraard).

Een ander verschil is dat mijn gevoel zegt dat Scrum meer een wijze van organiseren is en dat Lean veel meer betrekking heeft op inhoud (bedrijfsprocessen, werkprocessen, productie). Op zich wel grappig, want dat zou ook kunnen betekenen dat ze elkaar kunnen versterken (Scrumboard bij Lean, Daily Standup, Retrospective op samenwerking). Wellicht goed om hier later eens op terug te komen.

Changes in het Agile beheerproces

In de vorige post heb ik het "Agile beheerproces" beschreven. De essentie van deze post is dat het beheerproces geen statisch geheel is, maar een repeterend karakter kent. Belangrijk hierbij is dat dit de manier is om om te gaan met verandering. De omgeving van een willekeurig bedrijf en daarmee verandert ook de dienstverlening.

Voorbeelden van verandering zijn:

• de wens van de eindklant veranderd (smaak, kwaliteit, etc.);
• regelgeving vanuit de overheid wordt aangescherpt;
• hogere kwaliteitseisen vanuit uw branchevereniging;
• uw dienstverlening met aan vernieuwde certificering voldoen;
• etc.

Wat de reden ook is, u moet op veranderingen in kunnen spelen. De snelheid van veranderen is hierbij belangrijk. Indien uw concurrenten binnen twee maanden kunnen inspelen op nieuwe trends, waar u langere tijd nodig heeft, kan dit voor u een nadelige situatie opleveren.

Een aantal belangrijke ingrediënten voor snelheid van veranderen zijn:

• Uw verandercapaciteit;
• Uw budget;
• De flexibiliteit van uw bedrijfsprocessen.

In deze post gaan we dieper in op de verandercapaciteit. We staan eerst stil bij het proces waarin verandering tot stand moet komen. Vaak bent u onderdeel van een grotere organisatie (bijvoorbeeld een verzekeraar met meerdere producten). En stel u bent verantwoordelijk voor 1 van deze producten. Uw collega-afdelingen zullen net als u ook wensen/behoeften hebben. U wilt dus allemaal inspelen op veranderingen in de markt.

Omdat u (waarschijnlijk) niet de enige bent binnen uw organisatie met wensen/behoeften, moeten er goede spelregels worden afgesproken zodat een ieder op het juiste moment aan de beurt komt. Zodra de spelregels helder zijn, hebben we ook een scheidsrechter nodig die op basis van heldere criteria het totaal aan wensen/behoeften prioriteert. Deze scheidsrechter zal vaak een raad van wijze mannen en vrouwen zijn, die met verstand van zaken oordelen over de wijzigingen.

De raad van wijze mannen en vrouwen kent in praktijk vele namen, maar in deze post noem ik het CAB (Change Advisory Board). Het prioriteren zal veelal op basis van Business Value gaan. In een toekomstige post wordt ingegaan op de definitie van Business Value.

Figuur 1. Proces voor veranderingen prioriteren

en doorvoeren

Op basis van prioriteit wordt bepaald welke verandering eerst opgepakt moet worden. De hoeveelheid wijzigingen die opgepakt kunnen worden, zijn afhankelijk van:

1. de omvang van iedere individuele wijziging

2. de totale omvang van de verandercapaciteit van een organisatie.

De omvang van iedere wijziging moet apart bepaald worden. Dit kan bijvoorbeeld uitgedrukt worden in uren. Bijvoorbeeld wijziging X kent:
- ontwerp: 40 uren

- bouw: 75 uren
- test: 35 uren

- ...

De verandercapaciteit van een bedrijf moet in soortgelijke eenheden worden uitgedrukt overeenkomstig de eenheden van de wijzigingen. Vervolgens kunnen net zoveel wijzigingen worden ingepland als er ruimte is in de verandercapaciteit.

Door continue uw verandercapaciteit te meten (en te weten), kan de doorstroming van wijzigingen geoptimaliseerd worden. Het proces van het prioriteren, beoordelen en implementeren van wijzigingen is weergegeven in figuur 1. Wel moet gezegd worden dat de weergave in deze post en in figuur 1 een vereenvoudigde weergave betreft, want de praktijk is weerbarstiger. Bijvoorbeeld omdat er ook verstoringen optreden, verandercapaciteit variabel is (ziekte, verlof, verloop) en niet alle wijzigingen dezelfde inspanning vergen.

Toch kan op basis van bovenstaande gesteld worden, dat om het proces van doorvoeren van (ICT) wijzigen soepel te laten verlopen de volgende ingrediënten voor handen moeten zijn:
- Goed ingericht proces voor beoordelen en sturen van verandering;
- Duidelijke spelregels om de keur van wensen te prioriteren;
- Omvang van iedere individuele wijziging;
- De omvang van verandercapaciteit.

In een toekomstige post ga ik in op de eenheden van het uitdrukken van verandercapaciteit.

Agility in uw beheerproces

Veel processen in uw bedrijf zijn repeterend. Belangrijk in dergelijke processen is een stabiel karakter en een betrouwbaar verloop. Om de mensen en de processen in deze flow te brengen is het belangrijk dat u hierop stuurt. Het gaat niet vanzelf!

Eén van deze processen is uw IT-beheerproces. Een stabiel en betrouwbaar karakter van een IT-beheerproces vergt bovenal duidelijkheid en inzichtelijkheid. Het gaat erom dat men weet wat er gaat komen en hoe dit zich verhoudt tot het grote proces. Maak dus uw proces inzichtelijk in een voor iedereen begrijpbare taal. Dus niet IT termen, maar de taal van de business. Zij zijn immers gebaat bij veranderingen. Dit brengt geld in het laatje.

Naast een betrouwbaar proces is het ook belangrijk dat u de inspanningen van uw mensen waarde blijven toevoegen. Waarde is vooral kennis die in de loop van de tijd wordt opgebouwd. Het kan hierbij gaan om inhoudelijke kennis van IT componenten, veranderingen in uw bedrijfsproces en vooral de samenwerking intensiveren. En bovenal: door het repeterende karakter bent u in staat snel en eenvoudig in te spelen op veranderingen: ook in uw ICT landschap.

Het Agile beheerproces kan u hierbij helpen. Dit is weergegeven in figuur 1.

Figuur 1. Agile beheerproces

Dit proces is erop gericht om veranderingen in uw bedrijfsproces te garanderen door structurele aanpassing in specificaties, IT-componenten en ondersteunend beheer. Op zodanige wijze vertaald dat u als klant het gehele traject kunt volgen en kunt bijsturen indien nodig.

Uw ICT proces wordt inzichtelijk gemaakt en de samenwerking wordt intensiever en daardoor leuker. Dus meer resultaat op een leuke maar gezamenlijke manier.

In een mijn volgende update ga ik (in meer detail) in op de verschillende aspecten en voordelen van dit model.

De Agile organisatie

Op dit moment werken we aan een concept om een (willekeurige dienstverlenende) organisatie zo in te richten dat deze soepel kan inspelen op veranderingen. Dit kunnen veranderingen zijn in de markt, gewijzigde regelgeving of gewijzigd beleid.

Met ons concept zijn we in staat om samen met u, verandering in het DNA van uw organisatie te implementeren. Met verandering omgaan, structureel veranderen en dit borgen zijn de belangrijkste ingrediënten. Ons streven is om uw organisatie Agile te maken!

Wilt u meer weten? Neemt u contact met ons op via onderstaande contactinformatie.

Tel : +31 (0) 6 57 18 55 90

Email : informatie@NuanceinIT.nl

IT projecten complex?

Enige tijd terug las ik in Computable (online) een artikel met als titel:
"Regisseren ICT is net zo complex als registeren film". Wat mij met name in het artikel triggerde was de mededeling dat een project manager een soort duizendpoot moet zijn tegenwoordig. Dit onderwerp houdt mij ook al enige tijd bezig.

In een grijs verleden ben ik als programmeur gestart in de IT en via implementatie consultant door geëevalueerd tot managing consultant. Ik houd me tegenwoordig bezig met het invullen van (functionele) business vraagstukken.

Daar waar mijn bezigheden voorheen gericht waren op een applicatie die als een monoliet (zeg maar applicatie uit één stuk) was opgezet, ben ik me meer gaan bezig houden met een applicaties opgebouwd uit services (SOA). Eén van de aspecten die bij een dergelijke implementatie om de hoek komen kijken, is de toename van verschillende IT bouwstenen. Allemaal goed in hun eigen toepassing. Voorbeelden zijn:

- Java voor de meest uiteenlopende intelligente verhandelingen
- SQL voor gegevensbevraging
- database voor opslag
- Enterprice Service Bus voor berichtroutering
- Business Rule Engine voor beslisregels
- Etc.

Dit hoeft uiteraard niet, maar kan wel handig zijn. Er is immers zoveel te verkrijgen op de markt (zowel op basis van licentie als open source). Om met deze verscheidenheid aan bouwstenen één werkend geheel te verkrijgen, vereist veel expertise. En dit moet je vaak samen brengen door verschillende mensen erbij te betrekken. Natuurlijk op twee assen:

1. Horizontaal: verschillende techneuten (per IT bouwsteen één)
2. Verticaal: business/architectuur via functioneel naar techniek

En dat alles ook nog in harmonie met elkaar...

In lijn met bovenstaande weet ik door eigen ervaring dat in dergelijke onderwerpen bar weinig vanzelfsprekend is. Bij het uitwerken van functionele vraagstukken naar te implementeren oplossingen, moet je scherp blijven tot de laatste punt. Je moet je continue afvragen of een ieder het snapt, is er al iemand afgehaakt, hebben we het over hetzelfde, etc. En om dit jezelf af te kunnen vragen moet je inhoudelijk op de hoogte zijn van de diversiteit aan onderwerpen.

Mijn conclusie:
Kortom je moet een duizendpoot zijn (ook als je (nog) geen project manager bent).